Android对于性能优化方面主要有一下几方面理解:
第一、页面的绘制
- 简化页面UI结构,复杂的UI布局会导致大量View重叠,出现过度绘制的可能性比较大,要避免布局嵌套过多,例如一般情况下,优先使用LinearLayout布局。
- 复用背景色,例如如果父布局和子View背景色是相同的,只需要父布局设置背景色即可,子View不用设置。
第二、布局的优化
- 布局的选择,能满足需求的情况下优先选择
LinearLayout
,因为RelativeLayout
在measure
会比LinearLayout
多出一次,
即使LinearLayout
使用了weight
后,性能依然会比RelativeLayout
好 - 边距的设置,
RelativeLayout
的measure
过程中,如果出现子View和布局本身高度不同时候,还会触发measure
过程,解决方法很简单,使用padding
代替marigin
- 复用布局,include
- 延迟加载,ViewStub
- 合并布局层级,merge
- 尽可能少用wrap_content。wrap_content 会增加布局 measure 时计算成本,在已知宽高为固定值时,不用wrap_content 。
- 删除控件中无用的属性。
第三.使用增强型循环语法
增强的for循环(有时也称为“for-each”循环)可用于实现Iterable接口和数组的集合。 使用集合,分配一个迭代器来对hasNext()和next()进行接口调用。 使用ArrayList,手写的计数循环速度大约比for-each快3倍(有或没有JIT),但对于其他集合,增强型循环语法将完全等同于显式迭代器使用。
有几种方法来迭代数组:
static class Foo {
int mSplat;
}
Foo[] mArray = ...
public void zero() {
int sum = 0;
for (int i = 0; i < mArray.length; ++i) {
sum += mArray[i].mSplat;
}
}
public void one() {
int sum = 0;
Foo[] localArray = mArray;
int len = localArray.length;
for (int i = 0; i < len; ++i) {
sum += localArray[i].mSplat;
}
}
public void two() {
int sum = 0;
for (Foo a : mArray) {
sum += a.mSplat;
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
zero()是最慢的,因为JIT不能优化通过循环的每次迭代获得数组长度一次的成本。
one()更快。 它将所有内容都拉到局部变量中,避免查找。 只有阵列长度提供了性能优势。
对于没有JIT的设备,two()是最快的,并且对于具有JIT的设备与one()不可区分。 它使用Java编程语言
1.5
版中引入的增强型for循环语法。
所以,您应该默认使用增强型for循环,但考虑一个手写的计数循环,用于性能关键的ArrayList迭代(因为ArrayList的手写的计数循环比for-each快)。
第四、SharedPreferences的写入操作
写操作比读操作复杂一些,向SharedPreferences
写入数据时候,有commit
和apply
两个方法。
- commit方法,直接将数据同步写入磁盘
- apply方法,先将数据写入内存,再异步写入磁盘
commit和apply方法区别在于同步写入和异步写入,以及是否需要返回值。在不需要返回值的情况下,使用apply方法可以极大的提高性能。
在使用lint静态扫描代码时候,会建议使用apply
去替代commit
,说明官方也是支持使用apply
方法的。
但是!!!
并不是是说apply不会阻塞到主线程,它也有可能会阻塞到主线程。详情请看这篇文章SharedPreferences调用导致的ANR分析。
使用apply方法时候,会向QueuedWork
队列中添加一个等待写入操作完成的线程,只有当写入操作完成后,才会从QueuedWork
将等待线程线程移除掉。
而主线程中,Service的启动和stop
以及Activity的onPause()
和onStop()
生命周期都会等待其他异步线程完成,才会继续执行。
例如停止Service的时候代码如下(ActivityThread类中):
private void handleStopService(IBinder token) {
···
QueuedWork.waitToFinish(); // 等待其他异步线程完成
···
}
可以看到,如果使用apply方法写入大量复杂数据,确实有可能会阻塞到主线程,甚至可能导致ANR。
优化方法:
- 复杂数据
- 即时性较弱(距离下次使用时间较长),新建子线程使用commit方法,防止阻塞到主线程
- 即时性较强,可以考虑直接放在内存中
- 简单数据,使用apply方法
第五、获取设备&应用基本信息
比如说包名、IMEI信息等等,是比较耗时的操作,可以进行一些优化。
- 固定信息获取采用缓存策略,例如版本号、版本名称、手机mac地址、运营商信息等等,一次获取,缓存到内存,下次直接使用
- 不部分不固定信息,例如网络情况(2G/3G/4G/WIFI),可以采用监听网络变更方式,来即时更新网络情况
- 其他不固定信息,比如基站信息,只能每次获取
第六、减少安装包大小的常用方案
- 代码混淆。使用proGuard 代码混淆器工具,它包括压缩、优化、混淆等功能。
- 资源优化。比如使用 Android Lint 删除冗余资源,资源文件最少化等。
- 图片优化。比如利用 AAPT 工具对 PNG 格式的图片做压缩处理,降低图片色彩位数等。
- 避免重复功能的库,使用 WebP图片格式等。
- 插件化。比如功能模块放在服务器上,按需下载,可以减少安装包大小。
在移动设备中,电池的重要性不言而喻,没有电什么都干不成。对于操作系统和设备开发商来说,耗电优化一致没有停止,去追求更长的待机时间,而对于一款应用来说,并不是可以忽略电量使用问题,特别是那些被归为“电池杀手”的应用,最终的结果是被卸载。因此,应用开发者在实现需求的同时,需要尽量减少电量的消耗。
在Android5.0以前,在应用中测试电量消耗比较麻烦,也不准确,5.0之后专门引入了一个获取设备上电量消耗信息的API:Battery Historian。Battery Historian是一款由Google提供的Android系统电量分析工具,和Systrace一样,是一款图形化数据分析工具,直观地展示出手机的电量消耗过程,通过输入电量分析文件,显示消耗情况,最后提供一些可供参考电量优化的方法。
除此之外,还有一些常用方案可提供:
计算优化,避开浮点运算等。
避免WaleLock使用不当。
使用Job Scheduler。
第八、代码静态扫描工具Lint
lint工具是一款代码检查工具,打包前运行lint检查代码,可以帮助我们发现很多不易觉察的问题。
我们知道,当我们在布局中给textview赋值时,会出现下面的提示:
但是这个提示并不明显,现在这个提示是警告(warning)级别
第九.使用 Android Studio 生成 trace 文件
Android Studio 内置的 Android Monitor 可以很方便的生成 trace 文件到电脑。
在 CPU 监控的那栏会有一个闹钟似的的按钮,未启动应用时是灰色:
启动应用后,这个按钮会变亮,点击后开始追踪,相当于代码调用 startMethodTracing:
当要结束追踪时再次点击这个按钮,就会生成 trace 文件了。
生成 trace 后 Android Studio 自动加载的 traceview 图形如下:
从这个图可以大概了解一些方法的执行时间、次数以及调用关系,也可以搜索过滤特定的内容。
左上角可以切换不同的线程,这其实也是直接用 Android Studio 查看 trace 文件的缺点:无法直观地对比不同线程的执行时间。
鼠标悬浮到黄色的矩形上,会显示对应方法的开始、结束时间,以及自己占用和调用其他方法占用的时间比例: