2. 单缓冲的困境：闪烁原理、绘制过程阻塞、CPU空转、典型单缓冲Demo分析
好，咱们直接进入正题。上一章我聊了嵌入式GUI的整体架构，今天咱们来拆解一个最基础、也最让人头疼的问题——单缓冲。
说白了，单缓冲就是一块显存，CPU往里面画，LCD控制器从里面读。听起来简单，对吧？但实际跑起来，问题一堆。我当年刚做嵌入式界面时，就被这个“简单”的方案坑得不轻。
2.1 闪烁原理：你看到的不是画面，是“撕裂”
为什么会闪烁？你想想看，LCD刷新是连续的，每秒60帧甚至更高。而CPU画图是离散的，画完一行再画下一行。
假设屏幕正在刷新第200行，CPU却把第100行的内容改了。那这一帧画面就变成了：上半截是新内容，下半截是旧内容。等下一帧刷新时，CPU可能画完了，画面又完整了。但人眼会捕捉到这种“上下不一致”的瞬间——这就是闪烁。
核心矛盾： 显示器的连续扫描 vs CPU的离散绘制，在单缓冲下必然冲突。
我做过一个实验：在STM32F429上，用单缓冲刷一个320×240的界面，每帧绘制时间约12ms。LCD刷新周期约16ms（60Hz）。结果就是，大约每3帧就会出现一次明显的撕裂。用户反馈说“屏幕在抖”，其实就是这个原因。
2.2 绘制过程阻塞：CPU被“绑死”在画布上
单缓冲的第二个大坑，是绘制期间CPU不能干别的。
你调用 lcd_draw_pixel() 或 fill_rect() 时，CPU必须等数据写入显存完成后，才能返回。如果这时候有按键中断、传感器数据来了，对不起，先排队。
// 典型的单缓冲绘制流程（伪代码）
void gui_draw_frame() {
// 清屏：逐像素写入显存
for (int y = 0; y < SCREEN_H; y++) {
for (int x = 0; x < SCREEN_W; x++) {
lcd_write_pixel(x, y, BACKGROUND_COLOR);
}
}
// 绘制控件：又是逐像素操作
draw_button(10, 10, 100, 40, "OK");
draw_label(10, 60, "Hello World");
// 整个过程中，CPU 100% 占用，无法响应其他任务
}
你看，这个函数不执行完，系统就卡在这里。我见过一个产品，因为单缓冲绘制时间太长，导致触摸屏响应延迟超过200ms，用户点一下按钮要等半天才有反馈。体验极差。
注意： 单缓冲下，绘制时间 = 阻塞时间。如果你的绘制循环里有延时或等待，整个系统都会“冻住”。
2.3 CPU空转：看似在忙，实则低效
你可能觉得，CPU一直在画图，不算空转吧？
其实不然。单缓冲的绘制过程中，CPU大部分时间在等待——等待显存写入完成、等待LCD控制器释放总线、等待DMA传输结束。这些等待期间，CPU不能做有意义的事，只能轮询状态寄存器。
我测过一个典型场景：用SPI接口的LCD，时钟频率36MHz，写一个像素需要约1μs。320×240的屏幕，清屏一次就是76,800μs ≈ 77ms。这77ms里，CPU有超过60ms是在等待SPI发送完成。你说这不是空转是什么？
| 操作 | 时间消耗 | CPU有效利用率 |
|---|---|---|
| 清屏（320×240） | ~77ms | < 20% |
| 绘制一个按钮 | ~5ms | ~30% |
| 绘制一段文本（20字符） | ~3ms | ~25% |
| 整帧刷新 | ~100ms | < 15% |
看到没？CPU大部分时间在“假装忙碌”。我曾经在一个项目里，为了优化这个空转，把SPI中断优先级调到最高，结果又引发了中断嵌套的问题。嗯，这里要注意：单缓冲的瓶颈往往不在CPU算力，而在IO带宽。
2.4 典型单缓冲Demo分析
咱们来看一个具体的例子。假设你有一个温湿度计界面，需要每秒更新一次数据。
// 单缓冲温湿度计Demo
void task_display(void *arg) {
while (1) {
// 1. 读取传感器（假设耗时2ms）
float temp = read_temperature();
float humi = read_humidity();
// 2. 清屏（耗时77ms）
lcd_clear(WHITE);
// 3. 绘制标题（耗时10ms）
draw_text(10, 10, "温湿度计", FONT_24, BLACK);
// 4. 绘制温度值（耗时8ms）
char buf[16];
sprintf(buf, "温度: %.1f°C", temp);
draw_text(10, 50, buf, FONT_20, BLUE);
// 5. 绘制湿度值（耗时8ms）
sprintf(buf, "湿度: %.1f%%", humi);
draw_text(10, 90, buf, FONT_20, GREEN);
// 6. 等待剩余时间（目标周期1000ms）
vTaskDelay(pdMS_TO_TICKS(1000 - 105)); // 105ms已消耗
}
}
这个Demo有什么问题？我列一下：
- 闪烁严重： 每次更新都清屏重绘，用户会看到屏幕“闪一下”。
- 响应延迟： 绘制期间（约105ms），触摸和按键无响应。
- CPU浪费： 105ms里CPU有效工作不到20ms，其余都在等IO。
- 帧率不稳定： 如果传感器读取偶尔超时，整个周期会抖动。
我曾经在一个医疗设备上见过类似的实现。护士说“屏幕老是跳”，工程师查了两周才发现是单缓冲闪烁。后来改成双缓冲，问题立刻解决。这个教训让我记住了：单缓冲只适合静态画面，或者更新频率极低（比如几秒一次）的场景。
我的建议： 如果你现在用的是单缓冲，先别急着优化。把绘制时间、闪烁频率、CPU利用率都测一遍。数据会告诉你该不该换方案。
2.5 单缓冲的适用场景
说了这么多缺点，单缓冲是不是一无是处？也不是。在一些资源极度受限的场景下，它还是能用的：
- 显存极小： 比如只有几KB的MCU，双缓冲的额外开销承受不起。
- 画面几乎不变： 比如只显示一个静态Logo，或者数字时钟（每秒只改几个像素）。
- 刷新率要求低： 比如工业仪表，5秒更新一次，闪烁不明显。
- 成本敏感： 省掉一颗外部SRAM，BOM成本能降几毛钱。
但如果你要做动画、滑动、触摸交互，单缓冲基本是死路。我建议你直接跳到双缓冲，别在单缓冲上浪费时间。
2.6 本章小结：一张图看懂单缓冲困境
下面这张SVG图，把单缓冲的核心问题串起来了。你可以看到：CPU、显存、LCD控制器三者之间的冲突，以及最终如何导致闪烁和阻塞。
这张图把单缓冲的三个核心问题串起来了：CPU写入和LCD读取争抢同一块显存，导致闪烁；绘制过程串行阻塞，无法响应其他任务；CPU在等待IO时大量空转。这三个问题，就是双缓冲要解决的目标。