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

• 丢在哪里：是 ftrace、producer 共享内存、central buffer，还是解析阶段。
• 影响什么：是调度事件不可信，还是进程名/线程名可能缺失，还是 App 自定义事件、FrameTimeline 或 log 缺段。
• 怎么补救：下一次抓取是减事件、加 buffer、分 buffer、写文件，还是缩短窗口。

ftrace 丢失：内核事件跟不上

如果 stats 里出现 ftrace_cpu_has_data_loss，说明内核 ftrace per-CPU buffer 到用户态读取这一段发生了丢失。典型场景是事件开得太多，或者设备压力大时 traced_probes 没能及时读取每个 CPU 的 buffer。

ftrace_cpu_overrun_* 这类计数可以辅助判断哪个 CPU 发生过 overrun，但不能精确还原 Trace 时段轴里的丢失阶段。要定位更具体的时段点，需要 FtraceEventBundle.lost_events 或原始 packet/UI 证据；没有这些证据时，只能降级为“该 CPU 的 ftrace/sched 证据不可靠”。

ftrace 专项检查不要只依赖通用入口。overrun 和 dropped event 相关统计在不同版本里可能是 info，需要专门拉出来：

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

SELECT name, idx, severity, source, value
FROM stats
WHERE value != 0
  AND (
    name IN (
      'ftrace_cpu_has_data_loss',
      'ftrace_setup_errors'
    )
    OR name GLOB 'ftrace_cpu_overrun_*'
    OR name GLOB 'ftrace_cpu_dropped_events_*'
  )
ORDER BY name, idx;

这类丢失会作用 CPU 调度、Runnable 时间、唤醒关系、Binder 内核事件等判断。已经观察到的 sched rows 可以作为残留线索，负向结论要全部降级：不能写“没有 Runnable 等待”“没有 wakeup 延迟”“没有调度阻塞”。要讨论 CPU busy，还要在同一窗口内检查 sched、thread_state、CPU idle、CPU frequency 或 sys_stats cpufreq 覆盖。

下一次抓取可以从这段配置开始调：

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

data_sources {
  config {
    name: "linux.ftrace"
    target_buffer: 0
    ftrace_config {
      ftrace_events: "sched/sched_switch"
      ftrace_events: "sched/sched_waking"
      buffer_size_kb: 32768   # 增大内核每 CPU buffer
      drain_period_ms: 100    # 更频繁地从内核读取
    }
  }
}

还要删掉当前问题用不到的 ftrace 事件。不要把所有 checkbox 都打开后再靠 buffer 硬扛。滑动 jank 先保留 sched/sched_switch、sched/sched_waking、FrameTimeline 和 App marker，先删无关 IRQ、Camera、GPU vendor 事件；Binder 慢才打开 binder events；Camera open 才加 Camera/GPU 相关事件。高频 ftrace 事件会挤掉同一层 ftrace per-CPU buffer 里的低频 kernel tracepoints；process stats、log、power、FrameTimeline 这类数据被挤掉，则属于后面的 central buffer 混放问题。

示例的 32768 KiB 是每 CPU 的 buffer，8 核设备仅这一层就可能占约 256 MiB；它是需要测量后选择的高占用值，不能直接当线上默认。buffer_size_kb 和 drain_period_ms 属于本地调参项，官方参考也提醒它们在并发 ftrace session 下不保证完全按配置生效。

公开 preset 先减事件。只有需要非默认 ftrace buffer，且要兼容不同 Perfetto 版本时，再考虑 buffer_size_kb + buffer_size_lower_bound；Perfetto v43+ 的多数配置可以保持 unset。写公开 preset 时，不要只给一个数字；要同时写清楚设备范围、Android/Perfetto 版本、事件集合和文件上升速度。

producer / TraceWriter packet loss：先定位再归因

如果出现 traced_buf_trace_writer_packet_loss，先把它当成 packet loss 总信号，不要直接归因为 producer shared memory。它可能来自 producer 共享内存突发，也可能和 RING_BUFFER 起点前、DISCARD 结束后的 packet loss、sequence 缺包、central buffer policy 有关。归因要结合 traced_buf_chunks_overwritten、traced_buf_chunks_discarded、traced_buf_sequence_packet_loss、traced_buf_patches_failed、buffer idx 和 fill policy。

Android 常见的 android.os.Trace / androidx.tracing 走 atrace/ftrace 路径，优先看 ftrace loss 和 ftrace_setup_errors。Perfetto SDK Track Event、自定义 DataSource、大块数据包、heapprofd 采样这类 producer，才更直接对应 shared memory 和 producer 侧写入策略。

这类丢失的判断方式很直接：如果你的 App 自定义事件正好用于划分业务阶段，那么业务阶段耗时就可能缺段；如果丢的是 heapprofd 或 CPU profiling 相关数据，采样结论也要降低可信度。

报告里要把缺失 marker 写成字段，而不是只写一句“业务事件可能丢了”。例如 checkout_submit 到 first_frame_present 之间缺少 network_done marker，只能报告端到端耗时，不能拆分网络/渲染阶段：fallback_used=true，missing_marker=network_done，recapture_reason=track_event_marker_missing。

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