2. OTA基础概念
在讨论镜像压缩之前，必须先建立对 OTA 升级全链路的统一认知。镜像压缩并不是孤立的技术动作，它嵌入在“制作—传输—校验—写入—激活”的完整流程中，压缩策略的选择会直接影响传输时长、存储占用、校验开销与回滚能力。本节从升级流程、镜像组成、传输与存储机制、性能指标四个维度建立基础坐标系。
一、OTA升级流程：从版本包到生效
一次典型的 OTA 升级可以拆解为六个阶段：版本构建、包分发、下载、校验、写入与激活。不同阶段对镜像的形态要求不同，压缩通常发生在构建与分发阶段，而解压可能发生在下载后、写入前，甚至在写入过程中流式进行。
- 版本构建：编译产出系统镜像、应用镜像、资源镜像，并生成元数据清单（manifest）。
- 包分发：将镜像打包为 OTA 包，可能采用整包或差分包形式，并附带签名与哈希。
- 下载：设备端通过 HTTP/HTTPS、MQTT 或 P2P 等方式获取包体，受网络带宽与稳定性影响。
- 校验：对包体或分片进行哈希、签名验证，确保完整性与来源可信。
- 写入：将镜像写入 A/B 分区或恢复分区，可能涉及解压、解密与对齐。
- 激活：切换启动标志，重启进入新版本，失败则回滚到旧分区。
关键认知：压缩发生在“构建—分发”环节，但解压成本会转移到设备端。压缩率越高，传输越省，但解压 CPU 与内存开销可能越大，必须结合设备算力权衡。
二、镜像文件组成：不只是一个大文件
OTA 包通常由多个逻辑部分组成，理解其结构有助于判断哪些部分适合压缩、哪些部分必须保持原样。常见组成包括：
| 组成部分 | 作用 | 是否适合压缩 |
|---|---|---|
| 元数据清单 | 描述版本、分区、哈希、签名信息 | 通常不压缩，需快速读取 |
| 系统镜像 | 包含内核、根文件系统、驱动 | 适合，压缩收益高 |
| 应用镜像 | 业务 APK、二进制、资源文件 | 适合，但需注意已压缩资源 |
| 差分包 | 仅包含新旧版本差异 | 适合，但需先解压再打补丁 |
| 签名与证书 | 保证来源可信与完整性 | 不可压缩，需保持原格式 |
镜像内部通常按分区组织，例如 boot、system、vendor、userdata 等。压缩可以针对单个分区独立进行，也可以对整个包体统一压缩。独立压缩便于按需解压，统一压缩则压缩率更高但解压粒度粗。
三、镜像传输与存储机制
传输与存储是压缩收益最直接体现的环节。传输侧关注带宽占用与断点续传，存储侧关注分区容量与写入寿命。常见的传输机制包括分片下载、断点续传、并行下载与 P2P 分发；存储机制则涉及 A/B 双分区、恢复分区、缓存分区与外部存储。
# 典型 OTA 包结构示意
ota_package.zip
├── manifest.json # 版本、分区、哈希
├── payload.bin # 压缩后的镜像数据
├── payload_properties.txt # 压缩算法、偏移、大小
└── metadata.signature # 签名文件
在 A/B 分区方案中，新镜像写入非活动分区，压缩后的镜像在写入前解压，或直接以压缩形态存储、启动时解压。若采用流式解压，可减少峰值存储占用，但对解压速度与顺序有要求。存储介质为 eMMC/UFS 时，写入放大与擦写寿命也需纳入考量，过度压缩可能增加解压时的内存占用，反而影响写入稳定性。
实践提示：对于资源受限设备，建议对 system 与 vendor 分区分别压缩，保留 manifest 与签名不压缩，以便快速校验与断点续传。
四、常见OTA性能指标
衡量 OTA 性能不能只看“包变小了”，而应建立多维指标体系。以下指标在镜像压缩优化中最为常用：
- 包体大小：压缩后总字节数，直接影响下载流量与分发成本。
- 压缩率：原始大小与压缩后大小的比值，反映压缩算法效率。
- 下载时长：受带宽、分片策略与服务器响应影响。
- 解压耗时：设备端解压 CPU 时间，影响升级总时长。
- 峰值内存：解压过程中占用的最大内存，决定低端设备可行性。
- 写入耗时：解压后写入分区的耗时，与存储介质性能相关。
- 升级成功率：端到端成功比例，受校验、回滚与异常恢复影响。
- 回滚耗时：升级失败后恢复旧版本的时间。
这些指标之间存在权衡关系。例如，使用高压缩比算法可降低包体大小与下载时长，但可能增加解压耗时与峰值内存；使用差分包可进一步减小包体，但差分还原需要额外计算与存储。优化目标应结合设备档位与网络环境确定优先级。
常见误区：只关注压缩率而忽略解压开销，导致低端设备升级超时或内存溢出；或对已压缩资源（如 JPEG、MP4）重复压缩，收益极低却增加 CPU 负担。
五、案例场景：一次典型的 OTA 升级链路
假设某车载设备通过 4G 网络升级，包体原始大小 1.2GB，采用 zstd 压缩后为 680MB。下载阶段耗时约 8 分钟，解压耗时 45 秒，写入耗时 90 秒，总升级时长约 10 分钟。若改用差分包，包体可降至 120MB，下载仅需 1.5 分钟，但差分还原需额外 60 秒，总时长反而更短。这说明压缩与差分策略必须结合网络与算力综合评估。