4、ANR问题分析基础：ANR的定义、触发场景、超时机制
各位同学，今天我们来聊聊ANR。说实话，ANR是Android系统稳定性里最让人头疼的问题之一。我刚开始做系统开发那会儿，一看到ANR日志就头大，满屏的堆栈信息根本不知道从哪看起。后来踩的坑多了，慢慢就摸清了门道。
ANR，全称是Application Not Responding，也就是应用无响应。说白了，就是系统觉得你的App太慢了，卡住了，用户等得不耐烦了。系统就会弹出一个对话框，问用户是「继续等待」还是「关闭应用」。嗯，这个对话框大家应该都见过。
核心定义：ANR是Android系统对应用主线程（UI线程）长时间阻塞的一种监控机制。当主线程在规定时间内没有完成特定操作，系统就会判定为ANR。
4.1 ANR的触发场景
ANR不是随便触发的，它有明确的触发条件。我把它归纳为三大类：Service超时、Broadcast超时、Input超时。咱们一个一个来看。
4.1.1 Service超时
Service的ANR触发场景主要有两种：
- 前台Service：执行时间超过20秒
- 后台Service：执行时间超过200秒
你可能会问，为什么前台和后台的阈值差这么多？其实道理很简单——前台Service用户能直接感知到，所以要求更严格。后台Service嘛，用户看不见，系统就宽容一些。
我的经验：我在项目中遇到过一个问题，某个Service在后台做大量数据库操作，结果用户切到前台后，Service还在跑，直接触发了ANR。后来我把耗时操作扔到子线程里，问题就解决了。记住，Service的onStartCommand()是跑在主线程的！
4.1.2 Broadcast超时
BroadcastReceiver的超时机制更严格：
- 前台广播：执行时间超过10秒
- 后台广播：执行时间超过60秒
这里有个坑，我必须要提醒大家。广播接收器的onReceive()方法默认也是跑在主线程的。如果你在里面做了网络请求或者文件读写，那基本就是等着ANR了。
避坑指南：我曾经在一个项目中，直接在onReceive()里调用了Thread.sleep(15000)来模拟耗时操作。结果你猜怎么着？系统直接弹了ANR对话框。后来我改用goAsync()配合子线程处理，才搞定。
4.1.3 Input超时
Input超时是最常见的ANR类型，也是用户感知最明显的。它的触发条件是：
- 按键/触摸事件：5秒内没有处理完成
说白了，就是用户点了屏幕，系统把事件发给了你的App，但你的App主线程卡住了，5秒内没响应。用户就会看到那个烦人的对话框。
为什么会这样？我分析一下常见原因：
- 主线程在做耗时操作（网络、IO、计算）
- 主线程被锁阻塞（死锁、锁竞争）
- 主线程在做大量View绘制（布局嵌套太深）
- Binder调用卡住（跨进程通信超时）
4.2 超时机制详解
系统是怎么判断ANR的？说白了，就是靠一个「定时炸弹」——Handler + 消息机制。我画个简单的流程图给你看：
// 伪代码示意
// 系统在发送消息时，会同时发送一个延迟消息作为"定时炸弹"
sendMessage(msg);
sendMessageDelayed(ANR_TIMEOUT_MSG, TIMEOUT_DURATION);
// 如果正常消息处理完了，就移除"定时炸弹"
handleMessage(msg) {
removeMessages(ANR_TIMEOUT_MSG);
// 处理正常逻辑
}
// 如果"定时炸弹"先触发了，说明超时了
handleMessage(ANR_TIMEOUT_MSG) {
// 生成ANR
appNotResponding();
}这个机制其实很巧妙。系统在派发一个任务给主线程时，同时启动一个定时器。如果任务在规定时间内完成了，定时器就被取消。如果定时器先到期了，那就说明任务超时了，系统就会生成ANR。
4.2.1 各组件超时时间汇总
| 组件类型 | 前台超时 | 后台超时 |
|---|---|---|
| Service | 20秒 | 200秒 |
| BroadcastReceiver | 10秒 | 60秒 |
| Input事件 | 5秒 | 5秒 |
| ContentProvider | 10秒 | 10秒 |
注意：ContentProvider的超时机制比较特殊，它是在publish()过程中触发的，平时不太常见。但如果你自己实现了一个ContentProvider，记得别在onCreate()里做耗时操作。
4.3 如何定位ANR问题
好了，理论讲完了，咱们来点实战的。遇到ANR怎么查？我一般按这个步骤来：
- 看trace文件：ANR发生时，系统会生成
/data/anr/traces.txt文件。这里面记录了所有线程的堆栈信息。 - 找主线程：在trace文件里找到"main"线程，看它卡在哪个方法上。
- 分析锁状态：如果主线程在等待锁，看看其他线程是不是持有了锁没释放。
- 看CPU使用率：ANR日志里会记录CPU使用情况，如果CPU跑满了，可能是线程太多或者死循环。
我的小技巧：我个人习惯用adb pull /data/anr/traces.txt把文件拉到本地，然后用Sublime Text打开。搜索"main"关键字，很快就能定位到主线程的堆栈。如果看到nativePollOnce，那说明主线程在等消息，不是ANR的根因。真正的问题往往在nativeCall或者BinderProxy.transact这些地方。
4.4 总结
ANR问题分析，说白了就是三个步骤：
- 知道什么场景会触发ANR（Service、Broadcast、Input）
- 知道超时时间是多少（5秒、10秒、20秒...）
- 知道怎么查trace文件（找主线程、看锁、看CPU）
你想想看，掌握了这些基础，再遇到ANR问题，是不是心里就有底了？下一章我会讲具体的案例分析，到时候咱们一起手撕几个真实的ANR日志。
嗯，今天就到这里。记住一句话：主线程不要做耗时操作，这是铁律。