1. LVGL 内存全景：内存池、动态分配、静态分配与碎片化问题
做嵌入式 UI 开发，说白了就是在跟内存打交道。LVGL 再漂亮，内存一崩，啥都白搭。我刚开始用 LVGL 时，就吃过内存不足的亏——界面画到一半，系统直接 HardFault。后来我才意识到，搞懂 LVGL 的内存模型，是优化的第一步。
这一章，咱们把 LVGL 的内存全景摊开来看。内存池、动态分配、静态分配、碎片化，这四个概念搞清楚了，后面优化才有方向。
1.1 LVGL 内存架构总览
LVGL 的内存管理，其实就三层：
- 底层内存池：你给 LVGL 划一块连续 RAM，它自己管。
- 中间分配层：提供
lv_mem_alloc、lv_mem_free等接口。 - 上层对象/资源：控件、样式、图片、字体，都通过分配层拿内存。
我习惯把这三层画成一张图，方便团队新人理解。下面这张 SVG 就是 LVGL 内存架构的核心逻辑：
核心要点：LVGL 的内存池大小由 LV_MEM_SIZE 决定，默认 32KB。这个值设小了，界面复杂时直接分配失败；设大了，RAM 不够用。我一般先按预估最大使用量的 1.5 倍来设，跑起来后再用监控工具微调。
1.2 内存池：LVGL 的私有金库
LVGL 默认不直接用系统的 malloc，而是自己维护一个内存池。为什么？
- 确定性：嵌入式系统里，标准
malloc的行为不可控，碎片化严重。 - 可预测：LVGL 的内存池大小固定，分配失败时能立刻知道，不会拖垮系统。
- 轻量：LVGL 内置的分配器代码量小，适合资源受限的 MCU。
配置方式很简单，在 lv_conf.h 里：
/* 使用 LVGL 内置内存分配器 */
#define LV_MEM_CUSTOM 0
/* 内存池大小，单位字节 */
#define LV_MEM_SIZE (32 * 1024) /* 32KB */
/* 内存对齐，一般 4 字节或 8 字节 */
#define LV_MEM_ATTR
#define LV_MEM_POOL_INCLUDE
#define LV_MEM_POOL_EXTERN如果你想让 LVGL 用系统的 malloc，把 LV_MEM_CUSTOM 设为 1 就行。但我个人不建议这么做——除非你的 RTOS 内存管理非常优秀，否则碎片化问题会让你头疼。
我的经验：在 STM32F429 上跑 LVGL，我习惯设 LV_MEM_SIZE 为 48KB。这个值够跑一个中等复杂的仪表盘界面，同时给系统其他任务留了足够空间。如果 RAM 紧张，可以降到 24KB，但需要精打细算。
3. 动态分配：灵活但需谨慎
LVGL 里大部分对象都是动态分配的。你创建一个按钮：
lv_obj_t *btn = lv_btn_create(lv_scr_act()); // 内部调用 lv_mem_alloc这个 btn 指针指向的内存，就是从 LVGL 内存池里动态分配的。动态分配的好处是灵活——用多少拿多少，用完释放。但坏处也很明显：
- 分配耗时：频繁分配释放会拖慢 UI 响应。
- 碎片化：这是最大的坑，后面单独讲。
- 内存泄漏：忘了
lv_obj_del，内存就丢了。
我记得有一次，项目里动态创建了上百个标签控件，每个标签都带自定义样式。跑了一天，界面突然卡死。一查，内存池只剩 200 字节了——全是碎片。
避坑指南：动态分配不是不能用，但要控制频率。我一般只在界面初始化时做动态分配，运行期间尽量复用已有对象。如果你需要在运行时频繁创建/销毁控件，考虑用 lv_obj_clean 清空内容而不是删除重建。
1.4 静态分配：性能与安全的平衡点
静态分配，说白了就是提前把内存准备好，运行时不再动态申请。LVGL 支持两种静态分配方式：
| 方式 | 说明 | 适用场景 |
|---|---|---|
| 全局变量 | 直接定义 lv_obj_t my_btn，但 LVGL 对象通常需要指针，所以用得少 |
极简界面，对象数量固定 |
| 静态缓冲区 | 用 static uint8_t buf[1024] 作为图片或字体的临时存储 |
图片解码、字体渲染 |
| LVGL 静态创建 | 通过 lv_obj_create_from_addr 等接口，从指定地址创建对象 |
内存极度受限的场景 |
静态分配的好处是零碎片、零分配耗时。但缺点也很实在——不够灵活，界面变了得改代码。
我个人的习惯是：核心控件用静态分配，动态控件用动态分配。比如主界面上的标题栏、底部导航栏，这些一直存在的控件，我直接静态分配。而弹窗、列表项这些可能动态增减的，用动态分配。
1.5 碎片化问题：隐形内存杀手
碎片化，是 LVGL 内存管理里最让人头疼的问题。你明明还有 10KB 空闲内存，但申请一个 2KB 的缓冲区却失败了——因为空闲内存被分割成了几十个小块，没有一块连续空间超过 2KB。
为什么会这样？
你想想看，LVGL 里各种对象大小不一：一个按钮可能占 80 字节，一个图片描述符可能占 200 字节，一个字体位图可能占 4KB。频繁分配释放后，内存就像被狗啃过一样，到处都是洞。
碎片化的典型表现：
- 系统运行一段时间后，UI 响应变慢。
- 偶尔出现控件创建失败，但重启后又正常。
- 内存监控显示空闲总量充足，但最大连续块很小。
如何监控碎片化？ LVGL 提供了 lv_mem_monitor_t 结构体，可以实时查看内存使用情况：
lv_mem_monitor_t mon;
lv_mem_monitor(&mon);
LV_LOG_USER("used: %d, free: %d, frag: %d%%",
mon.total_size - mon.free_size,
mon.free_size,
mon.frag_pct);其中 frag_pct 就是碎片率。我一般要求碎片率不超过 20%，超过这个值就要考虑优化了。
我曾经在一个项目里遇到过碎片率飙到 60% 的情况。排查下来，是因为一个定时器每 100ms 就动态创建和销毁一个临时标签。后来改成复用同一个标签，碎片率直接降到 5%。
1.6 三种分配策略的对比
为了让你更直观地理解，我把三种方式放在一起对比：
| 特性 | 内存池（内置分配器） | 动态分配（malloc） | 静态分配 |
|---|---|---|---|
| 分配速度 | 快（O(1) 或 O(n) 取决于算法） | 中等（依赖 libc 实现） | 零耗时（编译时已确定） |
| 碎片化风险 | 中（可通过内存池大小控制） | 高（系统堆碎片不可控） | 无 |
| 灵活性 | 高 | 高 | 低 |
| 内存利用率 | 中（有内部碎片） | 中 | 高（无额外开销） |
| 调试难度 | 低（LVGL 自带监控） | 高（需要外部工具） | 低 |
| 推荐场景 | 大多数 LVGL 项目 | RTOS 内存管理优秀时 | 内存极受限、对象固定 |
看到这个表，你可能会问：那我到底该用哪种？
嗯，我的建议很简单：默认用 LVGL 内置内存池，除非你有充分的理由切换到系统 malloc。静态分配作为补充，用在那些生命周期跟整个应用一样长的对象上。
小技巧：如果你发现碎片化严重，可以试试把 LV_MEM_SIZE 增大 20%-30%。虽然治标不治本，但能快速缓解问题。真正的根治方法，我们会在后面的章节里详细讲——包括内存池调优、对象复用、以及自定义分配器。