众所周知，⼀个好的产品，除了功能强⼤，好的性能也必不可少。有调查显⽰，近90%的受访者会因为APP性能差⽽卸载，性能也是造成APP⽤户沮丧的头号原因。
那Android客户端性能的指标都有哪些？如何发现和定位客户端的性能问题？本⽂结合多个项⽬的开发实践，给出了要关注的重要指标项⽬，以及定位和解决性能问题的⼀般步骤。 性能优化应该贯穿于功能开发的全部周期，⽽不是做完⼀次后⾯便不再关注。每次发布版本前，最好能对照标准检查下性能是否达标。
记住：产品=性能×功能！
⼀、 性能检查项
1. 启动速度
1）这⾥的启动速度指的是冷启动的速度，即杀掉应⽤后重新启动的速度，此项主要是和你的竞品对⽐。
2）不应在Application以及Activity的⽣命周期回调中做任何费时操作，具体指标⼤概是你在onCreate，o
nResume，onStart等回调中所花费的总时间最好不要超过400ms，否则⽤户在桌⾯点击你的应⽤图标后，将感觉到明显的卡顿。
2. 界⾯切换
太阳能手电1）应⽤操作时，界⾯和动画不应有明显卡顿;
2）可通过在⼿机上打开 设置->开发者选项->调试GPU过度绘制，然后操作应⽤查看gpu是否超线进⾏初步判断；中央空调控制
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尽可能的发现⼀些编码的疏漏。
> 开启 StrictMode：
>> 对于应⽤程序⽽⾔，Android 提供了⼀个最佳使⽤实践：尽可能早的在
android.app.Application 或 android.app.Activity 的⽣命周期使能 StrictMode，onCreate()⽅法就是⼀个最佳的时机，越早开启就能在更多的代码执⾏路径上发现违规操作。
>> 监控代码
public voidonCreate() {
if (DEVELOPER_MODE) { StrictMode.setThreadPolicy(newStrictMode.ThreadPolicy.Builder() .detectAll().penaltyLog() .build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder() .detectAll().penaltyLog() .build());
}
如果主线程有⽹络或磁盘读写等操作，在logcat中会有"D/StrictMode"tag的⽇志输出，从⽽定位到耗时操作的代码。
3）如果主线程⽆耗时操作，还存在卡顿，有很⼤可能是必须在UI线程操作的⼀些逻辑有问题，⽐如控件measure、layout耗时过多等，此时可通过Traceview以及systrace来进⾏分析。
4）Traceview：Traceview主要⽤做热点分析，出最需要优化的点。
> 打开DDMS然后选择⼀个进程，接着点击上⾯的“Start Method Profiling”按钮（红⾊⼩点变为⿊⾊即开始运⾏），然后操作我们的卡顿UI，然后点击"Stop Method Profiling"，会打开如下界⾯：
图中展⽰了Trace期间各⽅法调⽤关系，调⽤次数以及耗时⽐例。通过分析可以出可疑的耗时函数并进⾏优化；
5）systrace：抓取trace：
> 执⾏如下命令：
$ cd android-sdk/platform-tools/systrace
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议