3. 帧缓冲区优化：单缓冲与双缓冲机制、局部刷新策略、DMA2D硬件加速、压缩帧缓冲
帧缓冲区，说白了就是显存里那块专门用来存放一帧画面的内存区域。很多刚入行的朋友觉得它不就是一块内存嘛，能有多大？我见过一个项目，UI 只有几个按钮和进度条，结果帧缓冲开了 800×480×32bit，光这一项就吃掉 1.5MB——在资源紧张的 MCU 上，这简直是灾难。
所以这一章，咱们就聊聊怎么把这块「内存大户」给管好。我会从最基础的缓冲机制讲起，再到局部刷新、硬件加速，最后聊聊压缩帧缓冲。每个方法我都踩过坑，希望能帮你少走弯路。
3.1 单缓冲 vs 双缓冲：选对模式省一半
先看最基础的问题：到底用几个缓冲区？
| 特性 | 单缓冲 | 双缓冲 |
|---|---|---|
| 内存占用 | 1 个帧缓冲大小 | 2 个帧缓冲大小 |
| 画面撕裂 | 容易发生 | 可避免 |
| 实现复杂度 | 低 | 中 |
| 适用场景 | 静态界面、低刷新率 | 动画、视频、高刷新率 |
单缓冲模式下，CPU 直接往显存里画。画到一半的时候，如果 LCD 控制器开始扫描这一帧，就会出现上半截是新画面、下半截还是旧画面的撕裂现象。我早期做的一个温控器项目就吃过这个亏——用户旋转旋钮时，数字跳变伴随着明显的撕裂，客户直接退货。
双缓冲则是在后台准备一个「后备缓冲区」。所有绘制操作都在后台完成，等整帧画好了，再通过一个指针交换或者复制操作，一次性推到前台显示。这样 LCD 控制器永远只扫描完整的一帧。
关键结论：如果你的 UI 有动画或者频繁刷新，别犹豫，上双缓冲。虽然内存翻倍，但用户体验的提升是质的飞跃。如果只是静态显示或者刷新率很低（比如 1Hz 以下），单缓冲完全够用。
3.2 局部刷新策略：别整帧重绘，只改变动的区域
很多人的第一版实现是这样的：每次按键按下，就把整帧清掉重新画一遍。你想想看，一个 800×480 的屏幕，哪怕只改了一个像素的颜色，也要重绘 384000 个像素——这太浪费了。
局部刷新的核心思想很简单：只更新发生变化的矩形区域。
- 脏矩形追踪：每次绘制操作记录下影响的矩形范围（x, y, w, h）。
- 区域合并：如果有多个脏矩形相邻或重叠，合并成一个更大的矩形，减少刷新次数。
- 局部传输：只将脏矩形区域的数据刷新到 LCD 控制器。
举个例子，一个数字时钟界面，只有中间的秒数每秒变化。如果做整帧刷新，每次要传 1.5MB 数据；如果只刷新秒数所在的 40×20 像素区域，每次只传 3.2KB——差了将近 500 倍。
我的经验：脏矩形合并的阈值要调好。合并得太激进，刷新的区域变大，省不了多少；合并得太保守，刷新次数太多，CPU 开销反而增加。我一般把合并阈值设在 16 像素以内——两个脏矩形距离小于 16 像素就合并。
3.3 DMA2D 硬件加速：让硬件帮你搬数据
说到搬数据，很多 MCU 都集成了 DMA2D 控制器（比如 STM32 系列）。这东西说白了就是一个专门用来处理 2D 图形数据搬运的硬件模块。
DMA2D 能干这些事：
- 内存拷贝：从 A 地址搬到 B 地址，比 CPU 用 memcpy 快 3-5 倍。
- 颜色格式转换：比如 ARGB8888 转 RGB565，硬件直接搞定。
- Alpha 混合：前景和背景按透明度混合，CPU 算起来很慢，DMA2D 一眨眼就完事。
- 填充：整片区域填同一个颜色，比 for 循环快得多。
我记得有个项目，UI 上有个半透明的弹出菜单。用 CPU 做 Alpha 混合，每帧要花 15ms；换成 DMA2D 之后，降到 2ms 以内。帧率从 30fps 直接飙到 60fps。
注意：DMA2D 虽然快，但它会占用总线带宽。如果你的系统里还有别的 DMA 通道（比如 ADC、SPI），要注意优先级配置。我曾经遇到过 DMA2D 和音频 DMA 抢总线，导致音频出现爆音——调了优先级才解决。
3.4 压缩帧缓冲：RLE 与 LZ4
最后聊聊压缩。你可能觉得帧缓冲是实时显示的，压缩了怎么用？其实思路是这样的：在内存里存压缩后的帧数据，需要显示的时候再解压到显存。
3.4.1 RLE（游程编码）
RLE 的原理很简单：把连续相同的像素值压缩成「值 + 重复次数」。比如 100 个连续的红色像素，原本要占 100 个像素的存储空间，RLE 只需要存 2 个值。
适合场景：
- 大面积纯色背景的 UI
- 图标、字体位图（通常有大量空白区域）
- 文字渲染（黑白或少量颜色）
不适合场景：
- 照片、渐变色背景（相邻像素几乎都不相同）
- 复杂图形界面
我做过一个测试：一个典型的工业控制界面，背景是纯蓝色，上面有白色文字和几个彩色按钮。RLE 压缩后，帧缓冲从 1.5MB 降到了 280KB——压缩比超过 5:1。
3.4.2 LZ4
LZ4 是一种更通用的压缩算法，压缩率比 RLE 高，但解压速度也更快（号称是业界最快的压缩算法之一）。它的原理是基于字典匹配——找到重复的数据块，用引用代替。
LZ4 在嵌入式上的优势：
- 解压速度极快，通常能达到 400-500 MB/s
- 解压代码只有几百字节，适合 ROM 紧张的场景
- 压缩率适中，一般能到 2:1 到 4:1
我的建议：如果 UI 内容变化不大（比如大部分是静态元素），用 RLE 就够了，实现简单、解压快。如果 UI 内容复杂、变化频繁，LZ4 更合适——虽然压缩率不如 zlib，但解压速度是它的 10 倍以上，对实时性影响小。
3.5 综合策略：怎么选？
实际项目中，我一般会组合使用这些技术。下面这张图展示了我的典型决策流程：
嗯，这里要注意：压缩帧缓冲不是银弹。它节省了内存，但增加了解压的 CPU 开销。如果你的 CPU 本来就快跑满了，压缩反而会让系统变慢。我一般只在内存极度紧张（比如 RAM 小于 256KB）的时候才考虑压缩帧缓冲。
避坑指南：我曾经在一个项目里同时用了双缓冲 + 局部刷新 + DMA2D + LZ4 压缩，结果发现性能瓶颈不在帧缓冲，而在触摸响应。优化要抓主要矛盾，别一上来就堆技术。先分析瓶颈在哪，再对症下药。
总结一下这章的核心：帧缓冲区优化没有银弹，但组合使用单/双缓冲、局部刷新、DMA2D 和压缩技术，通常能把内存占用降低 50%-80%，同时保持流畅的用户体验。关键是要根据你的硬件资源和 UI 特点，找到最适合的平衡点。