3. 内存管理优化：别让内存成为你的瓶颈

嵌入式GUI开发，说白了就是跟有限的内存资源死磕。我见过太多项目，界面逻辑写得漂漂亮亮，一跑起来就卡顿、闪退，最后查下来，十有八九是内存管理出了问题。这一章，我们就来聊聊怎么把内存这块“硬骨头”啃下来。

3.1 内存池设计：自己的内存自己管

为什么不用标准库的 malloc 和 free？原因很简单：不可预测。你永远不知道一次分配要花多久，也不知道碎片什么时候会把堆撑爆。对于GUI这种实时性要求高的场景，这简直是灾难。

我个人习惯，在项目启动阶段就划出一块固定大小的内存池，专门给GUI模块用。这样分配和释放的时间都是确定的，不会出现“卡一下”的情况。

3.1.1 固定大小块内存池

这是最常用、也最可靠的一种。把内存池切成若干个大小相同的块，每个块用一个空闲链表串起来。分配时从链表头取一个，释放时再放回去。

/* 固定大小块内存池示例 */
#define POOL_BLOCK_SIZE  64   /* 每个块64字节 */
#define POOL_BLOCK_NUM   32   /* 总共32个块 */

typedef struct {
    uint8_t  block[POOL_BLOCK_SIZE];
    uint32_t next_free;        /* 指向下一个空闲块的索引 */
} PoolBlock;

typedef struct {
    PoolBlock blocks[POOL_BLOCK_NUM];
    uint32_t  free_head;       /* 空闲链表头 */
} MemPool;

void pool_init(MemPool *pool) {
    for (int i = 0; i < POOL_BLOCK_NUM - 1; i++) {
        pool->blocks[i].next_free = i + 1;
    }
    pool->blocks[POOL_BLOCK_NUM - 1].next_free = 0xFFFFFFFF; /* 结束标记 */
    pool->free_head = 0;
}

void *pool_alloc(MemPool *pool) {
    if (pool->free_head == 0xFFFFFFFF) return NULL; /* 池空了 */
    uint32_t idx = pool->free_head;
    pool->free_head = pool->blocks[idx].next_free;
    return (void *)&pool->blocks[idx].block;
}

void pool_free(MemPool *pool, void *ptr) {
    /* 计算索引，把块放回空闲链表头 */
    uint32_t idx = ((uint8_t *)ptr - (uint8_t *)pool->blocks) / sizeof(PoolBlock);
    pool->blocks[idx].next_free = pool->free_head;
    pool->free_head = idx;
}

你看，这个实现里没有链表指针，只用了一个 uint32_t 索引。为什么？因为指针在32位系统上占4字节，索引也占4字节，但索引可以保证指向池内，不会出现野指针。我在一个项目里用这个方案，把内存分配时间从平均几十微秒降到了几百纳秒。

3.1.2 多级内存池

固定大小块有个问题：如果对象大小超过块大小，就装不下；如果远小于块大小，又浪费。怎么办？搞多级池。

比如，我同时维护三个池：16字节池、64字节池、256字节池。分配时根据请求大小，选择最合适的池。这样既避免了浪费，又保持了确定性。

池级别	块大小	块数量	适用场景
小对象池	16 字节	64	事件结构、坐标结构
中对象池	64 字节	32	控件描述符、字符串缓冲区
大对象池	256 字节	8	图像解码临时缓冲区

3.2 动态内存分配避免策略：能静态就别动态

你想想看，一个GUI界面，按钮、标签、窗口这些控件，数量在编译时是不是基本确定的？那为什么还要在运行时去 malloc 它们呢？

我的原则：所有GUI控件的生命周期如果跟应用一样长，就静态分配；只有那些临时创建的对话框、弹出菜单，才考虑用内存池。

3.2.1 静态分配与对象池

定义一个全局的控件数组，编译时就分配好。运行时只是从这个数组里“激活”或“休眠”控件。

/* 静态控件池 */
#define MAX_BUTTONS  16
#define MAX_LABELS   16

static Button button_pool[MAX_BUTTONS];
static Label  label_pool[MAX_LABELS];

Button *button_create(void) {
    for (int i = 0; i < MAX_BUTTONS; i++) {
        if (!button_pool[i].in_use) {
            button_pool[i].in_use = 1;
            return &button_pool[i];
        }
    }
    return NULL; /* 池满了 */
}

void button_destroy(Button *btn) {
    btn->in_use = 0;
}

这样做的好处是：零碎片。所有控件都在固定的内存地址上，不会因为反复创建销毁而产生空洞。

3.2.2 栈上分配

对于生命周期很短的临时对象，比如一次触摸事件的处理上下文，直接用栈上分配。函数返回时自动释放，连池都不用进。

void handle_touch_event(TouchEvent *ev) {
    /* 栈上分配，零开销 */
    TouchContext ctx;
    ctx.x = ev->x;
    ctx.y = ev->y;
    ctx.timestamp = get_tick();
    
    /* 处理逻辑... */
    /* 函数返回时，ctx自动销毁 */
}

3.3 显存复用：别让帧缓冲闲着

显存（DMA Buffer）是GUI里最贵的资源之一。一个800x480的16位色帧缓冲，就要768KB。如果双缓冲，就是1.5MB。对于只有几MB内存的MCU来说，这简直是奢侈品。

复用思路：显存不只是在刷屏时才用。在渲染间隙，它完全可以干点别的。

3.3.1 双缓冲区的角色互换

传统双缓冲：一个前台显示，一个后台渲染。渲染完成后交换。但交换后，原来的前台缓冲就空闲了。我建议把这个空闲缓冲用作临时纹理存储或图像解码缓冲区。

/* 双缓冲复用示例 */
typedef struct {
    uint16_t *front;   /* 当前显示缓冲 */
    uint16_t *back;    /* 后台渲染缓冲 */
    uint16_t  buffer0[BUFFER_SIZE];
    uint16_t  buffer1[BUFFER_SIZE];
} FrameBuffer;

void swap_buffers(FrameBuffer *fb) {
    /* 交换指针 */
    uint16_t *tmp = fb->front;
    fb->front = fb->back;
    fb->back = tmp;
    
    /* 此时，fb->back 指向的旧前台缓冲可以复用 */
    /* 比如，用来解码一张小图片 */
    decode_image_to_buffer(some_image, fb->back, IMAGE_SIZE);
}

嗯，这里要注意：复用时要确保渲染引擎已经完成了对旧前台缓冲的DMA传输，否则会出现画面撕裂。我一般会在交换后加一个 wait_for_vsync 或者 DMA_transfer_done 标志。

3.3.2 局部刷新与脏矩形

没必要每次都刷新整个屏幕。只刷新变化的部分，能省下大量显存带宽。

我实现过一个脏矩形管理器：每次控件更新时，记录下它所在的矩形区域。刷新时，只把这些区域的数据从后台缓冲拷贝到前台缓冲。对于静态背景，完全不用动。

/* 脏矩形列表 */
#define MAX_DIRTY_RECTS 8

typedef struct {
    int16_t x, y, w, h;
} Rect;

static Rect dirty_rects[MAX_DIRTY_RECTS];
static int  dirty_count = 0;

void mark_dirty(int16_t x, int16_t y, int16_t w, int16_t h) {
    if (dirty_count < MAX_DIRTY_RECTS) {
        dirty_rects[dirty_count].x = x;
        dirty_rects[dirty_count].y = y;
        dirty_rects[dirty_count].w = w;
        dirty_rects[dirty_count].h = h;
        dirty_count++;
    }
}

void flush_dirty_rects(FrameBuffer *fb) {
    for (int i = 0; i < dirty_count; i++) {
        /* 只拷贝脏矩形区域 */
        dma_copy(fb->front, fb->back, dirty_rects[i]);
    }
    dirty_count = 0;
}

3.4 内存碎片整理：亡羊补牢

就算用了内存池，也难免有碎片。尤其是当你不得不使用 malloc 时（比如加载外部字体、解码大图片），堆碎片会慢慢累积。

我的经验：碎片整理不是万能的，但关键时刻能救命。

3.4.1 压缩式整理

把所有已分配的内存块移动到堆的一端，空出一整块连续空间。这需要暂停所有任务，移动数据，更新指针。开销很大，但效果显著。

/* 伪代码：压缩式碎片整理 */
void heap_defrag(void) {
    disable_all_interrupts();  /* 停止所有任务 */
    pause_gui_rendering();     /* 暂停GUI渲染 */
    
    /* 遍历堆，移动已分配块 */
    for (each allocated block) {
        move_block_to_low_address(block);
        update_all_pointers_to(block);
    }
    
    resume_gui_rendering();
    enable_all_interrupts();
}

3.4.2 预防胜于治疗

与其等碎片多了再整理，不如一开始就避免。我的做法是：

• 固定大小分配：所有GUI对象都用内存池，不用 malloc。
• 大块一次性分配：如果必须用堆，比如加载一张大图片，一次性分配好，用完立刻释放，不要反复调整大小。
• 定期检查：在调试版本里，每隔一段时间打印堆的使用情况和碎片率。碎片率超过30%就报警。

3.5 本章知识体系

下面这张图，把本章的核心逻辑串起来了。你可以把它当作一个决策树：从内存分配开始，到显存复用，再到碎片整理，每一步都有对应的策略。