图像资源压缩：PNG/JPEG压缩原理、TouchGFX图像格式选择、有损与无损压缩策略
图像资源，说白了就是嵌入式UI的「体重秤」。你界面再漂亮，一张图几兆，跑起来照样卡成PPT。我刚开始做TouchGFX项目时，就吃过这个亏——UI设计稿美得很，结果刷屏速度惨不忍睹。后来才明白，图像压缩不是可有可无的优化，而是嵌入式UI的生存底线。
这一章，咱们就把图像压缩这件事彻底聊透。从PNG和JPEG的压缩原理，到TouchGFX支持的图像格式怎么选，再到有损和无损策略怎么搭配。嗯，内容有点干，但都是实战干货。
核心观点：在TouchGFX中，图像格式的选择直接影响Flash占用、解码速度和渲染质量。没有「最好」的格式，只有「最合适」的场景。
2.1 PNG与JPEG压缩原理——先搞懂它们怎么「瘦身」的
你想想看，一张原始位图（比如BMP）是赤裸裸的像素数据。PNG和JPEG就是给它穿上不同的「压缩衣服」。穿法不同，效果天差地别。
2.1.1 PNG：无损压缩的「老实人」
PNG用的是Deflate算法，本质是LZ77 + Huffman编码的组合拳。它不会丢掉任何一个像素，压缩率完全取决于图像内容的冗余度。
- 水平方向冗余：同一行相邻像素颜色相近，PNG会记录差值而非绝对值。
- 垂直方向冗余：上下行之间颜色变化小，PNG也能利用这个规律。
- 调色板模式：颜色数少于256色时，PNG可以用索引色表，压缩率极高。
我在项目中遇到过一个问题：一张纯色渐变背景图，PNG压缩后只有几KB，但换成复杂纹理的图标，同样的尺寸却大了10倍。原因就是——PNG对「平坦区域」压缩效果好，对「高频细节」无能为力。
实战技巧：如果你的PNG图片包含大量纯色块或渐变，压缩率通常不错。但如果图片噪点多、纹理复杂，PNG会变得很「胖」。这时候就该考虑JPEG或者TouchGFX的专用格式了。
2.1.2 JPEG：有损压缩的「实用主义者」
JPEG的思路完全不同。它先把图像从RGB转换到YCbCr色彩空间，然后对亮度（Y）和色度（Cb、Cr）分开处理。人眼对亮度变化敏感，对色度变化不敏感——JPEG就利用这个弱点，狠心丢掉一部分色度信息。
具体步骤我简单列一下：
- 色彩空间转换（RGB → YCbCr）
- 色度下采样（通常4:2:0，丢掉一半以上的色度数据）
- 分块DCT变换（把图像切成8x8的小块，转成频率系数）
- 量化（这一步是「有损」的核心，高频系数被舍入或归零）
- 熵编码（Huffman或算术编码，无损压缩剩余数据）
说白了，JPEG就是「睁一只眼闭一只眼」——只要你看不太出来，它就敢丢。质量参数Q值越低，丢得越狠，文件越小。
注意：JPEG在低质量设置下会产生明显的「块效应」和「振铃效应」。在TouchGFX的UI中，如果背景图出现块状瑕疵，用户体验会大打折扣。我曾经在一个医疗设备项目上，因为JPEG压缩过度，导致屏幕上的文字边缘出现彩色伪影——被客户当场退货。从那以后，我对JPEG的质量参数再也不敢马虎。
2.2 TouchGFX图像格式选择——选对格式，事半功倍
TouchGFX支持多种图像格式，但每种格式的解码方式、内存占用、渲染速度都不一样。我习惯把它们分成三类：
| 格式 | 存储方式 | 解码时机 | Flash占用 | RAM占用 | 适用场景 |
|---|---|---|---|---|---|
| Bitmap (BMP) | 原始像素 | 无需解码 | 最大 | 最小（直接使用） | 小图标、小尺寸元素 |
| PNG | 压缩像素 | 运行时解码 | 中等 | 大（需解压到RAM） | 需要透明通道的图标、小图 |
| JPEG | 压缩像素 | 运行时解码 | 小 | 大（需解压到RAM） | 照片级背景、大尺寸图片 |
| L8 / A4 / A2 | 索引色 | 无需解码 | 极小 | 最小 | 纯色图标、文字、简单图形 |
| RGB565 / ARGB2222 | 原始像素（压缩位深） | 无需解码 | 中等 | 最小 | 无透明或低透明需求的UI元素 |
看到这个表，你可能已经发现了：没有「万能」的格式。BMP虽然省RAM，但Flash占用大；PNG虽然Flash小，但解码需要额外RAM和CPU时间。怎么选？我一般遵循这几个原则：
- 小图标（< 32x32）：直接用BMP或L8索引色，省去解码开销。
- 中等尺寸带透明（32x32 ~ 200x200）：PNG是合理选择，但要注意控制解码缓冲区大小。
- 大尺寸背景（全屏或接近全屏）：JPEG优先，配合DMA2D硬件解码可以大幅提升性能。
- 纯色或渐变的UI元素：L8/A4/A2索引色格式，Flash占用可以压缩到极致。
我的习惯：在项目初期，我会把所有图像资源先用PNG格式导入TouchGFX Designer，方便调试。等到UI基本定型后，再逐个分析每个图像的使用频率和尺寸，批量转换成最优格式。这样既保证了开发效率，又不会牺牲最终性能。
2.3 有损与无损压缩策略——什么时候该「丢」，什么时候该「保」
这个问题，说白了就是在「画质」和「性能」之间找平衡。我把它拆成两个维度来考虑：
2.3.1 无损压缩策略（适合「保」的场景）
以下场景，我建议你坚决使用无损压缩：
- 图标和按钮：边缘清晰，颜色分明，有损压缩会产生锯齿和色斑。
- 文字和数字：哪怕一个像素的偏差，文字都可能变得模糊或出现伪影。
- 小尺寸图像（< 64x64）：有损压缩的「块效应」在小图上会被放大，肉眼很容易察觉。
- 需要透明通道的图像：JPEG不支持透明，PNG是唯一选择。
无损压缩的优化手段：
- 减少颜色数：用图像处理工具（如PhotoShop、GIMP）将图标颜色数降到256色甚至16色，PNG压缩率会大幅提升。
- 使用TouchGFX的L8格式：如果颜色数不超过256，L8格式比PNG更省Flash，且无需解码。
- 去除元数据：PNG文件中的EXIF、ICC等元数据对UI毫无用处，用工具批量删除可以节省5%~15%的空间。
2.3.2 有损压缩策略（适合「丢」的场景）
以下场景，有损压缩是更好的选择：
- 全屏背景图：用户不会盯着背景看细节，JPEG质量75~85通常就够用。
- 照片或渐变纹理：自然图像对人眼的容错率高，适当有损压缩几乎看不出区别。
- 大尺寸图像（> 400x400）：无损压缩的PNG可能比JPEG大5~10倍，Flash根本扛不住。
有损压缩的优化手段：
- 调整JPEG质量参数：从Q=90开始逐步降低，直到肉眼刚能察觉瑕疵为止，然后回调5个点作为安全余量。
- 色度下采样：4:2:0是标准做法，如果图像以灰度为主，可以尝试4:0:0（只保留亮度）。
- 预处理降噪：在压缩前对图像做轻微模糊，可以减少高频噪声，让JPEG压缩更高效。
避坑指南：我曾经在一个智能家居项目上，把所有背景图都用JPEG Q=50压缩，Flash确实省了不少。结果客户在强光下使用设备时，背景图的块状伪影被放大得一塌糊涂。后来我改成Q=80，Flash只多了15%，但画质问题彻底解决。记住：压缩策略要结合实际使用环境来定，别光看数字。
2.4 知识体系总览
下面这张图，我把本章的核心逻辑串起来了。你可以把它当作一个决策参考：
这张图的核心逻辑很简单：先看是否需要透明，再看颜色数，最后看尺寸。每一步都对应一个或几个最优格式。你按照这个流程走，基本不会选错。