3. LVGL双缓冲架构：刷新机制与Buffer配置

好，我们进入LVGL双缓冲的核心地带。说实话，LVGL的刷新机制和buffer配置，是我在项目里踩坑最多的地方。很多初学者觉得“不就是配个buffer嘛”，结果跑起来要么撕裂，要么卡顿，要么内存爆了。今天我把这块彻底讲透。

3.1 LVGL的刷新机制：从脏矩形到屏幕

LVGL的刷新，说白了就是“哪里变了刷哪里”。它不会像某些GUI框架那样全屏重绘，而是维护一个脏矩形（Dirty Area）列表。

流程是这样的：

1. 用户操作或定时器触发，某个控件状态改变
2. LVGL标记该控件所在的区域为“脏”
3. 在 lv_task_handler() 中，LVGL遍历脏矩形列表
4. 调用你注册的 flush_cb 回调，把这部分数据刷到屏幕

我刚开始做LVGL项目时，以为它每次都会刷全屏。后来用逻辑分析仪抓SPI波形才发现——原来只刷一小块。这个设计对低带宽的显示屏特别友好。

为什么会这样设计？你想想看，嵌入式设备的MCU资源有限，如果每次刷新都重绘整个屏幕，那CPU占用率会高得吓人。LVGL这种按需刷新的方式，能大幅降低CPU负载。

3.2 lv_disp_drv_t中的buffer配置

这是今天最核心的部分。LVGL的显示驱动结构体 lv_disp_drv_t 里，有几个关键成员专门管buffer：

成员	类型	说明
buffer	lv_disp_draw_buf_t *	指向绘制缓冲区的指针
flush_cb	函数指针	刷新回调，把buffer数据送到屏幕
rounder_cb	函数指针	坐标对齐回调（部分硬件需要）
set_px_cb	函数指针	逐像素设置回调（很少用）

其中 lv_disp_draw_buf_t 才是buffer配置的主战场。它的结构长这样：

typedef struct {
    void *buf1;           // 缓冲区1
    void *buf2;           // 缓冲区2（双缓冲时使用）
    void *buf_act;        // 当前活跃缓冲区（内部使用）
    uint32_t size;        // 缓冲区大小（像素数量）
    lv_area_t area;       // 当前刷新区（内部使用）
    uint32_t flushing:1;  // 正在刷新标志（内部使用）
} lv_disp_draw_buf_t;

我个人习惯在初始化时这样配置：

static lv_color_t buf1[MY_DISP_HOR_RES * 100];  // 部分缓冲，100行
static lv_color_t buf2[MY_DISP_HOR_RES * 100];  // 第二个缓冲区

lv_disp_draw_buf_t draw_buf;
lv_disp_draw_buf_init(&draw_buf, buf1, buf2, MY_DISP_HOR_RES * 100);

lv_disp_drv_t disp_drv;
lv_disp_drv_init(&disp_drv);
disp_drv.draw_buf = &draw_buf;
disp_drv.flush_cb = my_flush_callback;
lv_disp_drv_register(&disp_drv);

3.3 全屏缓冲 vs 部分缓冲

这是LVGL双缓冲架构里最需要做选择的地方。两种方案各有优劣，我分别说说。

3.3.1 全屏缓冲（Full Buffering）

全屏缓冲就是buffer大小等于整个屏幕的像素数。比如320x240的屏幕，buffer就是320*240个像素。

优点：

• 刷新效率最高，一次flush就能刷完整个脏矩形
• 没有“切分”开销，CPU占用率最低
• 动画效果最流畅

缺点：

• 内存占用巨大。320x240的16位色屏，需要320*240*2 = 150KB。如果是双缓冲，就是300KB
• 很多MCU根本扛不住这么大的RAM

我记得有一次给客户做产品，他们用的STM32F407只有192KB RAM。全屏双缓冲直接吃掉300KB，连系统都跑不起来。后来只能改成部分缓冲。

3.3.2 部分缓冲（Partial Buffering）

部分缓冲就是buffer只占屏幕的一部分，比如10行、20行。LVGL会分多次把脏矩形刷完。

优点：

• 内存占用小，适合资源受限的MCU
• 可以灵活调整buffer大小，平衡性能和内存

缺点：

• 刷新次数多，CPU占用率相对高
• 如果buffer太小，可能出现“刷不过来”的情况，导致画面撕裂

3.4 双缓冲的工作流程

我们来看一下LVGL双缓冲的完整流程。我画了一张图帮你理解：

流程其实不复杂：

1. 应用层修改控件后，LVGL标记脏矩形
2. 在 lv_task_handler() 中，LVGL检查是否有脏矩形需要刷新
3. 如果有，它把内容绘制到 buf1，同时通过 flush_cb 把 buf2 的数据刷到屏幕
4. 绘制完成后，交换两个buffer的角色
5. 等待 flush_cb 完成，然后继续下一轮

3.5 实际项目中的buffer选择策略

说了这么多理论，到底怎么选？我根据项目经验总结了一个决策表：

场景	推荐方案	理由
RAM > 2倍屏幕大小	全屏双缓冲	性能最好，动画流畅
RAM > 1倍屏幕大小	全屏单缓冲	省一半内存，但可能有轻微撕裂
RAM > 屏幕1/4	部分双缓冲（1/4屏）	平衡性能和内存
RAM < 屏幕1/10	部分单缓冲（10-20行）	内存优先，牺牲一点性能

嗯，这里要注意：全屏双缓冲虽然好，但不是所有MCU都吃得消。我做过一个项目，用的芯片只有64KB RAM，屏幕是480x272的16位色。全屏需要480*272*2 = 261KB，根本不可能。最后用了20行的部分双缓冲，效果也还行。

3.6 常见问题与避坑

最后分享几个我在项目中踩过的坑：

• buffer大小不是像素字节数：lv_disp_draw_buf_t 的 size 成员是像素数量，不是字节数。比如16位色，320个像素的size是320，不是640。我刚开始就搞混过，结果buffer只分配了一半大小，画面显示不全。
• flush_cb里要加完成标志：在 flush_cb 的最后一定要调用 lv_disp_flush_ready()，否则LVGL会一直等待，卡死在刷新循环里。
• DMA传输时注意缓存一致性：如果MCU有Cache，DMA传输前后要清理或无效化Cache，否则可能读到脏数据。