1. 内存优化概述：为什么界面移植要关注内存
各位好，我是老周。做嵌入式界面移植这些年，我踩过最大的坑，就是内存。你想想看，一个在 PC 上跑得飞快的界面，搬到资源受限的嵌入式设备上，动不动就黑屏、卡死、甚至重启。说白了，内存就是那个「看不见的瓶颈」。
我记得刚入行那会儿，接手一个智能家居面板的移植项目。原方案在 Linux 上用了 64MB 内存，目标芯片只有 512KB SRAM。我天真地以为「优化一下就行」，结果第一版固件连开机动画都跑不完。嗯，从那以后，我再也不敢小看内存优化了。
1.1 为什么界面移植必须关注内存
嵌入式设备和 PC 最大的区别是什么？资源。PC 上 8GB 内存起步，嵌入式设备可能只有几百 KB 到几 MB。界面库本身就要占一大块，再加上字体缓存、图片解码、控件树、事件队列……稍不注意就爆了。
我总结过三个核心原因：
- 硬件天花板：芯片选型定了，内存就焊死在 PCB 上了。后期加不了，只能省着用。
- 实时性要求：界面卡顿 100ms，用户就骂娘。内存碎片多了，malloc 耗时飙升，直接拖垮帧率。
- 成本敏感：多 1MB 内存，BOM 成本可能涨 0.5 美金。量产 10 万片就是 5 万美金——老板会找你谈话的。
核心观点：界面移植的本质，是用有限的内存，跑出流畅的交互。内存不是「够用就行」，而是「每一字节都要算清楚」。
1.2 常见的内存瓶颈分析
我在项目中遇到过各种各样的内存问题。归纳起来，无非这几类：
| 瓶颈类型 | 典型表现 | 根因 |
|---|---|---|
| 静态内存超限 | 编译报错，链接失败 | 全局变量、常量数组、字体表太大 |
| 堆内存碎片 | 运行一段时间后 malloc 失败 | 频繁申请/释放小块内存，碎片化严重 |
| 栈溢出 | 函数调用深时死机 | 递归调用、局部大数组、中断嵌套 |
| 显存不足 | 画面撕裂、刷新不全 | 帧缓冲区分配不合理，或双缓冲开销过大 |
| 缓存未命中 | 界面操作响应慢 | 数据布局不连续，CPU 频繁 cache miss |
为什么会这样？我举个例子。有个同事移植 LVGL 到 STM32F4 上，界面里用了 20 张 100x100 的 ARGB8888 图片。每张 40KB，20 张就是 800KB。芯片总共才 1MB Flash，代码占一半，剩下 500KB 根本塞不下。最后只能把图片压缩成 RLE 格式，运行时解压——代价是 CPU 多花 3ms 每帧。
避坑指南：我曾经在一个项目里，把字体表定义成全局数组，结果 .rodata 段直接爆了。后来才发现，用字库裁剪工具把不需要的字符去掉，体积能省 60%。记住：不要「全量包含」，要「按需加载」。
1.3 优化目标设定
优化不是瞎搞。你得先定目标，再动手。我个人习惯用「三层目标法」：
- 硬性指标：不能超过芯片的物理内存上限。比如 SRAM 只有 256KB，那你的堆+栈+全局变量总和必须 ≤ 256KB。
- 性能指标：界面刷新率 ≥ 30fps，malloc 耗时 ≤ 1ms，栈使用率 ≤ 70%。
- 可维护指标：代码改动量 ≤ 20%，优化后仍能方便地添加新控件。
你想想看，如果只盯着「省内存」，把代码改得面目全非，后期维护成本反而更高。我见过有人为了省 2KB，把整个事件循环改成状态机，结果加一个新按钮要改 5 个文件——得不偿失。
我的建议：先跑一次内存分析工具（比如 GCC 的 -fstack-usage 和 map 文件分析），找到 TOP 3 的内存消耗点。集中精力解决这 3 个，通常能覆盖 80% 的问题。别一上来就搞微优化，那是最后一步的事。
1.4 知识体系总览
下面这张图，是我自己梳理的「界面移植内存优化」知识框架。后面 29 章，都会围绕它展开。
这张图我建议你保存下来。每次遇到内存问题，先定位它在哪个分支，再对症下药。别眉毛胡子一把抓——这是我用几次加班换来的教训。
1.5 本章小结
这一章我们聊了三件事：
- 为什么界面移植必须关注内存——硬件天花板、实时性、成本，一个都不能少。
- 常见瓶颈有哪些——静态超限、堆碎片、栈溢出、显存不足、缓存未命中。每个都有典型症状。
- 怎么设定优化目标——硬性指标、性能指标、可维护指标，三层缺一不可。