3 步定位卡顿Perfetto 性能分析实战手册【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto列表滑动掉帧、冷启动变慢logcat 里翻半天却查不到原因。这类问题的共性是耗时发生在多个线程、多个进程之间单条日志只能看到碎片。Perfetto 性能分析用 trace带时间戳的系统事件记录文件把 CPU 调度、内存、GPU、帧事件全部对齐到一条时间轴上让谁在什么时候卡住了直接可见。Perfetto 能帮你查什么适合Android 与 Linux 上的系统级性能问题系统追踪默认跑在 Android/LinuxWindows/macOS 只能采应用内数据系统级探针缺失包括线程为什么没被调度、锁在哪等待、内存怎么增长、帧为什么迟到。你的应用代码可以通过 Tracing SDK 或 atrace 埋点在代码里打时间戳标记把内部函数变成时间轴上的 slice一段带起止时间的事件块。边界也要清楚它负责看到发生了什么不负责怎么修。定位到锁竞争或热点调用栈后优化还得回到代码本身。拿到第一份 trace 的最短路径git clone https://gitcode.com/GitHub_Trending/pe/perfetto录制用仓库里自带的tools/record_android_trace脚本手机 USB 连电脑装好 adbpython3 tools/record_android_trace -t 10s -b 32mb -a * sched freq view ss input10 秒时长32MB 缓冲区trace 事件先攒在设备内存里满了按策略丢弃或覆盖sched、freq采集 CPU 调度与频率view、ss、input采集 atrace 标注。录制结束文件自动拉回并在 Perfetto UI 打开。如果你习惯命令行配置也可以直接给设备上的 perfetto 进程喂一段文本配置格式参考 系统追踪教程。一次完整的卡顿排查采集先让掉帧帧浮出水面录 trace 时复现滑动。打开后找目标进程的 FrameTimeline 轨道需要 Android 12它给每个应用画 Expected Timeline 和 Actual Timeline 两条轨道实际渲染超过预算的帧会标红该应用导致掉帧或标黄SurfaceFlinger 侧导致。选中那块详情里直接给出 Present Type、Jank Type 和 GPU 合成与否。定位从帧到线程到调用栈帧掉帧只说明慢了原因是主线程没在预期时间运行。看主线程的调度状态轨道Running / Runnable / Sleeping 色块Runnable 却长时间不上 CPU 是调度延迟Sleeping 则是被阻塞。仓库里 SystemUI 调度阻塞案例 的完整流程值得照抄对sched_switch每次线程切换的内核事件挂调用栈采样把采样过滤到目标线程配置里加filter只采*systemui*避免全系统采样把采样器压垮。图中主线程在Choreographer#doFrame中卡了 15.5mssched_switch采样调用栈显示它 park 在ReentrantLock.lock上。点击恢复运行后的 Running 块看 woken by 字段找到唤醒者唤醒者的sched_waking采样调用栈则暴露出持锁方——多个后台协程线程排队抢同一把ScheduledThreadPoolExecutor的锁形成优先级反转。验证修复改代码前先把证据链固定用 Critical path lite 面板确认主线程状态变更的完整因果链。修复换锁、把任务出队挪出临界区后重录同样场景的 trace对比两条 FrameTimeline红块消失、doFrame 回到预算内才算闭环。高频场景速查内存持续增长先拿趋势再拿归因。配置里开linux.process_stats采集 RSS常驻物理内存计数器在 UI 里确认mem.rss曲线是单调爬升还是台阶式上涨——台阶往往对应某次批量分配。归因用堆 profilenative 堆用tools/heap_profile android -n 进程名跟踪 malloc/free 并按调用栈归因Java 堆用tools/java_heap_dump导出对象图。两者在 UI 里都呈现为火焰图看 Unreleased malloc size已分配未释放的字节数。Filters 输入框支持按帧名过滤比如输入applyStyle只看经过该函数的分配路径。GPU 高负载开启 GPU 探针后进程轨道下会出现 GPU Compute 轨道。选中一个 kernel 块详情面板给出 SM 频率、Duration、L1/L2 Cache Throughput、Compute 吞吐和各 pipe 的 active 百分比见下图Compute (SM) Throughput高说明是计算瓶颈DRAM Throughput高说明访存瓶颈Tensor Pipe Active 高则是矩阵运算密集。进阶两个抓手SQL 查询UI 左上角切到 SQL 模式trace 被解析成一堆标准表slice、thread_track、thread等可用聚合查询回答 UI 看不到的问题SELECT t.name AS thread_name, SUM(s.dur) / 1e6 AS ms FROM slice s JOIN thread_track tt ON s.track_id tt.id JOIN thread t ON tt.utid t.utid GROUP BY t.name ORDER BY ms DESC LIMIT 20;按线程汇总运行时长前几名就是 CPU 大户。表结构和标准库函数的完整清单见 SQL 分析入门。自定义追踪配置配置本质是一个文本 proto四个关键项buffers { size_kb: …, fill_policy: DISCARD }DISCARD 满了丢新事件RING_BUFFER 覆盖最旧数据、duration_ms、data_sources列表、以及每个探针内部的filter。排查单一进程时给linux.perf的采样加线程名过滤、给linux.ftrace只开需要的 tracepoint能把数据量和录制开销都压一个量级。避坑清单缓冲区别贪大也别贪小DISCARD 策略下缓冲区写满会丢事件录制结束后检查 UI 的 Info and stats 有无 drop 告警30 秒系统 trace32–64MB 是常见起点。全系统period: 1的调用栈采样会压垮采样器案例里空闲手机每秒就有约 2 万次调度事件必须用 filter 收窄到目标线程。内存曲线看 RSS 不够短促尖峰可能不留下高水位但足以触发 LMK 杀进程要看完整曲线或配合mm_event事件。堆 profile 只记录运行期间的分配启动前分配的内存看不到需要覆盖目标操作再录。帧块颜色有语义红是该应用导致掉帧黄是 SurfaceFlinger 导致蓝是丢帧——别把所有非绿帧都归咎于自己。录制期间尽量别切换 App 后台后台进程会被限频甚至冻结trace 里出现的行为和用户实际体验不一致。下一步先跑通录一份 10 秒 trace FrameTimeline 找红帧这条最小链路把它固化成你团队的卡顿排查 SOP再按上面的场景补内存与 GPU 探针。工具的价值不在多快出图而在每次卡顿都有同一套可复现的证据。【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 3 步定位卡顿：Perfetto 性能分析实战手册
3 步定位卡顿Perfetto 性能分析实战手册【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto列表滑动掉帧、冷启动变慢logcat 里翻半天却查不到原因。这类问题的共性是耗时发生在多个线程、多个进程之间单条日志只能看到碎片。Perfetto 性能分析用 trace带时间戳的系统事件记录文件把 CPU 调度、内存、GPU、帧事件全部对齐到一条时间轴上让谁在什么时候卡住了直接可见。Perfetto 能帮你查什么适合Android 与 Linux 上的系统级性能问题系统追踪默认跑在 Android/LinuxWindows/macOS 只能采应用内数据系统级探针缺失包括线程为什么没被调度、锁在哪等待、内存怎么增长、帧为什么迟到。你的应用代码可以通过 Tracing SDK 或 atrace 埋点在代码里打时间戳标记把内部函数变成时间轴上的 slice一段带起止时间的事件块。边界也要清楚它负责看到发生了什么不负责怎么修。定位到锁竞争或热点调用栈后优化还得回到代码本身。拿到第一份 trace 的最短路径git clone https://gitcode.com/GitHub_Trending/pe/perfetto录制用仓库里自带的tools/record_android_trace脚本手机 USB 连电脑装好 adbpython3 tools/record_android_trace -t 10s -b 32mb -a * sched freq view ss input10 秒时长32MB 缓冲区trace 事件先攒在设备内存里满了按策略丢弃或覆盖sched、freq采集 CPU 调度与频率view、ss、input采集 atrace 标注。录制结束文件自动拉回并在 Perfetto UI 打开。如果你习惯命令行配置也可以直接给设备上的 perfetto 进程喂一段文本配置格式参考 系统追踪教程。一次完整的卡顿排查采集先让掉帧帧浮出水面录 trace 时复现滑动。打开后找目标进程的 FrameTimeline 轨道需要 Android 12它给每个应用画 Expected Timeline 和 Actual Timeline 两条轨道实际渲染超过预算的帧会标红该应用导致掉帧或标黄SurfaceFlinger 侧导致。选中那块详情里直接给出 Present Type、Jank Type 和 GPU 合成与否。定位从帧到线程到调用栈帧掉帧只说明慢了原因是主线程没在预期时间运行。看主线程的调度状态轨道Running / Runnable / Sleeping 色块Runnable 却长时间不上 CPU 是调度延迟Sleeping 则是被阻塞。仓库里 SystemUI 调度阻塞案例 的完整流程值得照抄对sched_switch每次线程切换的内核事件挂调用栈采样把采样过滤到目标线程配置里加filter只采*systemui*避免全系统采样把采样器压垮。图中主线程在Choreographer#doFrame中卡了 15.5mssched_switch采样调用栈显示它 park 在ReentrantLock.lock上。点击恢复运行后的 Running 块看 woken by 字段找到唤醒者唤醒者的sched_waking采样调用栈则暴露出持锁方——多个后台协程线程排队抢同一把ScheduledThreadPoolExecutor的锁形成优先级反转。验证修复改代码前先把证据链固定用 Critical path lite 面板确认主线程状态变更的完整因果链。修复换锁、把任务出队挪出临界区后重录同样场景的 trace对比两条 FrameTimeline红块消失、doFrame 回到预算内才算闭环。高频场景速查内存持续增长先拿趋势再拿归因。配置里开linux.process_stats采集 RSS常驻物理内存计数器在 UI 里确认mem.rss曲线是单调爬升还是台阶式上涨——台阶往往对应某次批量分配。归因用堆 profilenative 堆用tools/heap_profile android -n 进程名跟踪 malloc/free 并按调用栈归因Java 堆用tools/java_heap_dump导出对象图。两者在 UI 里都呈现为火焰图看 Unreleased malloc size已分配未释放的字节数。Filters 输入框支持按帧名过滤比如输入applyStyle只看经过该函数的分配路径。GPU 高负载开启 GPU 探针后进程轨道下会出现 GPU Compute 轨道。选中一个 kernel 块详情面板给出 SM 频率、Duration、L1/L2 Cache Throughput、Compute 吞吐和各 pipe 的 active 百分比见下图Compute (SM) Throughput高说明是计算瓶颈DRAM Throughput高说明访存瓶颈Tensor Pipe Active 高则是矩阵运算密集。进阶两个抓手SQL 查询UI 左上角切到 SQL 模式trace 被解析成一堆标准表slice、thread_track、thread等可用聚合查询回答 UI 看不到的问题SELECT t.name AS thread_name, SUM(s.dur) / 1e6 AS ms FROM slice s JOIN thread_track tt ON s.track_id tt.id JOIN thread t ON tt.utid t.utid GROUP BY t.name ORDER BY ms DESC LIMIT 20;按线程汇总运行时长前几名就是 CPU 大户。表结构和标准库函数的完整清单见 SQL 分析入门。自定义追踪配置配置本质是一个文本 proto四个关键项buffers { size_kb: …, fill_policy: DISCARD }DISCARD 满了丢新事件RING_BUFFER 覆盖最旧数据、duration_ms、data_sources列表、以及每个探针内部的filter。排查单一进程时给linux.perf的采样加线程名过滤、给linux.ftrace只开需要的 tracepoint能把数据量和录制开销都压一个量级。避坑清单缓冲区别贪大也别贪小DISCARD 策略下缓冲区写满会丢事件录制结束后检查 UI 的 Info and stats 有无 drop 告警30 秒系统 trace32–64MB 是常见起点。全系统period: 1的调用栈采样会压垮采样器案例里空闲手机每秒就有约 2 万次调度事件必须用 filter 收窄到目标线程。内存曲线看 RSS 不够短促尖峰可能不留下高水位但足以触发 LMK 杀进程要看完整曲线或配合mm_event事件。堆 profile 只记录运行期间的分配启动前分配的内存看不到需要覆盖目标操作再录。帧块颜色有语义红是该应用导致掉帧黄是 SurfaceFlinger 导致蓝是丢帧——别把所有非绿帧都归咎于自己。录制期间尽量别切换 App 后台后台进程会被限频甚至冻结trace 里出现的行为和用户实际体验不一致。下一步先跑通录一份 10 秒 trace FrameTimeline 找红帧这条最小链路把它固化成你团队的卡顿排查 SOP再按上面的场景补内存与 GPU 探针。工具的价值不在多快出图而在每次卡顿都有同一套可复现的证据。【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考