UI 线程与主线程阻塞原理：Looper、MessageQueue、ANR 阈值、Systrace 定位

Android 应用的 UI 更新、触摸事件分发、生命周期回调全部运行在单一的主线程（又称 UI 线程）。这个线程的核心是 Looper + MessageQueue + Handler 三元组构成的异步消息循环。一旦消息循环被长时间阻塞，系统会触发 ANR（Application Not Responding），这是影响用户体验和耗电的最常见根源之一。本章从内部原理切入，分析阻塞场景，并借助 Systrace 完成精准定位。

1. 主线程消息循环机制

每个 Android 进程的主线程在启动时会调用 Looper.prepare() 创建唯一的 Looper 对象，然后执行 Looper.loop() 进入无限循环。循环内部反复从 MessageQueue 取出 Message，交给对应的 Handler 回调处理。一次消息处理的完整流程包含：入队（queue.next） → 分发（dispatchMessage） → 回调执行。如果回调执行时间超过系统阈值，则触发 ANR。

2. ANR 类型与阈值

系统根据输入事件、广播、服务、ContentProvider 等不同场景设置不同的超时阈值。主线程阻塞超过阈值时，系统会显示 ANR 对话框并输出 /data/anr/traces.txt。

3. 模拟主线程阻塞与 ANR 触发

在 Kotlin 中，直接在 onClick 或 onCreate 里调用 Thread.sleep(6000) 即可复现输入事件 ANR。注意：纯 Thread.sleep 不会导致耗时操作上报，但系统仍会检测到主线程无响应。

// MainActivity.kt
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        findViewById(R.id.btn_block).setOnClickListener {
            // 在主线程执行耗时操作，阻塞6秒 > 5秒 ANR 阈值
            Thread.sleep(6000)
            Toast.makeText(this, "完成", Toast.LENGTH_SHORT).show()
        }
    }
}

运行后点击按钮，大约 5 秒后屏幕出现 "应用无响应" 对话框。此时通过 adb 可抓取 ANR trace：

# 获取 ANR traces 文件（需要 root 或 adb bugreport）
adb shell cat /data/anr/traces.txt | grep -A 30 "main"

在输出中可以看到类似 at java.lang.Thread.sleep(Native Method) 的调用栈，以及 "waiting on ..." 信息。

4. 使用 Systrace 精准定位卡顿

Systrace（已被 Perfetto 继承，但传统 systrace.py 仍可用）可以通过 Trace 标签 记录主线程消息处理的时间轴。推荐在代码中手动添加 Trace.beginSection() 和 Trace.endSection() 来标记关键函数。

抓取步骤：

1. 连接设备，进入 $ANDROID_HOME/platform-tools/systrace/ 目录。
2. 执行命令：

   python systrace.py -a com.example.yourapp -o trace.html sched freq idle view input am wm

3. 在 App 中触发卡顿操作，等待 ANR 对话框出现后按 Ctrl+C 停止抓取。
4. 用 Chrome 浏览器打开 trace.html，查看主线程（通常标为 "tid=1" 或 "UI Thread"）的 Slice。卡顿区域会显示一个长条的 "B|E" 标记。

5. 常见阻塞原因与优化方向

• IO 操作：在主线程读写文件、SharedPreferences（注意 apply 异步）或数据库（query 应使用 ContentResolver.query(..., null, null) 或 Room 协程）。
• 网络请求：使用 Retrofit + OkHttp 时必须切换到 IO 线程（Dispatchers.IO）。
• 位图解码：BitmapFactory.decodeResource 可能耗时 > 100ms，应放入子线程。
• 布局嵌套过深：measure/layout 也可能占用主线程 > 5ms，需使用 Layout Inspector 或 GPU 过度绘制检测。
• 锁竞争：主线程意外持有一个长时间被占用的锁（如 HandlerThread 内的锁），导致 Binder 线程等待。

6. 通过 Looper 检查器预防卡顿

Android 提供了 Looper.getMainLooper().setMessageLogging() 接口，可以监听每个消息的处理耗时。利用它可以在开发阶段实时检测超过阈值的慢消息：

Looper.getMainLooper().setMessageLogging { logMsg ->
    if (logMsg.startsWith(">>>>> Dispatching")) {
        // 记录开始时间
        startTime = SystemClock.uptimeMillis()
    } else if (logMsg.startsWith("<<<<< Finished")) {
        val cost = SystemClock.uptimeMillis() - startTime
        if (cost > 16) { // 单帧 16ms 作为一个卡顿阈值
            Log.w("UIBlock", "消息处理耗时 ${cost}ms，请检查回调堆栈")
        }
    }
}

7. 总结：定位阻塞的通用流程

1. 复现 ANR 或明显卡顿。
2. 从 /data/anr/traces.txt 或 ADB bugreport 获取原始调用栈。
3. 使用 Systrace/Perfetto 抓取时间轴，观察主线程消息执行时长。
4. 结合自定义 Trace 标签，定位到耗时函数。
5. 判断是否属于 IO、网络、计算、锁竞争或过度绘制，并制定优化方案（移至子线程、缓存、优化算法等）。