📚 课程目录第2章 ANR触发机制详解

ANR触发机制详解：不同超时类型与系统判定流程归纳总结

说到ANR，大家第一反应肯定是“卡住了”、“点不动了”。但你真的了解系统是怎么判定ANR的吗？我刚开始接触Android性能优化时，也以为只要主线程卡5秒就会弹窗。后来踩了坑才发现——不同类型的ANR，触发条件和超时时间完全不一样。

这一章，我们就掰开揉碎，把ANR的触发机制彻底讲清楚。

ANR的大家族：四种超时类型

Android系统中，ANR主要分为四类：输入事件超时、广播超时、服务超时、ContentProvider超时。每类的超时时间和判定逻辑都有差异。

ANR类型	超时时间	触发场景	关键参数
输入事件ANR	5秒	触摸/按键事件在主线程中未处理	INPUT_TIMEOUT
广播ANR（前台）	10秒	前台广播onReceive执行超时	BROADCAST_FG_TIMEOUT
广播ANR（后台）	60秒	后台广播onReceive执行超时	BROADCAST_BG_TIMEOUT
服务ANR	20秒	Service的onCreate/onStart等生命周期超时	SERVICE_TIMEOUT
ContentProviderANR	10秒	Provider发布或查询超时	CONTENT_PROVIDER_TIMEOUT

    重点提醒： 输入事件ANR看似只有5秒，但系统并不是到了5秒才判定——它是按"分派耗时+超时时间"综合计算的。我曾经遇到一个case，触摸事件因为Binder调用卡住，4秒多就弹ANR了，查了半天才发现是InputDispatcher的等待机制在作祟。

系统判定流程：从卡顿到弹窗

系统判定ANR的过程，不是你想象中"一个计时器到点就炸"那么简单。它有一套完整的监控→检测→上报→兜底流程。

监控注册：AMS（ActivityManagerService）为每个关键操作注册超时监视器。比如发广播时，会往Handler里塞一个延时消息，超时时间就是上面表格里的值。
检测触发：主线程消息队列被阻塞，监视器的延时消息被执行，此时AMS会检查主线程是否真的卡住了——它会尝试向主线程发送一个"探针"消息，如果探针在规定时间内没有被处理，则判定为ANR。
信息收集：判定ANR后，系统立即做三件事：
- 写入/data/anr/traces.txt（所有线程堆栈）
- 输出logcat日志（关键字：ANR in ...）
- 生成dropbox条目（用于开发者分析）
弹窗兜底：如果应用处于前台，系统会弹出"应用无响应"对话框；如果处于后台，只记录日志不弹窗（Android 12及以上甚至可能直接杀掉进程）。

注意： 所谓"探针消息"其实是系统往主线程Looper里塞的一个空消息，用来判断主线程是否还在处理消息。如果主线程因为死锁阻塞，这个探针永远没人处理，系统就会判定ANR。我遇到过因为Binder线程池满导致主线程获取不到锁，探针发进去但主线程卡在binder.transact()上——这种是最难查的。

核心代码中的超时常量

这些超时时间在AOSP源码中定义，位于ActivityManagerService.java和InputManagerService.java。我截取几个关键值：

// 输入事件超时（InputDispatcher.cpp）
static const nsecs_t INPUT_EVENT_TIMEOUT = 5000000000 ns;  // 5秒

// 前台广播超时（ActivityManagerService.java）
private static final int BROADCAST_FG_TIMEOUT = 10 * 1000;  // 10秒

// 后台广播超时
private static final int BROADCAST_BG_TIMEOUT = 60 * 1000;  // 60秒

// 服务超时
static final int SERVICE_TIMEOUT = 20 * 1000;  // 20秒

// ContentProvider超时
static final int CONTENT_PROVIDER_TIMEOUT = 10 * 1000;  // 10秒

避坑指南： 我曾经天真地以为修改这些常量就能延长ANR时间——千万别！这些是系统源码，普通应用改不了。真想优化，只能从代码层面减少主线程耗时。

ANR触发机制知识图谱

下面这张图梳理了ANR从发生到弹窗的完整链路。你可以对照着理解上文提到的流程。

从这个流程图可以清晰看到：超时定时器 + 探针确认是ANR判定的双保险。我曾经有个线上bug，用户反馈点不动但没弹ANR，一查日志发现后台广播超时了但应用被系统直接杀了——因为Android 12之后，后台ANR不再友好弹窗，而是默默干掉进程。所以，监控ANR不能只盯着弹窗，还得抓traces文件。

不同超时类型的实战要点

输入事件ANR
最常见，5秒内主线程不能处理触摸事件就炸。但有个细节：如果上次事件分派耗时已经超过4秒，新事件一到可能直接判定ANR（因为超时是累计的）。我建议用Choreographer监控帧绘制延迟，提前发现卡顿。

广播ANR
前台广播10秒，后台广播60秒。但广播接收器里不能做耗时操作——这点大家都知道，但容易被忽略的是：goAsync()虽然能异步处理，但如果异步线程没在规定时间内调用finish()，照样ANR。嗯，我踩过这个雷。

服务ANR
20秒超时，通常发生在onCreate()或onStartCommand()中。如果你在主线程做网络请求或者I/O，服务就等着卡死吧。建议用IntentService或JobIntentService。

ContentProviderANR
Provider首次发布时10秒超时，冷启动时如果Provider的onCreate()做了数据库建表、大数据加载，很容易ANR。我处理过一个案例：某个第三方SDK的Provider在onCreate()里下载配置文件，直接导致应用启动就ANR。

小结一下

ANR触发机制说白了就是系统用"超时+探针"的组合来监控主线程健康。不同场景的超时时间差异巨大，不能一概而论。你想想看，5秒的输入ANR和60秒的后台广播ANR，完全是两个级别的容忍度。但不管哪种，核心问题永远是主线程被阻塞了。