一份 Perfetto Trace 里混合了多种数据。内核产生 sched_switchsched_wakeupCPU 频率等事件；Android Framework 和 App 通过 Trace API 记录代码区间；SurfaceFlinger 提供 FrameTimeline；process_statssys_stats 等数据源还会采集进程、CPU 和内存统计。这些数据来自不同的 Producer，采集前先由 TraceConfig 决定启用哪些 Data Source。

使用者痛点：在实际使用中。经常不知道到底打开了哪些 Data Source，导致关键事件缺失。

Data Source 启动后通过 TraceWriter 把记录编码成 protobuf 格式的 TracePacket再写入 Producer 和 Tracing Service 共享的内存。Tracing Service 收取已提交的数据，复制到 central buffer。最终输出 .pftrace 文件。Trace 文件的原始结构是一系列 TracePacket；说起来，packet 中常见时间戳、sequence ID 和具体 payload。文件内部没有 Perfetto UI 中的轨道，也没有 slice 这样的 SQL 表。

使用者痛点：很多人误以为文件里已经有 “轨道”，结果在 UI 中找不到对应数据。

打开 Trace 时Trace Processor 才开始解析 packet，对齐不同时钟，建立进程、线程和轨道的身份关系。再将数据整理为 processthreadsliceschedcounter 等可查询对象。老实说，Perfetto UI 和 PerfettoSQL 使用的都是这层解析结果。

使用者痛点：Pitfall – 在命令行或 Web UI 中直接查询时忘记先加载 Trace Processor，会得到空表或错误提示。

The Trace Processor 是 Perfetto 的 C++ 解析和分析引擎，不是 Android 设备上负责采集的后台服务。按理说，

• C/Wasm 场景：
  • 中打开 Trace 时它通常以 WebAssembly 形式运行在本地浏览器中；
• Slicing & Counter：slices /
• No back‑write:Slice 等表只存在于当前 Trace Processor 实例的内存中，不会回写到 .pftrace 文件。

TraceConfig 决定采什么

一次采集从 TraceConfigdata_sources.config.name 选择数据源。target_buffer 把该数据源的输出写入指定 central buffer，数据源自己的配置则放在对应的私有字段中。

示意图：TraceConfig 选择 Data Source，并将输出映射到目标 Central Buffer。

Pain point：If you forget to set correct buffer size,high‑frequency events will be dropped silently.

以下示例展示了针对 Android ≥ 10 的短时。实际可用的数据源、ftrace event、ATrace category 与 FrameTimeline 取决于设备、内核与程序建立配置还有 tracing 权限。说起来，

buffers {
sizekb: // 填写合适大小
fillpolicy: RINGBUFFER
}
buffers {
sizekb: // 填写合适大小
fillpolicy: RINGBUFFER
}
duration_ms: // 如 5000

datasources { config { 从name来看，"linux.ftrace" targetbuffer: 0 ftraceconfig { ftraceevents: "sched/schedswitch" ftraceevents: "sched/schedwaking" ftraceevents: "sched/schedwakeup" ftraceevents: "power/cpufrequency" ftraceevents: "power/cpuidle" ftraceevents: "binder/bindertransaction" ftraceevents: "binder/bindertransactionreceived" atracecategories: "gfx" atracecategories: "view" atracecategories: "input" atracecategories: "wm" atracecategories: "am" atracecategories: "aidl" atraceapps: "com.example.wechatfriendforperformance" compactsched { enabled: true } } } }

datasources { config { name这方面。"android.surfaceflinger.frametimeline" targetbuffer: 1 } }

datasources { config { 至于name，"linux.processstats" targetbuffer: 0 processstatsconfig { scanallprocessesonstart: true procstatspollms: // 如1000 } } }

datasources { config { 再看name，"linux.sysstats" targetbuffer :0 sysstatsconfig{ statperiodms : // 如1000 statcounters : STATCPUTIMES meminfoperiodms : // 如1000 meminfocounters : MEMINFOMEMTOTAL meminfocounters : MEMINFOMEMFREE meminfocounters : MEMINFOMEMAILABLE cpufreqperiod_ms : // 如1000 } }

• buckets:
• buffers 定义 Tracing Service 持有的 central buffer。size_kb 是容量，fill_policy 是写满后的处理方式。
• duration_ms 控制采集时长，这里是 ms 。
• data_sources.config.name 决定由哪个 Producer 响应。例如 linux.ftrace 收集内核 ftrace 与 ATrace；android.surfaceflinger.frametimeline 收录帧时间线。
• target_buffer 是 buffers 的零基索引。值 0 指向第一个 MB buffer，值 1 指向第二个 MB buffer。
• ftrace_config 、process_stats_config 、sys_stats_config 是各自私有配置，用来挑选具体事件、类别和轮询周期。

Pain point：If a required Data Source is omitted from config,those events can never be retro‑added after trace is recorded.

ATrace 和 TrackEvent 是两条写入方法

A​Trace 与 TrackEvent 都能记录 Slice 与 Counter。但进入 Trace 的方式不同：

A​Trace 是 Android 最早提供的程序 Trace 插桩机制，比 Perfetto 更早出现。其实，Java/Kotlin 使用 android.os.Trace . beginSection / endSection。NDK 使用 A​Trace_* 系列函数。这些入口最终把事件送入内核 **ftr ace** ring buffer，由 Perfetto 的 `linux.ftrack` Data Source 捕获并转化为 ``ftrack_events`` payload。老实说，如果想记录特定 App 的 A​T r a ce。需要在 `ftrack_config` 中添加对应包名：

ftrackconfig{
atrackapps:"com.example.wechatfriendforperformance"}

'TrackEvent' 属于 Perfetto Tracing SDK。SDK 中提供 `TRACE_EVENT`,`TRACE_EVENT_BEGIN`。`TRACE_COUNTER` 等宏/函数，可定义 Category/Track/参数/Flow。这类事件 **不**经过 kernel ` trace_marker`，而是直接由 SDK 调用 `TraceWriter` 写入共享内存中的 `` payload。需要在 `TraceConfig` 中显式启用 `` Data Source 才能看到这些记录。

*User Pain Point*：很多开发者混淆了两条方法。以为只要调用 `androidx.tracing.trace{}` 就一定走 SDK 方法——它仍然走 A​T race 桥接层，从而导致预期的数据缺失。

"八种常见写入形态"

"Data Source"、“数据形态”“TracePacket payload”“SQL 对象”是四个不同维度。一个 Data Source 可以产生多种 payload；一种 payload 可以贡献给多个表；一个逻辑事件也可能由多个 packet 共­同表达。下表仅列出主流方法，不代表严格的一对一映射。怎么说呢，

...