图片格式与内存占用：BMP、PNG、JPEG 在 LVGL 中的真实代价

做嵌入式 UI 最怕什么？我最怕的是：界面画好了，一加载图片，系统直接卡死，或者内存溢出重启。嗯，这绝不是危言耸听。我在好几个项目里都踩过这个坑——明明代码逻辑没问题，偏偏就是图片把系统拖垮了。

今天我们就来扒一扒，BMP、PNG、JPEG 这三种最常见的图片格式，在 LVGL 里到底是怎么吃内存的。你可能会觉得「不就是个图片吗？能有多大差别？」——差别大了去了。

先搞清楚一个核心概念：解码后的内存占用

不管你的原始文件是 BMP、PNG 还是 JPEG，一旦被 LVGL 解码到内存里，它都会变成「裸数据」。说白了，就是每个像素点用 RGB565 或 ARGB8888 格式存下来。

举个例子：一张 320×240 的图片，如果用 RGB565（每像素 2 字节），解码后的内存占用是：

320 × 240 × 2 = 153,600 字节 ≈ 150 KB

这个数字跟原始文件大小没有半毛钱关系。你拿一个 10KB 的 PNG 和一个 200KB 的 BMP，解码后占的内存是一样的——都是 150KB。为什么？因为解码后的数据是「展开」的，压缩算法已经失效了。

BMP：简单粗暴，但内存效率并不差

BMP 格式几乎不压缩。我在早期一个项目里用过 BMP 做开机 logo，因为解码器最简单，几乎不占用额外的 RAM 缓冲区。

BMP 在 LVGL 中的特点：

• 解码器极简：LVGL 内置的 BMP 解码器几乎不需要额外的内存缓冲区，直接逐行读取像素数据。
• 解码速度快：没有解压计算，CPU 开销极低。
• 文件体积大：一张 320×240 的 BMP 文件大约 225KB（24位色），是 PNG 的 5~10 倍。
• 内存占用：解码后 = 分辨率 × 每像素字节数，没有额外开销。

但要注意：BMP 不支持透明度（Alpha 通道）。如果你需要做图标叠加、圆角遮罩，BMP 就无能为力了。

PNG：功能强大，但解码内存是隐形杀手

PNG 是嵌入式 UI 里最常用的格式。支持透明、无损压缩、色彩丰富。但它的代价也很明显——解码时需要额外的内存缓冲区。

LVGL 的 PNG 解码器（基于 lodepng 库）工作流程是这样的：

1. 读取压缩的 PNG 文件到内存缓冲区（文件大小）。
2. 分配一个临时缓冲区用于解压 IDAT 数据块（约等于原始图像数据大小）。
3. 解压完成后，将数据写入最终的显示缓冲区。

这意味着，解码一张 320×240 的 PNG 图片，实际占用的峰值内存可能是：

文件缓冲区（假设 30KB） + 解压临时缓冲区（150KB） + 最终显示缓冲区（150KB） ≈ 330KB

你看，比 BMP 多了一倍。我在一个 STM32F429 项目里就吃过这个亏——同时加载 3 张 PNG 图标，内存直接爆了。

JPEG：压缩率高，但解码开销更大

JPEG 的压缩率是三种格式里最高的。一张 320×240 的照片，JPEG 可能只有 15~30KB。但它的解码器也是最「重」的。

LVGL 的 JPEG 解码器（基于 TinyJPEG 或 libjpeg-turbo）需要：

• 至少 2~3 行的 MCU（最小编码单元）缓冲区。
• IDCT 变换的临时矩阵。
• 色彩空间转换（YCbCr → RGB）的中间缓冲区。

实际测试下来，JPEG 解码的峰值内存大约是：

文件缓冲区（20KB） + 解码工作区（约 50~80KB） + 最终显示缓冲区（150KB） ≈ 220~250KB

比 PNG 略低，但解码速度慢很多。我在一个需要轮播图片的项目里试过，JPEG 解码一张 800×480 的图片，在 180MHz 的 Cortex-M4 上花了将近 200ms——这还没算 DMA 传输的时间。

三种格式的对比表格

对比维度	BMP	PNG	JPEG
文件体积（320×240）	~225KB	~30~80KB	~15~30KB
解码后内存	150KB	150KB	150KB
解码峰值内存	~150KB	~330KB	~250KB
解码速度	极快（微秒级）	中等（毫秒级）	慢（几十~几百毫秒）
透明度支持	不支持	支持（Alpha 通道）	不支持
适用场景	小尺寸图标、开机 logo	图标、按钮、UI 元素	照片、背景图、大尺寸图片

LVGL 内置解码器的局限性

说实话，LVGL 自带的图片解码器只能算「能用」，远谈不上「好用」。我总结了几点：

• BMP 解码器：只支持 24 位和 32 位 BMP，不支持 RLE 压缩的 BMP。如果你从网上随便下载一个 BMP，很可能解码失败。
• PNG 解码器：基于 lodepng，功能完整但性能一般。不支持渐进式解码，必须一次性加载完整文件。对于大图（比如 1024×768），解码时间可能超过 1 秒。
• JPEG 解码器：只支持基线 JPEG，不支持渐进式 JPEG。色彩空间只支持 YCbCr，不支持 CMYK 或灰度 JPEG。解码速度受限于 MCU 频率，在低主频芯片上表现不佳。
• GIF 解码器：只支持静态 GIF，不支持动画。嗯，你没看错——LVGL 的 GIF 解码器其实只能显示第一帧。

一张图看懂图片格式与内存的关系

下面这张 SVG 图，把三种格式从「文件存储」到「解码显示」的完整链路画出来了。你可以直观地看到，内存峰值出现在哪个环节。

实际项目中的选择策略

说了这么多，到底该怎么选？我个人的经验是：

• 图标、按钮、小尺寸 UI 元素：用 PNG。支持透明，文件不大，解码速度可以接受。如果 RAM 紧张，可以预解码成 RGB565 的 bin 文件，用 lv_img_dsc_t 直接加载。
• 全屏背景、照片、大图：用 JPEG。文件小，省 Flash 空间。但要注意解码速度，建议在后台任务里解码，或者用 DMA2D 加速。
• 开机 logo、启动画面：用 BMP。解码最快，系统还没完全启动就能显示出来。我习惯把 BMP 直接烧录到外部 Flash 的固定地址，用内存映射方式读取。
• 动画帧序列：别用 GIF。LVGL 的 GIF 解码器只支持静态帧。建议用 PNG 序列或者直接使用 LVGL 的 lottie 动画方案。