ANR 概述
什么是 ANR？
ANR 的全称是 Application Not Responding，中文叫「应用无响应」。说白了，就是你的 App 主线程被卡住了，系统觉得你太久没干活，直接弹个对话框告诉用户：「这个 App 罢工了，你要不要关掉它？」。
我个人习惯把 ANR 理解成 Android 系统给开发者设的一道 红线。你主线程必须在一定时间内完成关键任务，否则就触发。这个时间限制因场景不同而不同，下面我会细说。
ANR 的触发条件
我遇到过不少新手问：「为什么我代码里一个循环就会 ANR？」其实不是随便卡一下就触发，系统给不同场景设了不同的 超时阈值。下表整理了我日常排查中最常见的几类：
| ANR 类型 | 触发场景 | 超时时间 |
|---|---|---|
| Input 事件超时 | 主线程 5s 内未处理完触摸/按键事件 | 5 秒 |
| Service 超时 | Service 的 onCreate/onStartCommand 执行超过 20s | 20 秒 |
| BroadcastReceiver 超时 | 广播 onReceive 在主线程执行超过 10s（前台）/ 60s（后台） | 10s / 60s |
| ContentProvider 超时 | ContentProvider 的创建或查询超过 20s | 20 秒 |
嗯，这里要注意：Input 超时 其实是我们日常遇到最多的。用户点了个按钮，5 秒没反应，系统就判定 ANR。我曾经在项目里遇到过连续两次启动 Activity 中间加了大量文件读写，结果用户狂点屏幕，直接引发 Input ANR，连弹两次对话框。
ANR 的常见表现
你想想看，用户看到 ANR 时屏幕上会出现什么？
- 系统弹窗：「XXX 应用无响应」，包含「等待」和「关闭」两个按钮。
- 部分老机型或定制 ROM 上，弹窗样式不一样，但本质相同。
- 有些系统会直接弹出「强制关闭」或「报告」选项。
除了弹窗，其实还有一个隐藏表现：界面完全无响——滑动列表不跟手、按钮点击没反馈、甚至返回键都没用。我调过一台低端机，用户反馈「点了一下搜索就死机了」，抓了 traces.txt 发现主线程正阻塞在 SharedPreferences 的磁盘写入上，整整卡了 8 秒。
ANR 对用户体验的影响
这个部分我用三个关键词总结：中断、失望、流失。
- 中断当前操作：用户正在阅读、输入、游戏，一个 ANR 弹窗直接打断流程。很多人会直接关掉应用。
- 负面品牌印象：用户会认为这个 App 「卡死了」「垃圾应用」。我见过真实案例，某个电商 App 在双十一大促时因为订单详情页的图片解码 ANR 频发，当天差评率飙升 30%。
- 业务流失：如果 ANR 发生在支付、下单等关键路径上，用户极有可能放弃操作，转而投靠竞品。数据表明，ANR 率每上升 0.1%，用户次日留存率下降约 0.5%。
ANR 发生路径与影响
下面这张图可以帮你理清从事件触发到用户感知的全过程。你看，ANR 不是瞬间发生的，它经过了一系列判断和超时计数。理解这个链路，才知道在哪个环节下手拦截。
总结
ANR 并不是一个神秘的问题。它本质是 Android 系统的自我保护机制，在威胁用户体验之前发出警告。但对我们开发者来说，每一次 ANR 都是一次信任透支。我个人习惯把 ANR 率作为线上监控的核心指标之一，配合日志和堆栈分析，可以快速定位阻塞点。