1. 内存基础与瓶颈分析：嵌入式系统内存架构
做嵌入式GUI优化，第一件事不是看代码，而是搞清楚你的内存到底长什么样。我见过太多人上来就调显存、改缓存策略，结果连SRAM和DRAM的区别都没弄明白——说白了，方向错了。
这一节，咱们把内存的底裤扒干净。
1.1 嵌入式系统的三种内存
嵌入式设备里，内存就三种：SRAM、DRAM、Flash。它们各有各的脾气。
| 类型 | 速度 | 容量 | 掉电保持 | 典型用途 |
|---|---|---|---|---|
| SRAM | 极快（~ns级） | 小（KB~MB） | 否 | CPU缓存、显存、关键变量 |
| DRAM | 较快（~几十ns） | 大（MB~GB） | 否 | 主内存、帧缓冲、堆区 |
| Flash | 慢（~us级读/ms级写） | 大（MB~GB） | 是 | 代码存储、字库、图片资源 |
嗯，这里要注意：SRAM虽然快，但贵且容量小。我做过一个智能手表项目，MCU内部SRAM只有256KB，GUI跑起来直接爆了。后来不得不把一部分显存挪到外部DRAM，但DRAM刷新有延迟，画面偶尔会闪。这就是典型的「内存选型没想清楚」的坑。
核心结论：GUI的实时渲染数据（显存、图层、脏矩形）必须放在SRAM或快速DRAM里；静态资源（图片、字体）可以放Flash，但读取时要考虑延迟。
1.2 GUI内存占用模型
一个GUI系统，内存都花在哪了？我习惯把它拆成四块：
- 显存（Frame Buffer）：最吃内存的地方。一个800×480的屏幕，32位色，光显存就吃掉800×480×4 ≈ 1.5MB。你想想看，很多MCU总共才几MB内存。
- 图层缓冲区（Layer Buffer）：如果你做双缓冲或三缓冲，内存直接翻倍。我建议非必要不用三缓冲，除非你的屏幕刷新率要求很高。
- 控件对象（Widget Object）：每个按钮、标签、列表都是一个结构体。我见过一个项目，光按钮就定义了200多个，每个按钮结构体里塞了回调函数指针、坐标、颜色、字体句柄……加起来轻松上百KB。
- 资源缓存（Resource Cache）：字体位图、图片解码后的数据、图标缓存。这部分最容易失控——你永远不知道用户会在界面上放多少张图。
我的经验：做GUI内存预算时，先算显存，再算控件对象，最后留20%余量给缓存和堆碎片。我曾经因为没留余量，产品运行三天后内存碎片导致界面卡死——那叫一个惨。
1.3 常见内存泄漏场景
内存泄漏在嵌入式GUI里太常见了。我总结了几种「必死」场景：
- 动态创建控件不释放：很多人用
lv_obj_create()或GUI_ButtonCreate()，但忘了在页面切换时lv_obj_del()。每次切换页面，内存涨一点，直到系统崩掉。 - 图片解码缓存没清：解码一张JPEG或PNG，临时缓冲区可能占几百KB。如果你频繁切换图片，又不主动释放解码上下文，内存很快见底。
- 字体缓存无限增长：有些GUI库会缓存渲染过的字符位图。如果你用了动态字体（比如TTF），且不限制缓存大小，用户输入100个不同字符，缓存就膨胀100次。
- 回调函数闭包泄漏：在C语言里不常见，但如果你用了C++的lambda或std::function绑定到控件事件上，且控件生命周期管理不当，闭包捕获的变量永远不会释放。
避坑指南：我曾经在一个车载仪表项目里，发现每次切换菜单内存涨2KB。查了两天，最后发现是一个列表控件的「选中高亮」效果里，每次都会malloc一个临时颜色缓冲区，但只在控件销毁时才free。而那个列表控件在整个生命周期里从未被销毁——它只是被隐藏了。嗯，从那以后，我所有GUI代码都强制加一条规则：谁创建，谁销毁；谁隐藏，谁负责。
1.4 嵌入式GUI内存架构全景图
下面这张图，是我自己画的内存架构关系。你看一眼，就能明白数据怎么流动、瓶颈在哪。
这张图你看懂了吗？说白了，数据从Flash搬到DRAM，再从DRAM搬到SRAM，最后喂给显示控制器。每一步都有代价——延迟、带宽、功耗。优化的本质就是减少不必要的搬运，以及让搬运路径更短。
1.5 小结
这一节我们聊了嵌入式系统的三种内存、GUI的四大内存消耗模块，以及四个最常见的泄漏场景。你可能会觉得内容有点多，但这些都是后面所有优化技巧的基础。
我个人习惯，每接手一个GUI项目，第一件事就是画一张类似上面的内存架构图，标出每个模块占多少内存、数据怎么流动。然后拿着这张图去跟硬件工程师吵架——「你看，SRAM不够，得加钱！」