关于Android中ANR的详解

前言

关于ANR，以前只知道Activity、BroadCastReceiver、Service三种组件的ANR时限、一般采用哪些方式避免ANR、以及通过data/anr/traces.txt去分析ANR原因，感觉好像这就够用了。

但是，前几天看源码的时候，脑海里突然跳出一个问题：

ANR是怎么判断的5秒还是10秒？

这个问题迅速扩大为一连串问题：

ANR的时间定义在哪些文件里？

ANR是怎么计时的？

是谁在监控ANR？

所有的ANR都会弹窗吗？

traces.txt能记录多少内容？

ANR一定是app代码问题导致的吗？

前ANR机制的基本原理

任何功能都有个执行者，以及业务逻辑的实现原理，在ANR上，就是两个问题：

1.ANR是谁做的

ANR不可能是在应用层做的，有两个理由：

从能力上，发生ANR时，App自己已经死掉了，没有能力处理；

从安全上，App的安全事实上是不可控的，如果有恶意App故意不处理ANR，设备就废了。

所以，ANR的监控和处理，只能是在系统层做的。

系统层要做ANR的话，我们首先想到是在AMS，因为AMS管理着所有的组件，也只有AMS知道组件是什么时候启动的，以便判断是否触发了ANR。

不过，实际上，还有Activity Service，Input Manager Service这些服务，也参与了ANR的管理。

2.ANR是怎么判断超时时间的

这个问题，其实就是怎样定义超时时间、什么时候开始计时、以及如何计时的问题。

ANR超时时间的定义，是在执行者，也就是系统服务那里定义的，这个容易理解。

ANR从什么时候开始计时呢，在Android中，实际上是系统服务在控制每个组件的生命周期回调，所以可以在这个逻辑入口开始计时。

至于如何计时的问题，其实Android系统里已经有一个时间相对准确的