3. 性能指标与度量
嵌入式GUI的内存管理，说白了就是一场「精打细算的生存游戏」。显存就那么几MB，系统内存也紧巴巴，稍不注意就是黑屏或卡死。我这些年踩过的坑，十有八九都跟内存有关。今天咱们就把这块硬骨头啃下来。
3.1 内存池与预分配：别让malloc成为性能杀手
很多新手喜欢在GUI运行时频繁malloc/free。这在PC上问题不大，但在嵌入式环境里，这就是灾难。为什么？因为标准malloc的分配时间不确定，而且会产生大量碎片。
我个人习惯的做法是：启动时一次性分配，运行时零动态分配。
核心原则：GUI所有UI对象、缓冲区、纹理描述符，都在初始化阶段从内存池中预分配。运行时只做「借」和「还」，不做「生」和「死」。
来看一个简单的内存池实现思路：
// 内存池节点
typedef struct {
uint8_t* pool; // 实际内存块
uint32_t block_size; // 每个块大小
uint32_t total_blocks; // 总块数
uint32_t free_list; // 空闲块链表头
} MemPool_t;
// 初始化：把所有块串成链表
void MemPool_Init(MemPool_t* mp, void* buf,
uint32_t blk_sz, uint32_t cnt) {
mp->pool = (uint8_t*)buf;
mp->block_size = blk_sz;
mp->total_blocks = cnt;
// 构建空闲链表
for (int i = 0; i < cnt - 1; i++) {
*(uint32_t*)(mp->pool + i * blk_sz) = i + 1;
}
*(uint32_t*)(mp->pool + (cnt-1) * blk_sz) = 0xFFFFFFFF;
mp->free_list = 0;
}
// 分配：O(1)时间复杂度
void* MemPool_Alloc(MemPool_t* mp) {
if (mp->free_list == 0xFFFFFFFF) return NULL;
uint32_t idx = mp->free_list;
mp->free_list = *(uint32_t*)(mp->pool + idx * mp->block_size);
return mp->pool + idx * mp->block_size;
}
// 释放：O(1)时间复杂度
void MemPool_Free(MemPool_t* mp, void* ptr) {
uint32_t idx = ((uint8_t*)ptr - mp->pool) / mp->block_size;
*(uint32_t*)ptr = mp->free_list;
mp->free_list = idx;
}
这段代码我用了好几年，从STM32F4到i.MX RT系列都没出过问题。注意看：分配和释放都是O(1)，没有链表遍历，没有内存碎片。
经验之谈：内存池的块大小怎么定？我一般按UI对象类型分池——按钮池（64字节）、图片描述符池（128字节）、动画帧池（256字节）。这样既避免浪费，又保证每个池内部块大小一致。
3.2 纹理压缩格式选择：ETC2 vs ASTC
纹理是显存消耗的大头。一张1024x1024的RGBA8888纹理，裸奔就是4MB。你想想看，很多MCU的总显存才8MB，一张图就吃掉一半，这还怎么玩？
所以纹理压缩不是「锦上添花」，而是「雪中送炭」。目前嵌入式领域主流就两个选择：ETC2和ASTC。
| 特性 | ETC2 | ASTC |
|---|---|---|
| 压缩比 | 固定6:1（RGBA） | 可调，从4:1到16:1 |
| 硬件支持 | 几乎所有Mali GPU | Mali T6xx+、高通Adreno |
| 质量 | 中等，有块效应 | 优秀，细节保留好 |
| 解码开销 | 低 | 中等 |
| 适用场景 | UI图标、简单渐变 | 照片、复杂纹理 |
我在一个智能家居项目里做过对比：同样一张背景图，ETC2压缩后1.2MB，ASTC 8x8压缩后只有0.6MB，而且肉眼几乎看不出区别。但要注意——ASTC的解码器面积比ETC2大不少，如果你的GPU是Mali-400这种老架构，老老实实用ETC2。
避坑指南：我曾经在一个项目里全用ASTC 4x4，结果在某个低端芯片上解码一帧花了8ms，直接导致掉帧。后来改成：背景用ASTC 8x8，图标用ETC2，按钮用未压缩的RGBA4444。帧率从22fps拉回到55fps。
3.3 显存与系统内存的平衡艺术
嵌入式GPU通常有自己的专用显存（VRAM），但容量很小。很多时候我们需要在VRAM和系统内存之间来回倒腾数据。这里有个关键问题：什么时候该把纹理留在VRAM，什么时候该换出去？
我总结了一套「三级缓存策略」：
- 常驻层：UI框架、桌面背景、常用图标。这些永远在VRAM里，不换出。
- 热交换层：当前页面的图片、字体缓存。页面切换时批量换入换出。
- 按需加载层：弹窗、二级菜单的纹理。用的时候从系统内存解压到VRAM，用完立刻释放。
关键指标：VRAM命中率要保持在85%以上。如果低于这个值，说明你的热交换策略有问题，频繁的DMA传输会吃掉大量带宽。
具体实现时，我会用一个LRU链表来管理VRAM中的纹理槽位。每次渲染时，被访问的纹理移到链表头部；当需要换入新纹理时，从尾部淘汰。这个算法简单，但在GUI场景下效果很好——因为用户的操作通常有局部性。
3.4 碎片整理与GC调优
即使用了内存池，长时间运行后还是可能出现碎片问题。尤其是那些大小不一的纹理缓存、动画帧缓冲区，用久了就像老房子的杂物间——东西不多，但就是塞不进新的。
碎片整理有两种思路：
- 紧缩式整理：把所有已分配块移动到一端，合并空闲空间。代价是移动期间所有指针失效，需要重映射。
- 分代式整理：把内存按对象生命周期分代。短期对象（如动画帧）在年轻代分配，频繁回收；长期对象（如字体缓存）在老年代，很少移动。
我个人更推荐第二种。为什么？因为GUI的UI对象生命周期差异极大——按钮、标签这些几乎不销毁，而动画帧、过渡效果几秒钟就没了。把它们混在一起管理，纯属给自己找麻烦。
实战技巧：我在一个车载仪表盘项目里，把动画帧缓冲区单独划了一个256KB的环形缓冲区。每帧动画用完直接覆盖写，根本不需要GC。帧率稳定在60fps，连续跑了72小时没出过内存问题。
至于GC调优，如果你的GUI框架用了脚本语言（比如Lua或JS），那GC就是绕不开的坎。我的建议是：
- 减少临时对象：比如颜色值、矩形坐标，用结构体复用而不是每次new。
- 手动触发GC时机：在页面切换完成、用户无操作的间隙触发，不要在动画渲染中触发。
- 调整GC阈值：把GC触发阈值设高一点，让GC少跑几次，每次跑久一点。频繁的微GC比一次大GC更伤性能。
嗯，这张图基本概括了本章的核心逻辑。从顶层的内存池预分配，到纹理压缩的选择，再到显存平衡和碎片整理，每一步都是在跟有限的资源做博弈。记住一句话：嵌入式GUI的内存管理，不是「够用就行」，而是「刚刚好」。