1. 消息队列
基于消息队列实现，通过替换 Looper 的 Printer 实现。
Looper
问题：线上开启这个监控模块，快速滑动时平均帧率起码降低 5 帧，上图中所示的大量字符串拼接导致性能损耗严重。
另一个方案：可以通过一个监控线程，每隔 1 秒向主线程消息队列的头部插入一条空消息。假设 1 秒后这个消息没有被主线程消费掉，说明阻塞消息运行的时间在 0 ~ 1 秒之间。如果我们需要监控 3 秒卡顿，那么在第 4 次轮询中头部消息依然没有被消费的话，就可以确定主线程出现了一次 3 秒以上的卡顿。
监控线程
2. 插桩
基于消息队列的卡段监控并不准确，正在运行的函数有可能并不是真正耗时的函数。
假设一个消息循环里面顺序执行了 A、B、C 三个函数，当整个消息执行超过 3 秒时，因为函数 A 和 B 已经执行完毕，只能得到的正在执行的函数 C 的堆栈，事实上它可能并不耗时。
卡顿函数
能否直接利用 Android Runtime 函数调用的回调事件，做一个自定义的 Traceview++ 呢？可以拿到整个卡顿过程所有运行函数的耗时，可以明确知道其实函数 A 和 B 才是造成卡顿的主要原因。
Traceview++
可以在函数入口和出口加入耗时监控代码，但是需要考虑的细节很多。
-
避免方法数暴增。
在函数的入口和出口应该插入相同的函数，在编译时提前给代码中每个方法分配一个独立的 ID 作为参数。 -
过滤简单的函数
过滤一些类似 return 、i++ 这样的简单函数，并且支持黑名单配置。对一些调用非常频繁的函数，需要添加到黑名单中来降低整个方案对性能的损耗。
插桩
不管我们使用哪种卡顿监控方法，最后都可以得到卡顿时的堆栈和当时 CPU 运行的一些信息。大部分卡顿问题都比较好定位，例如主线程执行一个耗时任务，读一个非常大的文件或者是执行网络请求等。
3. 其他监控
- 帧率
业界都使用 Choreographer 来监控应用的帧率，需要排除掉没有操作的情况，只在**界面存在绘制的时候才做统计。
可以通过 addOnDrawListener 实现：
getWindow().getDecorView().getViewTreeObserver().addOnDrawListener
对用户来说，感觉最明显的是连续丢帧情况，将连续丢帧超过 700 毫秒定义为冻帧，也就是连续丢帧 42 帧以上。
因此可以统计冻帧率。冻帧率就是计算发生冻帧时间在所有时间的占比。
- 生命周期监控
Activity、Service、Receiver 组件生命周期的耗时和调用次数也是我们重点关注的性能问题。例如，Acitivity 的 onCreate() 不应该超过1秒。
life
每个组件各个生命周期的调用次数也是非常有参考价值指标的，可以查看是否频繁的拉起某个组件。
- 线程监控
Java 线程管理令人头疼，应用启动已经创建了大量线程，而且大部分线程都没有经过线程池管理，另一方面某些线程优先级或者活跃程度比较高，占用了过多的 CPU，这会降低主线程 UI 响应能力，我们需要对这些线程做重点的优化。
对于 Java 线程，总的来说需要监控以下两点
- 线程数量。需要监控线程数量的多少，以及创建线程的方式。例如有没有使用我们特有的线程池，这块可以通过 got hook 线程的 nativeCreate() 函数，主要用于进行线程收敛、也就是减少线程数量。
-
线程时间。监控线程的用户时间 utime、系统时间 stime 和优先级。主要看哪些线程 utime + stime 时间比较多，占用了过多的 CPU。
thread time
导致卡顿的原因会有很多，比如函数非常耗时、I/O 非常慢、线程间的竞争或者锁等。其实很多时候卡顿问题并不难解决，相比较解决来说，更困难的是如何快速发现这些卡顿点，以及通过更多的辅助信息找到真正的卡顿原因。
网友评论