4. 缓冲区与显存优化：双缓冲 vs 单缓冲、行缓冲技术、显存压缩、局部刷新策略
说到嵌入式GUI的内存占用，缓冲区这块儿绝对是重头戏。我见过太多项目，前期功能跑得欢，一到内存紧张就抓瞎。说白了，显存怎么分配、怎么刷新，直接决定了你的系统能不能稳定跑起来。
这一章咱们就聊聊缓冲区那些事儿。我会结合自己踩过的坑，把双缓冲、单缓冲、行缓冲、显存压缩和局部刷新这些技术掰开揉碎了讲。
4.1 双缓冲 vs 单缓冲：选哪个？
先问个问题：你的屏幕在刷新时，有没有出现过撕裂感？或者画面闪烁？如果有，大概率是缓冲区策略没选对。
单缓冲，就是只有一个显存区。CPU往里面写数据，LCD控制器同时从里面读数据往外刷。你想想看，这俩同时操作一个地方，不出问题才怪。我早期做一个温控器项目，用的就是单缓冲，结果数字跳动时屏幕下半部分老是出现残影。后来查了半天，发现是读写冲突。
双缓冲就不一样了。它有两个显存区：一个叫后缓冲（Back Buffer），CPU只管往里画；另一个叫前缓冲（Front Buffer），LCD控制器只管往外刷。画完了，交换一下指针，瞬间切换。用户看到的永远是完整的画面。
| 对比项 | 单缓冲 | 双缓冲 |
|---|---|---|
| 内存占用 | 1 × 显存大小 | 2 × 显存大小 |
| 画面撕裂 | 容易发生 | 不会发生 |
| 实现复杂度 | 低 | 中 |
| 适用场景 | 静态界面、低刷新率 | 动画、视频、高刷新率 |
核心结论：如果你的MCU内存小于显存大小的2倍，老老实实用单缓冲+局部刷新。否则，双缓冲是更稳妥的选择。
4.2 行缓冲技术：内存不够时的救命稻草
双缓冲好是好，但内存翻倍不是谁都能接受的。尤其是那些只有几十KB RAM的MCU，连一个完整的显存放进去都够呛，更别说两个了。
这时候，行缓冲就派上用场了。
行缓冲的思路很简单：我不一次性把整屏数据都准备好，而是只准备一行。LCD扫到哪一行，我就临时渲染哪一行。说白了，就是用时间换空间。
我记得做一个128×64的单色屏项目时，显存只需要1KB。但客户非要加动画效果，单缓冲撕裂严重，双缓冲又需要2KB，而那块MCU总共才4KB RAM。最后我用了行缓冲：每次只渲染一行像素，跟着LCD的行同步信号走。动画虽然慢了点，但内存稳稳地控制在1.2KB以内。
我的经验：行缓冲特别适合单色屏和低分辨率彩屏。如果分辨率超过320×240，行缓冲的渲染压力会很大，CPU可能跟不上LCD的刷新速度。
4.3 显存压缩：RLE 与 LZ4
显存压缩，说白了就是让数据变小再存进去。常见的两种压缩算法：RLE（游程编码）和LZ4。
4.3.1 RLE：简单粗暴，适合色块多的界面
RLE的原理特别简单：把连续相同的像素值压缩成「重复次数 + 像素值」。比如 0x00 0x00 0x00 0x00 0xFF 0xFF 压缩成 0x04 0x00 0x02 0xFF。
我做过一个工业仪表盘，背景是纯黑色，只有几个数字和指针是彩色的。这种界面用RLE压缩，压缩率能到80%以上。但要注意，如果画面内容很杂乱（比如照片），RLE反而会让数据变大。
// RLE 编码示例（伪代码）
void rle_encode(uint8_t *input, int len, uint8_t *output) {
int i = 0, o = 0;
while (i < len) {
uint8_t pixel = input[i];
int count = 1;
while (i + count < len && input[i + count] == pixel && count < 255) {
count++;
}
output[o++] = count;
output[o++] = pixel;
i += count;
}
}
4.3.2 LZ4：压缩率高，但需要更多CPU
LZ4比RLE复杂得多。它不光压缩连续重复的数据，还能利用字典匹配找到重复的片段。压缩率通常比RLE高，但解压时需要更多的计算。
我曾经在一个项目里对比过：同样是320×240的16位色界面，RLE压缩后是45KB，LZ4压缩后只有28KB。但LZ4解压一次需要约2ms，而RLE只需要0.5ms。如果你的CPU主频不高，LZ4可能会拖慢刷新速度。
| 算法 | 压缩率（典型） | 解压速度 | 内存开销 | 适用场景 |
|---|---|---|---|---|
| RLE | 20% ~ 80% | 极快 | 极低 | 色块多、图标、文字 |
| LZ4 | 40% ~ 90% | 快 | 低 | 复杂界面、照片 |
注意：显存压缩不是万能的。解压需要额外的CPU时间和临时缓冲区。如果CPU已经跑满了，压缩反而会让系统变慢。我曾经在一个项目里盲目上LZ4，结果帧率从30fps掉到了12fps，后来换回RLE才解决问题。
4.4 局部刷新策略：只画需要变化的部分
这个策略听起来简单，但做起来门道很多。局部刷新的核心思想是：不要刷新整个屏幕，只刷新变化区域。
我见过很多新手，每次更新数据就把整屏重绘一遍。你想想看，一个320×240的16位色屏，整屏刷新要写153600字节的数据。如果只是更新一个数字，这得多浪费？
局部刷新的关键步骤：
- 脏区域标记：记录哪些区域发生了变化。
- 区域合并：把相邻的脏区域合并成更大的矩形，减少刷新次数。
- 裁剪渲染：只渲染脏区域内的内容。
- DMA传输：用DMA把脏区域的数据送到显存。
我做一个智能家居面板时，用了一个简单的脏矩形列表。每次按键只更新按键周围的20×20像素区域，整屏刷新次数从每秒60次降到了不到10次。CPU占用率直接降了40%。
我的建议：局部刷新配合行缓冲效果更好。先标记脏区域，然后只刷新脏区域对应的行。这样既省显存，又省CPU。
4.5 知识体系总览
下面这张图把本章的核心逻辑串起来了。你可以看到，不同的内存预算和性能要求，对应着不同的技术选型。
4.6 避坑指南
最后，分享几个我亲身踩过的坑：
- 别盲目上双缓冲。我曾经在一个只有16KB RAM的项目里硬上双缓冲，结果系统直接起不来。后来改成行缓冲+局部刷新，才把问题解决。
- RLE别用在照片上。有一次我把一张渐变色背景图用RLE压缩，结果压缩后的数据比原图还大。后来改用LZ4才正常。
- 局部刷新别忘了合并脏区域。如果不合并，频繁的小区域刷新会导致LCD控制器频繁切换地址，反而降低效率。
- 行缓冲要跟LCD时序配合好。如果CPU来不及渲染下一行，屏幕会出现水平条纹。我一般会预留一行缓冲的时间余量。
嗯，这一章的内容就到这里。缓冲区优化是个细活，需要根据你的硬件资源和应用场景灵活选择。记住一句话：没有最好的方案，只有最合适的方案。