1.前言

ANR比较棘手在于，没有崩溃日志，定位问题比较困难，而且ANR是必须要解决的问题。

Android对ANR的监控机制
Android应用程序是通过消息来驱动的，Android某种意义上也可以说成是一个以消息驱动的系统，UI、事件、生命周期都和消息处理机制息息相关。Android的ANR监测方案也是一样，大部分就是利用了Android的消息机制。

anr.png

2.主流的ANR监控方案

主流的ANR监控方案：FileObserver，WatchDog，Looper.loop。它们都各有优缺点，无法覆盖所有情况，所以在线上使用的时候可以结合这几种方案一起使用。

2.1 FileObserver实现ANR监控

当ANR发生的时候，我们是可以通过监听该文件目录data/anr/的写入情况来判断是否发生了ANR，看起来这是一个不错的时机。需要注意的是，所有应用发生ANR的时候都会进行回调，因此需要做一些过滤与判断，如包名、进程号等。

优点:

基于原生接口调用，时机和内容准确
无性能问题实现简单

缺点:
最大的困难是兼容性问题，这个方案受限于Android系统的SELinux机制，5.0以后基本已经使低权限应用无法监听到trace文件了，但是可以在开发内测阶段通过root手机进行监控。

2.2 ANR-WatchDog实现ANR监控

ANR-WatchDog是参考Android WatchDog机制（com.android.server.WatchDog.java）起个单独线程向主线程发送一个变量+1操作的消息，然后自我休眠sleep 自定义ANR的阈值一般是5s，休眠过后判断变量是否+1完成，如果未完成则告警。

watchdog.png

优点:

兼容性好，各个机型版本通用
无需修改APP逻辑代码，非侵入式
逻辑简单，性能影响不大

缺点:
无法保证能捕捉所有ANR，对阈值的设置直接影响捕获概率.比如如果设置了5s就无法捕获10s的Receiver和20s的service 引起的ANR。

2.3 Looper.loop实现ANR监控

巧妙的利用了Android原生Looper.loop中的一个log打印逻辑。
这个log打印逻辑正是在Message消息分发前后，大部分的性能卡顿问题都是在这里发生的，监控这两个逻辑之间的时间差就可以得到当前主线程的卡顿状态，如果超时则获取trace信息并上报。

实现原理:开启子线程执行，会消耗cpu资源，谨慎开启,开发中一般针对部分用户下发开关:

设置Looper.setPrinter(自定义printer)实现println方法;

在消息执行前后,Looper会调用
Looper.mPriter.pritlin(“>>>>> dispatch msg.target msg.callBack,msg.what”)//子线程开启收集线程堆栈信息
Looper.mPriter.pritlin(“<<<<<< finish msg.target msg.callBack,msg.what”)//子线程结束收集线程堆栈信息

首先需要判断msg.target的Looper是否等于主线程的Looper.

其次计算这两个函数前后时间差是否超过200ms超过的话就上报堆栈调用信息。

优点:

灵活配置可监控常见APP应用性能也可作为一部分场景的ANR监测，并且可以准确定位ANR和耗时调用栈。
谷歌已经明确标注This must be in a local variable, in case a UI event sets the logger这个looger对象是可以被更改的，已经有开发者遇到在使用WebView时logger被set为Null导致，进而造成监控失败。

3.如果dispatchMessage消息执行的非常久是无法触发监控的逻辑。

4.无法监控CPU资源紧张造成系统卡顿，无法响应的ANR

2.4 注册信号函数

使用注册信号函数机制监听SINGAL_QUIT信号，可以监听ANR和Crash触发逻辑。可以作为FileObserver在5.0以后因权限问题无法监测data/anr目录的使用。
因为当应用发生crash和ANR的时候，系统会向目标进程发送SIGNAL_QUIT信号，应用虚拟机捕获到信号以后会收集系统信息输出到日志文件中(data/anr/trace.txt)然后kill掉目标进程。trace文件中数据过大，可以根据当前时间节点和进程id进行信息过滤。详情参考:让Native Crash 与ANR无处发泄