Android Perfetto 系列 15：Boot Trace、长时间现场 Trace 与偶发问题抓取
开机慢、亮屏后偶发卡顿或几小时后才出现的音频断续，通常等不到工程师连上电脑再按「开始录制」。要保留问题发生前的调度、帧或音频事件，采集配置必须提前在设备上运行。
现场抓取要先确定触发点前后各保留多久，再选 Ring Buffer、周期写文件或 trigger。文件写出后，还要确认问题窗口没有被覆盖、关键数据源没有丢失。设备开机属于更早的特殊窗口，单独处理。
Perfetto 系列文章
- Android Perfetto 系列目录
- Android Perfetto 系列 1：Perfetto 工具简介
- Android Perfetto 系列 2：Perfetto Trace 抓取
- Android Perfetto 系列 3：熟悉 Perfetto View
- Android Perfetto 系列 4：使用命令行在本地打开超大 Trace
- Android Perfetto 系列 5：Android App 基于 Choreographer 的渲染流程
- Android Perfetto 系列 6：为什么是 120Hz？高刷新率的长处与挑战
- Android Perfetto 系列 7：MainThread 和 RenderThread 解读
- Android Perfetto 系列 8：深入理解 Vsync 机制与性能分析
- Android Perfetto 系列 9：CPU 信息解读
- Android Perfetto 系列 10：Binder 调度与锁比拼
- Android Perfetto 系列 11：PerfettoSQL、Trace Processor 与回归检测
- Android Perfetto 系列 12：Trace 数据流与丢失排查
- Android Perfetto 系列 13：Perfetto SDK、Track Event 与 App 现场 Trace
- Android Perfetto 系列 14：heapprofd 与内存 Profiling
- Android Perfetto 系列 15：Boot Trace、长时段现场 Trace 与偶发问题抓取
- Android Perfetto 系列 16：GPU、Power Counters 与硬件瓶颈分析
- Android Perfetto 系列 17：专项场景自动化、问题清单与平台体系
- Android Perfetto 系列 18：响应速度实战，从输入事件到首帧反馈
- 短片(B站) - Android Perfetto 基础和案例分享
- 影像(B站) - Android Perfetto 分享 - 出图类型分享：AOSP、WebView、Flutter + OEM 平台优化分享
长录制期间，数据源持续写入，Buffer 容量和文件周期决定最后能留下哪一段。配置里只放目的难题需要的信号，并按估计写入速率计算保留窗口；开太多数据源容易让根因发生前的事件先被覆盖。
示意图：STOP trigger 封存触发窗口，周期写文件分批落盘，clone 则保留原会话继续运行。
长 Trace 先造型证据窗口
长 Trace 的核心是取舍：难题前后各保留多少，哪些数字源值得留下。开始写配置前，先把状况窗口问清楚：
| 难题 | 作用配置的地方 |
|---|---|
| 问题多久复现一次 | duration_ms、是否需要后台运行、是否需要周期 snapshot |
| 根因在议题前还是问题后 | 选择 STOP trigger 还是 START trigger |
| 需要保留问题前多少秒 | Ring Buffer 大小、数字源宽度、写文件周期 |
| 使用者能不能手工停止 | 是否需要自动 trigger、是否接入 bugreport |
| 早期 ADB 不可用 | Boot Trace、平台预置、init/service 触发或厂商方案 |
| trace 启动后可能断 USB | --background-wait、detached mode、snapshot 或后台服务 |
| 文件最大能多大 | max_file_size_bytes、上传策略、本地 TTL |
| 数据是否敏感 | log tag 白名单、是否禁用 atrace_apps: "*" |
偶发 UI 卡顿通常需要议题前几十秒；温升降频可能需要几分钟风向；车机长稳议题可能要跑几个小时。这类场景通常只周期性拉取 snapshot，或只上传 summary。
常见场景可以先映射到 preset，再写 TraceConfig：
| 场景 | 推荐模式 | 触发和验收重点 |
|---|---|---|
| UI 偶发卡顿 | Ring Buffer + STOP trigger | App marker、FrameTimeline 覆盖目的窗口、触发前窗口足够 |
| ANR 前兆 | Ring Buffer + STOP trigger | 主线程、Binder、锁等待、I/O 和关键业务阶段同时在场 |
| 温升降频 | write_into_file 或 snapshot | CPU freq、idle、thermal 状态和 App 关键阶段按分钟级趋势保留 |
| 业务 timeout | App marker + STOP/START trigger | 根因在 timeout 前就用 STOP；需要继续观察恢复过程就用 START |
| 音频 underrun | Ring Buffer + STOP trigger | audio/server 事件、sched、binder、wakeups 和 underrun marker 同步 |
现场采集先受设备和权限限制
现场方案不能只看 TraceConfig，还要看设备版本、build 类型和触发者权限。
| 环境 | 可以依赖什么 | 不该假设什么 |
|---|---|---|
| userdebug / root 研发设备 | adb root、/data/misc/perfetto-configs、android.log、更多系统服务和 ftrace 事件 | 仍要控制 log 白名单、buffer 大小和上传范围 |
| user build + adb shell | 常规平台 Trace、包名限定的 atrace、审核过的 preset | 不默认依赖 android.log；不能假设任意配置路径都可读；优先使用 /data/misc/perfetto-configs |
| 普通 App | 记录 App 侧 ATrace / Track Event，激活预先声明的 trigger | 不能决定采集哪些系统统计结果、抓多大、传到哪里 |
| CPU / native / Java profiling | 按数据源要求检查 debuggable、profileable、Android 版本 | 不把 |
文本 proto 配置的扩展名可以是 .pbtxt 或 .pbtx；解析方式由 perfetto --txt 或工具链里的编码步骤决定。本文后面统一用 .pbtxt 做文件名。
Boot Trace 是特殊现场窗口
App 冷启动和系统开机是两类问题。App 启动路径在旧的 Systrace 响应速度实战里已经讲过，第 05 篇也覆盖了启动后的渲染链路，这里只处理设备级开机：ADB 还没可用、但 Android 已经进入 /data 挂载后的启动阶段，怎么把平台 Trace 抓全、看准、写成可复查结论。
需要 Boot Trace 的场景通常有几类：
本文由News整理发布，仅供参考。
