图解说明LVGL中disp_drv.flush_cb的渲染触发机制

深入理解LVGL的flush_cb：从一帧绘制到屏幕刷新的完整旅程

你有没有遇到过这样的情况：UI明明已经更新了，但屏幕就是“卡”在那里不动？或者动画滑动时出现撕裂、闪烁，像老电视信号不良一样？

如果你正在用LVGL开发嵌入式图形界面，十有八九，问题就出在disp_drv.flush_cb这个看似简单的回调函数上。

别被它短短几行代码迷惑——这个函数其实是整个LVGL渲染流水线中最关键的一环。它不是普通的函数，而是连接软件世界与硬件屏幕之间的“最后一公里”。搞不懂它，轻则界面卡顿，重则系统冻结；搞懂了它，你就能让UI丝滑流畅，CPU还能腾出手干别的事。

今天我们就来彻底拆解flush_cb的触发机制，带你一步步看清：从一个按钮被点击，到像素真正点亮屏幕，中间到底发生了什么。

为什么flush_cb如此重要？

在开始之前，先问自己一个问题：LVGL是怎么知道什么时候该把画面“刷”到屏幕上的？

答案是：它不知道。

LVGL本身并不直接控制屏幕。它只负责“画”——在内存里合成好要显示的内容。至于这些内容何时、如何传给物理显示屏，全靠开发者注册的一个函数：flush_cb。

你可以把它想象成一个“快递员”：

• LVGL是仓库管理员，负责打包好货物（像素数据）；
• flush_cb是快递员，负责把包裹送到客户（屏幕）手中；
• 而lv_disp_flush_ready()就是你签收快递时说的那句“收到了”。

如果快递员送完货却不告诉你他完成了，仓库就会一直以为包裹还在路上，不敢发下一单——于是所有后续更新都被阻塞，界面就“卡住”了。

这就是为什么很多初学者移植LVGL时，界面能亮，但点按钮没反应——因为他们忘了在DMA传输结束后调用lv_disp_flush_ready()。

flush_cb是怎么被触发的？一张图讲清楚

我们先来看一个真实场景下的完整流程：

用户触摸屏幕 ↓ LVGL检测到事件 → 按钮状态改变 ↓ LVGL标记按钮所在区域为“脏区”（invalid area） ↓ 主循环调用 lv_timer_handler() ↓ LVGL发现有脏区 → 启动渲染器进行绘制 ↓ 将新图像写入缓冲区（可能是部分重绘） ↓ 绘制完成 → 自动调用 disp_drv.flush_cb(area, color_p) ↓ 你的 flush_cb 函数启动SPI/DMA发送数据 ↓ 等待传输完成（通过中断或轮询） ↓ 在传输完成中断中调用 lv_disp_flush_ready(disp_drv) ↓ LVGL释放缓冲区 → 继续处理下一帧或进入空闲状态

注意关键点：

• flush_cb不是定时调用的，它是事件驱动的——只有当有内容需要刷新时才会触发。
• 它也不是每“帧”调一次，而是可能在一帧内多次调用（比如多个不连续的小区域更新）。
• 最致命的是：如果你不调用lv_disp_flush_ready()，LVGL会认为屏幕一直在忙，不会再发起任何新的刷新请求。

所以，界面“卡住”的本质，往往是flush_cb发出了，但“完成信号”没回来。

实战代码解析：同步 vs 异步刷新

场景一：小尺寸OLED屏（SSD1306），I2C接口

这类屏幕分辨率低（128×64）、数据量小（1KB显存），可以直接由CPU通过I2C写入，适合同步刷新。

static void oled_flush(lv_disp_drv_t * disp_drv, const lv_area_t * area, lv_color_t * color_p) { uint8_t * buffer = (uint8_t *)color_p; int width_bytes = (area->x2 - area->x1 + 1 + 7) / 8; for (int y = area->y1; y <= area->y2; y++) { ssd1306_set_cursor(area->x1, y); ssd1306_write_buffer(&buffer[(y - area->y1) * width_bytes], width_bytes); } // ✅ 立即通知LVGL：我已经刷完了 lv_disp_flush_ready(disp_drv); }

✅ 特点：
- 函数返回前已完成所有数据传输；
- 可以安全地立即调用lv_disp_flush_ready()；
- CPU会被短暂阻塞，但影响不大。

场景二：大尺寸TFT屏（ILI9341），SPI+DMA

这是最常见的坑点。屏幕大（240×320）、颜色深（RGB565，每像素2字节），一帧数据高达150KB。如果让CPU一个个字节发，那CPU就别干别的了。

正确的做法是：启动DMA传输，然后立刻返回，等中断来了再说。

static void lcd_flush(lv_disp_drv_t * disp_drv, const lv_area_t * area, lv_color_t * color_p) { uint32_t width = area->x2 - area->x1 + 1; uint32_t height = area->y2 - area->y1 + 1; uint32_t size = width * height; lcd_set_window(area->x1, area->y1, area->x2, area->y2); // 设置GRAM地址范围 // 🔁 启动DMA传输，函数立即返回 HAL_SPI_Transmit_DMA(&hspi3, (uint8_t *)color_p, size * 2); // ❌ 千万不要在这里调用 lv_disp_flush_ready()！ }

然后在SPI传输完成中断中通知LVGL：

void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef * hspi) { if (hspi == &hspi3) { // ✅ 此时DMA已结束，数据已送达屏幕 lv_disp_flush_ready(&disp_drv); } }

⚠️ 常见错误写法（会导致界面卡死）：

// 错误示范：在 flush_cb 中轮询等待 HAL_SPI_Transmit(&hspi3, data, len, HAL_MAX_DELAY); // 阻塞CPU lv_disp_flush_ready(disp_drv); // 虽然调用了，但CPU已被占用

这种写法虽然最终也会调用lv_disp_flush_ready()，但由于使用了阻塞式SPI传输，CPU在整个刷新期间无法执行其他任务，包括响应触摸、运行定时器等，用户体验极差。

刷新模式怎么选？一张表帮你决策

💡 小知识：LVGL支持“多段刷新”（multi-pass flushing）。如果你的缓冲区小于最大刷新区域，LVGL会自动将大区域拆成多个小块，逐次调用flush_cb。

常见问题与调试秘籍

问题1：屏幕卡住，UI不更新

🔍 检查清单：
- 是否在DMA/I2C传输完成后调用了lv_disp_flush_ready()？
- 是否在错误的地方调用了它（比如还没发完就通知）？
- 中断是否被正确触发？可以用GPIO打一个脉冲验证。

🔧 调试技巧：

// 在 flush_cb 开始和中断结束处翻转GPIO HAL_GPIO_WritePin(DEBUG_GPIO, PIN_FLUSH_START, GPIO_PIN_SET); // ... 发送数据 HAL_GPIO_WritePin(DEBUG_GPIO, PIN_FLUSH_START, GPIO_PIN_RESET); // 在 lv_disp_flush_ready() 前 HAL_GPIO_WritePin(DEBUG_GPIO, PIN_FLUSH_DONE, GPIO_PIN_SET); lv_disp_flush_ready(disp_drv); HAL_GPIO_WritePin(DEBUG_GPIO, PIN_FLUSH_DONE, GPIO_PIN_RESET);

用示波器看这两个信号的时间差，就能判断传输是否真完成了。

问题2：画面撕裂（tearing）

撕裂的本质是：屏幕正在扫描显示旧画面时，你把新画面的数据刷上去了。

解决方案：
-启用双缓冲：一个用于显示，一个用于绘制，交换时原子切换；
-使用VSYNC同步：等待屏幕垂直回扫间隙再刷新（类似PC的垂直同步）；
-限制刷新率：避免刷新频率远高于屏幕扫描频率。

LVGL原生支持VSYNC-like机制（disp_drv.rounder_cb和hor_res/ver_res配合），可在刷新前做延迟对齐。

问题3：刷新太慢，动画卡顿

性能瓶颈通常出现在：
- SPI时钟太低（建议≥20MHz）；
- 使用轮询而非DMA；
- 缓冲区太小导致频繁调用flush_cb；
- 屏幕命令开销大（如每次刷新都发“设置窗口”指令）。

优化建议：
- 提高SPI频率；
- 使用四线SPI或QSPI；
- 缓存GRAM地址窗口，避免重复设置；
- 合理分配缓冲区大小（推荐至少1/10屏幕面积）。

高阶技巧：如何设计高效的刷新策略？

技巧1：智能缓冲区分配

不要盲目申请全屏缓冲。例如：

// 对于 320x240 RGB565 屏幕 // 全屏缓冲 = 320*240*2 = 153,600 字节 ≈ 150KB —— 太贵！ // 更优方案：两个 320x50 的缓冲区 // 总内存 = 2 * 320*50*2 = 64,000 字节 ≈ 64KB

LVGL会优先使用大缓冲区进行整块刷新，不够时自动降级为多段刷新，平衡性能与内存。

技巧2：合并小区域刷新

LVGL默认会对多个小“脏区”进行合并，减少flush_cb调用次数。你可以通过以下方式优化：

// 在 lv_conf.h 中调整 #define LV_DISP_DEF_REFR_PERIOD 33 // 默认33ms（约30fps） #define LV_MEM_SIZE (32U * 1024U) // 确保有足够内存处理合并

刷新周期越长，越容易合并多个更新，减少总刷新次数。

技巧3：利用monitor_cb监控刷新性能

LVGL提供了一个隐藏功能：刷新监控回调。

static void monitor_cb(lv_disp_drv_t * disp, uint32_t time, uint32_t px) { printf("Refresh: %d ms, %d pixels\n", time, px); } // 注册到驱动 disp_drv.monitor_cb = monitor_cb;

它可以告诉你每次刷新花了多久、刷了多少像素，是性能调优的利器。

写在最后：掌握flush_cb，才算真正入门LVGL

很多人觉得LVGL移植就是“配一下驱动，跑个例程”，但实际上，能否写出高效稳定的flush_cb，是区分普通开发者和嵌入式GUI高手的关键分水岭。

它不仅仅是一个函数，更是一种思维方式：

• 你是否理解异步编程模型？
• 你是否懂得软硬件协同设计？
• 你是否能在内存、速度、稳定性之间做出合理权衡？

下次当你面对一块新屏幕时，不要再急着跑demo。先问问自己：

“我的数据怎么传？”
“什么时候算真正完成？”
“CPU能不能在这期间去干点别的？”

想清楚这三个问题，你的flush_cb就不会错。

这才是嵌入式图形开发的真功夫。

如果你在实现过程中遇到了其他挑战，欢迎在评论区分享讨论。