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

1
2
3

incremental_state_config {
  clear_period_ms: 5000
}

clear_period_ms 会让使用增量状态的统计结果源周期性重新发描述信息，适合 Ring buffer 场景。另一个办法是用 target_buffer 把低频元数字放进更不容易被覆盖的 buffer。

这个配置只会通知声明兼容 incremental state clear 的数字源，不是对所有数字源强行生效。Buffers and dataflow 文档给的口径更严格：clear_period_ms 最好比 central buffer 估算可保留窗口低一个规模级。比如某个 buffer 大约只能留 60 秒数字，5 秒清一次描述信息比 30 秒清一次稳得多。

长 Trace 还要关注 flush

长时刻抓取里，有些统计结果源事件很少，可能在共享内存里待很久才提交。UI 里会表现成时间轴异常拉长，或者 Trace Processor 导入时出现 out-of-order 一类议题。

可以加周期 flush：

1

flush_period_ms: 10000

这个配置会让 tracing service 周期性请求统计结果源提交未写满的共享内存页。Buffers and dataflow 文档把 10-30 秒作为长 Trace 的常见范围；具体行为还要看设备上的 Android/Perfetto 版本，以及 write_into_file、write_flush_mode 等配置。

实战里优先确认 write_into_file、file_write_period_ms、I/O 压力和导入错误，再决定是否显式设置 flush_period_ms；过高频 flush 会增加开销。

如果 stats 里出现 traced_flushes_failed 或 traced_final_flush_failed，先在报告里写清可信度边界，再检查长 Trace 的 file write、flush/write flush 配置和 I/O 压力。它不应被当成普通 parser 噪声。

如果已经拿到一份没有周期 flush 的长 Trace，导入时又遇到 out-of-order，一次性救急可以让 Trace Processor 用 --full-sort 导入。这会牺牲内存，把更多排序工作放到导入阶段；它适合离线分析，不适合作为采集配置的长期答案。

--full-sort 不能修 clock 难题。看到 clock_sync_failure、clock_sync_failure_unknown_source_clock、clock_sync_mixed_clock_sources、clock_sync_failure_undeferrable_packet_loss 这类统计项时，要先按“时段戳/clock 语义不可信”处理，再结合 packet loss、ClockSnapshot、producer 写法和导入排序定位根因；不要只靠 --full-sort 或 flush 解释。

报告里怎么写可信度

有 data loss 的 Trace 不一定完全作废，但报告必须写边界。结构化字段先定下来：

1
2
3

stat_name,stat_idx,idx_semantics,severity,source,value,affected_evidence,affected_metrics,decision,next_config_action
ftrace_cpu_has_data_loss,3,cpu,data_loss,trace,1,sched/thread_state/wakeup,RunnableNegativeConclusion,degrade_or_recapture,reduce_ftrace_events+increase_ftrace_buffer
traced_buf_chunks_overwritten,0,buffer,info,trace,8,buffer0_data_sources,AppTrackEvent;FrameTimeline,recapture_if_target_window_missing,split_buffers+increase_buffer0

自然语言模板可以这样写：

1
2
3
4

完整性检查：stats 表存在 ftrace_cpu_has_data_loss，CPU 3 value=1；ftrace_cpu_overrun_delta / dropped_events_delta 只作为辅助说明。
影响范围：sched/ftrace 事件可能缺失，线程状态占比和唤醒关系只能作为参考；不能写“没有 Runnable 等待”。
仍可使用：未发现 FrameTimeline parser/pairing 异常，目标窗口内 expected/actual slices 覆盖完整，且未命中同源 buffer loss；App SDK Track Event 未见 packet/sequence/tokenizer/interning/track hierarchy 异常。若这些数据与丢失 buffer 同源，仍需降级。
下一次配置：减少 ftrace 事件，ftrace buffer 调到 32768KB，drain_period_ms 调到 100ms。

报告里的「没有看到」只描述观测结果。只有目标数字源覆盖窗口、且相关丢失统计没有议题时，才能进一步讨论事件是否没有发生。

总结

一份 Trace 有 ftrace loss，不必把所有结果都丢弃。FrameTimeline 若独立采集且目标窗口覆盖完整，可以继续报告帧数；Runnable 与唤醒归因则要降级。把受冲击的统计结果源、窗口和下一次配置调整写在同一份报告里，读者才能复查结论边界。

参考文档

1. Buffers and dataflow
2. Trace configuration
3. Trace Processor Stats
4. Instrumenting the Linux kernel with ftrace

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

• Perfetto stats 定义
• v58.2 stats 定义（含 indexed 项）
• v57.2 stats 定义

关于我 && 博客

欢迎关注 Android Performance。

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