📚 课程目录第3章工具链准备

3、工具链准备：熟悉常用的性能分析工具（如Perfetto、Systrace、GPU profiler、内存分析器）的安装与基本使用

旭日性能优化工作本质上是一场“数据驱动的诊断手术”。在动手调整任何参数之前，我们必须先建立一套可靠的观测体系。如果缺少精准的工具链，帧率波动、内存泄漏、温度失控都只是模糊的主观感受，无法定位到具体的函数调用栈、GPU渲染管线阶段或内存分配点。本章将系统梳理旭日平台上最核心的四类性能分析工具：系统级追踪工具（Perfetto/Systrace）、GPU专用剖析器、内存分析器以及温度与功耗监控工具。我们将聚焦于这些工具的安装路径、基本操作流程、关键指标解读以及它们在实际问题定位中的协同方式。

上图展示了旭日性能优化工具链的完整工作流。在实际项目中，我们通常先在设备端进行多维度数据采集，然后通过统一的时间戳将CPU、GPU、内存和温度数据汇聚到同一份trace文件中，最后在主机端使用可视化工具进行交叉分析。这种协同方式能够帮助我们快速建立“现象→原因→代码位置”的映射关系。

3.1 系统级追踪：Perfetto 与 Systrace 的安装与核心操作

核心原理：Perfetto 是 Android 10+ 及旭日 RTOS 上推荐的全系统追踪工具，它取代了早期的 Systrace。其核心机制是通过内核的 ftrace 机制和用户空间的 atrace 服务，以极低的开销记录 CPU 调度、线程唤醒、系统调用、Binder 通信以及应用自定义的 Trace 点。Systrace 本质上是 Perfetto 的前身，其生成的 HTML 报告在分析短时卡顿时仍有价值，但 Perfetto 提供了更强大的 SQL 查询分析和多轨道缩放能力。

安装与启动流程：在旭日开发环境中，Perfetto 通常已集成在系统镜像中。若需手动安装，可通过以下命令完成：

# 检查设备端 perfetto 版本
adb shell perfetto --version

# 若未安装，推送二进制文件（以 arm64 为例）
adb push perfetto /data/local/tmp/
adb shell chmod +x /data/local/tmp/perfetto

# 启动一个 10 秒的追踪，捕获 CPU 调度和内核事件
adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto-trace \
    -t 10s \
    sched freq idle am_proc_start gfx_view

# 拉取 trace 文件到主机
adb pull /data/misc/perfetto-traces/trace.perfetto-trace .

关键操作要点：在录制长帧率问题时，建议使用 --buffer-size 参数增大缓冲区（例如 128MB），避免高频事件导致的数据丢失。对于 Systrace，虽然已停止更新，但在旧版本系统上仍可使用 python systrace.py --time=10 -o trace.html 命令生成报告。在 Perfetto UI（ui.perfetto.dev）中，我们应重点关注 SurfaceFlinger 轨道、RenderThread 轨道以及 CPU 频率轨道，这三者能直接反映帧生成节奏和降频情况。

经验提醒：在录制长时间追踪（超过30秒）时，务必开启 --conservative 模式或使用 --ring-buffer 功能，否则 trace 文件会迅速膨胀至数 GB，导致分析时内存溢出。对于周期性卡顿问题，建议采用“边录制边观察”的策略，在问题复现后立即停止录制。

3.2 GPU 性能剖析：从帧时间到渲染阶段拆解

判断方法：GPU Profiler 的核心价值在于将一帧的渲染时间拆解为 CPU 提交时间、GPU 执行时间和 显示合成时间。在旭日平台上，我们通常使用 gpustats 命令行工具或 Android Studio 的 GPU Profiler 插件。若使用 Mali GPU，则推荐使用 Arm Streamline Performance Analyzer。

操作流程：以 Android Studio GPU Profiler 为例，连接设备后选择目标进程，点击 “GPU” 面板即可开始录制。关键指标包括：

Frame Time：总帧时间，目标应低于 16.6ms（60fps）或 11.1ms（90fps）。
Render Stage：Vertex Shader、Fragment Shader、Rasterization 各阶段耗时。
Draw Call 数量：每帧的绘制调用次数，通常应控制在 200 次以内。
Overdraw：像素过度绘制倍数，超过 2.0 时需检查半透明层叠。

对于更底层的 GPU 计数器，可使用命令行方式获取：

# 开启 GPU 计数器采集（Mali 系列）
adb shell setprop debug.gpu.counters "Mali_GPU_ACTIVE,Mali_FRAG_ACTIVE,Mali_VERT_ACTIVE"
adb shell dumpsys gfxinfo <package_name> framestats

实战场景：某游戏在复杂场景中帧率从 60fps 骤降至 40fps。通过 GPU Profiler 发现 Fragment Shader 阶段耗时从 4ms 激增至 12ms，而 Draw Call 数量并未显著增加。进一步查看计数器发现 Mali_FRAG_ACTIVE 占比高达 95%，说明瓶颈在像素填充率。通过减少动态阴影的分辨率并将部分后处理特效改为 half-resolution 渲染，帧时间恢复至 14ms。

风险提示：GPU Profiler 在录制时会增加 5%-10% 的额外开销，因此测得的帧时间会略高于真实值。在对比优化前后数据时，务必使用相同的录制条件（同一场景、同一时长、同一设备温度），否则对比结果不具备参考意义。

3.3 内存分析器：追踪泄漏与分配压力

核心原理：内存分析器主要分为两类：Java/堆内存分析（使用 Android Profiler 的 Memory 面板）和 原生内存分析（使用 malloc_debug 或 heapprofd）。旭日平台上的内存问题往往表现为 RSS 持续增长、GC 频繁或直接内存溢出。Perfetto 内置的 heapprofd 工具可以在不重启应用的情况下对原生内存分配进行采样。

操作流程（以 heapprofd 为例）：

# 在设备端启动 heapprofd 服务，采样 5 秒
adb shell heapprofd -p <pid> -t 5s -o /data/misc/heapprofd/heap.pb

# 拉取并转换文件
adb pull /data/misc/heapprofd/heap.pb .
# 使用 Perfetto UI 打开 heap.pb 即可查看调用栈分配热力图

判断方法：在分析内存报告时，应重点关注 “分配次数多但释放次数少” 的函数栈。例如，若发现 BitmapFactory.nativeDecodeStream 分配了 200MB 内存但仅释放了 50MB，则基本可判定为图片未及时回收。对于 Java 堆，可利用 Android Studio 的 Heap Dump 功能，对比两次 dump 之间 Shallow Size 与 Retained Size 的差值来定位泄漏 Activity。

工具名称	适用场景	关键指标	安装方式
Android Profiler	Java/Kotlin 堆分析	Heap Size、Allocation Rate	Android Studio 内置
heapprofd	原生 C/C++ 内存	调用栈分配统计	系统内置（API 27+）
malloc_debug	检测内存越界/重复释放	guard region 校验	adb shell setprop libc.debug.malloc 1
dmabuf 分析	GPU/显示内存泄漏	dmabuf 句柄数量	cat /sys/kernel/debug/dma_buf/bufinfo

案例拆解：某视频应用在连续播放 2 小时后内存占用从 300MB 涨至 1.2GB。通过 heapprofd 采样发现 MediaCodec 的 dequeueOutputBuffer 调用栈中，每次解码后未调用 releaseOutputBuffer，导致底层 buffer 持续累积。修复后内存稳定在 350MB 左右。此案例说明，内存分析不仅要看总占用，更要关注 buffer 生命周期管理。

3.4 温度与功耗监控：降频与热约束的预警

核心原理：温度控制是旭日性能优化中容易被忽视但至关重要的一环。当 SoC 温度超过阈值（通常为 85°C-95°C），系统会触发 热降频 机制，优先降低 CPU/GPU 频率以保护硬件。这种降频往往导致帧率断崖式下跌。因此，我们需要实时监控温度变化与频率调整的联动关系。

监控命令：

# 实时读取 CPU 温度（以 tsens 为例）
adb shell cat /sys/class/thermal/thermal_zone0/temp

# 查看当前 CPU 频率
adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

# 使用 perfetto 同时记录温度与频率（推荐）
adb shell perfetto -t 30s -o /data/misc/trace.therm \
    -c /data/local/tmp/thermal_config.pbtx

判断方法：在分析温度问题时，应绘制 “温度-频率-帧时间” 三轴曲线。若发现帧时间恶化与 CPU 频率下降在时间上高度重合，且此时温度超过 80°C，则可判定为热降频导致。此时优化方向不是提升性能，而是 降低功耗：例如限制最大频率、优化渲染分辨率、减少不必要的后台任务。

  实战建议：在性能测试间期，务必记录设备温度。若测试开始时温度已超过 40°C，应先让设备冷却至室温（25°C-30°C）再开始测试。否则，由于热累积效应，测试结果会逐渐偏离真实性能水平。建议在测试脚本中增加温度检查点，当温度超过 45°C 时自动暂停测试。

3.5 工具链协同与常见误区

协同策略：单一工具往往只能看到问题的一个侧面。例如，Perfetto 显示 CPU 空闲但帧率低，此时需要借助 GPU Profiler 确认是否 GPU 过载；若 GPU 负载正常，则需检查内存分析器是否出现频繁的页面交换。推荐的排查顺序是：先看温度与频率（排除热降频）→ 再看 CPU 调度（排除线程饥饿）→ 然后看 GPU 渲染阶段（排除着色器瓶颈）→ 最后看内存分配（排除 GC 或泄漏）。

常见误区：

误区一：过度依赖 Perfetto 而忽略 GPU 计数器。Perfetto 的 GPU 轨道在部分旭日驱动上可能不完整，必须结合厂商工具交叉验证。
误区二：在 Debug 包上做性能分析。Debug 包包含大量日志和断言代码，其性能特征与 Release 包差异巨大，分析结果不可信。
误区三：忽略 trace 录制时的负载干扰。录制 trace 本身会占用 CPU 和存储 I/O，对于微卡顿（< 5ms）问题，建议使用 --light 模式减少采样频率。
误区四：只关注平均帧率而不看帧时间分布。平均 60fps 可能掩盖了每 2 秒一次的 200ms 长卡顿，应使用 dumpsys gfxinfo framestats 查看 P95/P99 帧时间。

总结复盘：工具链的熟练运用是性能优化的基本功。建议团队建立标准化的 “性能问题诊断 SOP”：第一步，使用 Perfetto 录制 10 秒常规场景；第二步，使用 GPU Profiler 录制同一场景的渲染阶段；第三步，使用 heapprofd 采样 5 秒内存分配；第四步，同步记录温度曲线。通过这套组合拳，80% 的帧率与内存问题都能在半小时内定位到具体函数或资源。最后，务必保持工具版本的统一，避免因工具差异导致的数据误判。