4、图像资源优化：图像尺寸与分辨率选择、图像裁剪与拼接、纹理图集（Texture Atlas）生成
图像资源，往往是嵌入式GUI里最吃内存的大户。我见过不少团队，代码写得挺漂亮，结果一张背景图就把整个系统拖垮了。说白了，图像优化不是锦上添花，而是雪中送炭。这一章，咱们就聊聊怎么把图像资源“榨干”，让它既好看又省资源。
4.1 图像尺寸与分辨率选择：别让像素白占地方
很多新手会犯一个错误：UI设计稿给的是1920x1080，就直接把原图塞进嵌入式设备。你想想看，一块320x240的屏幕，硬塞一张全高清图，不仅浪费存储，解码还慢。我建议，图像尺寸必须跟显示分辨率对齐。
核心原则：图像像素数 = 显示区域像素数 × 缩放系数。缩放系数通常取1.0，除非你有特殊的抗锯齿需求。
举个例子。你的屏幕是480x272，一个按钮图标占60x60像素。那你准备的图标资源，就应该正好是60x60。别搞成120x120再让CPU去缩，那是在浪费算力。
分辨率选择上，我个人习惯遵循“三步走”：
- 确认目标屏幕的物理尺寸和DPI。比如7寸屏，1024x600，那图像精度做到每英寸150像素就足够了。
- 按实际显示尺寸裁剪。不要留白边，不要包含不可见区域。
- 色彩深度按需选择。能上16位色，就别用32位。能上8位索引色，就别用16位。
小技巧：我在项目中遇到过，有些MCU支持硬件JPEG解码。这时候，你可以直接存JPEG格式，解码后扔给显示缓冲区。但要注意，JPEG解码需要额外的RAM做中间缓存，别把堆栈撑爆了。
4.2 图像裁剪与拼接：把大图拆成小积木
图像裁剪，说白了就是把一张大图里有用的部分切出来。拼接呢，就是把多张小图拼成一张大图。这两个操作，在嵌入式GUI里几乎是天天用。
为什么要裁剪？因为很多UI素材是设计师给的PSD或PNG源文件，里面包含大量透明区域和留白。直接加载整张图，透明区域也会占用内存。我建议，把每个UI元素单独裁剪出来，只保留有效像素区域。
举个例子，一个进度条背景图是400x20，但实际有效区域只有中间380x16的渐变条，两边各10像素的圆角。你可以把背景裁剪成三块：左圆角、中间渐变条、右圆角。显示的时候，中间部分水平平铺。这样，存储和内存都省了。
注意：裁剪时一定要考虑对齐方式。我曾经因为裁剪时没留1像素的出血位，导致拼接时出现1像素的缝隙。嗯，那画面，真是逼死强迫症。
图像拼接，则是反过来。把多个小图标拼成一张大图，然后通过坐标偏移来显示不同图标。这样做的好处是：减少文件句柄数量，减少I/O操作次数。
我常用的拼接策略：
- 水平拼接：适用于宽度固定、高度一致的图标序列，比如工具栏按钮。
- 垂直拼接：适用于高度固定、宽度一致的图标序列，比如列表项图标。
- 网格拼接：适用于大小一致的图标矩阵，比如表情包或键盘按键。
4.3 纹理图集（Texture Atlas）生成：把碎片打包成整块
纹理图集，也叫精灵图（Sprite Sheet）。这个概念在游戏开发里很常见，但在嵌入式GUI里同样好用。它的核心思想是：把多个小纹理合并到一张大纹理上，渲染时通过UV坐标来采样。
为什么这么做？因为嵌入式GPU（如果有的话）在切换纹理时，会有状态切换开销。你每切换一次纹理，GPU就要重新加载纹理数据到缓存。如果所有小图都在一张大图上，那GPU只需要加载一次，然后随便切。
即使没有GPU，纯CPU渲染的场景下，纹理图集也能减少文件读取次数。你想想看，从Flash里读一张512x512的大图，跟读10张64x64的小图，哪个快？显然是大图快，因为Flash的随机读取性能远不如顺序读取。
纹理图集生成的关键参数：
- 图集尺寸：通常取2的幂次方，比如256、512、1024。这样对齐GPU的纹理单元。
- 内边距（Padding）：每个子纹理之间留1-2像素的间隙，防止采样时出现边缘溢出。
- 排序算法：常用“最大矩形算法”或“贪心算法”，尽量提高空间利用率。
下面是我在项目里用过的一个简单纹理图集布局示例：
// 纹理图集描述结构体
typedef struct {
uint16_t atlas_width; // 图集总宽度
uint16_t atlas_height; // 图集总高度
uint16_t x; // 子纹理在图集中的X偏移
uint16_t y; // 子纹理在图集中的Y偏移
uint16_t w; // 子纹理宽度
uint16_t h; // 子纹理高度
} texture_atlas_entry_t;
// 示例：三个图标打包到一张256x256的图集里
texture_atlas_entry_t icons[] = {
{256, 256, 0, 0, 64, 64}, // 图标A：左上角
{256, 256, 66, 0, 64, 64}, // 图标B：A右边，留2像素间隙
{256, 256, 0, 66, 128, 64}, // 图标C：A下面，宽度翻倍
};生成纹理图集，我推荐用工具自动完成。手动拼？太累了，而且容易出错。常用的工具有：
| 工具名称 | 适用场景 | 特点 |
|---|---|---|
| TexturePacker | 通用，支持多种输出格式 | 商业软件，算法优秀，支持命令行 |
| LibGdx TexturePacker | Java生态，适合Android/Linux | 开源，可集成到构建脚本 |
| 自制Python脚本 | 高度定制化需求 | 灵活，但需要自己实现排序算法 |
我的经验：在资源极度受限的MCU上，我甚至把纹理图集直接转成C语言数组，编译进固件里。这样连文件系统都省了。但要注意，数组太大可能会超出编译器的限制，需要分块处理。
下面这张图，展示了纹理图集的核心逻辑：
你看，整个流程很清晰：碎片输入 -> 打包算法 -> 输出图集。关键就在于中间那一步的算法选择。我建议，如果图集里碎片数量少于50个，用贪心算法就够了。超过100个，最好用最大矩形算法，空间利用率能高10%左右。
避坑指南：我曾经在生成图集时，忘了考虑字节对齐。有些MCU要求图像数据按4字节对齐，否则DMA传输会出错。所以，生成图集后，一定要检查每个子纹理的起始地址是否对齐。不对齐的话，手动补一些填充字节。
最后，总结一下图像资源优化的三个核心点：
- 尺寸对齐：图像像素数 = 显示像素数，别多别少。
- 裁剪拼接：去掉透明区域，把大图拆成可复用的积木块。
- 纹理图集：把碎片打包成整块，减少I/O和纹理切换开销。
嗯，这些技巧，我在好几个量产项目里都用过。效果嘛，存储占用至少省一半，渲染速度也能提升30%以上。你试试看，肯定有收获。