ANR 触发机制与分类：触发条件、系统日志位置、关键时间阈值

ANR（Application Not Responding）是 Android 系统针对应用主线程（UI 线程）阻塞过久的一种保护机制。理解其触发条件、时间阈值以及系统日志的提取位置，是进行 ANR 治理的第一步。本节将剖析 ANR 的核心触发原理，并提供一个清晰的分类框架。

1.1 ANR 触发条件与核心时间阈值

系统通过一个“心跳检测”机制来监控主线程的响应能力。每当主线程处理完一个关键消息（如输入事件、广播、服务启动命令）后，系统会为其设置一个“超时闹钟”。如果在规定时间内主线程没有处理完毕并返回，系统就会触发 ANR。

不同类型的操作具有不同的超时阈值，如下表所示：

1.2 ANR 系统日志与 Trace 文件位置

当 ANR 发生时，系统会在设备本地生成两份关键证据：事件日志 (Event Log) 和 Trace 文件。开发者需要知道如何提取它们。

1. 事件日志 (Logcat 中的 Event 缓冲区)
事件日志记录了 ANR 发生的概览信息，包括进程名、ANR 类型、CPU 负载等。可以通过以下命令直接过滤：

# 过滤 ANR 事件
adb logcat -b events | grep "am_anr"

输出示例：

01-01 12:00:00.000  1000  1123  1123 I am_anr  : [0,12345,com.example.app,957184433,Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms timeout.  Wait queue length: 2.  Wait queue head age: 5751.6ms.)]

2. Trace 文件 (细节堆栈)
这是最核心的故障诊断文件，记录了发生 ANR 时刻所有线程的堆栈信息。文件路径根据 Android 版本有所不同：

• Android 10 及以下： /data/anr/traces.txt
• Android 11 及以上： /data/anr/anr_<进程名>_<时间戳>.trace （或 /data/system/anr/）

提取命令：

# 拷贝到本地进行分析
adb pull /data/anr/ ./
# 或者直接查看最近的 trace 文件内容
adb shell cat /data/anr/your_app_trace.trace

1.3 ANR 触发机制的核心流程

下图概括了系统从监控到生成 Trace 文件的全过程，这是理解后续堆栈分析的基石。

1.4 ANR 分类实战：从日志判定类型

在分析 trace 文件之前，通常先查看 am_anr 日志来确认 ANR 的具体分类。以下是三种最典型的日志模式：

• Input ANR： 日志包含关键词 Input dispatching timed out。通常是由于主线程在执行 Layout、绘制或响应触摸事件时耗时过长。这类 ANR 对用户体验影响最大。
• Broadcast ANR： 日志包含关键词 Broadcast of Intent + 超时信息。常见原因是在 onReceive() 中执行了网络请求、数据库写入或文件 I/O 等耗时的同步操作。
• Service ANR： 日志包含关键词 Service did not execute within。多见于 onStartCommand 中执行了繁重的后台任务而未及时切换到工作线程。