Android ANR 定位与治理：从主线程阻塞到线上证据闭环
ANR（Application Not Responding）并不等于“应用崩溃”。它表示系统发现应用在规定时间内没有响应关键事件，于是向用户展示无响应对话框，或者在后台留下相关记录。对用户来说，ANR 往往比普通崩溃更令人困惑：页面还停留在屏幕上，却怎么点都没有反应。
真正困难的地方不在于记住几个超时阈值，而在于回答三个问题：哪个线程阻塞了响应、它在等待什么、为什么只在某些设备或场景发生。本文从机制、证据采集、典型问题到工程治理，建立一套可复用的排查方法。
ANR 为什么通常与主线程有关
Android 的界面绘制、输入事件分发、生命周期回调和大部分组件回调都运行在主线程。主线程通过 Looper 不断从 MessageQueue 取出任务执行。只要某个任务占用主线程太久，后面的输入、绘制和生命周期消息就无法及时处理。
常见触发场景包括：
- 输入事件长时间没有被处理，例如点击后主线程执行大批量计算。
BroadcastReceiver的回调执行过久，或者异步处理没有按时结束。- 前台服务启动后，没有及时调用
startForeground()。 ContentProvider初始化或访问耗时，拖住应用启动和跨进程调用。- 主线程发生锁等待、Binder 阻塞、磁盘 I/O 或网络等待。
系统最终报告的是“应用未响应”，但根因可能在其他线程。例如工作线程持有一把锁，主线程恰好在等待这把锁；此时主线程堆栈只展示锁等待，真正需要修复的是工作线程的临界区。
先判断是慢，还是彻底卡住
排查 ANR 时，不要看到主线程堆栈就立即修改代码。先把问题分成两类：
持续阻塞：死锁、无限循环、无法返回的 Binder 调用等问题会让线程长期停在相似位置。多次抓取堆栈时，调用栈通常基本不变。
阶段性耗时：数据库迁移、大 JSON 解析、类初始化、图片解码等任务最终能够完成，只是超过了系统容忍时间。连续堆栈可能落在同一段任务的不同位置，系统 Trace 中也能看到主线程持续处于运行状态。
这个区分会影响优化策略。持续阻塞需要消除等待关系或修复逻辑错误；阶段性耗时则需要搬离主线程、拆分任务、减少工作量或调整执行时机。
建立证据链：不要只看一张堆栈
一次可靠分析至少需要以下信息：
- ANR 类型、发生时间、进程和前后台状态。
- 主线程以及相关工作线程的完整堆栈。
- 事发前后的系统负载、内存压力和线程调度情况。
- 对应版本、设备、系统版本及用户操作路径。
- 同一问题的出现频率和聚类特征。
本地复现时，可以先通过 ADB 观察进程和日志：
adb shell pidof com.example.app
adb logcat -v threadtime
adb shell dumpsys activity processes
需要分析线程调度、Binder 或 I/O 时，应抓取 Perfetto Trace。Android Studio 的 System Trace 也提供了更直观的入口。关注主线程在问题窗口内是 Running、Runnable、Sleeping 还是锁等待，并沿着唤醒关系寻找真正占用资源的线程。
线上环境可以结合 Google Play Console 的 Android Vitals、应用性能监控平台和自建埋点。不要上传用户敏感数据；日志只保留诊断需要的操作阶段、任务耗时和脱敏标识。
典型问题：主线程执行磁盘 I/O
下面的代码看似简单，却可能在低端设备、文件膨胀或存储繁忙时制造卡顿：
fun loadConfig(context: Context): Config {
val text = context.filesDir
.resolve("config.json")
.readText()
return json.decodeFromString(text)
}
如果它在 Application.onCreate() 或 Activity 的生命周期回调中直接调用，文件读取和反序列化都会占用主线程。可以使用协程明确切换调度器：
class ConfigRepository(
private val context: Context,
private val json: Json,
private val ioDispatcher: CoroutineDispatcher = Dispatchers.IO,
) {
suspend fun load(): Config = withContext(ioDispatcher) {
val text = context.filesDir
.resolve("config.json")
.readText()
json.decodeFromString(text)
}
}
切换到 I/O 线程并不是终点。还要考虑调用方是否重复加载、结果是否可缓存、失败时如何降级，以及页面是否真的需要等待完整配置后才能展示。
典型问题：锁竞争把主线程拖住
假设缓存更新在工作线程中执行，而主线程读取时使用同一把锁：
private val lock = Any()
private val cache = mutableMapOf<String, Item>()
fun replaceAll(items: List<Item>) = synchronized(lock) {
cache.clear()
items.forEach { cache[it.id] = it }
}
fun get(id: String): Item? = synchronized(lock) {
cache[id]
}
当 replaceAll() 处理大量数据时，主线程调用 get() 就可能长时间等待。改进思路不是简单“多加一把锁”，而是缩小临界区：先在锁外构建不可变快照，再快速替换引用。
@Volatile
private var snapshot: Map<String, Item> = emptyMap()
fun replaceAll(items: List<Item>) {
val next = items.associateBy(Item::id)
snapshot = next
}
fun get(id: String): Item? = snapshot[id]
实际项目中还要根据一致性要求选择 Mutex、原子引用、单线程执行器或数据库事务。核心原则是：主线程不应等待不可控时长的临界区。
典型问题：Binder 调用看起来很轻
访问系统服务、跨进程 Provider 或远程 Service 时，代码表面上只是一个方法调用，底层却可能发生 Binder IPC。远端进程繁忙、锁竞争或返回数据过大时，调用方会被阻塞。
因此，不要仅凭 API 形式判断它是否适合主线程。对耗时不确定的 IPC 应记录调用耗时，必要时移到后台线程，并设计超时、取消和降级策略。对于高频调用，可以批量查询、缓存稳定结果，避免在列表绑定或绘制路径上反复跨进程访问。
用 StrictMode 提前暴露主线程违规
开发环境可以启用 StrictMode，尽早发现主线程磁盘和网络操作：
if (BuildConfig.DEBUG) {
StrictMode.setThreadPolicy(
StrictMode.ThreadPolicy.Builder()
.detectDiskReads()
.detectDiskWrites()
.detectNetwork()
.penaltyLog()
.build()
)
}
StrictMode 是预警工具，不是 ANR 检测器。它无法发现所有锁竞争、CPU 密集任务或第三方 SDK 内部问题，也不适合把所有告警直接变成线上崩溃。更合理的方式是在开发和测试构建中启用，并逐步清理高频违规。
线上排查的实用流程
收到 ANR 告警后，可以按下面的顺序推进：
- 按版本、机型、系统和 ANR 类型聚类，确认影响面。
- 将发生时间与发布、配置下发、后台任务和用户路径对齐。
- 检查主线程状态，识别 CPU 执行、锁等待、I/O 或 Binder 阻塞。
- 沿锁持有者、Binder 对端或任务提交链继续追踪，找到根因线程。
- 使用接近线上条件的数据量和设备复现，并抓取连续堆栈及 Trace。
- 修复后通过基准测试、压力场景和灰度指标验证，而不是只确认“本地不卡了”。
每次修复都应留下可验证的指标，例如主线程任务的 P95/P99 耗时、启动阶段磁盘读取量、特定 IPC 调用时长，以及 Android Vitals 中受影响用户比例。只有指标回落，治理才算形成闭环。
从修复个案升级为工程治理
ANR 很少靠一次专项彻底解决。更有效的做法是把约束放进日常研发流程：
- 为主线程关键任务增加轻量耗时监控，并设置合理采样率。
- 对启动初始化进行分级，只保留首屏必须同步完成的工作。
- 在代码评审中重点检查生命周期回调、Receiver、Provider 和 Binder 调用。
- 使用 Macrobenchmark 或真实场景性能测试覆盖启动、页面切换和长列表操作。
- 将线上 ANR 按堆栈特征聚类，持续跟踪高影响问题的回归情况。
- 对第三方 SDK 建立版本、初始化耗时和降级开关，避免失控依赖阻塞主线程。
总结
ANR 的表象是应用没有响应，根因却可能分布在主线程计算、磁盘 I/O、锁持有者、Binder 对端或组件时限之中。有效排查需要把线程堆栈、系统 Trace、业务路径和线上指标连成证据链。
治理的关键也不是机械地把所有代码丢到后台线程，而是控制主线程任务的最坏耗时，消除不可控等待，并让每次修复都能被数据验证。做到这一点，ANR 才会从偶发且难复现的问题，变成可以持续观测和系统治理的工程指标。
