搞懂 LVGL 刷新机制：不是“重画”，而是“只画该画的”
你有没有遇到过这样的场景？
在 STM32F407 上跑一个带按钮和温度标签的界面，一切正常；
但一加上实时曲线图或滑动列表，屏幕就开始卡顿、闪烁、甚至偶尔花屏；
你调高了主循环频率、开了 DMA、换了更快的 SPI 时钟——还是没用；
最后发现，只要把lv_label_set_text()改成lv_label_set_text_fmt()就变流畅了……
这不是玄学。这是你第一次触碰到了 LVGL 的刷新机制内核——而绝大多数教程，把它藏在了“初始化之后、lv_timer_handler()之前”那几行被忽略的注释里。
真正卡住你的，从来不是 CPU 算力，也不是 SPI 速度，而是你对 LVGL如何决定“这一帧到底要重画哪一块像素”这件事，缺乏一次清醒的认知重建。
刷新，不是“重画整个界面”，而是“修复被改坏的那一小块”
很多开发者初学 LVGL，会下意识认为：“我改了一个按钮的状态，它变色了 → 所以 LVGL 把整个按钮重画了一遍”。
错。更准确地说：
LVGL 并不关心“按钮变了”，它只关心“屏幕上哪些像素已经和当前对象树状态不一致了”，然后找出这些像素构成的最小矩形区域集合，仅重绘它们。
这个过程，就叫无效区域计算（Invalidation）——它是 LVGL 实现轻量、高效、低内存占用 GUI 的第一道逻辑闸门。
它怎么知道哪块“坏了”？
当你调用：
lv_obj_add_state(btn, LV_STATE_PRESSED);LVGL 并不会立刻去画按钮按下效果。它只是悄悄在按钮对象上打了个标记：dirty = true。
接着，它还会顺手把这个标记“传染”给按钮的所有父容器（比如一个lv_obj_t *panel），因为父容器的裁剪区域、透明度、遮罩等都可能影响最终显示结果。
但注意：此时什么都没画，CPU 也没忙。
真正的计算，发生在下一帧刷新周期开始前——也就是lv_refr_task()被触发时。这时 LVGL 才会：
- 遍历整棵树，收集所有
dirty == true的对象； - 对每个对象，计算其在屏幕上的实际渲染边界（考虑缩放、旋转、clip corner、mask、opacity）；
- 将所有边界矩形与父容器的裁剪区域求交集；
- 合并所有重叠/相邻矩形，生成一组互不重叠、已裁剪的
lv_area_t链表（即_lv_inv_areas）； - 这些区域，就是接下来唯一会被光栅化的范围。
你可以把它想象成 Photoshop 里的“选区”：LVGL 不是重做整张图，而是先用魔棒精准框出需要重刷的几块区域，再对每一块单独执行“填充”或“描边”。
所以，“卡顿”的第一个真相是：
- 如果你在一个 for 循环里反复调用
lv_label_set_text()，LVGL 每次都会标记 label 为 dirty → 累积大量细碎无效区域 → 合并开销飙升 → 渲染前就卡
