本文要点
- ANR概述
- 发生ANR后Android系统的执行流程
- ANR-WatchDog原理与实战
- ANR的传统解决套路
- ANR模拟实战
- 线上ANR监控方案【ANR-WatchDog原理分析】
- ANR-WatchDog实战
- ANR-WatchDog总结
- ANR-WatchDog与AndroidPerformanceMonitor的区别
项目GitHub
#ANR概述
-
KeyDispatchTimeout，5s 即按键或者触摸事件，在特定的时间（一般5s）之内没有响应；
-
BroadcastTimeout，前台10s，后台60s BroadReceiver 在特定的时间（一般前台10s，后台60s）之内没有响应完成；
-
ServiceTimeout，前台20s，后台200s Service 在特定的时间（一般前台20s，后台200s）之内没有处理完成；
#发生ANR后Android系统的执行流程
- APP发生ANR
- 进程接收异常终止信号，开始写入进程ANR信息（当时场景，包含当前线程所有堆栈信息、CPU/IO的使用情况等）；
- 弹出ANR提示框，提示用户关闭APP或者继续等待；（不同ROM表现不同，有的手机厂商会去掉这个提示框）
#ANR的传统解决套路
- 【线下】在AS的Terminal中，使用
adb pull data/anr/traces.txt 要存储在本地的路径导出上面提到的ANR现场信息文件； 导出来后，便可对文件内容进行详细分析：从CPU、IO、锁冲突等原因思考；
#ANR模拟实战
- 模拟ANR原因：锁冲突；
更改代码：
运行程序，等到程序ANR或崩溃， 在Terminal使用刚刚提到的命令，导出ANR的信息文件：
生成文件：
打开文件，可以找到原因：
上次的BlockCanary同样捕捉到原因：
线下套路其实就是在APP发生ANR时， 导出信息文件， 查看文件，结合代码进行分析；
#线上ANR监控方案
-
通过
FileOberver监控上述的ANR信息文件的变化， 如果这个文件发生了变化，那就说明发生了ANR， 那便可以把它上报到服务器，进行详细的分析； 【高版本需注意权限问题】 -
ANR-WatchDog
- 依赖
compile 'com.github.anrwatchdog:anrwatchdog:1.4.0' - 官网 github.com/SalomonBrys…
- 原理（源码分析）：
ANRWatchDog本身就是Thread的子类：ANRWatchDog中，用一个绑定了主线程Looper的Handler， 去处理_ticker【一个Runnable任务单元】； 任务单元对一些值进行了处理，如_tick、_reported：_tick在初始为ANRWatchDog的全局变量时，被赋值为0；^^^^^^^^^^^^^^^^^ 在ANRWatchDog的run()中， 首先被利用去判定_ticker被post没有（因为一开始就_tick为0的话说明_tick还没被post）， 没有便将_tick=加上卡顿周期，之后post了_ticker； 此时_tick不为0！！^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^_ticker中的run()，再一次将_tick置零；^^^^^^^^^^^^^^^^^^^^^^^^^^ 所以只要_ticker不被处理，其run()便不会执行，_tick就不会被置零，由此根据
_tick的值可以判断_ticker是否被处理了；_tick重新归零则主线程处理了_ticker，_tick不为零则判定主线程卡顿，它没处理_tick！！！！！！！！ANRWatchDog的run()中， 用刚说的主线程Handler，post了_ticker这个任务， 然后自己sleep一段时间【即一个卡顿周期，稍后细说】， 如果sleep结束之后，如果_tick != 0 && !_reported， 则说明主线程还没有处理_ticker的run()， 没有处理_ticker这个任务单元, 那便认为主线程发生了卡顿【如源码注释所示】：！！！！！！ 确定发生了卡顿，就开始封装一个ANRError，进行后续处理了：另外补充一下，
ANRWatchDog提供了两个重载的构造器， 提供给开发者对卡顿判定周期进行设置，开发者不设置则使用默认配置： 【跟BlockCanary同一个德行】接着仔细看
ANRError的构造流程这里是有两种构造方式
New()、NewMainOnly()，其最终处理都差不多， 就是通过mainLooper拿到主线程， 再通过主线程拿到现场的堆栈信息， 最后返回构造好的ANRError实例：拿到
ANRError实例之后， 通过_anrListener.onAppNotResponding(error);回调机制处理ANRError实例；回调机制就妙啊！^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 刚刚的
_anrListener.onAppNotResponding(error);只是一个应用层上的调用；onAppNotResponding()的实现方式暴露给开发者了， ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 在外部可以通过setANRListener()自己定制包含不同处理方式的ANRListener： ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^开发者不定制，则使用框架自带的默认处理方式呗： 处理方式简单粗暴哈，直接把
ANRError丢出去， 这样APP就直接崩溃了：ANRError乃是Error的子类：
- 依赖
#ANR-WatchDog实战
- 引入依赖
- 初始化ANR-WatchDog：
- 还是上面那个项目，手动阻塞60s，
运行程序，
程序会5s后崩溃【5s是默认周期时间，崩溃操作见上面源码分析】
在
logcat定位关键字fatal，可以看到ANRError打印的信息， 信息中包括了崩溃现场所有线程的堆栈信息； 以及显示bug代码的位置；
优化： 当然默认的APP崩溃处理法并不妥当， 影响用户体验， 实际开发中， 我们可以自己定义
ANRListener，自定义处理方式【上面说过了】， 把堆栈信息上报给服务器就是了！！！！
#总结
- 非浸入式
- 弥补高版本无权限问题
#与AndroidPerformanceMonitor的区别
- AndroidPerformanceMonitor： 原理是基于Handler-Message机制， 监控主线程每一个Message的执行， 在每一个Message的分发执行前后，进行信息处理； （不足： 一般没有阻塞的情况下， 每一个Message的执行时间是非常短暂的， 达不到ANR的级别； 而且InputEvent在queue.next中block，不会继续执行dispatchMessage， 而是从native回调给InputEventReceiver.dispatchInputEvent处理分发， 所以BlockCanary也就无法监控到这类ANR）
- ANR-WatchDog：
不管主线程是怎么执行的，
只管最后的结果，
我sleep一个周期之后，就要看我
_tick值有没有被修改， 没被修改就是ANR！ AndroidPerformanceMonitor适合全程监控卡顿，ANR-WatchDog适合补充ANR监控； 两者可以相辅相成，结合使用！
参考：
