Android客户端优化.docx

Android客户端性能优化 众所周知，一个好的产品，除了功能强大，好的性能也必不可少。有调查显示，近90%的受访者会因为APP性能差而卸载，性能也是造成APP用户沮丧的头号原因。 那Android客户端性能的指标都有哪些？如何发现和定位客户端的性能问题？本文结合多个项目的开发实践，给出了要关注的重要指标项目，以及定位和解决性能问题的一般步骤。 性能优化应该贯穿于功能开发的全部周期，而不是做完一次后面便不再关注。每次发布版本前，最好能对照标准检查下性能是否达标。记住：产品=性能×功能！ 更多Android、Linux、嵌入式和物联网原创技术分享敬请关注微信公众号：嵌入式企鹅圈。 一、 性能检查项 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 shell dumpsys gfxinfo 应用包名-cmd trim 5`后，再）用命令`adb shell dumpsys meminfo 应用包名`查看内存大小 5. 过度绘制 1）打开设置中的GPU过度绘制开关，各界面过度绘制不应超过2.5x；也就是打开此调试开关后，界面整体呈现浅色，特别复杂的界面，红色区域也不应该超过全屏幕的四分之一； 6. lint检查： 1）通过Android Studio中的 Analyze-Inspect Code 对工程代码做静态扫描；找出潜在的问题代码并修改； 2） 0 error 0 warning，如果确实不能解决，需给出原因。 7. 反射优化： 1）在代码中减少反射调用； 2）对频???调用的返回值进行Cache； 8. 稳定性： 1）连续48小时monkey不应出现闪退，anr问题。 2）如果应用接入了数据埋点的sdk，比如百度统计sdk，友盟统计sdk等，这些sdk都会将应用的崩溃信息上报回来，开发者应每天关注这些统计到的崩溃日志，严格控制应用的崩溃率； 9. 耗电： 1）应用进入后台后不应异常消耗电量； 2）操作应用后，退出应用，让应用处于后台，一段时间后通过`adb shell dumpsys batterystats`查看电量消耗日志看是否存在异常。 二、性能问题常见原因 性能问题一般归结为三类： 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过度绘制中打开调试，看对应界面是否有过度绘制，如果有先解决掉： 定位过