1、卡顿问题分析指标

• CPU 的使用率
  我们可以把 CPU 时间分为两种：用户时间和系统时间。用户时间和系统时间。用户时间就是执行用户态应用程序代码所消耗的时间；系统时间就是执行内核态系统调用所消耗的时间，包括 I/O、锁、中断以及其他系统调用所消耗的时间，包括 I/O、锁、中断以及其他系统调用的时间。

• CPU饱和度
  CPU 饱和度反映的是线程排队等待 CPU 的情况，也就是CPU 的负载情况。CPU 饱和度首先会跟应用的线程数有关，如果启动的线程过多，容易导致系统不断地切换执行的线程，把大量的时间浪费在上下文切换都需要刷新寄存器和计数器，至少需要几十纳秒的时间。

2、Android 卡顿排查工具

分析工具主要分为两流派，第一个流派是 instrument。获取一段时间内所有函数的调用过程，可以通过分析这段时间内的函数调用流程，再进一步分析待优化的点；第二个流派是 sample。有选择性或者采用抽样的方式观察某些函数调用过程，可以通过这些有限的信息推测出流程中的可疑点，然后再继续细化分析。

1）Traceview

Traceview 属于 instrument 类型，它利用 Android Runtime 函数调用的 event事件，将函数运行的耗时和调用关系写入 trace 文件中。它可以用来查看整个过程有哪些函数调用，但是工具本身带来的性能开开销过大，有时无法反映真实的情况。

2）Nanoscope

Uber开源instrument类型性能分析工具，其实现原理直接修改Android 虚拟机源码，在ArtMethod执行入口和执行结束位置增加埋点代码，将所有的的信息先写到内存，等到trace结束后统计生成结果文件。
缺点：

• 需要自己刷ROM，并且当前只支持Nexus 6P，或者采用其提供的x86架构的模拟器。
• 默认只支持主线程采集，其他线程需要代码手动设置，考虑到内存大小的限制，每个线程的内存数组只能支持大约20秒的时间段。

3）systrace

systrace是Android 4.1新增的性能分析工具，其利用了Linux的ftrace调试工具，相当于在系统各个关键位置都增加了一些性能指针，即在代码中增加了埋点。Android在ftrace的基础上封装了atrace，增加了更多特有的指针，例如，Graphics，ActivityManager、Dalvik VM、System Server等。
systrace 工具只能监控特定系统调用的耗时情况，所以它是属于 sample 类型，而且性能开销非常低。但是它不支持应用程序代码的耗时分析，所以在使用时有一些局限性。
我们可以通过编译时给每个函数插桩的方式来实现，也就是在重要函数插桩的方式来实现，也就是在重要函数的入口和出口分别增加Trace.beginSection和Trace.endSection。当然出于性能的考虑，我们会过滤大部分指令数比较少的函数，这样就实现了在 systrace 基础上增加应用程序耗时的监控。通过这样方式的好处有：

• 可以看到整个流程系统和应用程序的调用流程。包括系统关键线程的函数调用，例如渲染耗时、线程锁，GC 耗时等。
• 性能损耗可以接受。由于过滤了大部分的短函数，而且没有放大I/O，所以整个运行耗时不到原来的两倍，基本可以反映真实情况。

4）Simpleperf

Android 5.0 新增了Simpleperf性能分析工具，它利用 CPU 的性能监控单元（PMU）提供的硬件 perf 事件。使用 Simpleperf 可以看到所有的 Native 代码的耗时，有时候一些 Android 系统库的调用对分析问题有比较大的帮助，例如加载 dex、verify class 的耗时等。
Simpleperf同时封装了systrace的监控功能，它属于sample类型，性能开销非常低，使用火焰图展示分析结果。

3、可视化分析工具

Android studio的Profiler集成了如下几种分析工具：

• Sample Java Methods 的功能，类似于Traceview的sample类型；
• Trace Java Methods的功能，类似于Traceview的instrument类型；
• Trace System Calls 的功能，类似于systrace；
• SampleNative （API Level 26+）的功能类似于Simpleperf。

1）Call Chart

Call Chart是Traceview和systrace默认使用的展示方式，它按照应用程序的函数执行顺序来展示，适合分析整个流程的调用。

image.png

2）Flame Chart

Flame Chart即是大名鼎鼎的火焰图，它以一个全局的视野来看待一段时间的调用分布，可以很自然的把空间和时间维度上的信息融合在一张图上，如下图所述的例子：

image.png

4、卡顿监控方法

1）消息队列

通过替换Looper的Printer实现监控消息消费情况，通过一个监控线程，每个1秒向主线程的头部插入1个空的消息，假设1秒后这个消息还没有被消费掉，说明小子阻塞的时间是0~1秒，查询消息还没被消费的次数，即可粗略估算卡顿时间，缺点是无法精确确认空消息的发送间隔，且带来不小的性能损耗

2）插装

在方法的出入口或核心出采用插装的方式埋入统计的代码，详细的监控我们所关心的数据，但要考虑性能的损耗和代码的稳定性，一定要考虑下面的问题：

• 避免方法数暴增
• 过滤简单的函数
• 白名单设计
  插桩方案看起来美好，它也有自己的短板，那就是只能监控应用内自身的函数耗时，无法监控系统的函数调用，整个堆栈看起来好像“缺失了”一部分。

3）Profilo

Facebook开源库Profilo综合了各大方案的优点，总结来说如下：

• 集成atrace功能，ftrace所有性能埋点数据都会通过trace_marker文件写入到内核缓冲区，Profilo通过PLT Hook拦截了写入操作，截取了部分数据用于分析，这样所有systrace的探针都可以拿到，诸如，四大组件的生命周期、锁等待时间、类校验、GC时间等；
• 快速获取Java堆栈，Profilo的实现类似Native崩溃捕捉的方式快速获取Java堆栈，不用插装，性能损失小。捕捉信息齐全。当然它也有不足问题，内部使用了许多Hook，兼容性是个大问题，且不支持Android 8.0和9.0。

4）帧率

我们通常使用帧率来衡量界面的流程度，Android Vitals 将连续丢帧超过700毫秒定义为冻帧，也就是连续丢帧42帧以上。冻帧率就是计算发生冻帧时间在所有时间的占比，出现丢帧的时候，我们可以获取当前的页面信息，View信息和操作路径信息，降低二次排查的暗度。

5）生命周期监控

Activity、Service、Fragment、Receiver等组件的生命周期的耗时和调用次数也是我们关注的重点。对于组件生命周期我们应该采用更加严格地监控。

6）线程监控

Java线程的使用情况可以帮助我们发现问题，主要会监控一下两点：

• 线程数量
• 线程时间，监控线程的用户时间 utime、系统时间 stime 和优先级