Perfetto如何快速追踪Android性能问题

Perfetto如何快速追踪Android性能问题【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto应用打开列表页时卡了两秒日志里却什么都看不到。你需要的是一次完整的Android 性能追踪而不是再猜一轮。这篇教程用 Perfetto 跑通「录制 → 读数据 → 定位根因」的全流程全程只需要 adb 和官方文档里的现成 SQL。读完你能做到2 分钟内录出第一个可打开的 trace读懂帧卡顿、内存、CPU 三类数据跟一个真实的冷启动变慢案例走到修复 一认识它Android 性能追踪靠什么Perfetto 是 Google 开源的系统级性能追踪与剖析工具深度集成在 Android 里设备连上后你用 adb 就能直接录。一次录制同时捕获内核调度、进程内存、渲染管线等多路数据丢进一个文件。它的 UI 提供时间线瀑布和 SQL 查询两种视图看图定位、查数验证不用切换工具。这也是它成为 Android 官方推荐方案的原因数据全、零安装、查询可编程。 二最小上手路径一条命令录出第一个 trace本节只给最短路径录一个 10 秒的 trace拉回本地打开即算跑通。echo duration_ms: 10000 buffers: { size_kb: 8192 } | adb shell perfetto -c - --txt -o /data/misc/perfetto-traces/first.pftrace adb pull /data/misc/perfetto-traces/first.pftraceduration_ms控制录制时长到点自动停止。把拉下来的first.pftrace拖进 Perfetto UI能看到 CPU 轨道和进程列表就说明链路通了。完整的数据源配置这里不展开跑通再谈。 三三个高频场景卡顿、内存、CPU 各怎么查怎么录卡顿打开 FrameTimeline现象列表滚动发涩用户说「不流畅」但你看不到哪一帧掉了、谁的责任。操作在 UI 的 Record 页启用android.surfaceflinger.frametimeline数据源配置里就一行name: android.surfaceflinger.frametimeline复现卡顿后停止录制。结果怎么看每个出帧的应用会有两条轨道——Expected Timeline 是系统给的时间窗口Actual Timeline 是真实耗时。slice 颜色即结论红色是应用自身导致的卡顿黄色是 SurfaceFlinger 的锅蓝色是掉帧。点一下红色 slice底部会给出Present Type早/准点/迟到、Jank Type如App Deadline Missed和On time finish。避坑FrameTimeline 需要 Android 12S及以上且暂不支持 SurfaceView版本不够时轨道会是空的。怎么查 Java 内存泄漏录一个堆快照现象应用越用越卡、内存曲线只涨不跌你想找到是谁把对象攥在手里。操作UI 的 Record 页点Memory探针勾选ART heap dumps在 Names 里填进程名开始录制并复现操作没有 UI 环境时也可以跑仓库里的tools/java_heap_dump -n com.example.myapp。结果怎么看在 ART heap dump 轨道上点箭头标记会展开一张堆图。默认按 Object Size 聚合相同类型的对象看最宽的保留链切到Dominated Object Size则用支配树口径更接近「真正留住这些对象」的责任方。root 的总字节数就是快照时刻的堆规模。避坑录制时长对堆转储没有意义——完整 dump 只在结束时刻产出一份选 10 秒以内即可录更久不会多出任何数据。怎么算进程 CPU 占用SQL 一行聚合现象你知道某个进程「很忙」但说不清它在 10 秒窗口里实际吃掉了多少 CPU 时间。操作录制时先启用sched_switch、sched_waking等 ftrace 调度事件完整配置见官方文档然后在 UI 的 Query(SQL) 面板里执行INCLUDE PERFETTO MODULE linux.cpu.utilization.process; SELECT name, time_to_ms(SUM(runtime)) AS runtime_msec FROM cpu_cycles_per_process JOIN process USING(upid) WHERE name com.example.myapp GROUP BY name;结果怎么看runtime_msec是该进程在整个录制窗口内实际占用的 CPU 毫秒数。拿它对比窗口总时长就知道进程是 CPU 密集还是大部分时间在等待再按核统计sched_slice的条数能看出线程是否均匀分布在各核上。避坑录制时没开 ftrace 调度事件cpu_cycles_per_process就没有数据查询会直接返回空——录制配置比查询语句更重要。 四跟一个真实问题走到最后冷启动为什么变慢测试群反馈「App 打开明显变慢了」量了一下冷启动从常规的 1.5 秒左右涨到了4.1 秒。第一假设是主线程干了重活解析配置、等网络。于是录了一次启动窗口先看主线程——doFrame和各阶段 slice 都不慢第一假设被推翻。第二个假设转向锁启动路径如果撞上别人正拿着的synchronized主线程会被动等待。用官方文档里现成的两条模块android.monitor_contention与android.startup.startups把启动时段和主线程锁竞争做交集完整查询见docs/getting-started/android-trace-analysis.md跑了一遍结果很干脆主线程在启动阶段累计花了约2.3 秒等一把锁而持锁方是一个后台同步线程在批量写缓存。瓶颈不在主线程自己的工作量而在它和后台线程共享了一把锁。修复方向就清晰了缓存改懒加载、把大锁拆细、后台写盘移出启动关键路径。改动后重新录一次同样的 trace冷启动回落到1.6 秒且锁竞争查询里主线程的阻塞时长归零。这个故事的价值在于「启动慢」有十个常见原因SQL 证据能把怀疑从十个缩小到一个。 五常见疑问Quser build 的设备提示我的应用不能被剖析怎么办在 manifest 里把应用标记为profileable或debuggable即可userdebug / eng 版本系统没有这个限制。Qnative 堆剖析为什么看不到进程启动前的分配堆剖析不是回溯式的只记录会话开始之后的 malloc。要覆盖启动分配必须在进程启动之前就开始录制。QFrameTimeline 轨道为什么是空的确认两件事设备是 Android 12S或更高且界面内容不是 SurfaceView。两者任一不满足轨道就不会有数据。 六想继续深入docs/getting-started/android-trace-analysis.mdAndroid trace 的 SQL 食谱从找 slice 到内存、调度聚合帮你把「看图」升级成「查数」。docs/case-studies/memory.mdAndroid 内存问题端到端排查案例帮你串起 native 堆与 Java 堆转储两条线。docs/data-sources/frametimeline.mdFrameTimeline 全部卡顿类型与 Expected/Actual 双轨道定义帮你精确归因每一帧。docs/getting-started/system-tracing.md从零构建完整录制配置帮你决定数据源、buffer 与时长怎么配。录一条 trace 只需一行命令真正的功夫在读懂它——如果你手头有卡了很久的性能问题欢迎在留言里描述场景一起看它该用哪条查询来破。【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考