3. Main Thread任务排查：消息队列深度、耗时Handler、布局渲染锁

3.1 现象识别

当应用出现以下现象时，极可能是主线程任务过载导致卡顿：

• 列表滑动卡顿：手指滑动列表时画面跳跃、掉帧明显（连续多次超过16ms）。
• 点击响应延迟：按下按钮后界面超过100ms才有视觉反馈。
• 页面打开慢：Activity/Fragment启动时黑屏或白屏时间>200ms。
• ANR：系统弹出“应用无响应”对话框。

这些现象的本质是主线程Looper的消息循环被阻塞或积压，导致Choreographer无法及时处理VSYNC信号进行帧渲染。

3.2 数据采集

使用 CPU Profiler 或 Systrace 抓取主线程执行轨迹，重点关注以下指标：

3.3 原因定位

拿到Trace后，按以下根因分类树逐层排查：

1. 消息队列深度过大：主线程MessageQueue中积压了多个待处理的消息（如不断post的Runnable、定时器回调）。
   判断规则：在Profiler中查看“msg dispatch”事件的间隔是否越来越长，或消息队列中同时存在超过5条消息未处理。
2. 单个Handler任务耗时过长：某个Handler的handleMessage()或Runnable.run()执行时间超过16ms。
   判断规则：在Method Tracing中查找耗时>10ms的Handler.dispatchMessage()内部方法，定位具体任务类。
3. 布局渲染锁竞争：主线程在View.measure() / layout() / draw()中因为持有全局锁（如WindowManagerGlobal.sWindowManagerService）导致被阻塞。
   判断规则：Systrace中看到“Choreographer#doFrame”耗时突然变长，且其内部存在“Lock contention”标签。

3.4 修复动作

根据不同根因采取对应修复方案：

// 在Handler中移除即将执行的Runnable
handler.removeCallbacks(myRunnable);
// 使用postAtFrontOfQueue()将紧急消息提前
handler.postAtFrontOfQueue(urgentTask);

// 错误：主线程解码Bitmap
public void handleMessage(Message msg) {
    Bitmap bmp = BitmapFactory.decodeFile(path); // 可能>100ms
}
// 正确：异步解码
ExecutorService executor = Executors.newSingleThreadExecutor();
executor.execute(() -> {
    final Bitmap bmp = BitmapFactory.decodeFile(path);
    handler.post(() -> imageView.setImageBitmap(bmp));
});

// 使用ViewStub
<ViewStub android:id="@+id/stub"
    android:inflatedId="@+id/heavy_layout"
    android:layout="@layout/heavy_layout"
    android:layout_width="match_parent"
    android:layout_height="wrap_content" />
// Java中按需inflate
ViewStub stub = findViewById(R.id.stub);
stub.inflate();

3.5 复测

修复后再次执行对应场景的Profiler录制，重点验证：

• 主线程消息队列峰值深度不超过3（在Profiler的“Main”线程下查看消息发送间隔）。
• 每个Handler任务执行时间均小于5ms（火焰图中无超过5ms的局部深色条）。
• Choreographer帧渲染时间稳定在16ms以内，无锁等待标签出现。

使用如下命令快速对比Trace：

# 抽取改进前后的主线程消息处理时间
python systrace.py -t 5 -o before.html gfx input
# 修改代码后再次抓取
python systrace.py -t 5 -o after.html gfx input
# 在浏览器中比较两个文件，关注 "SurfaceFlinger" 和 "Choreographer" 段

3.6 预防

将以下规则纳入团队开发规范与CI流程：

1. 消息队列监控：在Debug版本中，每5秒打印主线程Looper消息队列大小，若连续3次超过10则触发告警。
2. Handler审计：禁止在主线程Handler中执行网络请求、数据库查询、Bitmap解码、JSON解析等操作（通过Lint规则或Code Review）。
3. 布局渲染锁预检：在onDraw或onMeasure中添加耗时断言，超过5ms则输出堆栈。
4. 使用专用工具：定期用Android Vitals (Play Console)或Firebase Performance Monitoring监控主线程卡顿率，设置阈值报警。

public class UIThreadCheck {
    private static final long WARN_THRESHOLD_MS = 5;
    public static void assertMainThread(String reason) {
        if (Looper.myLooper() == Looper.getMainLooper()) {
            Log.w("UIThreadCheck", "Main thread " + reason + " at " + SystemClock.uptimeMillis());
        }
    }
}