Android Perfetto 系列 15：Boot Trace、长时刻现场 Trace 与偶发问题抓取

Boot Trace 是平台或系统启动专项窗口；App 冷启动不走这条路线。分析前要先讲边界：

• Android boot tracing 是 Android 13+ 的能力。更早版本需要厂商自己的启动采集方案。
• 它在 persistent properties 加载后启动，也就是 /data 已挂载之后；不覆盖 PMIC 上电、bootloader、kernel early boot、first-stage init。更早阶段要靠 pstore、kernel cmdline/ftrace persistent buffer 或 vendor init instrumentation。
• 这类流程通常假设研发设备或 userdebug 上可以 adb root。生产 user build 需要平台预置、工程版本或厂商诊断入口。
• UI 的相对时间轴起点不等于电源键按下或 PMIC 上电；SQL ts 保留 Trace Processor 统一时钟域下的时刻戳，并不会自动从 tracing 开始归零。报告里比较同一份 Trace 内的相对阶段，不要把不同设备的绝对 ts 硬比较。
• “开机完成”没有唯一标准。Launcher 第一帧、可输入、网络可用、导航服务支持 ready、后台任务完成，可能是不同班底的指标。
• 输出文件要等 trace 停止，或至少等首个 flush/写文件周期之后才会就绪；persist.debug.perfetto.boottrace 是 one-shot，下一次 boot 前要重新设置。

boottrace.pbtxt 要设置合理的 duration_ms，让这次启动采集有明确终点；flush_period_ms 只控制周期提交，不能代替结束条件。第一版不要太贪心，先抓 init、sched、freq、idle、进程生命周期、process stats、Activity/Window/SurfaceFlinger 相关 ATrace；log 只在 userdebug 或平台诊断版本上按白名单开启。

Boot Trace 的 buffer 策略要和 ready 点匹配。DISCARD 更容易保住早期 init/zygote 事件，但 buffer 满了会丢后续 ready 点；RING_BUFFER 能保住最近窗口，却可能覆盖早期启动事实。90 秒启动窗口不要用 32MB DISCARD 硬扛，优先加大 buffer、缩窄数字源，或打开周期写文件并验收 traced_buf_chunks_discarded。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

duration_ms: 90000
flush_period_ms: 10000
write_into_file: true
file_write_period_ms: 5000
max_file_size_bytes: 536870912

buffers { size_kb: 131072 fill_policy: DISCARD }

data_sources {
  config {
    name: "linux.ftrace"
    ftrace_config {
      ftrace_events: "sched/sched_switch"
      ftrace_events: "sched/sched_waking"
      ftrace_events: "task/task_newtask"
      ftrace_events: "task/task_rename"
      ftrace_events: "sched/sched_process_exec"
      ftrace_events: "sched/sched_process_exit"
      ftrace_events: "sched/sched_process_fork"
      ftrace_events: "sched/sched_process_free"
      ftrace_events: "power/cpu_frequency"
      ftrace_events: "power/cpu_idle"
      atrace_categories: "am"
      atrace_categories: "wm"
      atrace_categories: "gfx"
    }
  }
}

data_sources {
  config {
    name: "linux.process_stats"
    process_stats_config {
      scan_all_processes_on_start: true
      proc_stats_poll_ms: 1000
    }
  }
}

一次可复用的抓取流程可以写成这样。pull 前不要只等文件非空；工程脚本应该等待配置里的 duration 结束，再确认文件大小连续稳定：

生成文章海报 / 分享二维码