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

1
2
3

SELECT
  trace_start() / 1e9 AS trace_start_s,
  trace_dur() / 1e9 AS trace_dur_s;

如果时长不符合预期，先查 trigger_timeout_ms、max_file_size_bytes、后台GF程是否被杀、文件是否还没 close、duration_ms 是否按 suspend 语义计算。数字不完整时，报告要写明哪些判断不能下。

再跑全局做工检查。stats 体检的完整查询和“常见项 → 处置决策”的映射表第 12 篇已经给过，把那topics SQL 放GF分析脚本开头直接复用即可，这里不重复。现场长 Trace 要在它之上多做两层。

先是 per-buffer 检查。traced_buf_* 的 idx 对应 buffer 下标; 下面同时列出的全局 flush/config 项不能按 buffer 编号解释：

1
2
3
4
5
6
7
8
9
10
11
12
13

SELECT name, idx, severity, source, value
FROM stats
WHERE value != 0
  AND (
    name GLOB 'traced_buf_*'
    OR name IN (
      'traced_flushes_failed',
      'traced_final_flush_failed',
      'config_write_into_file_no_flush',
      'config_write_into_file_discard'
    )
  )
ORDER BY idx, name;

RING_BUFFER 下的 traced_buf_chunks_overwritten 不一定是错误，它通常指出窗口外的旧数字被覆盖。要单独看它是否把 trigger 前根因覆盖掉：

1
2
3
4
5

SELECT name, idx, severity, source, value
FROM stats
WHERE name = 'traced_buf_chunks_overwritten'
  AND value != 0
ORDER BY idx;

如果现场打开 ftrace，还要记录 ftrace clock、可用事件和 setup error。跨 trace 比较时，clock 或事件集不同，会直接作用 sched/freq 结论可信度：

1
2

adb shell cat /sys/kernel/tracing/trace_clock
adb shell cat /sys/kernel/tracing/available_events | head

把偶发问题变成证据

一次偶发议题的证据包至少要能回答：触发点在哪、触发前事件保留了多久、文件是否完成写入、哪些数字源发生丢GA。缺任何一项，报告都应缩小结论范围。App 侧 Track Event 可标记业务触发点，Draw台 Trace 再解释触发前后发生了什么。

参考文档

1. Trace configuration
2. Buffers and dataflow
3. Tracing in Background
4. Running perfetto in detached mode
5. Perfetto command-line reference
6. TraceConfig proto reference
7. Android boot tracing
8. FrameTimeline
9. ATrace
10. Android Log
11. Clock synchronization
12. Trace Processor Stats

源码核对版本：b23c67be1159e3f0b0657bd97be9e139e0d8ee2c（2026-09-19）。

• Trigger 与 duration 语义

关于我 && Blog

欢迎关注 Android Performance。

Generate poster / share QR code