📚 课程目录第2章主线程阻塞原理

第2章：主线程阻塞原理——Handler机制、Looper.loop() 与 MessageQueue 瓶颈

2.1 现象识别

当用户触摸屏幕或执行系统操作时，若主线程被阻塞超过特定阈值（触摸事件 5 s、广播 10 s、服务 20 s），系统将弹出 ANR 对话框。日志中出现以下关键特征：

ANR in —— 明确哪个组件发生 ANR
Input dispatching timed out —— 输入事件分发超时
Dispatching to took … ms —— 某个视图处理事件耗时过长
Reason: keyDispatchingTimedOut / executing service / broadcast of Intent

💡 快速判断规则： 如果在 logcat 中连续 2 次以上出现“Input dispatching timed out”且堆栈指向 android.os.Handler.dispatchMessage()，则 90% 为主线程 Handler 阻塞。

2.2 数据采集

获取 ANR 时主线程的调用栈与消息队列状态：

核心日志：/data/anr/traces.txt 中包含每个线程的堆栈，定位主线程当前执行的函数。
实时工具：

# 抓取当前所有线程堆栈
adb shell dumpsys dropbox --print data_app_anr

# 监控实时主线程消息延迟
adb shell dumpsys activity processes

# 使用 systrace 截取输入事件与消息分发时间线
python systrace.py -t 5 -a 你的包名 sched freq input view

采集项	格式	关键字段
traces.txt 堆栈	`"main" prio=5 tid=1 Native at java.lang.Thread.sleep(Native Method) at com.example.MainActivity.onCreate(...) - locked <0x1234> (a android.os.Binder)`	tid=1 主线程，Native/Daemon 状态，锁地址
dumpsys activity	`Displayed com.example/.MainActivity: +2s100ms`	启动耗时 > 2s 预示主线程卡顿
Systrace 切片	选中主线程 slice "Looper.dispatch"	dispatch 时长若 > 300ms 直接标记为高耗时

2.3 原因定位——故障树分析法

将主线程阻塞原因分解为三个层级：

Looper.loop() 自循环等待 —— 当 MessageQueue.next() 返回 null 或进入 idle 时无阻塞，但若有同步屏障（sync=false消息）可导致低优先级消息无限等待。
MessageQueue 头部消息处理耗时 —— 当前消息的 Handler.handleMessage() 或 Runnable.run() 执行了 IO、网络、长循环、锁等待。
Binder 同步调用阻塞主线程 —— 主线程调用 Binder.transact() 并设置 FLAG_ONEWAY = false，响应超时。

🔍 排查判断表（使用 traces.txt 快速定位类型）

堆栈关键帧	阻塞类型	直接原因	推荐修复方向
`android.os.MessageQueue.next()` + `epollWait`	空等待（正常）	无待处理消息	检查是否遗漏 barrier 或系统调度问题
`android.os.Handler.handleCallback()` → 自定义 Runnable	消息执行超时	代码中直接执行了耗时运算或 IO	将耗时移至子线程 / HandlerThread
`android.os.BinderProxy.transact()` + `waitForResponse`	Binder 同步等待	远程 service 响应慢或死锁	改用 oneway 或异步 Binder 调用
`java.lang.Thread.sleep()` / `Object.wait()`	主动挂起	开发者故意 sleep 或 wait	严禁主线程 sleep；改用 Handler.postDelayed
`android.view.ViewRootImpl.performTraversals()` 累计多次	布局/绘制超时	重复测量、布局或过度绘制	优化 View 层级、使用 ConstraintLayout

2.4 修复动作

根据上表格定位到具体阻塞原因后，执行对应修复：

方案 A（耗时任务）： 使用 HandlerThread 或 Kotlin 协程 Dispatchers.IO 将 IO / 网络 / 大文件操作彻底移出主线程。
方案 B（锁竞争）： 检查主线程是否持有锁（- locked <0x...>），改用 synchronized 减小锁范围或替换为 ReentrantReadWriteLock。
方案 C（Binder 同步）： 将跨进程调用改为 oneway，或使用 android.os.Messenger 异步返回。
方案 D（barrier 问题）： 在子线程中避免发送 sync barrier，如需延时任务使用 sendMessageDelayed。

// 修复示例：将网络请求移出主线程（HandlerThread）
HandlerThread worker = new HandlerThread("NetworkWorker");
worker.start();
Handler workerHandler = new Handler(worker.getLooper());
workerHandler.post(() -> {
    // 执行耗时网络 IO
    String result = fetchFromNetwork();
    // 回到主线程更新 UI
    mainHandler.post(() -> updateUI(result));
});

2.5 复测验证

修复后必须执行以下验证步骤：

自动化压力测试： 使用 Monkey 或 UI Automator 模拟高频交互，持续 30 分钟以上。
启动延迟测量：

# 测量 Activity 启动到首帧完成时间
adb shell am start -W com.example/.MainActivity | grep TotalTime
# 预期 TotalTime < 300ms 为健康，> 800ms 应分析

手势流畅度验证： 开启 Profile GPU Rendering 查看柱状图是否持续在绿线 (16ms) 以下。
再次抓取堆栈： 运行 adb shell dumpsys dropbox --print data_app_anr 确认无新 ANR 记录。

2.6 预防策略

代码提交前检查： 在 CI 中插入 StrictMode，检测主线程磁盘读写、网络访问、长等待：

if (BuildConfig.DEBUG) {
    StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
        .detectDiskReads()
        .detectDiskWrites()
        .detectNetwork()
        .penaltyLog()
        .build());
}

定期监控： 集成 Firebase Performance Monitoring 或内部打点，建立“消息处理耗时 > 200ms”告警。
设计原则： 任何可能超过 1ms 的任务都假设子线程执行；对 Handler.postDelayed() 设置最长可接受延迟（如 300ms），超越即触发上报。
工具固化： 使用 Android Studio Profiler 的 CPU 记录 + 堆栈采样作为常规性能测试流程。

2.7 核心知识结构图

▲ 图中橙色节点为消息处理入口，红色节点为阻塞源头与 ANR 触发后果。验证时请结合 traces.txt 中 com.android.internal.os.HandlerCaller$Callback 等帧加以索引。