3. 升级包制作与管理：差分升级包、全量升级包、升级包签名、升级包版本管理

好，咱们进入第三个核心环节。升级包怎么做？怎么管？

说实话，很多团队在OTA上栽跟头，不是栽在传输协议上，而是栽在升级包本身。包做大了，用户流量扛不住；包做错了，设备变砖；包没签名，被黑客塞个恶意固件进来……嗯，这些坑我都踩过。

3.1 全量升级包 vs 差分升级包

先搞清楚两个基本概念。

全量升级包，就是把整个固件镜像打包。比如你的语音系统固件是32MB，那全量包就是32MB。好处是简单粗暴，坏处是——你想想看，用户用4G网络下载32MB，流量费够买杯奶茶了。

差分升级包，只包含新旧版本之间的差异部分。比如这次只改了语音唤醒词库和几个驱动，可能差分包只有2MB。我做过一个项目，全量包28MB，差分包压缩完才1.8MB，用户升级成功率直接从72%飙到96%。

差分算法怎么选？我个人习惯用bsdiff和hdiffpatch。bsdiff对二进制文件效果好，但内存消耗大；hdiffpatch更轻量，适合资源受限的嵌入式设备。

# 生成差分包示例（bsdiff）
bsdiff old_firmware.bin new_firmware.bin diff_patch.bin

# 设备端应用差分包
bspatch old_firmware.bin new_firmware.bin diff_patch.bin

我在项目中遇到过一个问题：差分包在某个批次设备上总是应用失败。查了两天，发现是这批设备的Flash坏块管理策略跟差分算法冲突。后来加了校验和重试机制才搞定。

3.2 升级包签名：别让你的设备裸奔

升级包不签名，相当于你家大门没锁。黑客可以伪造一个升级包，让你的语音系统变成“监听系统”。

签名流程其实不复杂：

1. 用私钥对升级包的哈希值加密，生成签名
2. 把签名附加到升级包尾部
3. 设备端用公钥解密签名，比对哈希值

算法选择上，我建议用ECDSA（椭圆曲线数字签名算法）。为什么？签名短，计算快。RSA也行，但嵌入式设备上ECDSA性能优势明显。

# 生成密钥对
openssl ecparam -genkey -name prime256v1 -out private.pem
openssl ec -in private.pem -pubout -out public.pem

# 签名升级包
openssl dgst -sha256 -sign private.pem -out signature.bin upgrade.bin

# 验证签名（设备端）
openssl dgst -sha256 -verify public.pem -signature signature.bin upgrade.bin

还有一点要注意：签名验证必须在安全环境中执行。如果Bootloader被篡改，签名验证就是个摆设。所以，信任根要放在芯片的OTP（一次性可编程）区域或安全元件里。

3.3 升级包版本管理：别搞出“版本地狱”

版本管理看似简单，但做不好会出大乱子。我见过一个团队，版本号用“v1.0.1”、“v1.0.2”这样递增，结果某次升级后，设备端版本号比服务器还高，导致无法回滚。

我建议采用语义化版本号：

字段	含义	示例
主版本号	不兼容的API或重大架构变更	2.0.0
次版本号	向下兼容的功能新增	1.3.0
修订号	向下兼容的问题修复	1.2.5
构建号	每次构建自动递增	1.2.5.20240315

另外，升级包元数据里要包含：

• 目标设备型号（不同硬件不能混用）
• 最低兼容版本（防止跨大版本升级）
• 升级包类型（全量/差分）
• 文件校验和（SHA256）
• 签名数据

{
  "package_version": "1.2.5",
  "target_model": "SMART_SPEAKER_V3",
  "min_compatible_version": "1.0.0",
  "package_type": "diff",
  "checksum": "a1b2c3d4e5f6...",
  "signature": "base64_encoded_signature",
  "file_size": 2097152
}

3.4 升级包管理流程：从构建到分发

一个完整的升级包管理流程，我总结为四步：

1. 构建阶段：CI/CD流水线自动编译固件，生成全量包
2. 差分阶段：对比上一个正式版本，生成差分包
3. 签名阶段：用离线私钥签名，生成签名文件
4. 发布阶段：上传到CDN，更新版本数据库

这里有个坑：差分包不能无限差分。比如从v1.0到v1.1差分，再从v1.1到v1.2差分……累积到v1.5时，差分链太长，应用失败率会飙升。我建议最多保留3级差分链，超过就生成全量包。

还有，升级包要保留历史版本。为什么？因为有些用户可能跳过多个版本，需要从v1.0直接升到v1.5。这时候差分包就不适用了，得提供全量包。

嗯，升级包制作与管理这块，说白了就是三个字：小、稳、安。包要小，过程要稳，安全要到位。做到这三点，OTA升级就成功了一大半。