4. 启动性能分析工具链
Android 启动性能优化不是靠猜，而是靠“观测—定位—验证”的闭环。启动过程横跨 BootROM、Bootloader、Kernel、init、Zygote、SystemServer、Launcher 等多个阶段，单一工具无法覆盖全部链路。工程上通常把工具链分为三层：系统级时间线（Bootchart、Systrace、Perfetto）、内核与日志层（dmesg、ftrace、atrace、logcat）、函数与采样层（simpleperf）。理解每个工具的采样原理、数据粒度和适用边界，才能在正确的阶段用正确的工具。
一、核心原理：三类观测手段的差异
第一类是事件追踪（Tracing）。atrace/ftrace 基于内核 tracepoint 与静态插桩，把调度、频率、binder、图形等事件按时间戳记录；Systrace 是 atrace 的上层封装与可视化，Perfetto 则是其现代替代，支持更长时长、更大缓冲和 SQL 查询。第二类是采样剖析（Profiling）。simpleperf 基于 perf_event_open，以固定频率采样 CPU 周期与调用栈，回答“CPU 时间花在哪个函数”。第三类是日志与状态快照。dmesg 记录内核启动时序，logcat 记录用户态打点，Bootchart 则通过采集 /proc 数据生成启动阶段的资源占用图。
二、方法流程：按阶段选择工具
启动早期（BootROM 到 Kernel）几乎只能依赖串口日志与 dmesg。进入 init 之后，Bootchart 可以给出进程创建、CPU 占用、IO 等待的全局视图，适合回答“哪个阶段整体变慢了”。当需要看清线程调度、binder 同步、SurfaceFlinger 合成等细节时，使用 Perfetto 抓取 trace，并用 SQL 统计关键 slice 的耗时分布。若发现某进程 CPU 占用异常，再用 simpleperf 采样其调用栈，定位到具体函数。
# 1. 抓取 Perfetto trace（设备端）
adb shell perfetto -o /data/misc/perfetto-traces/boot.pftrace \
-t 20s sched freq idle am wm gfx view binder_driver hal dalvik
# 2. 拉取并打开
adb pull /data/misc/perfetto-traces/boot.pftrace
# 使用 ui.perfetto.dev 打开，或命令行查询
# 3. simpleperf 采样 SystemServer
adb shell simpleperf record -p $(adb shell pidof system_server) \
-g --duration 10 -o /data/local/tmp/perf.data
adb shell simpleperf report -i /data/local/tmp/perf.data --sort dso,symbol
# 4. 查看内核启动日志
adb shell dmesg | grep -iE "init|driver|probe|time"
# 5. 过滤启动关键日志
adb logcat -b events | grep -E "boot_progress|am_proc_start|wm_boot"三、典型场景与工具对照
| 问题现象 | 首选工具 | 关键观测点 |
|---|---|---|
| 开机整体时间变长 | Bootchart | 各阶段起止时间、CPU/IO 峰值 |
| 某阶段卡顿、掉帧 | Perfetto / Systrace | 主线程 slice、binder 等待、调度延迟 |
| 内核驱动初始化慢 | dmesg + ftrace | probe 耗时、时钟与电源域 |
| 应用冷启动慢 | logcat + Perfetto | bindApplication、ActivityStart、首帧 |
| CPU 占用高但不知在哪 | simpleperf | 热点函数、调用栈占比 |
| 自定义事件缺失 | atrace / ftrace | trace_marker、自定义 tracepoint |
四、误区与复盘
误区一：只抓一次 trace 就下结论。启动受温度、后台任务、存储状态影响极大，必须多次采样取中位数，并对比修改前后。
误区二：把 Systrace 当唯一工具。Systrace 已逐步被 Perfetto 取代，长时长抓取容易丢事件；新项目应优先使用 Perfetto。
误区三：忽略采样开销。simpleperf 高频采样会引入额外负载，ftrace 全量开启可能撑爆缓冲区，需控制事件集合与时长。
复盘建议：建立“基线 trace 库”，每次版本迭代保存一份启动 trace 与 simpleperf 报告，用同一套 SQL 或脚本自动对比关键 slice 耗时，才能把偶发问题变成可回归的指标。
工具链的价值不在于工具本身，而在于形成“全局概览—阶段定位—函数下钻—回归验证”的固定路径。掌握每个工具的采样原理与适用边界，才能在启动优化中快速缩小问题范围，避免在错误的数据上做无效优化。