📚 课程目录第2章嵌入式GUI基础

2. 嵌入式GUI基础

做嵌入式GUI，说白了就是跟存储空间和带宽较劲。我见过太多项目，UI设计得花里胡哨，结果一烧录发现Flash爆了——那种感觉，就像你精心打包好行李，结果箱子合不上。

这一章，咱们就聊聊图片格式和压缩。你想想看，一张800×480的24位真彩色BMP，裸数据就要1.1MB。在只有8MB Flash的MCU上，你放不了几张图。所以，选对格式、压对方式，是嵌入式GUI工程师的基本功。

  核心观点： 嵌入式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左右。但代价是什么？文字边缘会出现振铃效应，纯色区域会有块状噪声。

我的经验法则： 如果图片包含文字、图标、线条，用PNG（无损）。如果是照片、渐变背景、纹理，用JPEG（有损）。别在JPEG里放文字，你会后悔的。

为什么会这样？因为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。嗯，这就是调色板模式的魅力。

注意： 调色板模式不是万能的。如果原图颜色丰富（比如照片），强行降色会导致明显的色阶和伪轮廓。我见过有人把一张夕阳照片降到16色，结果天空变成了一块一块的色块，惨不忍睹。

图片压缩工具：你的“瘦身”工具箱

光选对格式还不够，你得会用工具把图片“榨干”。我常用的工具就两个：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

避坑指南： 我曾经用ImageMagick批量转换一批图标，没注意-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是系统工程，存储、性能、画质三者要平衡。

嗯，这一章就到这里。图片格式和压缩是嵌入式GUI的“基本功”，但很多人容易忽视。记住：选对格式、用好工具、自动化流程，你的Flash空间会感谢你的。