Android客户端性能优化

原文：http://blog.csdn.net/yueqian_scut/article/details/50762649

一、 性能检查参考标准

1. 启动速度

1）这里的启动速度指的是冷启动的速度，即杀掉应用后重新启动的速度，此项主要是和你的竞品对比。

2）不应在Application以及Activity的生命周期回调中做任何费时操作，具体指标大概是你在onCreate，onResume，onStart等回调中所花费的总时间最好不要超过400ms，否则用户在桌面点击你的应用图标后，将感觉到明显的卡顿。

2. 界面切换

1）应用操作时，界面和动画不应有明显卡顿;

2）可通过在手机上打开 设置->开发者选项->GPU呈现模式分析，然后操作应用查看gpu是否超线进行初步判断；

3. 内存泄露

1)back退出不应存在内存泄露，简单的检查办法是在退出应用后，用命令`adb shell dumpsys meminfo 应用包名`查看 `Activities Views` 是否为零;

2)多次进入退出后的占用内存`TOTAL`不应变化太大；

4.  onTrimMemory回调

1）应用响应此回调释放非必须内存；

2验证可通过命令`adb shelldumpsys gfxinfo 应用包名-cmd trim 5`后，再）用命令`adb shell dumpsys meminfo 应用包名`查看内存大小

5. 过度绘制

1）打开设置中的GPU过度绘制开关，各界面过度绘制不应超过2.5x；也就是打开此调试开关后，界面整体呈现浅色，特别复杂的界面，红色区域也不应该超过全屏幕的四分之一；

6. lint检查：

1）通过Android Studio中的 Analyze->Inspect Code 对工程代码做静态扫描；找出潜在的问题代码并修改；

2） 0 error & 0warning，如果确实不能解决，需给出原因。

7. 反射优化：

1）在代码中减少反射调用；

2）对频繁调用的返回值进行Cache；

8.  稳定性：

1）连续48小时monkey不应出现闪退，anr问题。

2）如果应用接入了数据埋点的sdk，比如百度统计sdk，友盟统计sdk等，这些sdk都会将应用的崩溃信息上报回来，开发者应每天关注这些统计到的崩溃日志，严格控制应用的崩溃率；

9.  耗电：

1）应用进入后台后不应异常消耗电量；

2）操作应用后，退出应用，让应用处于后台，一段时间后通过`adb shell dumpsysbatterystats`查看电量消耗日志看是否存在异常。

 

二、性能问题常见原因

性能问题一般归结为三类：

1. UI卡顿和稳定性:这类问题用户可直接感知，最为重要；

2. 内存问题：内存问题主要表现为内存泄露，或者内存使用不当导致的内存抖动。如果存在内存泄露，应用会不断消耗内存，易导致频繁gc使系统出现卡顿，或者出现OOM报错；内存抖动也会导致UI卡顿。

3. 耗电问题：会影响续航，表现为不必要的自启动，不恰当持锁导致系统无法正常休眠，系统休眠后频繁唤醒系统等；

三、UI卡顿常见原因和分析方法

下面分别介绍出现这些问题的常见原因以及分析这些问题的一般步骤。

1.卡顿常见原因

1）人为在UI线程中做轻微耗时操作，导致UI线程卡顿；

2） 布局Layout过于复杂，无法在16ms内完成渲染；

3）同一时间动画执行的次数过多，导致CPU或GPU负载过重；

4） View过度绘制，导致某些像素在同一帧时间内被绘制多次，从而使CPU或GPU负载过重；

5） View频繁的触发measure、layout，导致measure、layout累计耗时过多及整个View频繁的重新渲染；

6） 内存频繁触发GC过多（同一帧中频繁创建内存），导致暂时阻塞渲染操作；

7） 冗余资源及逻辑等导致加载和执行缓慢；

8）工作线程优先级未设置为Process.THREAD_PRIORITY_BACKGROUND，导致后台线程抢占UI线程cpu时间片，阻塞渲染操作；

9） ANR；

2. 卡顿分析解决的一般步骤：

1）解决过度绘制问题

>在设置->开发者选项->调试GPU过度绘制中打开调试，看对应界面是否有过度绘制，如果有先解决掉：

> 定位过渡绘制区域

> 利用Android提供的工具进行位置确认以及修改(HierarchyView , Tracer for OpenGL ES)

> 定位到具体的视图(xml文件或者View)

> 通过代码和xml文件分析过渡绘制的原因

> 结合具体情况进行优化

> 使用Lint工具进一步优化

2) 检查是否有主线程做了耗时操作：

 严苛模式（StrictMode），是Android提供的一种运行时检测机制，用于检测代码运行时的一些不规范的操作，最常见的场景是用于发现主线程的IO操作。应用程序可以利用StrictMode尽可能的发现一些编码的疏漏。

3）如果主线程无耗时操作，还存在卡顿，有很大可能是必须在UI线程操作的一些逻辑有问题，比如控件measure、layout耗时过多等，此时可通过Traceview以及systrace来进行分析。

4）Traceview：Traceview主要用做热点分析，找出最需要优化的点。

> 打开DDMS然后选择一个进程，接着点击上面的“Start Method Profiling”按钮（红色小点变为黑色即开始运行），然后操作我们的卡顿UI,然后点击"Stop Method Profiling"；

四、内存性能分析优化

1.内存泄露

该问题目前在项目中一般用leakcanary基本就能搞定，配置起来也相当简单：

2.内存抖动

如果代码中存在在ｏｎＤｒａｗ或者ｆｏｒ循环等多次执行的代码中分配对象的行为，会导致运行过程中ｇｃ次数增多，影响ｕｉ流畅度。一般这些问题都可通过ｌｉｎｔ工具检测出来。

五、耗电量优化建议

电量优化主要是注意尽量不要影响手机进入休眠，也就是正确申请和释放WakeLock，另外就是不要频繁唤醒手机，主要就是正确使用Alarm。

六、一些好的代码实践

1. 节制地使用Service

2. 当界面不可见时释放内存

3. 当内存紧张时释放内存

4. 避免在Bitmap上浪费内存

对大图片，先获取图片的大小信息，根据实际需要展示大小计算inSampleSize，最后decode；

5. 使用优化过的数据集合

6. 谨慎使用抽象编程

7. 尽量避免使用依赖注入框架

很多依赖注入框架是基于反射的原理，虽然可以让代码看起来简洁，但是是有碍性能的。

8. 谨慎使用externallibraries

9. 优化整体性能

10. 使用ProGuard来剔除不需要的代码

抛出异常首先要创建一个新的对象。Throwable 接口的构造函数用名为fillInStackTrace() 的本地方法,fillInStackTrace()方法检查栈,收集调用跟踪信息。只要有异常被抛出,VM 就必要调整调用栈,因为在处理过程中创建了一个新对象。异常只能用于错误处理,不应该用来控制程序流程。