4. 图片解码原理：软件解码 vs 硬件解码、解码器选择策略、解码过程中的内存开销
说到图片解码，很多嵌入式工程师第一反应就是「调个库就完事了」。嗯，早期我也是这么干的。直到有一次，我在一个跑着 FreeRTOS 的 Cortex-M4 项目里，用软件解码一张 800×480 的 JPEG 开机图，结果系统卡了整整 3 秒才显示出来——那感觉，就像按了开关等灯泡慢慢亮起来一样。
从那以后，我彻底明白了：解码不是「能不能解」的问题，而是「怎么解才不拖后腿」的问题。这一章，我们就来把解码这件事掰开揉碎。
4.1 软件解码 vs 硬件解码：到底差在哪？
先看一张我画的对比图，帮你快速建立整体认知：
说白了，软件解码就是用 CPU 硬算。JPEG 的 Huffman 解码、IDCT 变换、颜色空间转换，全在 CPU 里跑。硬件解码呢？芯片里集成了一个专门的解码模块，你给它压缩数据，它直接输出 RGB 像素，CPU 只需要发个启动命令。
核心结论：软件解码吃 CPU，硬件解码吃面积。选哪个，取决于你的 CPU 还有多少余量。
4.2 解码器选择策略：不是越新越好
我见过不少工程师，一上来就选最新的解码库，觉得功能全、性能好。结果呢？库太大，ROM 装不下；或者依赖太多，移植到 RTOS 上各种报错。
我个人习惯，选解码器就三个维度：
- ROM/RAM 预算——库本身占多大？运行时需要多少临时缓冲区？
- 解码速度要求——是开机显示一次，还是每秒 60 帧的动画？
- 图片格式覆盖——只解 JPEG？还是 PNG、GIF、BMP 都要？
下面这张表，是我在实际项目中常用的解码方案对比：
| 解码方案 | ROM 占用 | RAM 开销 | 解码速度 | 适用场景 |
|---|---|---|---|---|
| stb_image.h | ~40 KB | 低（单行缓冲） | 中等 | 原型验证、低分辨率 GUI |
| libjpeg-turbo | ~120 KB | 中（需 2~4 行缓冲） | 快（SIMD 优化） | Cortex-A 系列、Linux 平台 |
| 硬件解码器 IP | 0（库） | 低（仅帧缓冲） | 极快 | STM32MP1、i.MX RT 系列 |
| 轻量级 JPEG 解码 | ~15 KB | 极低（逐 MCU 解码） | 慢 | MCU 裸机、资源极度受限 |
我的经验：如果芯片有硬件解码器，优先用硬件。别自己折腾软件优化——硬件解码器的功耗和速度优势，软件再怎么优化也追不上。我曾经在一个 i.MX RT1060 项目里，硬件解码一张 1024×600 的 JPEG 只需要 8ms，而软件解码用了 120ms，差距超过 10 倍。
4.3 解码过程中的内存开销：藏在哪？
很多人以为解码就是「读文件 → 出像素」，内存开销就是一张位图的大小。其实没那么简单。你想想看，解码过程中至少有三个地方在吃内存：
- 压缩数据缓冲区——存放从 Flash 或文件系统读出来的 JPEG/PNG 原始数据
- 解码中间缓冲区——JPEG 的 MCU 行缓冲、Huffman 表、量化表、IDCT 临时矩阵
- 帧缓冲——最终输出的 RGB 像素数据
举个例子，一张 800×480 的 JPEG 图片：
- 压缩数据：通常 50~200 KB（取决于压缩率）
- 中间缓冲区：libjpeg 默认需要 2~4 行 MCU 缓冲，约 8~16 KB
- 帧缓冲：800 × 480 × 2（RGB565）= 768 KB
总开销接近 1 MB。如果你的芯片只有 512 KB RAM，那就得想办法了。
我曾经踩过的坑：在一个 STM32F429 项目里，我直接用 libjpeg 解码一张 480×272 的 JPEG，结果 malloc 失败。查了半天才发现，libjpeg 默认会申请一个完整的帧缓冲，而我的堆空间不够。后来改成逐行解码 + 直接写入 LCD 的 SDRAM，才把问题解决。
4.4 如何降低解码内存开销？
这里分享几个我常用的手段：
- 逐行/逐块解码——不解全图，解一行显示一行。stb_image 支持
stbi_load_from_memory配合回调，libjpeg 也有jpeg_read_scanlines。 - 直接输出到显示缓冲区——解码器的输出目标直接指向 LCD 的显存地址，省掉一次内存拷贝。
- 使用 RGB565 而非 RGB888——像素大小减半，视觉差异在嵌入式屏幕上几乎看不出来。
- 预解码到外部 Flash——如果图片是固定的开机画面，在量产前用 PC 工具解码成 raw 数据，直接烧录到 SPI Flash。运行时只需要 memcpy，零解码开销。
一句话总结：解码内存开销 = 压缩数据 + 中间缓冲 + 帧缓冲。想省内存，就从「减少中间缓冲」和「复用帧缓冲」入手。
4.5 实战建议：什么时候选什么方案？
最后，我根据自己的项目经验，给你一个快速决策指南：
- MCU 裸机，RAM < 256 KB：用轻量级 JPEG 解码器，逐 MCU 解码，直接输出到 LCD。别用 libjpeg，它太胖了。
- MCU + RTOS，RAM 256 KB ~ 1 MB：用 stb_image 或 libjpeg-turbo，配合逐行解码。如果芯片有硬件解码器，果断用。
- MPU + Linux，RAM > 64 MB：用 libjpeg-turbo 或硬件解码器。这时候内存不是瓶颈，速度才是。
- 开机画面/固定图片：预解码成 raw 数据，直接烧录到 Flash。运行时零解码，零内存开销。
嗯，解码这件事，说复杂也复杂，说简单也简单。关键是搞清楚你的瓶颈在哪——是 CPU 不够快？还是 RAM 不够大？对症下药，才能把性能榨出来。