升级包结构设计：升级包的组成与规范
好，咱们今天聊聊升级包的结构。说白了，升级包就是OTA升级的“弹药”。弹药如果装错了，枪都打不响。我在鸿蒙系统里折腾过不少升级包，踩过坑，也总结了一些经验，今天全部分享给你。
升级包的三大核心组成
一个完整的升级包，我习惯把它拆成三块：元数据、payload、签名。缺一不可。
1. 元数据（Metadata）
元数据就是升级包的“身份证”。它告诉系统：你是谁？你要升级谁？你有多大？
我在项目中遇到过，有人把元数据写错了，结果升级包发下去，设备死活不认。嗯，这里要注意，元数据必须包含以下关键字段：
- 包类型：是全量包还是差分包？
- 目标版本：比如 HarmonyOS 3.0 → 3.1
- 源版本：从哪个版本可以升级过来
- 包大小：payload 的原始大小和压缩后大小
- 校验算法：SHA256 还是 SHA512？
- 时间戳：打包时间，防止重放攻击
你想想看，如果元数据里目标版本写错了，设备升级到一半发现版本不匹配，那就尴尬了。我曾经见过一个案例，元数据里版本号多了一个空格，结果解析失败，整批设备回滚。所以，元数据的格式一定要严格定义。
2. payload（有效载荷）
payload 是升级包的核心，里面装的就是真正的升级数据。它可以是：
- 全量镜像：整个系统分区的镜像文件，比如 system.img、vendor.img
- 差分补丁：只包含新旧版本差异的数据块，用 bsdiff 或 imgdiff 生成
- 文件列表：每个文件的路径、权限、校验值
我个人习惯把 payload 分成多个块（chunk）。每个块独立压缩、独立校验。为什么这么做？因为升级过程中如果网络断了，或者设备掉电了，至少已经校验通过的块不用重传。说白了，就是断点续传的底层支持。
重要提示：payload 内部的数据块大小建议控制在 1MB 以内。太大容易导致内存压力，太小又增加元数据开销。我一般用 512KB 作为默认块大小。
3. 签名（Signature）
签名是升级包的安全锁。没有签名的升级包，设备应该直接拒绝。我在鸿蒙系统里用的是 PKCS#7 签名，配合 RSA 或 ECDSA 算法。
签名流程是这样的：
- 先对元数据 + payload 整体做哈希（比如 SHA256）
- 用私钥对哈希值签名
- 把签名结果和公钥证书一起打包进升级包
设备端收到包后，先验签。验签通过，才继续解析元数据。我曾经遇到过，有人把签名放在 payload 后面，结果设备先解析 payload 再验签，白白浪费了计算资源。正确的做法是：签名放在最前面，或者元数据里包含签名信息。
避坑指南：我曾经见过一个项目，签名算法用了 MD5，结果被暴力破解了。现在最低要求是 SHA256，建议用 SHA384 或 SHA512。另外，私钥一定要硬件隔离，别放在编译服务器上。
包格式规范
升级包的格式，说白了就是二进制数据的排列方式。我推荐用 TLV（Type-Length-Value） 结构。为什么？因为解析简单，扩展方便。
一个典型的升级包二进制布局如下：
+------------------+
| Magic Number | // 4字节，比如 0x4F5441 ("OTA")
+------------------+
| Header Size | // 4字节，头部总长度
+------------------+
| Metadata | // JSON 或 protobuf 格式
+------------------+
| Payload Chunk1 | // 压缩后的数据块1
+------------------+
| Payload Chunk2 | // 压缩后的数据块2
+------------------+
| ... |
+------------------+
| Signature | // PKCS#7 签名数据
+------------------+嗯，这里要注意：Magic Number 一定要选一个不容易冲突的值。我见过有人用 0x00000000，结果空文件也能被误识别。建议用 ASCII 字符，比如 "HOTA" 或者 "OHOS"。
元数据我推荐用 protobuf 而不是 JSON。为什么？因为 protobuf 是二进制格式，解析速度快，体积小。在嵌入式设备上，每节省 1KB 都是好的。当然，如果你团队对 JSON 更熟悉，用 JSON 也行，但记得压缩。
个人经验：我习惯在元数据里加一个 "compat_version" 字段。这个字段用来标识升级包格式的版本。比如 v1 只支持全量包，v2 支持差分包。这样以后格式升级了，旧设备也能优雅地拒绝不兼容的包。
版本兼容性设计
版本兼容性，说白了就是：老设备能不能用新包？新设备能不能用老包？
我在鸿蒙系统里设计了一套规则，分享给你：
1. 前向兼容
新版本的升级包，必须能被旧版本的升级程序解析。怎么做？
- 元数据格式固定，新增字段用 optional 标记
- payload 的压缩算法保持向下兼容
- 签名算法不能突然升级，要留过渡期
2. 后向兼容
旧版本的升级包，新版本的升级程序也要能解析。怎么做？
- 解析器要支持多个版本的元数据格式
- 遇到不认识的可选字段，直接跳过
- 遇到不支持的压缩算法，报错并提示用户
3. 版本号规则
我建议用 语义化版本号：主版本.次版本.修订号。
| 版本变化 | 含义 | 兼容性要求 |
|---|---|---|
| 主版本+1 | 包格式大改，不兼容 | 必须全量升级 |
| 次版本+1 | 新增功能，但格式兼容 | 差分包可用 |
| 修订号+1 | 小修小补 | 完全兼容 |
你想想看，如果主版本从 2 跳到 3，说明包格式变了。这时候旧设备必须用全量包，不能走差分。我见过有人没注意这个，结果差分包打上去，设备直接变砖。
核心原则：升级包的设计，要保证设备在任何情况下都能恢复。哪怕升级包本身有问题，设备也要能回滚到上一个可用版本。所以，版本兼容性不是锦上添花，而是保命底线。
总结一下
升级包结构设计，说白了就是三件事：元数据说清楚、payload 放对地方、签名锁死安全。格式规范用 TLV，版本兼容性用语义化版本号。我在实际项目中，每次打包前都会跑一遍自动化校验脚本，确保元数据、payload、签名三者一致。嗯，这个习惯救过我不少次。
下一章，咱们聊聊升级包的生成工具链。到时候我会手把手教你写一个打包脚本。