显存与帧缓冲：嵌入式图形系统的“双核引擎”
显存和帧缓冲，这两个词听起来有点硬件味儿。但说白了，它们就是嵌入式图形系统里最核心的“仓库”和“传送带”。
我刚开始做嵌入式UI时，总觉得只要把像素数据扔给屏幕就行了。结果呢？画面撕裂、闪烁、卡顿，一个都没少。后来我才明白——不理解显存和帧缓冲，就别谈性能优化。
显存工作原理：你的像素住哪儿？
显存，全称是“视频存储器”。在嵌入式系统里，它通常就是一块专用的RAM区域。CPU或GPU把要显示的像素数据写进去，显示控制器再把它读出来，送给屏幕。
这里有个关键点：显存是双端口访问的。什么意思？就是写入和读取可以同时进行。CPU往显存里写新画面，显示控制器同时从显存里读旧画面去刷新屏幕。这两件事互不干扰。
但有个坑——如果CPU写得太快，显示控制器读到了“半成品”画面，那就撕裂了。嗯，这就是我当年踩过的坑。
核心要点：显存带宽 = 像素时钟 × 位宽 / 8。比如一个800×480的屏幕，24位色深，60Hz刷新率，带宽需求大约是 800×480×24×60 / 8 ≈ 69 MB/s。如果你的显存带宽低于这个值，画面就会出问题。
帧缓冲结构：从像素到屏幕的“流水线”
帧缓冲，其实就是显存里的一块连续地址空间。每个地址对应屏幕上的一个像素点。显示控制器按行扫描，一行扫完换下一行，直到整屏刷新完毕。
我习惯把帧缓冲想象成一个二维数组：
// 假设屏幕分辨率是 800×480，颜色深度 16位
// 帧缓冲大小 = 800 × 480 × 2 = 768,000 字节
uint16_t framebuffer[480][800]; // 每行800个像素，共480行
// 设置 (x, y) 位置的像素为红色 (0xF800)
framebuffer[y][x] = 0xF800;你看，就是这么直接。但实际项目中，帧缓冲的结构比这复杂一点。它通常包含：
- 像素数据区：存放每个像素的颜色值
- 控制寄存器区：配置分辨率、颜色深度、刷新率等参数
- 调色板区：如果使用索引颜色模式，这里存颜色映射表
我曾经在一个项目里，因为帧缓冲起始地址没对齐到32字节，导致DMA传输效率直接腰斩。从那以后，我每次分配帧缓冲都会手动对齐。
我的习惯：帧缓冲地址尽量对齐到缓存行大小（通常是32或64字节）。这样CPU读写时，缓存命中率更高，性能能提升10%-20%。
颜色深度与像素格式：你的像素长什么样？
颜色深度，说白了就是一个像素用多少位来表示。常见的就这几种：
| 颜色深度 | 位数 | 颜色数 | 常见格式 | 典型场景 |
|---|---|---|---|---|
| 1位 | 1 | 2 | 黑白 | 电子墨水屏、低端LCD |
| 8位 | 8 | 256 | 索引色 | 老旧设备、低功耗显示 |
| 16位 | 16 | 65536 | RGB565 | 嵌入式UI主流 |
| 24位 | 24 | 1677万 | RGB888 | 高质量显示 |
| 32位 | 32 | 1677万+Alpha | ARGB8888 | 带透明效果的UI |
你想想看，为什么嵌入式系统里RGB565这么流行？因为它只用16位，就能显示65536种颜色。对于大多数UI来说，这已经足够了。而且它占用的显存只有RGB888的2/3，带宽需求也更低。
RGB565的像素格式长这样：
// RGB565 像素格式
// 高5位：红色 (R)
// 中间6位：绿色 (G)
// 低5位：蓝色 (B)
// 将 RGB888 转换为 RGB565
uint16_t rgb565 = ((r & 0xF8) << 8) | ((g & 0xFC) << 3) | (b >> 3);
// 从 RGB565 提取各分量
uint8_t r = (rgb565 >> 8) & 0xF8;
uint8_t g = (rgb565 >> 3) & 0xFC;
uint8_t b = (rgb565 << 3) & 0xF8;这里有个细节：绿色占6位，因为人眼对绿色最敏感。所以绿色能表示64级，红蓝各32级。这是硬件设计上的一个巧妙权衡。
注意：不同硬件平台对像素格式的字节序要求不同。有些是Little-Endian，有些是Big-Endian。我曾经在一个项目里，因为没注意字节序，显示出来的颜色全乱了。排查了整整两天才发现是这个问题。
帧缓冲与显存的关系：一张图说清楚
下面这张图，是我自己总结的显存与帧缓冲的协作流程。你看一遍就能明白：
你看，整个流程其实很清晰。CPU负责“画”，显示控制器负责“读”，显存就是中间的“缓冲区”。帧缓冲则是这个缓冲区里的“画布”。
颜色深度对性能的影响
颜色深度越高，每个像素占用的位数越多，显存带宽需求就越大。我做过一个对比测试：
| 颜色深度 | 每像素字节数 | 800×480 帧缓冲大小 | 60Hz 带宽需求 | CPU 写入耗时 (1MB数据) |
|---|---|---|---|---|
| RGB565 (16位) | 2 | 768 KB | 46 MB/s | ~12 ms |
| RGB888 (24位) | 3 | 1.125 MB | 69 MB/s | ~18 ms |
| ARGB8888 (32位) | 4 | 1.5 MB | 92 MB/s | ~24 ms |
看到没？从16位升到32位，带宽需求翻了一倍，CPU写入时间也翻了一倍。如果你的MCU主频不高，或者显存带宽有限，选RGB565往往是性价比最高的选择。
我的建议：在项目初期，先确定UI的颜色需求。如果不需要透明效果，就用RGB565。如果需要透明，可以考虑RGB565 + 1位Alpha，或者直接上ARGB4444（16位，4位Alpha）。别一上来就用ARGB8888，那是给自己找麻烦。
避坑指南：我踩过的那些坑
最后，分享几个我亲身经历过的坑，希望能帮你少走弯路：
- 帧缓冲地址未对齐：我曾经在一个STM32项目里，帧缓冲地址没对齐到32字节，结果DMA传输效率只有理论值的60%。后来手动对齐后，性能直接提升40%。
- 颜色深度不匹配：有一次，我用的LCD控制器只支持RGB565，但我的UI库默认输出ARGB8888。结果显示出来的颜色全偏了。排查了三天才发现是颜色深度不匹配。
- 显存带宽不足：在一个高分辨率项目里，我用了ARGB8888，结果屏幕刷新率死活上不去。后来换成RGB565，问题立刻解决。
- 字节序搞反：这个前面提过，但值得再说一次。不同平台的字节序可能不同，一定要先确认再编码。
嗯，这些坑我都踩过。希望你看完这一章，能少踩几个。