2、性能指标采集：使用FPS Meter、Profile工具、Trace事件采集帧率数据
好，咱们进入第二章。上一章我们聊了帧率不稳到底是个什么鬼，这一章就动真格的了——怎么把数据抓到手。
我个人习惯，做性能优化之前，先问自己三个问题：
- 现在的帧率到底是多少？
- 哪里在拖后腿？
- 瓶颈是CPU、GPU还是内存？
这三个问题，分别对应三种工具：FPS Meter、Profile工具、Trace事件。咱们一个一个来。
2.1 FPS Meter：最直观的“体检报告”
FPS Meter，说白了就是给仪表盘装个“心跳监测仪”。它能实时告诉你当前画面每秒刷新了多少次。
我常用的几种方式：
- Android自带的FPS Meter：在开发者选项里打开“GPU渲染模式分析”，选“在屏幕上显示为条形图”。你会看到一堆彩色柱子，绿色代表正常，红色代表超时。我在项目里见过红色柱子占满屏幕的情况——那基本就是卡成PPT了。
- Unity/Unreal引擎内置的Stats窗口：按一下快捷键，帧率、绘制调用数、三角面数全出来了。我建议你把这个窗口固定在屏幕角落，开发时一直开着。
- 自己写一个FPS计数器：有时候引擎自带的工具不够灵活，我就自己写一个。代码很简单，几行就行：
// 简易FPS计数器（C#示例）
float deltaTime = 0.0f;
void Update() {
deltaTime += (Time.deltaTime - deltaTime) * 0.1f;
float fps = 1.0f / deltaTime;
// 显示到UI上
Debug.Log("当前帧率: " + Mathf.Round(fps));
}
2.2 Profile工具：给代码“做CT扫描”
FPS Meter告诉你“你病了”，Profile工具告诉你“病在哪”。
我常用的Profile工具：
| 工具名称 | 适用平台 | 主要功能 |
|---|---|---|
| Unity Profiler | Unity项目 | CPU/GPU/内存/渲染耗时 |
| Android Studio Profiler | Android原生 | 线程、内存、网络、电量 |
| Xcode Instruments | iOS/macOS | CPU、GPU、Metal性能 |
| Perfetto | Android/Linux | 系统级Trace分析 |
我记得有一次，一个仪表盘项目帧率只有20帧。用FPS Meter看到问题后，我打开Unity Profiler，发现一个叫“UpdateGaugeData”的函数占了60%的CPU时间。点进去一看，好家伙，里面有个循环在逐像素更新指针位置——其实完全可以用Shader搞定。改完之后，帧率直接飙到55帧。
2.3 Trace事件：捕捉“瞬间卡顿”的元凶
有些卡顿是偶发性的，比如每10秒卡一次。这种问题，Profile工具抓不住，因为采样率不够。这时候就需要Trace事件了。
Trace事件，说白了就是在代码里埋“信标”。程序运行时，这些信标会记录下每个关键节点的开始和结束时间。我习惯在以下位置埋点：
- 帧开始/结束：看一帧的总耗时
- 渲染管线关键节点：比如“准备数据”、“提交DrawCall”、“GPU渲染完成”
- 数据更新点：比如“收到CAN数据”、“解析完成”、“UI刷新”
- 资源加载点：比如“纹理加载”、“模型实例化”
举个例子，在Android上用Perfetto抓Trace：
// 在关键代码段前后加Trace标记
Trace.beginSection("UpdateDashboardData");
// ... 你的数据更新逻辑 ...
Trace.endSection();
Trace.beginSection("RenderGauge");
// ... 你的渲染逻辑 ...
Trace.endSection();
抓完Trace后，用Perfetto打开，你会看到一条时间轴，上面标着每个标记的耗时。我曾经用这个方法抓到一个“每10秒卡顿200ms”的问题——原来是一个定时器触发了垃圾回收。嗯，GC这东西，真是嵌入式开发的噩梦。
2.4 三种工具的配合使用
这三种工具不是孤立的。我一般这样用：
- 先用FPS Meter看整体：确认帧率确实有问题，记录下波动范围。
- 再用Profile工具定位：找到最耗时的函数或模块。
- 最后用Trace事件深挖：针对可疑的代码段，埋点抓取详细时间线。
你想想看，如果一上来就埋一堆Trace，那就像在沙漠里撒网——捞到鱼的概率很低。先缩小范围，再精准打击，这才是老工程师的做法。
好了，这一章就到这里。记住一句话：没有数据，就没有优化。下一章我们聊聊怎么分析这些数据，找出真正的瓶颈。