📚 课程目录第3章镜像压缩核心原理

3. 镜像压缩核心原理

OTA 镜像压缩不是“把文件压小”这么简单。它发生在固件构建、差分生成、传输、设备端落盘与升级校验的完整链路中，任何一次压缩策略的选择，都会同时影响包体大小、解压耗时、内存峰值、Flash 写入量以及升级失败后的回滚成本。理解镜像压缩的核心原理，关键在于把“压缩算法”放回 OTA 的真实约束里去看。

一、压缩算法分类：从字典、熵编码到混合编码

镜像压缩算法通常可以按编码机制分为几类。第一类是字典压缩，代表是 LZ77/LZ4/Zstandard 中的 LZ 系列，它通过滑动窗口查找重复字节序列，用“距离+长度”替代重复内容，适合镜像中大量重复的代码段、零填充和资源块。第二类是熵编码，如 Huffman、算术编码、rANS，它根据符号出现概率重新分配码长，适合压缩已经去除冗余后的数据。第三类是混合编码，如 DEFLATE、Zstandard、Brotli，把字典匹配与熵编码结合，在压缩比和解压速度之间取得不同平衡。

在 OTA 场景中，算法选择还要看“解压端”的能力。设备端可能只有几十 KB RAM，没有文件系统缓存，甚至解压过程要与 Flash 擦写并行。因此，压缩比最高的算法不一定最优，解压时能否流式处理、是否需要整块缓冲、是否支持随机访问，往往比压缩率更关键。

二、无损与有损压缩：镜像为什么几乎必须无损

无损压缩保证解压后数据与原始镜像逐字节一致，适用于可执行代码、文件系统元数据、签名信息、校验表等。有损压缩会丢弃部分信息，通常用于图像、音频、视频等允许误差的媒体数据。OTA 镜像的主体是固件，任何字节变化都可能导致校验失败、启动异常或安全签名不匹配，因此镜像压缩默认必须无损。

但“无损”并不等于“所有内容都同等对待”。在资源受限设备上，可以对镜像中的不同区域采用不同策略：代码段和关键配置使用强无损压缩；已压缩的图片、字体、音频资源可以跳过二次压缩，避免浪费 CPU；零填充区域可以用稀疏描述替代。这样既保持整体无损，又避免对不可压缩数据做无效劳动。

核心判断：OTA 镜像压缩的第一原则是“可逆且可校验”。任何有损手段只能作用于明确允许误差的媒体资源，且必须与签名、哈希、回滚机制隔离设计。

三、压缩比与解压速度权衡：没有免费午餐

压缩比、压缩速度、解压速度、内存占用四者构成典型的权衡关系。高压缩比算法通常需要更大的窗口、更复杂的匹配和更长的编码时间；解压速度则取决于算法是否支持流式解码、是否依赖大字典、是否需要多次遍历。对于 OTA，压缩发生在构建服务器，时间相对充裕；解压发生在设备端，时间、CPU 和内存都更紧张。因此，策略通常是“压缩端可以慢，解压端必须快”。

下面这张图展示了镜像压缩在 OTA 链路中的位置，以及压缩比、解压速度、内存峰值和 Flash 写入量之间的相互牵制关系。

从图中可以看到，压缩比提升会带来包体减小，但可能增加解压复杂度和内存峰值；解压速度提升有利于缩短升级窗口，但往往牺牲压缩率。真正合理的策略，是在设备资源、升级时限和传输成本之间找到可验证的平衡点。

四、镜像压缩的独特约束：与普通文件压缩的差异

OTA 镜像压缩与普通文件压缩最大的不同，在于它必须满足“升级过程本身不能变砖”。这带来几项独特约束：

断电安全：解压和写入过程中若掉电，必须保证旧镜像仍可启动，或至少能进入恢复模式。因此压缩包通常要分块、带校验，并支持断点续传或原子切换。
回滚可用：压缩后的镜像必须保留版本标识和回滚信息，不能因为压缩而丢失 A/B 分区切换所需的元数据。
签名与校验：压缩会改变字节布局，签名通常针对压缩后的包或解压后的镜像分别设计，必须明确校验顺序，避免“先解压后验签”带来的安全窗口。
Flash 寿命与写入放大：解压后写入量可能大于压缩包体积，若解压与擦写交错，可能增加写放大。分块压缩和按需解压可以缓解。
启动时间：若压缩镜像需要在启动时解压，解压速度直接影响开机时间，必须纳入启动预算。

五、方法流程与参数选择：从镜像到可升级包

一个可落地的镜像压缩流程通常包括：镜像分区划分、可压缩性分析、算法与块大小选择、压缩与校验生成、设备端解压验证、升级回滚测试。下面给出一个典型的参数配置示例，用于说明压缩块大小、算法级别和校验方式如何共同决定最终效果。

# 典型 OTA 镜像压缩参数示例
image:
  partitions:
    - name: boot
      compress: zstd
      level: 9
      block_size: 64KB
      checksum: crc32
    - name: system
      compress: lz4
      level: 3
      block_size: 256KB
      checksum: sha256
    - name: vendor
      compress: none
      reason: "已压缩资源，二次压缩收益低"
  verify:
    order: "decompress -> hash -> signature"
    rollback: "A/B slot + metadata"

在这个示例中，boot 分区体积小但关键，采用较高压缩级别和较小块，便于快速校验；system 分区体积大，采用 LZ4 换取更快解压；vendor 分区若本身已是压缩资源，则跳过压缩，避免 CPU 浪费。校验顺序明确为“先解压、再哈希、再验签”，确保安全边界清晰。

六、案例与误区复盘

某设备团队曾将 system 分区从 LZ4 切换到高压缩比算法，包体缩小了约 18%，但升级耗时从 42 秒增加到 79 秒，且部分低端机型在解压阶段出现内存不足重启。复盘发现，问题不在压缩算法本身，而在于没有评估设备端解压内存峰值和 Flash 写入节奏。后续改为“分块 Zstandard + 流式解压 + 双缓冲校验”，包体只缩小 11%，但升级耗时回落到 48 秒，失败率显著下降。

常见误区：只看压缩比，不看解压路径；对已压缩资源重复压缩；忽略断电和回滚场景；把签名校验放在解压之后却没有隔离信任边界。这些都会让“更小的包”变成“更高的升级风险”。

因此，镜像压缩的核心原理可以归纳为一句话：在无损、可校验、可回滚的前提下，用分块和流式策略，把压缩比、解压速度与内存峰值调到设备能承受的平衡点。理解这一点，后续的差分压缩、块级优化和升级性能调优才有稳定的判断基准。