ANR概念与危害归纳总结
做Android开发这么多年，我碰到过不少让人头大的问题。但要说最让开发者焦虑的，ANR排前三。我自己刚入行时，第一次在线上看到ANR日志，脑子一片空白。今天咱们就把这个“拦路虎”彻底拆开来看。
什么是ANR？——不只是“卡死”那么简单
ANR的全称是Application Not Responding，翻译过来就是“应用无响应”。系统觉得你的App在耍大牌，不响应它的请求了，于是直接弹个对话框问用户：是继续等？还是关掉？
说白了，这就是系统对你主线程的一种“超时监控”。你想想看，如果用户点了一个按钮，主线程却去做了个网络请求，卡住5秒钟没反应，系统就会判定——这个App废了，得让它“醒醒”。
核心门槛：系统规定的主线程阻塞超时时间
- 输入事件（触摸/按键）：5秒
- 广播接收器（前台）：10秒 /（后台）：60秒
- Service（前台）：20秒 /（后台）：200秒
- ContentProvider：10秒
为什么会有不同时长？因为不同组件的“容忍度”不一样。我在项目中就遇到过，广播里做了个数据库写入，偶尔超10秒，以为后台没事，结果前台广播也超时——原来手机当时在低内存状态，IO变慢了很多。
ANR的常见触发场景
我归纳了最常见的几类“坑”，用表格列出来，方便你对照自己的代码排查。
| 场景 | 典型原因 | 我踩过的雷 |
|---|---|---|
| 主线程做网络请求 | 阻塞5秒以上 | 曾经在OnCreate里直接OkHttp同步请求，用户狂点按钮，ANR率飙升到3% |
| 广播中执行耗时操作 | onReceive()里跑数据库/文件IO | 接收系统锁屏广播做数据清理，用户锁屏解锁几次就ANR |
| 主线程死锁 | 两个线程互相持有锁等待 | 自己写的线程池和主线程共用同一个锁，排查了一整天 |
| Binder调用阻塞 | 与系统服务交互卡住 | 在Service里调bindService后未超时处理，系统等20秒直接杀 |
| 动画或布局过度复杂 | 单帧渲染超过16ms累积 | 一个ListView嵌套了四个层级的Layout，滚动起来UI线程没法处理触摸事件 |
避坑指南：我曾经犯过的错——在BroadcastReceiver里直接执行SharedPreferences写入，以为量小没事。结果用户手机存储快满时，写入耗时飙到几十秒。后来我改了：所有非UI操作一律扔IntentService或WorkManager。
ANR的危害——不仅仅是用户体验问题
ANR带来的影响是链条式的。我把它拆成三个层面来看：
- 用户直接流失 —— 弹出“强制关闭”对话框，大部分用户会选择关掉App，甚至去应用商店打一星差评。我见过一个电商App因为ANR率超过5%，月活用户直接下降12%。
- 系统资源浪费 —— ANR发生后，系统会强行杀死进程，导致之前的缓存、状态全丢。下次启动又重新初始化，耗费更多电量、流量。
- 开发团队背锅 —— 很多公司把ANR率作为App质量核心指标，一旦超标，版本可能被否决。我记得有一次发布前夜，QA发现ANR率突然升高到2.3%，整个团队通宵查问题。
警告：千万不要以为“我的App只在后台收到ANR，用户没看到弹窗就没事”。系统会记录所有ANR事件，很多应用商店的自动审核机制会直接读取ANR率数据，超过阈值会禁止更新版本。我朋友的项目就因为后台ANR率过高，被商店直接下了架。
我的ANR排查经历
讲一个真实案例吧。曾经有个版本上线后，线上ANR率从0.1%突然跳到1.8%。日志里都是Input dispatching timed out，指向一个Fragment的onResume方法。但我看了半天代码，没发现主线程有明显阻塞。
后来我把systrace抓下来一分析，发现是ViewPager的预加载+一个自定义动画库，在主线程里做了Bitmap的decodeResource操作。虽然每次只有几十毫秒，但几个页面预加载叠加起来，刚好超过5秒阈值。其实这个问题的根因就一句话：不要在主线程做任何图片解码。
嗯，这里要注意：ANR并不总是有一个“罪魁祸首”占据5秒，它可能是多个小延迟累积的结果。就像咱们平时说的“压死骆驼的最后一根稻草”。
知识体系图
下面这张图是我自己画的ANR全景，把概念、触发条件、危害串起来，方便你建立整体认知。
个人习惯：每接手一个新项目，我第一件事就是去后台看ANR率趋势。如果发现某个版本突然升高，我会拉取那段时间的traces.txt，用grep "main"快速定位主线程堆栈。嗯，这个习惯帮我提前发现了不少隐患。
总之，ANR不是一个遥不可及的问题。它就在你的主线程里，等着你犯错。今天我们先打好概念基础，后面我会带你一步步拆解真正的复现和定位方法。