Android卡顿检测方案

应用的流畅度最直接的影响了App的用户体验，轻微的卡顿有时导致用户的界面操作需要等待一两秒钟才能生效，严重的卡顿则导致系统直接弹出ANR的提示窗口，让用户选择要继续等待还是关闭应用。

所以，如果想要提升用户体验，就需要尽量避免卡顿的产生，否则用户经历几次类似场景之后，只会动动手指卸载应用，再顺手到应用商店给个差评。关于卡顿的分析方案，已经有以下两种：

• 分析trace文件。通过分析系统的/data/anr/traces.txt，来找到导致UI线程阻塞的源头，这种方案比较适合开发过程中使用，而不适合线上环境；

• 使用BlockCanary开源方案。其原理是利用Looper中的loop输出的>>>>> Dispatching to和< finished="">

下面就开始说本文要提及的卡顿检测实现方案，原理简单，代码量也不多，只有BlockLooper和BlockError两个类。

0

基本使用

在Application中调用BlockLooper.initialize进行一些参数初始化，具体参数项可以参照BlockLooper中的Configuration静态内部类，当发生卡顿时，则会在回调（非UI线程中）OnBlockListener。

在选择要启动（停止）卡顿检测的时候，调用对应的API

使用上很简单，接下来看一下效果演示和源码实现。

1

效果演示

制造一个UI阻塞效果

看看AS控制台输出的整个堆栈信息

定位到对应阻塞位置的源码

当然，对线程的信息BlockLooper也不仅输出到控制台，也会帮你缓存到SD上对应的应用缓存目录下,在SD卡上的/Android/data/对应App包名/cache/block/下可以找到，文件名是发生卡顿的时间点，后缀是trace。

2

源码解读

当App在5s内无法对用户做出的操作进行响应时，系统就会认为发生了ANR。BlockLooper实现上就是利用了这个定义，它继承了Runnable接口，通过initialize传入对应参数配置好后，通过BlockLooper的start()创建一个Thread来跑起这个Runnable，在没有stop之前，BlockLooper会一直执行run方法中的循环，执行步骤如下：

• Step1. 判断是否停止检测UI线程阻塞，未停止则进入Step2；

• Step2. 使用uiHandler不断发送ticker这个Runnable，ticker会对tickCounter进行累加；

• Step3. BlockLooper进入指定时间的sleep（frequency是在initialize时传入，最小不能低于5s）；

• Step4. 如果UI线程没有发生阻塞，则sleep过后，tickCounter一定与原来的值不相等，否则一定是UI线程发生阻塞；

• Step5. 发生阻塞后，还需判断是否由于Debug程序引起的，不是则进入Step6；

• Step6. 回调OnBlockListener，以及选择保存当前进程中所有线程的堆栈状态到SD卡等；

介绍完BlockLooper后，再简单说一下BlockError的代码，主要有getUiThread和getAllThread两个方法，分别用户获取UI线程和进程中所有线程的堆栈状态信息，当捕获到BlockError时，会在OnBlockListener中以参数的形式传递回去。

3

总结

以上就是BlockLooper的实现，非常简单，相信大家都看得懂。当然以上的实现还可以继续拓展，例如像LeakCanary一样，在卡顿发生时UI上做出一些提示之类的。想看源码的同学，请移步：https://github.com/D-clock/AndroidPerformanceTools