3. OTA升级包制作与管理：升级包类型、签名加密、版本管理与存储策略
好，咱们接着聊升级包这块。说实话，升级包是整个OTA系统的“弹药”，弹药要是出了问题，仗就没法打了。我在多个座舱项目里都踩过升级包的坑，今天把这些经验掰开了讲给你听。
3.1 升级包类型：全量 vs 增量
升级包分两种：全量包和增量包。这个选择直接影响用户体验和服务器成本。
全量升级包，说白了就是把整个系统镜像打包。比如你的座舱系统有2GB，那全量包就是2GB。好处是简单粗暴，不管当前是什么版本，刷就完了。坏处也明显——下载时间长，流量消耗大。
我记得有一次，客户抱怨说升级一次要半小时，用户都等得不耐烦了。一查，用的就是全量包。嗯，那时候我就意识到，全量包只适合大版本升级，比如从Android 10升到Android 12这种跨度。
增量升级包就聪明多了。它只包含两个版本之间的差异部分。比如系统从v1.0升到v1.1，可能只改了50MB的代码，那增量包就只打包这50MB。
我建议你这样做：
- 小版本迭代（如v1.0.1 → v1.0.2）：用增量包，用户几乎无感
- 大版本升级（如v1.x → v2.0）：用全量包，避免增量链路过长导致问题
- 跨版本升级（如v1.0 → v1.5）：生成多个增量包，或者直接全量
核心原则：增量包能省流量，但全量包更可靠。我一般建议“小增大全”，即小版本增量，大版本全量。
3.2 升级包签名与加密
升级包如果不做签名和加密，那跟裸奔没区别。你想想看，黑客要是篡改了升级包，往里面塞个恶意程序，整个座舱系统就废了。
签名是为了保证完整性——包没有被篡改过。加密是为了保证机密性——包的内容不会被偷看。
我在项目中遇到过这样的事：某次测试发现升级包校验失败，查了半天，原来是签名用的私钥过期了。从那以后，我定了个规矩——签名密钥必须设置有效期提醒，提前三个月就要预警。
具体怎么做？我推荐这套流程：
- 生成密钥对：用RSA-2048或ECDSA，私钥保存在安全服务器上
- 计算哈希：对升级包内容计算SHA-256哈希值
- 签名：用私钥对哈希值进行签名，生成签名文件
- 加密：用AES-256对升级包内容进行加密
- 打包：将加密后的升级包 + 签名文件 + 公钥证书打包在一起
避坑指南：我曾经见过有人把私钥直接放在打包脚本里，结果代码泄露后私钥也暴露了。记住，私钥永远不要出现在代码仓库里，要用专门的密钥管理服务。
代码示例（伪代码，但思路清晰）：
# 升级包签名流程
def sign_package(package_path, private_key):
# 1. 计算哈希
hash_value = sha256(package_path)
# 2. 签名
signature = rsa_sign(hash_value, private_key)
# 3. 加密
encrypted_package = aes_encrypt(package_path, session_key)
# 4. 打包
return Package(encrypted_package, signature, public_key_cert)
3.3 升级包版本管理
版本管理看着简单，但做不好会出大乱子。我见过最离谱的事——某车厂把v1.0.2的包标成了v1.0.1，结果所有车都收到了“降级”推送，用户一脸懵。
版本号我建议用三段式：
| 字段 | 含义 | 示例 |
|---|---|---|
| 主版本号 | 重大架构变更，不兼容 | v1 → v2 |
| 次版本号 | 功能新增，向下兼容 | v1.0 → v1.1 |
| 修订号 | Bug修复，小改动 | v1.0.1 → v1.0.2 |
除了版本号，还要维护一个版本兼容性矩阵。比如：
- v1.0.0 → v1.0.1：直接升级
- v1.0.0 → v1.1.0：需要先升到v1.0.1
- v1.0.0 → v2.0.0：必须全量包
注意：版本号一旦发布，就不能修改。如果发现包有问题，应该发布新版本，而不是替换旧版本。否则已经下载到车端的包会出问题。
3.4 升级包存储策略
升级包存哪里？怎么存？存多久？这些问题看似简单，但背后涉及成本、性能和可靠性。
云端存储：
- 用对象存储（如S3、OSS），支持CDN加速
- 按版本号分目录，比如
/packages/v1.0.0/ - 设置生命周期策略，旧版本自动归档或删除
车端存储：
- 下载到车端后，先校验签名，再解密
- 存储在独立分区，避免影响系统运行
- 升级完成后，及时删除临时文件
我个人习惯的做法是：云端保留最近3个全量包和最近5个增量包。太老的版本，用户基本不会用了，留着也是浪费存储成本。
还有一点——断点续传。升级包动辄几百MB，下载过程中网络断了怎么办？我建议车端下载时记录下载进度，下次续传。这个功能在信号不好的地下车库特别有用。
总结一下：升级包管理是个系统工程。全量还是增量，看场景；签名加密，必须做；版本管理，要严谨；存储策略，要灵活。把这些搞定了，OTA升级就成功了一大半。
嗯，今天就聊到这儿。下一章咱们讲讲升级流程和回滚策略，那才是真正考验系统设计能力的地方。