4. 字体与图片优化：字库裁剪、矢量与点阵的权衡、图片格式与解码内存
字体和图片，往往是嵌入式GUI里最吃内存的两大块。我见过不少项目，UI逻辑写得挺漂亮，结果一跑起来，内存直接爆了。查到最后，十有八九是字体库没裁剪，或者图片解码缓冲区开得太随意。
这一章，咱们就专门啃这两块硬骨头。我会结合自己踩过的坑，把字库裁剪、矢量与点阵的选择、图片格式对比，还有解码时的内存管理，一次性说清楚。
4.1 字库裁剪技术：别让没用到的字符占着内存
很多工程师拿到一个字体文件，直接全库加载。一个完整的宋体或黑体字库，少说几MB，大的十几MB。对于Flash和RAM都紧张的MCU来说，这简直是灾难。
核心思路很简单：只保留你真正用到的字符。
我在一个智能家居面板项目里，屏幕只需要显示数字、温度符号、几个中文字（开、关、设置、模式）。如果加载完整字库，Flash占用直接飙到3MB以上。裁剪之后，只剩不到200KB。
字库裁剪的三种常用手段：
- 手动指定字符集： 在代码里定义一个数组，列出所有用到的Unicode码点。工具根据这个列表生成子集字库。
- 扫描UI字符串： 写个脚本，自动扫描整个工程里所有界面字符串，提取出所有字符，然后生成字库。我习惯在构建脚本里加这一步，自动化，省心。
- 运行时按需加载： 把字库分成多个小段（比如按常用字、次常用字分组），用到哪个段才加载到RAM。适合字库较大、RAM极小的场景。
我的习惯： 在项目初期就确定好UI上所有可能出现的文字。如果后期要加新功能，先更新字符集，再重新生成字库。别等到内存爆了才回头裁剪，那时候改起来很痛苦。
4.2 矢量字体（FreeType）与点阵字体的内存权衡
这是个老生常谈，但又必须认真对待的选择题。
矢量字体（FreeType）：
- 优点：缩放不失真，一个字体文件可以渲染任意大小。支持抗锯齿，显示效果细腻。
- 缺点：渲染需要CPU计算，解码过程需要临时缓冲区。FreeType库本身占用几十KB到上百KB的代码空间。渲染一个复杂字形时，临时内存开销可能达到几KB甚至十几KB。
点阵字体：
- 优点：渲染速度极快，直接拷贝像素数据即可。内存占用固定，每个字模的大小是确定的（比如16x16点阵，一个字符就是32字节）。
- 缺点：缩放效果差，放大后锯齿明显。每个字号都需要单独准备一套字模文件。
我做过一个对比测试，在Cortex-M4上，渲染一个24x24的汉字：
| 字体类型 | Flash占用（1000个汉字） | 渲染时间（单字） | 临时RAM开销 |
|---|---|---|---|
| 点阵（24x24） | 约576KB | ~0.1ms | 几乎为0 |
| 矢量（FreeType） | 约300KB（字库文件） | ~2-5ms | 约4-8KB |
你看，点阵虽然Flash占用大，但速度快、内存稳。矢量省Flash，但吃CPU和临时内存。
我曾经踩过的坑： 在一个低端MCU上用了FreeType，结果每次界面切换时，因为要渲染十几个新字符，导致明显的卡顿。后来换成预渲染的点阵缓存，把常用字符提前渲染好存到RAM里，才解决了问题。
我的建议：
- 如果MCU主频高（>200MHz）、RAM够用（>512KB），用FreeType，开发效率高。
- 如果MCU资源紧张，或者对实时性要求高（比如仪表盘），用点阵字体，或者混合使用——常用字符用点阵缓存，生僻字用矢量渲染。
4.3 图片格式选择：JPEG vs PNG vs WebP
嵌入式GUI里，图片格式选对了，内存能省一大截。咱们直接看对比：
| 格式 | 压缩率 | 解码内存 | 解码速度 | 适用场景 |
|---|---|---|---|---|
| JPEG | 高（有损） | 中等（需要逐行解码缓冲区） | 快（硬件JPEG解码器常见） | 照片、渐变背景、复杂图像 |
| PNG | 中等（无损） | 较高（需要完整解压到临时缓冲区） | 慢（软件解压，尤其Alpha通道） | 图标、按钮、需要透明背景的UI元素 |
| WebP | 高（有损/无损均可） | 高（解码器复杂，临时内存大） | 较慢（软件解码，计算量大） | 资源极度受限、需要最高压缩比的场景 |
说白了，JPEG是“省Flash、费RAM”的典型。PNG是“费Flash、省RAM”（如果直接存储解码后的数据）。WebP在嵌入式里用得少，因为解码库太大，临时内存开销也高。
我的经验： 对于UI图标，我倾向于直接用PNG转成C数组（RGB565或ARGB8888格式），解码时直接memcpy到显存，零解码开销。对于背景图，用JPEG，配合硬件解码器，边解码边显示，内存占用可控。
4.4 图片解码内存管理：别让解码缓冲区成为内存黑洞
图片解码时，最怕的就是一次性把整张图片解压到内存里。一张800x480的24位图，解压后就是800*480*3 ≈ 1.1MB。很多MCU的RAM总共才几百KB。
解决方案：分块解码（Tile-based Decoding）。
把图片分成若干个小块（比如64x64像素），每次只解码一个块，然后直接渲染到显存或LCD缓冲区。这样，临时缓冲区只需要64*64*3 ≈ 12KB。
我做过一个项目，需要在128x64的OLED上显示一张JPEG图片。如果全图解码，需要128*64*2 = 16KB（灰度图）。但MCU的RAM只有20KB，还要跑系统。后来改成按行解码，每次只解一行（128字节），边解边刷屏，内存占用降到几百字节。
分块解码的关键点：
- 块大小要匹配LCD的刷新机制： 比如LCD支持矩形区域刷新，块大小就设成矩形尺寸。
- 解码器要支持流式输入： JPEG和PNG都支持逐行/逐块解码，但需要正确设置回调函数。
- 内存池管理： 为解码器分配一个固定大小的内存池，避免动态分配带来的碎片问题。
我曾经犯过的错： 一开始没注意PNG的Alpha通道解码。PNG解码时，如果图片带透明通道，解码器会额外分配一个Alpha缓冲区。我那张图是ARGB8888格式，结果解码临时内存直接翻倍。后来改成预乘Alpha，或者干脆用不带Alpha的PNG，才把内存降下来。
嗯，字体和图片这块，说到底就是“空间换时间”还是“时间换空间”的博弈。没有银弹，只有根据你的硬件资源，找到那个最合适的平衡点。