图片资源格式与压缩：嵌入式GUI的存储博弈
做嵌入式GUI，说白了就是跟存储空间和带宽较劲。我见过太多项目，UI设计得花里胡哨，结果一烧录发现Flash爆了——那种感觉，就像你精心打包好行李，结果箱子合不上。
这一章，咱们就聊聊图片格式和压缩。你想想看，一张800×480的24位真彩色BMP，裸数据就要1.1MB。在只有8MB Flash的MCU上，你放不了几张图。所以，选对格式、压对方式，是嵌入式GUI工程师的基本功。
常见图片格式在嵌入式中的适用性
先过一遍四种主流格式。我按自己的经验，把它们分成两类：一类是“直接能用的”，一类是“需要解码的”。
| 格式 | 存储大小 | 解码开销 | 适用场景 | 我的评价 |
|---|---|---|---|---|
| BMP | 极大（无压缩） | 几乎为零 | 小尺寸图标、启动Logo | 简单粗暴，但空间浪费严重 |
| PNG | 中等（无损压缩） | 中等（需zlib） | 图标、按钮、界面元素 | 嵌入式GUI最常用，没有之一 |
| JPEG | 小（有损压缩） | 较高（IDCT运算） | 照片、背景图、大尺寸图像 | 适合自然图像，文字边缘会糊 |
| GIF | 极小（256色） | 低 | 简单动画、低色深图标 | 色彩受限，但支持动画是亮点 |
我个人习惯，界面控件和图标用PNG，背景图或照片用JPEG，GIF只在需要简单动画时考虑。至于BMP？嗯，除非你Flash多到没处花，否则尽量别用。
无损压缩 vs 有损压缩：一个关于“完美”的谎言
很多刚入行的朋友会问：“无损压缩不是更好吗？数据一点不丢。” 这话对，但不全对。
无损压缩（如PNG）保证像素级还原。但它的压缩率有限，通常只有2:1到5:1。我在一个智能家居项目里，用PNG存了一套仪表盘图标，128×128的24位图，压缩后每张大概8KB。效果很好，但一套50个图标就是400KB。
有损压缩（如JPEG）会丢弃人眼不敏感的高频信息。压缩率可以轻松达到10:1甚至20:1。同样是128×128的图，JPEG质量85%时只有3KB左右。但代价是什么？文字边缘会出现振铃效应，纯色区域会有块状噪声。
为什么会这样？因为JPEG的压缩算法基于离散余弦变换（DCT），它把图像分成8×8的块，然后丢弃高频分量。文字边缘的锐利变化正好是高频信号，所以最先被牺牲掉。
调色板模式 vs 真彩色：嵌入式GUI的“省钱”之道
这里我要重点讲一下调色板模式。说白了，就是用一张颜色表（调色板）来索引颜色，而不是直接存储每个像素的RGB值。
举个例子：一张320×240的图标，如果用真彩色（24位），需要320×240×3 = 230,400字节。但如果它只有16种颜色，我们可以用4位索引，只需要320×240×0.5 + 16×3 = 38,448字节。节省了83%！
| 模式 | 色深 | 每像素位数 | 颜色数 | 典型场景 |
|---|---|---|---|---|
| 调色板1位 | 1bpp | 1 | 2 | 黑白图标、文字 |
| 调色板4位 | 4bpp | 4 | 16 | 简单图标、低配UI |
| 调色板8位 | 8bpp | 8 | 256 | 大多数GUI元素 |
| 真彩色 | 24bpp | 24 | 16.7M | 照片、高精度图像 |
我曾经接手过一个项目，Flash只剩200KB，但UI需要30多张按钮图标。我让设计师把图标颜色从真彩色降到256色调色板，每张图从15KB降到了4KB。30张图，省了330KB。嗯，这就是调色板模式的魅力。
图片压缩工具：你的“瘦身”工具箱
光选对格式还不够，你得会用工具把图片“榨干”。我常用的工具就两个：pngcrush 和 ImageMagick。它们都是命令行工具，适合集成到自动化构建脚本里。
pngcrush：PNG的终极瘦身器
pngcrush 的核心工作就是尝试不同的压缩策略（过滤方法、zlib参数），找到最优组合。它不会改变像素，只是让PNG文件更小。
# 基本用法：压缩PNG
pngcrush -brute input.png output.png
# 减少调色板颜色数（从256色降到64色）
pngcrush -plte 64 input.png output.png
# 移除元数据（如EXIF、注释）
pngcrush -rem alla input.png output.png我个人习惯在构建脚本里加一步：pngcrush -brute -rem alla。这样能再压掉10%-20%的大小。别小看这10%，在嵌入式里，10%可能就是几百KB的Flash空间。
ImageMagick：图像处理的瑞士军刀
ImageMagick 能做的事情太多了。格式转换、缩放、裁剪、颜色量化、添加水印……我主要用它做批量处理和格式转换。
# 批量转换BMP到PNG
mogrify -format png *.bmp
# 将真彩色PNG转为8位调色板PNG
convert input.png -colors 256 output.png
# JPEG质量压缩（质量85%）
convert input.bmp -quality 85 output.jpg
# 批量缩放并转换
mogrify -resize 50% -format png *.jpg-colors参数默认使用Floyd-Steinberg抖动。结果图标边缘出现了噪点，在GUI上看起来脏兮兮的。后来我加了-dither None才解决。所以，批量操作前一定要先试一张。
知识体系：图片资源压缩的核心逻辑
下面这张图，是我自己梳理的图片资源压缩决策流程。每次做新项目，我都会走一遍这个流程。
这个流程的核心逻辑很简单：先判断图片类型，再选择压缩策略，最后用工具优化。我每次做新项目，都会把这个流程贴在工位上。
实战建议：从项目开始就规划好
最后，分享几个我踩过的坑和总结的经验：
- 尽早确定图片格式规范。 别等UI设计完了再压缩。我见过一个项目，设计师给了200张BMP，我们花了三天才转完。如果一开始就定好PNG+调色板，一天就能搞定。
- 自动化压缩流程。 把pngcrush和ImageMagick集成到CI/CD脚本里。每次提交代码，自动压缩所有图片。这样就不会有人“忘记”压缩了。
- 保留原始素材。 压缩后的图片是不可逆的。我习惯在Git里保留原始PSD或SVG，压缩后的图片作为构建产物。这样想改还能改。
- 测试解码性能。 不同的MCU解码速度差异很大。我曾经在一个Cortex-M0上跑JPEG解码，一张320×240的图解码用了800ms。后来换成PNG，虽然文件大了，但解码只要200ms。所以，别只看存储大小，还要看解码时间。
嗯，这一章就到这里。图片格式和压缩是嵌入式GUI的“基本功”，但很多人容易忽视。记住：选对格式、用好工具、自动化流程，你的Flash空间会感谢你的。