点击置顶文章查看博客目录（全站式导航）

关于Service的ANR场景还是比较少见的，它的ANR设计原理也是比较简单，在很多监控的方案中都可以看得到。

Broadcast触发ANR和Service触发ANR原理是一样的，都是通过延迟发送超时消息的形式BroadcastReceiver广播接收分为2类静态广播：通过的标签来申明注册动态广播：通过来注册，动态注册更为灵活，可在不需要时通过取消注册广播发送方式可分为三类普通广播：通过发送，可并行处理，我们最常用的是这种有序广播：通过发送，串行处理粘性广播：通过。

Input类型的ANR相对于ServiceBroadcastProvider实现的方式不一样，Input的ANR发生原因是输入事件分发超时，包括按键和屏幕的触摸事件。对于输入系统而言即使只有一次事件执行时间超过5s，只要用户后续没有再生成输入事件，那么也不需要ANRInput事件的ANR依赖用户输入的第一次事件有阻塞，在第二次输入的时候，系统事件分发超时才导致ANRInput的事件是需要从屏幕（输入设备）点击开始，从硬件设备驱动到应用层，涉及到的底层的交互，其中重要的角色有。

ANR的监控在Android6.0之前可以通过监听文件读取trace信息来分析，但从6.0之后就被禁止了。随着Android的发展，手机里的ANR越来越多，对ANR的监控方案也就五花八门。

在项目中经常遇到了手机假死问题，无规律的偶现问题，大量频繁随机操作后，便会出现假死，整个应用无法操作，不会响应事件，会发生各种奇怪的ANR，且trace不固定。而SyncBarrier是其中的罪魁祸首之一SyncBarrier大家又称它为同步屏障，这是安卓线程消息队列里面的一个新增加的东西，它是一种Handler中的同步屏障机制。简单可以理解安卓在Hanlder的处理上增加了优先级，优先级最高的就是SyncBarrier。

关于IdleHandler，比较多同学错误地认为，这个Handler的作用是主线程空闲状态时才执行它，那么用它做一些耗时操作也没所谓。可是IdleHandler在主线程的MessageQueue中，执行默认当然也是执行在主线程中的，这里的耗时操作其实很容易引起卡顿和ANR。IdleHandler是一种在只有当消息队列没有消息时或者是队列中的消息还没有到执行时间时才会执行的IdleHandler。

这种方案才是真正的监控ANR，matrix、xCrash都在使用这种方案，已经在国民应用微信等app上检验过，稳定性和可靠性都能得到保证。