2、帧率分析与监控：用数据说话

帧率这东西，说白了就是你的UI到底「卡不卡」的量化指标。很多工程师做完界面，肉眼看看觉得「还行啊」，结果一上真机，掉帧掉得亲妈都不认识。我见过太多项目，前期全靠感觉调，最后 deadline 前疯狂补课。

这一章，我们就来聊聊怎么用 TouchGFX Designer 自带的工具，把帧率这个「感觉」变成「数字」。你只有先学会怎么看数据，才知道往哪个方向优化。

2.1 帧率监视器：你的第一把尺

TouchGFX Designer 里内置了一个非常实用的工具——帧率监视器（Frame Rate Monitor）。它不是一个外挂插件，而是集成在模拟器和真机调试中的功能。

怎么打开？很简单：

• 模拟器模式：在 Designer 的右下角，有一个小眼睛图标，点开它，选择「Show Frame Rate」。
• 真机调试：在代码中调用 Application::getInstance()->enableFrameRateMonitor(true)，然后通过串口或屏幕直接查看。

打开之后，你会看到屏幕左上角出现一个实时刷新的数字。这个数字就是当前的 FPS（Frames Per Second，每秒传输帧数）。

2.2 FPS 与刷新率：别搞混了

很多新手会把 FPS 和屏幕刷新率（Refresh Rate）混为一谈。我刚开始做嵌入式 UI 时也犯过这个错。

简单来说：

• 刷新率：是屏幕硬件的能力。比如 60Hz 的屏幕，每秒最多能刷新 60 次画面。这是天花板。
• FPS：是你的软件实际渲染出来的帧数。你渲染得再快，如果屏幕只有 60Hz，你看到的也就是 60 帧。

但反过来，如果你的 FPS 只有 30，而屏幕是 60Hz，那屏幕有一半的时间是在显示重复的画面。这就是卡顿感的来源。

所以，你优化的目标不是让 FPS 无限高，而是让它尽量接近屏幕的刷新率。对于 60Hz 的屏幕，稳定在 60 FPS 就是满分。

2.3 如何判断帧率是否达标？

光看数字还不够，你得知道「多少算好」。我一般用三个标准来判断：

1. 平均 FPS ≥ 刷新率的 95%：比如 60Hz 屏幕，平均 FPS 要 ≥ 57。低于这个数，用户就能感知到微卡。
2. 最低 FPS 不低于 30：偶尔掉到 40 多可以接受，但如果掉到 30 以下，那就是明显的「顿挫感」。尤其是在滑动列表或动画切换时，掉到 30 以下基本就废了。
3. 帧率波动幅度 ≤ 10%：FPS 从 60 掉到 55 再回到 60，人眼几乎无感。但如果从 60 直接掉到 40，再弹回 60，这种「锯齿状」波动最影响体验。

你想想看，如果你的 UI 在滑动时，FPS 从 60 掉到 35，然后又跳回 58。虽然平均可能还有 50 多，但用户的感觉就是「卡了一下」。所以，我建议你不仅要看平均值，还要看 帧率曲线。

TouchGFX 的帧率监视器其实可以输出历史数据。你可以在代码里把每一帧的时间戳打印出来，然后用 Excel 或者 Python 画个折线图。这样，哪里掉帧，一目了然。

2.4 实战：用 SVG 理解帧率分析流程

下面这张图，是我自己总结的帧率分析流程。每次拿到一个新 UI 界面，我都会按这个步骤走一遍。

这个流程的核心在于「对比」。你改了一行代码，FPS 从 52 涨到了 57，那这行代码就是有效的。如果没变化，甚至下降了，那就得回滚。

2.5 避坑指南：帧率监视器的几个陷阱

工具虽好，但用不对也会被误导。我总结几个常见的坑：

• 不要在 Debug 模式下测帧率：Debug 模式会插入大量断言和日志代码，FPS 会比 Release 模式低 10-20%。一定要在 Release 模式下测。
• 不要在模拟器上信以为真：PC 的 CPU/GPU 比嵌入式平台强太多。模拟器上跑 60 FPS，真机上可能只有 30。模拟器只能看功能，不能看性能。
• 注意温度降频：有些 MCU 跑久了会发热，然后自动降频。我遇到过在实验室测了 5 分钟一切正常，结果客户现场跑了半小时就开始掉帧。所以，建议做 压力测试：让 UI 持续运行 30 分钟以上，观察帧率是否稳定。