LVGL 图像架构解析：缓存、解码器与数据类型
各位好，欢迎来到第二章。上一章我们搭好了 RT1052 的硬件环境，这一章咱们得把 LVGL 的图像架构彻底搞明白。说白了，你要是不理解 LVGL 怎么管理图片，后面做外部存储加载肯定会踩坑。我自己刚开始做 LVGL 项目时，就因为没搞懂缓存机制，图片加载慢得让人抓狂。
LVGL 图像缓存机制
LVGL 的图像缓存，核心目的就一个：减少重复解码。你想想看，如果每次刷新屏幕都要重新解码一张 JPEG 图片，那 CPU 得累死。LVGL 的做法是把解码后的图像数据暂存起来，下次再用就直接从缓存拿。
核心要点：LVGL 缓存是“解码后”的缓存，不是原始文件缓存。它存的是 RGB 像素数据，不是 JPEG/PNG 文件本身。
LVGL 的缓存机制分两层：
- 全局缓存（Global Cache）：所有图像共享，由
lv_img_cache_set_size()设置大小。我习惯把它设成 1~2 个全屏帧缓冲的大小。 - 局部缓存（Local Cache）：每个图像对象自己的缓存，默认关闭。需要手动调用
lv_img_cache_enable()开启。
这里有个关键参数——缓存条目数。LVGL 默认只缓存 1 张图片。如果你同时显示多张图，旧的会被踢出去。我在项目里遇到过这种情况：一个仪表盘界面有 6 张图标，结果每次切换页面都要重新解码，卡得不行。后来我把缓存条目数改成 8，问题就解决了。
我的建议：缓存条目数 = 你界面上同时显示的图片数量 + 2。别设太大，RT1052 的 RAM 很宝贵。
图像解码器（Decoder）原理
解码器是 LVGL 图像架构的灵魂。它负责把原始图像文件（JPEG、PNG、BMP 等）转换成 LVGL 能直接渲染的像素数据。LVGL 内置了解码器框架，你可以注册自己的解码器。
解码器的工作流程是这样的：
- 识别格式：根据文件头或扩展名判断图像类型
- 打开图像：读取文件信息，分配内存
- 解码数据：把压缩数据解压成 RGB 像素
- 缓存结果：把解码后的数据放入缓存
LVGL 默认支持 BMP、GIF、PNG、JPEG 等格式。但注意，PNG 和 JPEG 需要额外启用解码库。PNG 要用 lv_libpng，JPEG 要用 lv_libjpeg。我记得第一次用 LVGL 加载 JPEG 图片时，忘了链接 libjpeg 库，结果图片显示不出来，排查了半天才发现是解码器没注册。
避坑指南：我曾经在 RT1052 上同时启用 PNG 和 JPEG 解码器，结果内存爆了。这两个解码库都很吃 RAM，建议只保留你真正需要的格式。
解码器的核心结构体是 lv_img_decoder_t，它包含三个回调函数：
| 回调函数 | 作用 | 注意事项 |
|---|---|---|
info_cb |
获取图像宽高、格式等基本信息 | 不要在这里解码全部数据 |
open_cb |
打开并解码图像 | 分配内存，返回解码后的数据 |
close_cb |
释放解码资源 | 别忘了释放内存，否则会泄漏 |
如果你要加载外部存储的图片，通常需要自己实现 open_cb。因为 LVGL 默认的文件读取接口是针对内部文件系统的，外部存储（比如 SPI Flash、SD 卡）需要你封装一层。
图像数据类型：LV_IMG_SRC_VARIABLE 与 LV_IMG_SRC_FILE
LVGL 支持两种图像数据来源：变量和文件。理解它们的区别，能帮你做出正确的设计决策。
LV_IMG_SRC_VARIABLE（变量图像）
图像数据直接编译进固件，以 C 数组的形式存在。比如：
const lv_img_dsc_t my_image = {
.header.always_zero = 0,
.header.w = 100,
.header.h = 80,
.data_size = 100 * 80 * LV_COLOR_DEPTH / 8,
.header.cf = LV_IMG_CF_TRUE_COLOR,
.data = my_image_data
};这种方式的优点是加载速度极快，数据就在 Flash 里，不需要任何 I/O 操作。缺点是占用固件空间，一张 320x240 的 16 位色图片就要 150KB 左右。RT1052 的内部 Flash 通常只有 4MB，放不了几张图。
我的习惯：把启动 Logo、关键图标这类必须立即显示的图片用变量方式。其他图片都放外部存储。
LV_IMG_SRC_FILE（文件图像）
图像数据存储在文件系统中，运行时通过路径加载：
lv_img_set_src(img_obj, "S:/images/photo.bmp");文件图像的优点是灵活，可以随时更换图片内容，不占用固件空间。缺点是加载速度慢，需要经过文件系统读取、解码等步骤。
两种方式的对比：
| 特性 | LV_IMG_SRC_VARIABLE | LV_IMG_SRC_FILE |
|---|---|---|
| 存储位置 | 固件内部 Flash | 外部存储（SD卡、SPI Flash等） |
| 加载速度 | 极快（纳秒级） | 较慢（毫秒级，取决于存储介质） |
| 灵活性 | 差（需重新编译固件） | 好（可随时替换文件） |
| 内存占用 | 运行时无需额外内存 | 解码时需要临时内存 |
| 适用场景 | 小图标、启动画面 | 大图、动态内容 |
这里有个容易忽略的点：文件路径的格式。LVGL 的文件系统接口是抽象层，路径前缀对应不同的存储设备。比如 S: 可能对应 SD 卡，F: 对应 SPI Flash。我在项目中就吃过这个亏，路径写错了，图片死活加载不出来。
避坑指南：我曾经在 RT1052 上同时挂载了 SD 卡和 SPI Flash，结果两个设备的路径前缀搞混了。建议在初始化文件系统时，用 LV_FS_xxx 宏明确指定前缀，并在代码里统一管理。
图像架构整体流程
下面这张图展示了 LVGL 图像从加载到显示的整体流程。我把它画出来，方便你理解各个组件之间的关系。
从流程图可以看出，变量图像和文件图像最终都会经过解码器。区别在于：变量图像的数据已经在内存里，解码器直接处理；文件图像需要先通过文件系统读取数据，再交给解码器。缓存层位于解码器和显示渲染之间，如果缓存命中，解码步骤就被跳过了。
本章小结
这一章我们拆解了 LVGL 的图像架构。记住三个关键点：
- 缓存机制：减少重复解码，但要注意缓存条目数的设置
- 解码器原理：理解 info_cb、open_cb、close_cb 三个回调的作用
- 数据类型选择：变量图像快但占固件空间，文件图像灵活但加载慢