说实话Android 和 Linux 的性能分析工具我前后摸过不少从早期 PDT 到 systrace再到后来各种厂商私有方案都有各自的痛点。要么抓的数据太糙要么分析链路太折腾真正能“一条链路打穿”的工具并不多。Perfetto 算是这些年里我为数不多愿意真正投入去研究的那个它解决了 Android 和 Linux 两个平台在性能剖析上长期存在的割裂问题把 ftrace、atrace、heap profiler、energy estimation 这些散落在系统各处的数据源统一到了一套框架里。这篇文章我会从实际使用的角度把 Perfetto 的完整链路、常用姿势、以及我在真实项目中踩过的坑都拆开讲一遍。1. 项目概述为什么选择 Perfetto 这套方案1.1 它是什么从 Systrace 到 Perfetto 的替代关系很多人第一次听说 Perfetto是因为 Google 在 Android 10 之后逐渐弱化了 systrace 的地位转而推荐 Perfetto 这套新工具。但 Perfetto 并不是简单换个皮肤它的定位是Android 与 Linux 统一的性能追踪与剖析框架。用我自己的话说它干的事情就是把系统里各个模块产生的 trace 数据、采样数据、日志数据全部采集到一起用一种统一、高效、可扩展的格式保存下来然后给你一个强大的分析前端UI 和 SQL 引擎去查问题。我在实际使用中最直接的一个体验是systrace 时代我要看 CPU 调度、看 Binder 调用、看 SurfaceFlinger 合成需要分别加不同的 tag数据出来之后还经常对不上时间轴。Perfetto 不同它底层直接对接 kernel 的 ftrace 和 Android 的 atrace把这些数据源在时间轴上对齐。这么说吧过去分析一个掉帧问题我要开好几个窗口来回比对现在只要一份 Perfetto trace关键信息都在里面。另外一个很多开发者可能没太注意的点是Perfetto 在 Linux 桌面和服务器上同样可以使用。你在没有 Android 设备的环境里依然可以利用它抓取 Linux 系统层面的调度、中断、CPU 频率等信息。这也是它对比很多专用工具最有优势的地方一套工具两个平台都覆盖。1.2 它适合谁Android/Linux 性能排查的场景矩阵我从实际解决的案例出发整理了一下它适用的几个典型场景大家可以对照自己的需求Android 应用卡顿与掉帧分析这是最核心的场景。能精确看到 Choreographer 的帧时间线、RenderThread 的耗时、主线程上的耗时函数调用再配合 CPU 调度信息定位是应用自身问题还是系统资源竞争。App 启动速度优化冷启动、热启动流程里每个 ActivityThread、Binder 调用、ContentProvider 初始化耗时都能从 trace 中拉出来。我做过一个项目通过 Perfetto 定位到某个 ContentProvider 在冷启动时阻塞了主线程超过 300ms这个收益直接反映在启动耗时指标上。Linux 系统调度与性能剖析在服务器或嵌入式 Linux 上可以用它抓取 CPU 调度延迟、中断处理耗时、频率调节策略等问题。曾经排查过一个业务进程 CPU 占用不均衡的问题用 Perfetto 抓到某个 CPU 上 IRQ 频繁抢占定位到驱动层面的问题这类问题用传统 top/vmstat 很难看到。内存与堆分析Perfetto 集成了 heapprofd可以做 Native 内存的采样分析排查内存泄漏或大块内存分配问题。配合 SQL 查询能快速找出来自哪个 callstack 的分配占比最高。功耗与温控分析抓取电池电量、电源状态、CPU 频率、温度数据做功耗归因。系统耗电问题的归因靠看代码是看不出来的需要这类数据支撑。归纳起来很简单凡是“系统层面看不到的性能怪象”都值得先用 Perfetto 拉一份全量 trace 再下结论。2. 工具链核心机制Perfetto 的数据是怎么跑通的2.1 三层架构traced、traced_probes 与 trace_processorPerfetto 之所以灵活在于它不是一个大而全的二进制而是由多个组件组成的。我把它拆成三个阶段来理解数据采集、数据落地、数据分析。先看采集端。Android 系统里运行着一个名为traced的守护进程它负责接收来自客户端的 trace 请求并根据配置文件决定要开启哪些数据源。另一个守护进程traced_probes专门负责跟内核的 ftrace 交互把调度事件、CPU 频率变化、中断事件等抓取出来。这两个进程配合就解决了“用户空间想拿内核数据”的经典难题。再看落地端。抓取结束之后trace 数据以 protobufProtocol Buffers格式写成一个.pftrace文件。这个格式是 Perfetto 团队自己定义的结构紧凑、扩展性好也支持流式写入所以能支持长时间抓取而不至于把内存写爆。最后是分析端。trace_processor是 Perfetto 的离线分析引擎一个本地运行的 SQL 引擎专门用来加载.pftrace文件并提供 SQL 查询能力。无论你是用 Perfetto UI网页版还是命令行直接查询背后都是它在工作。我最常用的方式就是拉一个 trace 以后开个终端跑 SQL把数据直接导出成 CSV 做进一步处理。2.2 数据源设计为什么能对齐 ftrace 与 atrace这里有个关键设计值得专门讲讲时间轴对齐。Android 里用户在应用层打点产生的事件比如 Choreographer 的帧回调和内核里 scheduler 产生的事件比如某个线程被唤醒它们的时间戳来源是不同的。内核事件用的是 clock_monotonic上层应用打点可能用的是 CLOCK_MONOTONIC 里不同的等价时钟系统在启动时会对齐。Perfetto 的 traced_probes 有个专门的机制会把 ftrace 的 clock 和 boottime 对齐这样应用层的 trace marker 和内核事件才能放到同一时间坐标里。想一下如果没有这一层对齐你看到主线程某个方法的开始时间无法跟 CPU 上实际发生调度的时间对应起来那这个工具基本就没法用了。Perfetto 很早就解决了这个基础设施层面的问题后来者因此少走了很多弯路。2.3 两种抓取链路设备侧命令行与 PC 侧 adbPerfetto 抓取 trace 有两种常见路径设备侧命令行抓取以 root 或 shell 权限直接在设备上执行perfetto命令配置复杂一点可以写一个.pbtx文本格式的配置文件。这种方式多用于自动化测试脚本里比如压测过程中定时抓一段 trace 下来。PC 侧 adb 抓取通过adb shell perfetto远程执行或者使用 PC 上的tracebox工具将整个 perfetto 工具链打包成一个静态可执行文件方便在开发机上直接运行。我用得最多的是 PC 侧方式因为不用在设备上额外部署工具而且tracebox在 Mac 和 Linux 上都能跑兼容性很好。两条链路最终产出都是.pftrace文件后续分析完全一致。你不需要过度纠结用哪种方式按环境选最顺手的即可。提示日常分析建议优先使用 PC 侧 adb 方式。因为设备侧命令行模式下抓取结果的导出还要走 adb pull多一步操作。PC 侧还能顺手用 trace_processor 做一些轻量化的过滤和转储。3. 实操指南从抓取 trace 到分析 trace 的完整流程3.1 Android 平台一条命令拿到关键 trace我在 Android 项目里最常用的抓取方式先在命令行确认设备连接正常adb devices确认设备在线后直接执行抓取命令。比如我要抓取一次冷启动过程的 trace时长设为 10 秒adb shell perfetto -o /data/misc/perfetto-traces/startup.pftrace --time 10s --txt -c /data/local/tmp/trace_config.pbtx这里稍微解释一下参数-o指定输出文件路径建议放在/data/misc/perfetto-traces/目录权限合适方便导出。--time 10s表示抓取时长为 10 秒。时长越长文件越大分析也越慢要按需设置。--txt -c表示后面跟的配置文件是文本格式的.pbtx文件而不是二进制格式。配置文件里可以指定要采集的数据源比如ftrace、heapprofd、power、android.log等。等抓取完成用 adb pull 把文件拉到本地adb pull /data/misc/perfetto-traces/startup.pftrace ./拿到文件后我可以直接把.pftrace文件拖到 UI 页面看可视化时间线也可以用内置的 Shortcuts 快速筛选关键信息。如果你更习惯命令行还可以直接用 trace_processor 去做深度的 SQL 分析。3.2 Linux 平台无 UI 环境下的抓取与解析Linux 平台的使用方式稍有不同。因为 PC 上往往没有 Android 那套 traced 服务所以我一般直接用 tracebox 工具它会自己把需要的组件准备好。以 Ubuntu 服务器为例先下载对应架构的 tracebox 可执行文件发行版不同文件不同加执行权限后直接运行。抓取一段 30 秒的系统调度数据./tracebox -o trace.dat --time 30s --txt -c config.pbtx配置文件里同样可以声明数据源比如data_sources { config { name: linux.ftrace ftrace_config { ftrace_events: sched/sched_switch ftrace_events: sched/sched_wakeup ftrace_events: power/cpu_frequency } } }这个配置抓到的数据主要就是 CPU 调度切换、唤醒事件和频率变化。你说它跟perf sched record有什么不一样其实底层很可能都是 ftrace但 Perfetto 在时间线整合、查询能力上确实强很多尤其你把调度事件和其他用户态事件放一起分析的时候这个优势非常明显。无 UI 环境下分析也可以用命令行直接跑 SQL。trace_processor 可以加载 trace 文件进入交互式 shell./trace_processor trace.dat进入后可以用q命令做各种查询。我通常在服务器上把需要的数据用 SQL 导出成 CSV再拉回本地做图表分析。整个流程完全脱离图形界面适合部署在 CI 环境里做自动化性能回归。3.3 trace_processor用 SQL 回答性能问题讲真Perfetto 的 SQL 分析能力才是它拉开跟 systrace 差距的关键。早期性能分析基本靠“肉眼盯时间线”Perfetto 直接给了你一个 SQL 引擎等于把性能分析变成了一次数据库查询过程。举一个实际场景我想查一下一个 app 启动过程中主线程上调用时间最长的函数是什么。可以先找到主线程的 utid然后查 slice 表SELECT name, dur / 1e6 AS dur_ms, ts / 1e9 AS ts_s FROM slice WHERE utid 123 ORDER BY dur DESC LIMIT 10;这里slice表保存的是所有用户态打点的函数区间dur单位是纳秒我习惯除以 1e6 转成毫秒方便判断耗时量级。再比如我想从 trace 里查每个 CPU 上空闲占比可以通过 counter 表或直接用sched_slice做聚合。类似的Perfetto 还内置了几张常用视图比如process、thread、sched_slice、ftrace_event等基本能满足 90% 的性能分析需求。这个能力的意义在于你不需要为一个特定的性能问题去写复杂的解析脚本只要充分利用 SQL 的聚合、过滤、排序能力很多答案可以直接问出来。4. 实战场景三个高频性能问题的分析套路4.1 冷启动耗时排查先看线程再看 Binder冷启动问题大概是 Android 性能优化里咨询量最大的。按我的经验第一步不是去代码里猜而是抓一份冷启动 trace然后拉出process表看看整个过程里这个应用到底经历了什么。我常用的一个 SQL 是查跟目标应用相关的关键 sliceSELECT ts / 1e6 AS ts_ms, name, dur / 1e6 AS dur_ms FROM slice WHERE process.name com.example.app AND dur 0 ORDER BY ts;从结果里我会着重看几类 sliceActivityThread.handleBindApplication这代表 Application 进程的初始化过程包括 ContentProvider 的创建调用。ActivityStart相关事件Activity 启动的流程。Choreographer相关的帧回调看是否有明显掉帧。如果发现某个 slice 明显过宽比如某 ContentProvider 的attachInfo耗时很长我就能直接告诉开发同事去查这个提供者的初始化逻辑。如果 trace 显示主线程很闲但等待某个 Binder 调用那就要往系统服务方向排查了。整个流程的思路是先看主线程在等什么再看是谁拖慢了主线程最后定位到具体模块。这个三步走方法可以应对绝大多数启动性能问题。4.2 掉帧卡顿FrameTimeline 与 sched_wakeup 组合定位掉帧问题比启动问题要复杂因为涉及的线程可能是 RenderThread也可能是 GPU 合成线程。我用 Perfetto 的经验是Android 12 之后的系统能直接抓取track_event类型的FrameTimeline数据直观展示每一帧的生成过程。具体抓取时我会在配置里开启android.perfetto相关数据源或者使用桌面工具直接抓录一段 UI 操作。分析时我会看actual_frame_timeline_slice这个表会记录每一帧的display_frame_token、start_time、end_time、jank_type等字段。如果结果显示jank_type ! 0就说明这一帧掉帧了。此时再去查sched_wakeup事件看渲染线程是被什么原因唤醒的、唤醒之后有没有被抢占了 CPU。有一次我在某个低端机上排查掉帧就是靠这种组合方式定位到 GPU 驱动的一个 bug渲染线程频繁被一个高优先级的内核线程打断导致 fence 等待超时。需要单独列出一个实践建议分析掉帧时不要只看应用层打点一定要结合调度信息否则你看到的“RenderThread 耗时 30ms”实际上有一半是等 CPU 调度的时间。两者的优化方向完全不同。4.3 CPU 行为与后台耗电搞定功耗归因功耗问题有一个难点耗电不是某一个线程单独造成的而是多个模块反复唤醒、保持高频率运行叠加出来的结果。Perfetto 能抓 CPU frequency、scheduler、power rails 的数据正好能把这种叠加效应数据化。我的做法是抓一段线上场景的 trace比如待机状态挂后台 10 分钟观察 CPU frequency 的分布和时间占比。如果发现某个 CPU 一直高频运行再去看那个时间段内有哪些线程在跑。这里有个我踩过的坑有时候线程并没有进入 RUNNING 状态但频繁的sched_wakeup一样会让 CPU 无法进入深度 idle造成耗电。这个问题从线程状态上看是“这个线程没占多少 CPU”但实际上耗电影响很大。Perfetto 的调度事件能让你看到 wakeup 次数配合counter表看 CPU 频率时间线能把这个隐蔽问题揪出来。总之处理这类问题需要多源数据相互印证sleep 状态、wakeup 次数、CPU 频率分布、电源状态变化。把这些维度全部放到同一张时间线下看归因会容易得多。5. 常见问题与排查技巧实录5.1 trace 文件过大或抓取失败怎么办我最早用 Perfetto 时就遇到过抓了 30 秒 trace文件快 1GB 的情况。那时候 PC 配置也一般UI 加载直接卡死。后来我学乖了抓取之前先想清楚这次要解决什么问题按需裁剪数据源。一条实用原则尽量缩小抓取窗口比如启动问题抓 15 秒内就够不需要长时间挂着。如果确实需要长时间观察建议分成多段窗口分别抓取而不是直接拉长单一窗口。另外配置里可以设置flush_period_ms和max_file_size_bytes比如限定文件最大 200MB超过就自动截断。这类配置能避免抓取过程把设备内存和存储打满。如果抓取过程中提示权限不足大概率是 shell 权限在某些定制 ROM 上受限制此时需要 root 或者厂商开放才可覆盖到所有数据源。5.2 SQL 查询缓慢与常用视图很多人在第一次用 trace_processor 跑 SQL 时会碰到一条聚合查询等了好几分钟的情况。这时的第一反应不应该是加机器配置而是先看查询方式。trace_processor 的 SQL 引擎支持EXPLAIN QUERY PLAN你可以先分析一下查询计划。更常见的优化手段是尽量缩小时间范围或者先通过slice、sched_slice等宽表过滤出一部分行再跟其他表做 join避免大范围扫描。再推荐几个我常用的高频视图process、thread进程与线程基本信息。slice用户态打点区间比如函数调用、Binder 操作。sched_slice内核调度的运行片段能看出线程实际在 CPU 上跑了多久。counter计数器数据如 CPU 频率、电池电量、内存占用等。ftrace_event原始 ftrace 事件灵活而强大。从这些视图出发基本能应对 95% 的常规问题。如果碰到超级大的 trace 文件本地分析不动还可以考虑用 Perfetto 提供的 BigQuery 导入方案不过普通项目用不上知道有这条路就行。5.3 高频踩坑清单最后根据我自己的经验整理了一份常见的坑遇到类似情况可以少折腾问题现象原因处理方式抓取的 trace 里没有 ftrace 事件配置没有开启 linux.ftrace 数据源或者 shell 权限不足检查 pbtx 配置部分数据源需要 root 权限时间线上 Event 和 ftrace 对不齐设备时间同步问题或 trace 抓取时刚好有休眠事件建议刚开机后迅速抓取避免深度休眠造成的时间段失真应用层 slice 信息丢失目标 app 没有开启相应的 atrace category在配置中增加android.atrace数据源并配置对应的 categoriestrace 文件下载到本地后 UI 打不开trace 版本过新或过旧更新本地 UI 或使用对应版本的 trace_processor查询 slice 时看不到 Binder 调用需要抓取binder_driver相关事件在 ftrace_events 中添加上 binder 相关的 events注意在部分定制系统上perfetto命令的可用性取决于系统版本和权限策略。如果遇到perfetto: command not found先确认系统版本是否支持需要 root 时优先考虑在测试设备上统一处理。我自己的体会是Perfetto 这类工具只要把“抓取-分析-定位”的闭环跑顺一次后面的性能问题排查效率会明显上一个大台阶。你不再需要靠一堆临时脚本和直觉去猜问题而是直接从数据里找答案。如果是刚接触建议从 Android 上一两个最常见的启动/卡顿场景开始练手一步一步把数据分析的流程建立起来。后面再接触到其他复杂场景无非是换数据源、换 SQL 的事底层那套逻辑是通用的。
