认识ANR：不只是个弹窗那么简单

ANR，全称 Application Not Responding，也就是应用无响应。说白了，就是系统觉得你的 App 卡住了，点了没反应，超时后弹出一个对话框问用户「是要继续等，还是直接关掉？」。

我第一次遇到 ANR，是在一个视频编辑项目里。用户上传大文件时，整个界面冻结了十几秒。当时我就想：完了，用户肯定要骂了。后来追踪发现，是耗时操作直接跑在主线程上了。嗯，这个教训我记得很清楚。

ANR 到底长什么样？

系统会监控你的主线程（UI线程）是否被阻塞超过5秒（输入事件）、10秒（广播接收器）或20秒（服务）。一旦超时，就会向用户弹出一个无响应对话框：

// 典型的ANR日志片段（trace.txt）
"main" prio=5 tid=1 Blocked
  at com.example.app.MainActivity.doSomething(MainActivity.java:42)
  - waiting to lock <0x12345678> (a java.lang.Object)
  at ... 

看到这种堆栈，基本就锁定问题了。我一般会先看主线程在等什么锁，还是单纯在做耗时计算。

ANR 对用户体验的打击

你想想看，一个 App 用着用着突然卡死，然后弹窗问你要不要关掉。用户的第一反应肯定是「这 App 垃圾」。更严重的是，系统可能会在后台记录这个 ANR 事件，并影响 App 的稳定性评分——这直接关系到应用市场的推荐排名。

我统计过一张内部表格，大家可以感受一下：

一句话总结：ANR 是用户流失的隐形杀手。

ANR 的几种分类

Android 系统对 ANR 的触发条件有明确规定，我根据实际项目经验归纳成以下五种：

1. 输入事件超时 ANR——主线程5秒内没有处理完输入事件（如触摸、按键）。最常见。
2. 广播接收器超时 ANR——前台广播10秒、后台广播60秒内未执行完 onReceive 方法。
3. 服务超时 ANR——前台服务20秒、后台服务200秒内未执行完 onCreate、onStartCommand 或 onBind。
4. ContentProvider 超时 ANR——ContentProvider 的 publish 操作超过10秒未完成。
5. Jank 累积型 ANR（Android 12+）——由于频繁丢帧导致系统判断为 ANR，其实是一种新的「卡顿惩罚」机制。

一张图搞懂 ANR 分类与影响

下面这张 SVG 图帮你梳理 ANR 的触发类型、判断标准和最终影响，方便记忆：

避坑指南：我踩过的一些坑

• 千万不要在 BroadcastReceiver 的 onReceive 里做网络请求——我曾经写过一个「接收网络状态变化后上传日志」的广播，结果在弱网下直接等了20秒，ANR 频发。
• 不要在主线程里操作数据库——即使是 Room，如果你在主线程调用一个需要大量IO的查询，一样会卡死。正确的做法是用异步查询或 allowMainThreadQueries()（仅限调试）。
• 小心死锁——我在一个直播项目中遇到过，主线程拿锁A、子线程拿锁B，彼此等待，结果主线程卡死触发 ANR。当时用 systrace 才定位到这个死锁。
• SharedPreferences 的 commit 操作——也是主线程的坑。 commit 是同步写入，如果数据量大或者磁盘慢，就会卡住主线程。建议用 apply 或者改用 MMKV 等替代方案。