第2章：主线程阻塞根因分类：死锁、耗时IO、长时计算、Binder等待、锁竞争

主线程阻塞并非单一问题，而是多个根因的聚合表现。将根因归纳为五类——死锁、耗时IO、长时计算、Binder等待、锁竞争——是ANR治理的第一步。每一种阻塞模式都有其独特的信号特征、采集方法和修复路径。本章以“现象识别→数据采集→原因定位→修复动作→复测→预防”为主线，为每个根因建立排查规则。

2.1 现象识别：五类阻塞的外在表现

不同的根因会留下不同的“现场痕迹”。以下判断规则帮助你从ANR对话框出现前的用户行为、系统日志关键词快速定位方向。

2.2 数据采集：工具与命令

当ANR发生时，立即采集以下数据。采集动作必须在确认ANR后的30秒内执行，以免关键线程状态被回收。

1. logcat 全量抓取
   
   命令执行后保存至traces.log，用于后续分析系统服务超时标记。

   adb logcat -b all -d > traces.log

2. dumpsys activity anr 获取ANR列表
   
   该命令会输出最近5个ANR的记录，包含发生时间和最核心的trace摘要。

   adb shell dumpsys activity anr

3. adb shell 获取完整trace文件
   
   Android 11及以上需要先通过root或adb权限读取/data/anr目录。

   adb shell ls -l /data/anr/    # 查看最近的trace文件
   adb shell cat /data/anr/<traces_file> > anr_trace.txt

4. 使用StrictMode提前捕获IO/锁违规
   在release包未正式部署前，在debug包中启用StrictMode可提前暴露阻塞风险。
   
   StrictMode的日志输出位置：android.os.StrictMode: policy violation

   StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
           .detectDiskReads()   // 检测主线程读磁盘
           .detectDiskWrites()  // 检测主线程写磁盘
           .detectResourceMismatches()
           .penaltyLog()        // 仅log不抛异常
           .build());

2.3 原因定位：症状→根因的映射规则

以下“排查表”用于从trace字段快速确定根因类别。判断时优先搜索字符串，无需通读完整堆栈。

2.4 修复动作：针对五类根因的定向修复

每种根因的修复策略差异极大。以下为已验证的工程级修复方向。

1. 死锁修复：保证全局锁顺序一致；引入超时机制（tryLock）；或改用无锁数据结构。
2. 耗时IO修复：主线程中所有磁盘/网络/数据库操作迁移至子线程。使用AsyncTask、HandlerThread或Coroutines；数据库开启WAL模式并合并事务。
3. 长时计算修复：拆分计算任务到Worker；使用WorkManager；或优化算法，使用SparseArray代替HashMap等。
4. Binder等待修复：使用IHwBinder异步回调；在收到结果前先显示占位UI；对系统服务调用增加超时控制。
5. 锁竞争修复：减小临界区；使用ReadWriteLock；使用ConcurrentHashMap或CopyOnWriteArrayList；减少主线程持锁时间。

2.5 复测：验证修复有效性

修复后必须复测。核心方法：恢复ANR触发条件（如快速点击、大文件加载、频繁锁请求），确认以下三点：

• UI保持60fps，无卡顿感
• logcat中不再出现上述定位关键词
• adb shell dumpsys activity anr 列表不再增长

2.6 预防：将根因扼杀在编码阶段

在项目早期引入系统化的预防机制，能让ANR治理事半功倍。