📚 课程目录第1章课程导入

1. 课程导入

在 Android 性能优化领域，真正困难的问题往往不是“怎么改代码”，而是“问题到底出在哪里”。卡顿、掉帧、启动慢、发热、耗电、内存抖动、线程阻塞，这些现象背后可能同时牵涉应用层、系统服务、内核调度、GPU 渲染、I/O 与电源管理。Perfetto 正是 Google 为 Android 与 Linux 生态打造的统一性能追踪与可视化平台，它把系统级 trace、应用埋点、计数器、日志与调用栈汇聚到同一条时间轴上，让性能问题从“猜测”变成“可观测、可度量、可验证”。

本课程的目标不是让你记住若干命令，而是建立一套完整的性能分析思维：先明确问题类型，再选择采集方案，接着读懂 trace 中的关键信号，最后用数据闭环验证优化效果。

一、为什么需要 Perfetto：核心价值

传统工具各有边界：Logcat 只能看文本，Systrace 已逐步被 Perfetto 取代，Simpleperf 擅长 CPU 采样，GPU 工具偏图形，Battery Historian 偏功耗。Perfetto 的价值在于“统一”与“可扩展”：

统一数据源：ftrace、atrace、进程统计、GPU 计数器、电源状态、内存快照、Java/Kotlin 埋点、native 调用栈可同时进入一个 trace。
统一时间轴：所有事件按同一时钟对齐，能直接看出“谁在等谁”“谁抢占了谁”。
可编程采集：通过 TraceConfig 精确控制缓冲区、数据源、采样频率与触发条件，避免采集噪声。
可扩展分析：Trace Processor 提供 SQL 查询接口，可用 SQL 对 trace 做聚合、筛选与自动化回归。
跨平台：Android、Linux、Chrome 等场景共用一套 trace 格式与 UI。

二、整体知识框架：从采集到洞察

本课程的知识框架可以概括为“四层一闭环”。四层分别是：采集层、数据层、分析层、优化层；一闭环指“采集—分析—定位—验证”的迭代过程。下图展示了 Perfetto 性能分析的整体结构与数据流向，帮助你建立全局地图。

三、方法流程：一次完整的性能分析怎么做

性能分析最忌讳“上来就抓一大把 trace”。推荐遵循以下流程，每一步都有明确产出：

定义问题：是掉帧、启动慢、内存增长还是功耗异常？明确可量化指标，例如“冷启动 1.8s”“滑动帧率 48fps”。
选择数据源：渲染问题关注 SurfaceFlinger、Choreographer、GPU；线程问题关注 sched、freq、binder；内存问题关注 heapprofd、meminfo。
配置采集：控制缓冲区大小、采集时长与触发方式，避免丢包或过度开销。
读取时间轴：先看全局，再逐层下钻到进程、线程、切片与调用栈。
SQL 聚合：用 Trace Processor 把“看起来像”变成“算出来”，例如统计某线程的阻塞总时长。
验证闭环：优化后重新采集，用同一指标对比，确认收益真实存在。

下面是一段典型的 TraceConfig 片段，用于采集调度、频率与图形相关数据源：

buffers {
  size_kb: 65536
  fill_policy: RING_BUFFER
}
data_sources {
  config {
    name: "linux.ftrace"
    ftrace_config {
      ftrace_events: "sched/sched_switch"
      ftrace_events: "sched/sched_wakeup"
      ftrace_events: "power/cpu_frequency"
      atrace_categories: "gfx"
      atrace_categories: "view"
      atrace_categories: "wm"
    }
  }
}
duration_ms: 10000

四、典型场景与误区复盘

不同性能问题在 Perfetto 中呈现的信号不同。下表给出常见场景与首选数据源的对应关系，便于快速定位：

问题现象	首选数据源	关键观察点	常见误区
滑动掉帧	gfx、view、SurfaceFlinger、GPU	主线程耗时、RenderThread、帧间隔	只看应用线程，忽略合成与 GPU
冷启动慢	atrace、binder、sched	Application 创建、类加载、Binder 等待	把 I/O 等待误判为 CPU 忙
线程卡死	sched、binder、锁埋点	Runnable 与 Running 比例、唤醒链	只看单线程，忽略锁竞争
内存抖动	heapprofd、meminfo、Java 埋点	分配热点、GC 频率、对象存活	把 GC 当根因，忽略分配源头
功耗异常	power、freq、wakeup	CPU 驻留频率、唤醒次数、持锁	只看平均功耗，忽略瞬时峰值

常见误区一：采集时间过长、数据源过多，导致缓冲区溢出丢事件，分析结论失真。误区二：只看 UI 上的“大块”，不做 SQL 量化，容易把偶发当常态。误区三：优化后不重新采集，凭感觉判断收益。

建议每学完一个模块，都用同一份 trace 做一次“复述”：用三句话说明瓶颈在哪、证据是什么、下一步验证什么。这种训练能显著提升 trace 阅读速度。

本课程后续将围绕采集配置、UI 操作、SQL 查询、渲染与启动分析、内存与功耗、自动化回归等主题逐步展开。你不需要一次记住所有数据源，但需要建立“问题—数据源—指标—验证”的映射习惯。当你能用 Perfetto 把一次卡顿拆解成可度量的时间片段，性能优化就不再依赖直觉，而成为可重复的工程方法。