1. LVGL性能瓶颈分析：帧率、刷新率与那些拖慢界面的“真凶”
做嵌入式UI，最怕什么？
说白了，就是界面卡顿。你辛辛苦苦画好了控件，写好了逻辑，一上机，滑动掉帧，动画像PPT。我刚开始接触LVGL时也踩过这个坑，总觉得是芯片不够快，后来才发现，很多时候是我们自己把性能“浪费”掉了。
这一章，我们先不急着写代码。先把性能问题的“根”挖出来。搞清楚帧率、刷新率、CPU/GPU负载模型，以及那几个最常见的性能杀手。知己知彼，才能对症下药。
1.1 帧率(FPS)与刷新率：两个容易混淆的概念
先问个问题：你的屏幕每秒刷新60次，你的LVGL界面每秒也渲染60帧，它们是一回事吗？
不是。我见过不少工程师把这两个概念混为一谈，结果排查问题找错了方向。
- 刷新率 (Refresh Rate)：硬件参数。指屏幕每秒从显存读取并显示完整画面的次数。常见的有60Hz、90Hz、120Hz。这是显示器的“硬能力”。
- 帧率 (FPS, Frames Per Second)：软件指标。指你的应用程序（LVGL）每秒生成并提交完整画面的次数。这是软件的“产出速度”。
它们之间的关系，用一个比喻就清楚了：
刷新率是“高速公路的限速”，帧率是“你实际开车的速度”。你开60码，路也限速60码，完美。你只开30码，路再宽也没用。你开到90码，但路限速60，那多出来的30帧就会被丢弃（屏幕撕裂或等待）。
核心结论：LVGL优化的目标，是让帧率尽量接近并稳定在刷新率附近。对于60Hz屏幕，稳定在55-60FPS就是优秀；对于30Hz屏幕，稳定在28-30FPS即可。盲目追求120FPS在60Hz屏幕上毫无意义。
| 概念 | 归属 | 单位 | 典型值 | 谁决定 |
|---|---|---|---|---|
| 刷新率 | 硬件 | Hz | 60, 90, 120 | 屏幕驱动IC + 面板 |
| 帧率 (FPS) | 软件 | fps | 30, 45, 60 | CPU/GPU负载 + LVGL渲染效率 |
个人经验：我在调试一个STM32F429的项目时，屏幕是60Hz，但LVGL的FPS只有25左右。我一开始以为是屏幕驱动慢了，折腾了半天。后来用LVGL内置的帧率监控工具一看，发现是某个自定义控件的绘制函数里有个大循环，每次重绘都卡了十几毫秒。改掉之后，FPS直接跳到55。所以，先看软件帧率，别急着怀疑硬件。
1.2 CPU/GPU负载模型：你的芯片到底在忙什么？
LVGL的渲染过程，本质上是一个“生产-消费”模型。
- CPU：负责“生产”。处理触摸事件、运行动画逻辑、解析样式、构建绘制命令列表（display buffer）。
- GPU（或MCU的2D加速单元）：负责“消费”。根据CPU下发的绘制命令，把像素填充到显存（framebuffer）里。
大多数嵌入式平台没有独立的GPU，所谓的“GPU”其实就是CPU的Cortex-M内核加上一些硬件加速外设（如DMA2D、PXP）。这时候，CPU既要当爹（生产命令），又要当妈（执行绘制），负载很容易爆表。
我习惯把负载模型分成三种情况：
- CPU瓶颈：CPU忙于计算布局、解析样式、处理事件，导致绘制命令下发不及时。表现是FPS低，但CPU占用率100%。
- GPU/渲染瓶颈：CPU命令下得很快，但GPU（或DMA2D）来不及画。表现是FPS低，但CPU占用率只有30-40%，大部分时间在等渲染完成。
- 混合瓶颈：两者都忙，谁也救不了谁。这是最棘手的情况。
避坑指南：我曾经在一个项目里，为了追求炫酷的阴影效果，给每个按钮都加了lv_style_set_shadow_opa()。结果界面一打开，CPU占用率直接飙到90%，FPS掉到15。后来用LVGL的profiler一看，发现阴影的模糊计算占用了大量CPU时间。去掉阴影后，FPS恢复到55。所以，特效虽好，可不要贪杯。
下面这张图，能帮你快速定位瓶颈类型：
1.3 三大常见性能杀手
知道了瓶颈在哪，我们来看看具体是什么在“吃”性能。我总结了三个最常见的“凶手”。
1.3.1 过度绘制 (Overdraw)
这是最隐蔽的杀手。简单说，就是同一个像素点，在一帧内被重复绘制了多次。
举个例子：你有一个全屏的背景色，然后在上面放了一个半透明的按钮，按钮上又有一个图标。这个图标区域的像素，至少被绘制了三次：背景色 → 按钮背景色（半透明混合） → 图标。如果按钮背景完全不透明，那背景色就白画了。
如何发现：LVGL没有直接的overdraw可视化工具，但你可以通过减少lv_obj_set_style_bg_opa()为0的对象的数量来间接判断。或者，在关键绘制函数里加个计数器，统计lv_draw_rect/lv_draw_img的调用次数。
1.3.2 无效刷新 (Invalid Refresh)
LVGL是“脏矩形”刷新机制。只有标记为“无效”（invalid）的区域才会被重绘。但如果你不小心，很容易触发全屏刷新。
我见过最典型的场景：在lv_timer中每10ms调用一次lv_obj_invalidate(screen)，结果整个屏幕每10ms就重绘一次。哪怕画面根本没变。这等于把LVGL的增量渲染优势全扔了。
个人习惯：我写代码时，会尽量使用lv_obj_invalidate_by_area()来指定具体的脏矩形区域，而不是直接invalidate整个对象。尤其是在列表滚动或滑块拖动时，只刷新变化的那一小块，性能提升非常明显。
1.3.3 内存碎片 (Memory Fragmentation)
嵌入式系统的RAM是稀缺资源。LVGL的动态内存分配（malloc/free）如果频繁进行，很容易产生内存碎片。碎片多了，即使总空闲内存足够，也可能分配不出一个连续的大块内存给显示缓冲区或图片解码。
后果是什么？要么LVGL报错“lv_mem_alloc failed”，要么界面突然卡死，因为分配显示缓冲区失败了。
| 杀手名称 | 典型表现 | 排查方法 | 初步对策 |
|---|---|---|---|
| 过度绘制 | FPS低，CPU高，但界面元素简单 | 检查对象树，统计绘制命令数 | 减少透明层、合并背景绘制 |
| 无效刷新 | FPS波动大，静止画面也高负载 | 检查lv_timer中的invalidate调用 | 使用区域刷新，避免全屏刷新 |
| 内存碎片 | 运行一段时间后卡死或分配失败 | 调用lv_mem_monitor()查看碎片率 | 使用静态分配、内存池、定期整理 |
我曾经踩过的坑：在一个需要长时间运行的设备上，LVGL跑了三天后突然黑屏。查了三天日志，最后发现是内存碎片导致显示缓冲区分配失败。从那以后，我所有项目都会在初始化时预分配好显示缓冲区（使用静态数组），并且尽量复用对象，而不是频繁创建和删除。内存碎片这东西，平时看不见，一旦爆发就是致命伤。