📚 课程目录第1章 Systrace工具入门与录制准备

Systrace分析任务延迟技巧 - 第1节

现象识别：何时需要录制Systrace

Systrace 是 Android 平台最核心的系统级性能分析工具，用于捕捉进程与内核之间的交互时序。当你遇到以下任意一种现象时，就应考虑录制 Systrace 来定位延迟根因：

应用启动时间异常：冷启动/热启动耗时超过预期，或出现白屏、黑屏。
列表滑动卡顿：快速滑动时帧率掉到 30fps 以下，伴随明显的掉帧或丢帧。
输入响应延迟：点击、触摸后界面反馈超过 100ms，或按键到显示出现可感知的滞后。
动画不流畅：过渡动画、转场动画或自定义属性动画出现跳变、抖动的现象。
后台任务干扰：频繁的 GC、CPU 调度切换、Binder 同步等待导致主线程停顿。

判断规则：如果问题可以通过肉眼观察到“卡顿”或“延迟”，且持续时间超过 2 秒，就应该第一时间用 Systrace 记录现场。任何“偶发、不可复现”的卡顿，也应先录制 10～30 秒的 trace 来捕捉峰值。

数据采集：工具安装与录制准备

1. 工具安装与 ADB 配置

Systrace 随 Android SDK 打包发布，位于 sdk/platform-tools/systrace/ 目录下。配置步骤：

下载并解压 Android SDK（或直接使用 Android Studio 的 SDK Manager）。
确保 platform-tools/ 和 systrace/ 路径已加入系统环境变量 PATH。
连接设备并开启 开发者选项 中的 USB 调试。
执行 adb devices 确认设备已授权。
某些场景（如系统级 trace）需要设备已 root 或使用 userdebug 版本。

# 验证 ADB 连接
adb devices

# 查看 systrace 版本（位于 SDK 内部）
systrace.py --help

2. 自定义 Trace 标记（A/Trace API）

在应用的待分析关键路径中插入 Trace.beginSection() 和 Trace.endSection()，使 Systrace 能够识别自定义的“标签”，便于区分业务逻辑耗时。

import android.os.Trace;

public void doHeavyWork() {
    Trace.beginSection("myApp_heavyWork");
    try {
        // 待分析的耗时操作
        Thread.sleep(200);
    } catch (InterruptedException e) {
        // ...
    } finally {
        Trace.endSection();
    }
}

常见陷阱：Trace 名称长度不得超过 127 字符；同一线程内 beginSection 和 endSection 必须成对出现，否则会导致 trace 文件解析失败或标记不完整。

3. 录制命令选项

Systrace 采用 Python 脚本 systrace.py 进行录制，常用命令参数：

参数	说明	示例
`-t <秒>`	录制时长，默认 5 秒	`-t 10`
`-a <包名>`	追踪指定应用的自定义 Trace 标记	`-a com.example.app`
`-b <KB>`	内核缓冲区大小，默认 2048 KB	`-b 8192`
`-o <文件名>`	输出 trace 文件路径	`-o trace.html`
`类别标签`	选择要捕获的模块（如 sched, gfx, input, view 等）	`sched gfx view`

完整录制命令示例（录制 10 秒，捕获调度、图形、视图和应用自定义标记）：

systrace.py -t 10 -a com.example.app -b 4096 -o mytrace.html sched gfx view

4. 常见录制陷阱排查表

陷阱现象	可能原因	解决方案
trace 文件很小（<1 MB）	录制时长太短或缓冲区过小	增加 `-t` 到 15秒以上，`-b` 到 8192 KB
无自定义标记	忘记加 `-a` 参数或标记未命中	检查应用包名是否正确，确认 Trace API 已插入
跟踪记录中断/不完整	设备磁盘空间满或 CPU 过载无法写入	清理设备存储，降低抓取类别数
无法打开 trace.html	低版本 Chrome 不支持 Catapult 的 HTML 解析	升级 Chrome 至最新版，或改用 `--from-file` 方式打开
授权失败	ADB 未授权或设备已断开	重新连接设备，在手机上确认 USB 调试授权

原因定位：录制故障导致分析失效

若采集阶段出现上述陷阱，后续的延迟原因定位将缺乏可靠数据。典型的排查流程如下：

检查输出文件是否存在且大小符合预期（通常 >3 MB 才能覆盖主要事件）。
在 Chrome 浏览器中打开 trace.html，确认时间轴是否连续、有无明显空白段。
使用关键字搜索自定义标记（如 myApp_），验证是否被抓到。

  故障树判断：

  如果 trace 文件可用但找不到目标标记 → 返回检查 -a 参数或代码中的 Trace 调用；

  如果 trace 文件过小 → 增大缓冲区和时长重新录制；

  如果 trace 文件无法打开 → 检查 Chrome 版本或换用 perfetto 方式。

修复动作：应对常见录制陷阱

增大缓冲区：将 -b 提升至 8192～16384 KB，避免高频事件被截断。
延长录制窗口：使用 -t 30 甚至更长，确保捕获到偶发延迟。
精准指定应用包名：使用 -a com.your.package 并确保代码中 Trace 标记已同步编译。
使用稳定版 Chrome：推荐 100+ 版本，避免旧版解析器不兼容。
优先捕获核心类别：如果遇到资源不足，仅保留 sched gfx input view 四个核心标签。

复测：验证录制准备是否有效

执行修正后的录制命令，观察输出文件大小和自定义标记完整性：

# 复测命令（扩大缓冲区，指定包名）
systrace.py -t 20 -a com.example.app -b 8192 -o retest_trace.html sched gfx input view

打开 retest_trace.html，确认：

时间轴从 0 到 20 秒连续无断裂。
在搜索框输入 myApp_ 能定位到至少 1 个标记。
CPU 频率、调度列、图形帧列均有数据显示。

若一切正常，则录制准备阶段合格，可进入下一章的“延迟根因分析”。

预防：建立录制规范

在项目仓库中维护一个 systrace_capture.sh 脚本，固化常用参数（如缓冲区、时长、类别）。
将自定义 Trace 标记的命名约定写入代码规范：前缀 + 功能名（如 LoginActivity_attachToWindow）。
定期检查 ADB 版本和设备 USB 调试状态，避免因为环境变化导致录制失败。
每次发版前录制一次基线 trace，与历史版本对比帧率和 Binder 调用频次。