Android Perfetto 系列 12：Trace 数据流与丢失排查

关键图形数字源和 App SDK Track Event 也要检查 target_buffer。FrameTimeline、SurfaceFlinger/Winscope、App SDK Track Event 可以通过各自 data source 的 target_buffer 隔离；HWUI、Choreographer、RenderThread atrace 则跟随 linux.ftrace，要通过减少 ftrace 事件、增大 ftrace per-CPU buffer、增大或隔离 ftrace 的 central buffer 来保护。分 buffer 只能隔离 central buffer 竞争，不能修复 producer shared memory 已经写爆的议题。

确认“被挤掉的是不是本次分析依赖的数据”时，按依赖逐项查：目的窗口 FrameTimeline expected/actual 行数，App marker 数量，process/thread 名称完整性，log/power/memory 是否覆盖目标窗口，stats 里命中哪个 buffer idx。这些都对不上时，优先复抓；只冲击解释变量时，报告降级即可。

长 Trace：再解决周期写文件

如果要抓长时间现场议题，只加大内存 buffer 不够。应该让 Perfetto 周期写文件：

1
2
3
4
5
6
7
8
9
10

duration_ms: 600000
write_into_file: true
file_write_period_ms: 2500
flush_period_ms: 10000
max_file_size_bytes: 2147483648

buffers {
  size_kb: 32768
  fill_policy: RING_BUFFER
}

file_write_period_ms 越短，内存压力越低，但 I/O 开销越高。长 Trace 还要显式考虑 flush：新版本可以结合 write_flush_mode 自动策略，跨版本公开配置优先显式写 flush_period_ms，并在 stats 里检查 config_write_into_file_no_flush、config_write_into_file_discard。Trace configuration 文档提到 Android 常见 Trace 数据速率约 1-4 MB/s，这个数字只能做初始估算，专项配置要自己测一次文件增长速度。

如果状况有明确触发点，优先缩小采集窗口或使用触发式抓取，保留状况前后几十秒，比盲目长录更容易减少覆盖和 I/O 压力。

写文件还要看设备和启动方式。/data/misc/perfetto-traces/ 这类限制指的是 TraceConfig.output_path 字段在 system traced 场景下的路径约束；普通 adb shell perfetto -o ... 和 bugreport clone/save 是另一条 consumer 路径。要进入 bugreport，配置 bugreport_score > 0，由 dumpstate 触发保存；Android 12/13 和 Android 14 及以上的 session 处理方式还不同。公开 preset 里不要只贴 pbtxt，还要写清 Android/Perfetto 版本、执行命令和输出路径。

I/O 相关 tracepoint、syscall、pagefault 也要谨慎。长 Trace 写文件可能和被测 workload 比拼同一存储路径；stats 干净只能说明 trace 数据较完整，不能证明采集对现场没有扰动。报告里要区分 trace_quality_status 和 collection_perturbation_risk。

估算时可以按这条粗线算：

1
2
3
4

central buffer 至少需要的大小
  = 采集写入速率 MB/s
  * file_write_period_ms / 1000
  * 防护系数

安全性系数通常不要低于 2。因为写入速率不是匀速的，滑动、启动、Camera open、音频路由切换都会制造短时间突发。

增量状态丢失：事件还在，名字和上下文缺了

Perfetto 为了降低体积，会复用上下文信息。Track Event 的 track descriptor、interned strings，以及进程/线程元数据这类上下文 packet 一旦被覆盖或缺包，后续事件就可能只剩 ID，或者无法完整解析。

更隐蔽的表现通常是：

• UI 里只有 tid，看不到进程名。
• Track Event 轨道名字缺失或解析异常。
• stats 出现 sequence、incremental state、tokenizer、interning、track hierarchy 相关统计项。
• Trace Processor 跳过引用了缺失描述包的 packet。

优先看的统计项是这几个：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

SELECT name, idx, severity, source, value
FROM stats
WHERE value != 0
  AND (
    name IN (
      'traced_buf_trace_writer_packet_loss',
      'traced_buf_sequence_packet_loss',
      'traced_buf_incremental_sequences_dropped',
      'interned_data_tokenizer_errors',
      'track_event_tokenizer_errors',
      'track_hierarchy_missing_uuid',
      'tokenizer_skipped_packets'
    )
    OR name GLOB 'track_descriptor_*'
    OR name GLOB 'track_event_*missing*'
    OR name GLOB 'track_event_*invalid*'
  )
ORDER BY name, idx;

tokenizer、interning、track hierarchy 相关统计项更像解析后果或辅助信号。它们能提示“名字和上下文缺了”，但根因通常还要回到 sequence 缺包、Ring 覆盖或 producer 写入突发。报告里不要只写“Track Event 未见 packet loss”，还要拆出 track_event_packet_loss_count、track_event_sequence_loss_count、track_event_tokenizer_error_count、interning_error_count、track_hierarchy_error_count、track_event_invalid_end_count，再给 track_event_trust_level。

处理方式有两类：

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