3. 色彩深度与像素格式：RGB565、RGB888、ARGB8888 详解

做嵌入式 GUI 开发，色彩深度和像素格式是绕不开的基础问题。说白了，就是「一个像素点用多少 bit 来表示」。这个数字直接决定了你的图片占多大内存、刷屏有多快、画面好不好看。

我刚开始做嵌入式 GUI 时，总觉得色彩深度越高越好。直到有一次在 STM32F429 上跑 800×480 的界面，用 ARGB8888 格式，结果内存直接爆了。嗯，从那以后我再也不敢盲目选高色深了。

3.1 三种主流像素格式

嵌入式领域最常见的就这三种：RGB565、RGB888、ARGB8888。它们的区别在于每个像素占多少 bit，以及颜色分量怎么排列。

格式	每像素位数	颜色分量	总颜色数	典型场景
RGB565	16 bit	R:5 / G:6 / B:5	65,536	低端 MCU、小屏、低成本
RGB888	24 bit	R:8 / G:8 / B:8	16,777,216	中高端 MCU、真彩色需求
ARGB8888	32 bit	A:8 / R:8 / G:8 / B:8	16,777,216 + 256 级透明度	需要透明/半透明效果

3.2 色彩深度对内存的影响

这个很好算。一张图片占用的内存 = 宽度 × 高度 × 每像素字节数。

举个例子，一块 480×272 的屏幕：

• RGB565：480 × 272 × 2 = 261,120 字节 ≈ 255 KB
• RGB888：480 × 272 × 3 = 391,680 字节 ≈ 382 KB
• ARGB8888：480 × 272 × 4 = 522,240 字节 ≈ 510 KB

你看，同样一张图，ARGB8888 比 RGB565 多占了一倍内存。如果你的 MCU 只有 512 KB 的 SRAM，用 ARGB8888 存一张全屏图就直接满了，其他代码和数据根本没地方放。

3.3 色彩深度对性能的影响

内存只是其一，性能才是更隐蔽的坑。我习惯从三个维度来看：

3.3.1 传输带宽

刷屏时，数据要从 MCU 内存传到 LCD 控制器。假设 SPI 总线频率 40 MHz，8 bit 模式：

• RGB565：每像素 2 字节，传输时间 ≈ 像素数 × 2 / 5 MB/s
• ARGB8888：每像素 4 字节，传输时间翻倍

说白了，同样刷一帧，ARGB8888 要多等一倍的时间。如果你的界面需要 60 fps，RGB565 可能刚好跑满，ARGB8888 就只能降到 30 fps。

3.3.2 像素操作开销

做图像合成、Alpha 混合、颜色转换时，数据量越大，CPU 开销越大。ARGB8888 的 Alpha 混合需要做乘法除法运算，在 Cortex-M4 上跑一次混合大概要 50-80 个时钟周期。而 RGB565 的纯色块填充，用 DMA 就能搞定，CPU 几乎不参与。

3.3.3 帧缓冲大小

很多 MCU 没有硬件双缓冲，需要软件模拟。帧缓冲越大，切换开销越大。我见过一个项目用 RGB888 做双缓冲，结果内存不够，只能改成单缓冲 + 撕裂检测，画面体验差了很多。

3.4 如何选择？我的经验法则

你想想看，选色彩深度其实就是在「画质」和「资源」之间找平衡。我个人习惯按以下优先级判断：

1. 先看内存预算：MCU 的 SRAM 或外部 PSRAM 有多大？留出 30% 余量给系统栈和动态分配。
2. 再看显示内容：纯文字、图标、色块 → RGB565 足够。照片、渐变色、医疗影像 → 至少 RGB888。
3. 最后看透明度需求：需要半透明遮罩、阴影、淡入淡出 → 必须 ARGB8888。否则用 RGB565 + 1 bit 透明度掩码也能模拟。

3.5 色彩深度与像素格式关系图

下面这张图帮你理清色彩深度、像素格式、内存和性能之间的关系：

3.6 实际项目中的避坑指南

最后分享几个我踩过的坑，希望能帮你少走弯路：

• 别忽略字节对齐：有些 LCD 控制器要求像素数据 2 字节或 4 字节对齐。RGB565 天然 2 字节对齐没问题，但 RGB888 是 3 字节，在某些硬件上会触发对齐异常。
• Alpha 通道不是免费的：ARGB8888 的 Alpha 混合在软件里跑很慢。如果 MCU 没有硬件 2D 加速器，建议用 RGB565 + 全局透明度，或者用 1 bit 透明度掩码。
• 小心颜色空间转换：从 RGB888 转到 RGB565 时，低 3 bit 会被截断，导致色阶断层。我习惯在转换时加一点抖动（dithering），视觉效果好很多。
• 帧缓冲压缩：如果内存实在不够，可以考虑 RLE 或 LZ4 压缩帧缓冲。但要注意解压开销，别让 CPU 成为新瓶颈。