Android性能优化的一些记录

一直不清楚性能优化到底优化的是什么，特做个记录
网上的一些观点：
1、Android的渲染机制
2、内存优化
3、电量优化
4、流量优化
（可能还有其他的待补充）

一、Android的渲染机制

大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能。从设计师的角度，他们希望App能够有更多的动画，图片等时尚元素来实现流畅的用户体验。但是Android系统很有可能无法及时完成那些复杂的界面渲染操作。

引起性能问题的一个很重要的方面是因为过多复杂的绘制操作。Overdraw(过度绘制)描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次的UI结构里面，如果不可见的UI也在做绘制的操作，这就会导致某些像素区域被绘制了多次。这就浪费大量的CPU以及GPU资源。

二、内存优化

Memory Churn内存抖动，内存抖动是因为大量的对象被创建又在短时间内马上被释放。
内存泄漏，内存泄漏指的是那些程序不再使用的对象无法被GC识别，这样就导致这个对象一直留在内存当中。

三、电量优化

我们应该尽量减少唤醒屏幕的次数与持续的时间，使用WakeLock来处理唤醒的问题，能够正确执行唤醒操作并根据设定及时关闭操作进入睡眠状态。

某些非必须马上执行的操作，例如上传歌曲，图片处理等，可以等到设备处于充电状态或者电量充足的时候才进行。

触发网络请求的操作，每次都会保持无线信号持续一段时间，我们可以把零散的网络请求打包进行一次操作，避免过多的无线信号引起的电量消耗。

以上1、2、3内容来源于：http://hukai.me/android-performance-patterns/

四、流量优化

有的说法有这个优化，觉得有道理就加进来了

5、一些其他优化

5.1 Android应用String/StringBuilder/StringBuffer优化建议

一个关于String和StringBuffer的对比例子：

//性能差的实现String str1 = "Name:";String str2 = "GJRS";String Str = str1 + str2;//性能好的实现String str1 = "Name:";String str2 = "GJRS";StringBuffer str = new StringBuilder().append(str1).append(str2);

通过这个例子可以看出来，String对象（记得是对象，不是常量）和StringBuffer对象的主要性能区别在于String对象是不可变的，所以每次对String对象做改变操作（譬如“+”操作）时其实都生成了新的String对象实例，所以会导致内存消耗性能问题；而StringBuffer对象做改变操作每次都会对自己进行操作，所以不需要消耗额外的内存空间。

一个关于String和StringBuffer的对比例子：

//性能差的实现StringBuffer str = new StringBuilder().append("Name:").append("GJRS");//性能好的实现String Str = "Name:" + "GJRS";

在这种情况下你会发现StringBuffer的性能反而没有String的好，原因是在JVM解释时认为
String Str = “Name:” + “GJRS”;就是String Str = “Name:GJRS”;，所以自然比StringBuffer快了。

可以发现，如果我们拼接的是字符串常量则String效率比StringBuffer高，如果拼接的是字符串对象，则StringBuffer比String效率高，我们在开发中要酌情选择。当然，除过注意StringBuffer和String的效率问题，我们还应该注意另一个问题，那就是StringBuffer和StringBuilder的区别，其实StringBuffer和StringBuilder都继承自同一个父类，只是StringBuffer是线程安全的，也就是说在不考虑多线程情况下StringBuilder的性能又比StringBuffer高。

5.2 Android应用OnTrimMemory()实现性能建议

OnTrimMemory是Android 4.0之后加入的一个回调方法，作用是通知应用在不同的情况下进行自身的内存释放，以避免被系统直接杀掉，提高应用程序的用户体验（冷启动速度是热启动的2~3倍）。系统会根据当前不同等级的内存使用情况调用这个方法，并且传入当前内存等级，这个等级有很多种，我们可以依据情况实现不同的等级。

5.3 Android应用HashMap与ArrayMap及SparseArray优化建议

在Android开发中涉及到数据逻辑部分大部分用的都是Java的API（譬如HashMap），但是对于Android设备来说有些Java的API并不适合，可能会导致系统性能下降，好在Google团队已经意识到这些问题，所以他们针对Android设备对Java的一些API进行了优化，优化最多就是使用了ArrayMap及SparseArray替代HashMap来获得性能提升。

5.4 Android应用ContentProviderOperation优化建议

ContentProvider是Android应用开发的核心组件之一，有时候在开发中需要使用ContentProvider对多行数据进行操作，我们的做法一般是多次调运相关操作方法，殊不知这种实现方式是非常低性能的，取而代之的做法应该是使用批量操作，具体为了使批量更新、插入、删除数据操作更加方便官方提供了ContentProviderOperation工具类。所以在我们开发中遇到类似情景时请务必使用批量操作，具体的优势如下：

1、所有的操作都在一个事务中执行，可以保证数据的完整性。
2、批量操作在一个事务中执行，所以只用打开、关闭一个事务。
3、减轻应用程序与ContentProvider间的多次频繁交互，提升性能。

可以看见，这对于数据库操作来说是一个非常有用的优化措施，烦请务必重视（我们项目优化过，的确有很大提升）。

5.5 Android应用其他逻辑优化建议

关于API及逻辑性能优化其实有多知识点的，这里无法一一列出，只能给出一些重要的知识点，下面再给出一些常见的优化建议：

1、避免在Android中使用Java的枚举类型，因为编译后不但占空间，加载也费时，完全没有static final的变量好用、高效。

2、Handler发送消息时尽量使用obtain去获取已经存在的Message对象进行复用，而不是新new Message对象，这样可以减轻内存压力。

3、在使用后台Service时尽量将能够替换为IntentService的地方替换为此，这样可以减轻系统压力、省电、省内存、省CPU占用率。

4、在当前类内部尽量不要通过自己的getXXX、setXXX对自己内部成员进行操作，而是直接使用，这样可以提高代码执行效率。

5、不要一味的为了设计模式而过分的抽象代码，因为代码抽象系数与代码加载执行时间成正比。

6、尽量减少锁个数、减小锁范围，避免造成性能问题。

7、合理的选择使用for循环与增强型for循环，譬如不要在ArrayList上使用增强型for循环等。

以上5的类容来源于：http://blog.csdn.net/yanbober