📚 课程目录第2章性能分析工具布局

第2章：性能分析工具布局 —— 针对首屏场景的选型与数据捕获

2.1 渲染管线与数据采集点映射

LazyColumn 的首屏渲染本质上是 Compose 三阶段管线的一次完整运作：组合（Composition）→ 布局（Layout）→ 绘制（Drawing）。不同工具在这条管线上的观测锚点完全不同——选错工具等价于用错标尺。

管线阶段	核心产出	对标工具	首屏关注点
组合（Composition）	Compose Node 树 + Slot Table	Compose Compiler Metrics	Composable 函数是否被标记为可跳过
布局（Layout）	Intrinsic 测量 + 放置坐标	Layout Inspector	LazyColumn 子项实际测量了几次
绘制（Drawing）	DisplayList → GPU 栅格化	CPU Profiler / Systrace	每一帧的合成耗时是否超过 16ms

理解这张映射表是本章的认知起点：遇到首屏卡顿，第一步不是打开随便一个工具盲目抓取，而是先确定现象发生在哪个阶段，再选择对应的工具进行定点捕获。

  关键提示：LazyColumn 在组合阶段只对“可见项 + 预取项”执行 Composable 调用。当 item 数量远大于屏幕可见数时，组合阶段耗时通常远小于布局阶段。首屏瓶颈 80% 出现在布局与绘制阶段，因此 Systrace 和 Profiler 是首选武器。

2.2 核心工具详解与数据捕获实战

2.2.1 Compose Compiler Metrics —— 捕获组合阶段的可跳过率

这是唯一能在编译期给出“稳定性”声明的工具。通过 Gradle 配置开启后，编译器会为每个 Composable 函数生成一份 .txt 报告，标明该函数是否被标记为“可跳过”（skippable）以及“重启作用域”数量。

启用方法（build.gradle.kts）：

subprojects {
    tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile> {
        compilerOptions {
            freeCompilerArgs.add("-P")
            freeCompilerArgs.add("plugin:androidx.compose.compiler.plugins.kotlin:metricsDestination=${project.buildDir.absolutePath}/compose-metrics")
        }
    }
}

执行 ./gradlew assembleDebug 后在 build/compose-metrics 目录下找到 <module>-classes.txt。

首屏关注字段：

skippable：是否可跳过（true 才符合预期）
restartable：是否可重启
changes：参数变化数（0 表示纯静态）

实操判断：如果 LazyColumn 的 item Composable 被标记为 skippable=false，意味着每次重组时该 item 无论参数是否变化都会执行。这是首屏后滚动卡顿的常见根源，但首屏阶段主要关注“初次组合耗时”。

2.2.2 Layout Inspector —— 捕获布局阶段的视图层次

工具位于 Android Studio → Tools → Layout Inspector。首屏捕获最佳时机是：应用冷启动后界面首次绘制完成时立即点击 Capture。

首屏布局分析要点：

查看 LazyColumn 节点下实际测量了几个子项（Visible Items + Prefetch Items）
检查是否存在不必要的 Box、Row、Spacer 嵌套层数过深
确认 SubcomposeLayout 是否被意外触发（反映为多个测量槽）

常见错误：Layout Inspector 显示的是“组合后的 UI 树”，而非“布局阶段的测量耗时”。不要用 Layout Inspector 替代 Profiler 去判断帧率快慢。它只解答“树结构对不对”，不解答“测量慢不慢”。

2.2.3 CPU Profiler 与 Systrace —— 捕获绘制阶段的帧耗时

这两个工具是首屏性能问题的终审法官。CPU Profiler 适合快速查看 Call Chart 中的函数耗时，Systrace 适合微秒级精度分析。

Systrace 捕获命令（macOS/Linux）：

python $ANDROID_HOME/platform-tools/systrace/systrace.py \
    -a com.example.app \
    -b 20000 \
    --time=10 \
    -o trace.html

关键标签：Frame、Compose、Choreographer。

首屏捕获对照表：

工具	首屏关键指标	理想值	异常信号
Compose Compiler Metrics	可跳过率 / 重启数	skippable=true	item Composable 不可跳过
Layout Inspector	子项测量数 / 层级深度	测量数 = 可见项 + 预取数	大量多余测量槽
CPU Profiler	主线程帧耗时 / 组合耗时	≤16ms / 帧	连续掉帧 >1 次
Systrace	Composition 阶段持续时间	<5ms	Layout 阶段 >10ms

2.3 针对首屏场景的数据捕获实战流程

为了在后续章节中复现优化效果，必须建立一套标准化的首屏捕获流程。以下步骤假设你从零开始冷启动应用：

预热编译器指标：在 build.gradle.kts 中写入 metrics 配置，执行 ./gradlew assembleDebug 生成基准报告。
开启 Systrace 循环记录：启动 Systrace 并设置 -b 20000（20MB 缓冲区）确保首屏数据不被覆盖。
冷启动应用：通过 adb force-stop 杀进程 → 点击应用图标 → 注视屏幕直到首帧完全呈现。
停止 Systrace：按 Enter 终止录制，生成 trace.html。
捕获 Layout Inspector 快照：在首帧绘制完成瞬间点击 Capture，保存为 .li 文件。

# 步骤 2 & 3 等价命令
adb shell am force-stop com.example.app
python systrace.py -a com.example.app -b 20000 --time=8 -o trace.html
# 立即手动点击应用图标冷启动

  稳定性验证要点：所有数据捕获必须在 同一设备、同一 OS 版本、同一 CPU 频率策略 下进行。建议存储 trace.li 与 compose-metrics 日志到版本管理工具（如 Git LFS），便于回归比对。

2.4 工具选择的常见误区与避坑指南

误区：等卡顿发生了才去抓 Systrace——首屏的峰值耗时通常发生在 app 启动后 0~500ms 内，Systrace 必须预先记录或用堆栈唤醒方式触发。
误区：仅看 Layout Inspector 就下结论“布局太深”——Layout Inspector 不反应测量耗时，某些深层布局反而可能因为 Intrinsic 缓存表现更好。
误区：发布版（Release）跑 Profiler——发布版禁用了 Compose 的某些调试桩点，组合阶段标签会丢失，导致 SysTrace 看到的 Composition 耗时偏短。
误区：忽略编译器指标的 restartable 字段——首屏虽然只组合一次，但 restartable=false 结合非稳定参数会导致后续重组整棵子树，这在首屏后瞬间的预加载阶段就会被触发。