4. 性能调优与基准测试：帧率计算、内存带宽优化、使用LVGL的monitor工具
双缓冲驱动起来之后，画面是流畅了，但你真的知道它跑多快吗？我见过不少项目，驱动写完了就扔那不管，结果产品上市后用户反馈卡顿。说白了，没有量化就没有优化。这一章我们就来聊聊怎么给LVGL做体检——测帧率、算带宽、用官方工具抓性能瓶颈。
4.1 帧率计算：别靠感觉，看数字
帧率是UI流畅度的硬指标。LVGL里有个内置的帧率计数器，打开它只需要一行配置。
/* 在lv_conf.h中开启 */
#define LV_USE_PERF_MONITOR 1开启后，屏幕右上角会显示两个数字：FPS（帧率）和CPU使用率。我个人习惯在开发阶段一直开着它，就像开车看仪表盘一样自然。
但要注意，这个FPS是LVGL的渲染帧率，不是屏幕的刷新率。我曾经在一个项目里发现FPS显示60，但画面依然撕裂——后来才意识到是屏幕刷新率和双缓冲没对齐。
4.2 内存带宽优化：双缓冲的隐形杀手
双缓冲的本质是用内存换时间。但内存带宽是有限的，尤其是低端MCU。你想想看，每帧都要把整张画布从RAM刷到显存，如果带宽不够，帧率直接腰斩。
带宽的计算公式很简单：
带宽需求 = 分辨率 × 色彩深度 × 帧率
举例：480×272分辨率，RGB565（16位），60FPS
带宽 = 480 × 272 × 2 × 60 = 15.68 MB/s这个数字对很多MCU来说已经不小了。我遇到过最极端的情况——一个客户用SPI接口的屏幕，理论带宽只有10MB/s，结果双缓冲跑起来反而比单缓冲还慢。为什么？因为SPI的DMA传输占用了太多总线时间，CPU反而被饿死了。
4.2.1 优化策略
- 降低色彩深度： RGB565换成RGB332，带宽减半。代价是颜色精度下降，但很多工业界面够用了。
- 局部刷新： 不是每帧都需要刷全屏。LVGL的脏矩形机制会自动计算变化区域，但前提是你的驱动支持局部刷新。
- DMA双缓冲： 用DMA在后台搬运数据，CPU只管渲染。我习惯把两个buffer放在不同的内存区域（比如内部SRAM和外部PSRAM），让DMA可以并行操作。
4.3 使用LVGL的monitor工具
LVGL自带一个性能监控工具——lv_monitor。它比简单的FPS计数器详细得多，能告诉你每一帧的渲染时间、CPU占用、内存使用情况。
4.3.1 开启monitor
/* 在lv_conf.h中 */
#define LV_USE_MONITOR 1
/* 在代码中启动 */
lv_monitor_init();启动后，它会输出类似这样的日志：
[Monitor] Frame: 1234 | Render time: 12ms | CPU: 45% | Mem: 24KB
[Monitor] Frame: 1235 | Render time: 8ms | CPU: 30% | Mem: 24KB
[Monitor] Frame: 1236 | Render time: 15ms | CPU: 55% | Mem: 24KB看到没？渲染时间波动很大。我一般会盯着这个日志跑几分钟，找出最坏情况下的渲染时间。如果最坏情况超过16ms（60FPS的帧周期），那就得优化了。
4.3.2 分析瓶颈
monitor工具还能细分渲染阶段：
| 阶段 | 说明 | 优化方向 |
|---|---|---|
| draw_prepare | 准备渲染数据 | 减少对象数量，合并样式 |
| draw_rect | 绘制矩形/背景 | 使用简单圆角，避免复杂阴影 |
| draw_img | 绘制图片 | 使用压缩格式，缩小图片尺寸 |
| draw_text | 绘制文字 | 使用字体缓存，减少字体切换 |
| flush | 刷到屏幕 | 优化DMA传输，减少等待 |
我记得有一次，monitor显示flush阶段占了总时间的60%。一查发现是屏幕的TE（Tearing Effect）信号没用好，导致每次刷屏都在等VSync。加上TE中断后，flush时间从20ms降到了5ms。
4.4 性能调优实战流程
嗯，这里我总结一个标准流程，你照着做就行：
- 开monitor跑基准： 先跑一个典型场景，记录FPS、渲染时间、CPU占用。
- 定位瓶颈： 看哪个阶段耗时最长。如果是
flush，优化驱动；如果是draw_img，优化图片。 - 做一次改动： 每次只改一个参数，比如把图片从ARGB8888改成RGB565。
- 重新跑基准： 对比改动前后的数据。如果FPS没提升，说明改的不是瓶颈。
- 重复直到达标： 直到FPS稳定在目标值以上。
4.5 知识体系图
下面这张图总结了本章的核心逻辑：从帧率计算到带宽优化，再到monitor工具的使用，形成一个闭环。
4.6 总结
性能调优不是一锤子买卖。你每次加一个新功能、换一张大图、改一个动画参数，都应该跑一遍monitor看看有没有退化。我自己的习惯是：每次提交代码前，先跑一遍基准测试，把FPS和渲染时间记录在commit message里。这样出了问题，git bisect一查就知道是哪次改动引入的。
双缓冲只是给了你一个优化的基础，真正让UI飞起来的，是这些细致的调优工作。记住：没有数据就没有发言权。