3、升级包制作与管理：差分升级算法、升级包签名与加密、版本管理策略
好，咱们进入第三章。这一章讲的是升级包的制作与管理，说白了就是「怎么把新版本做成一个能安全、高效送到车上的包裹」。我在好几个项目里都栽过这方面的跟头，所以今天聊的内容，都是实打实的经验教训。
3.1 差分升级算法：别让车主等太久
先问一个问题：一个完整的车机系统镜像有多大？少说几个GB，多的十几个GB。如果每次升级都全量下载，那流量费谁出？下载时间谁等得起？
所以就有了差分升级。它的核心思想是：只传输新旧版本之间的差异部分。我最早接触这个是在一个T-Box项目上，当时固件只有32MB，全量升级也就几分钟。后来上了智能座舱，镜像直奔4GB，我才意识到差分升级不是「锦上添花」，而是「雪中送炭」。
3.1.1 常见的差分算法
目前主流的差分算法有这么几种，我列个表对比一下：
| 算法 | 原理 | 压缩率 | 内存消耗 | 适用场景 |
|---|---|---|---|---|
| bsdiff | 基于后缀排序的差异匹配 | 极高 | 高 | 二进制文件、固件 |
| hdiffpatch | 基于哈希的差异匹配 | 高 | 中 | 大文件、系统镜像 |
| xdelta | 基于VCDIFF标准 | 中 | 低 | 通用文件、配置 |
| 自定义差分 | 按块对比+压缩 | 中低 | 低 | 资源受限设备 |
我个人习惯在座舱项目上用 bsdiff，它的压缩率确实好。但要注意，bsdiff在生成差分包时内存占用很高，我曾经在服务器上生成一个2GB镜像的差分包，内存直接飙到8GB。所以服务器配置得跟上。
关键点：差分升级不是万能的。如果新旧版本差异太大（比如换了文件系统），差分包可能比全量包还大。这时候要设置一个阈值，超过阈值就自动切换为全量升级。
3.1.2 差分升级的流程
嗯，这里我把流程拆解一下，你想想看：
- 获取基准版本：从车上拿到当前运行的固件版本。
- 生成差分包：在云端用新旧两个版本生成差分文件。
- 下发差分包：通过OTA通道把差分包推送到车端。
- 本地合并：车端用旧版本+差分包，合并成新版本。
- 校验完整性：合并完成后做哈希校验，确保没出错。
我在项目中遇到过一个问题：车端合并时内存不够。bsdiff的合并过程虽然比生成过程轻量，但依然需要一定的内存缓冲区。当时我们用的是一块低端芯片，只有256MB RAM，合并一个1GB的镜像直接OOM了。后来我们改成了流式合并，边读边写，才把内存压下来。
小技巧：差分包生成时，可以按块（chunk）处理。比如每16MB一个块，分别生成差分，这样车端合并时只需要一个16MB的缓冲区就够了。
3.2 升级包签名与加密：别让黑客钻空子
升级包在传输过程中，最怕什么？怕被篡改，怕被窃取。你想想看，如果黑客伪造一个升级包，里面塞了恶意代码，然后推送到车上……那后果不堪设想。
所以，签名和加密是必须的。我见过一些初创公司，为了省事，升级包直接明文传输，连个校验都没有。嗯，这种项目我是不敢碰的。
3.2.1 签名：证明「我是我」
签名的目的是防篡改和防伪造。流程是这样的：
- 云端用私钥对升级包的哈希值进行签名。
- 车端用公钥验证签名。
- 验证通过，说明升级包确实是云端发的，且没有被改过。
这里要注意公钥的存储。公钥如果被替换了，那签名就形同虚设。我曾经在一个项目上看到，公钥直接硬编码在应用层代码里，而且没有做任何保护。我当时就建议：公钥必须存储在安全区域，比如TEE（可信执行环境）或者HSM（硬件安全模块）。
警告：千万不要把私钥放在代码仓库里！我见过有人把私钥提交到GitHub，结果被爬虫抓到了。那项目最后只能换证书，所有已出货的设备都得重新烧录公钥，成本巨大。
3.2.2 加密：防止「偷看」
签名的目的是防篡改，加密的目的是防泄露。有些升级包里可能包含敏感数据，比如地图数据、用户隐私配置等，这时候就需要加密。
常用的加密方式有两种：
- 对称加密：比如AES-256，速度快，适合大文件。但密钥分发是个问题。
- 非对称加密：比如RSA或ECC，速度慢，适合加密对称密钥。
实际项目中，我建议用混合加密：用非对称加密传输对称密钥，再用对称密钥加密升级包。这样既安全又高效。
举个例子：
// 云端加密流程
1. 生成随机对称密钥 K
2. 用 K 加密升级包 -> 得到密文 C
3. 用车端公钥加密 K -> 得到密文 K'
4. 将 C + K' 打包下发
// 车端解密流程
1. 用车端私钥解密 K' -> 得到 K
2. 用 K 解密 C -> 得到升级包明文
重要：加密和签名是两回事，不要混淆。签名用私钥，加密用公钥。签名是「我证明是我发的」，加密是「只有你能看」。两者结合使用，才能做到既防篡改又防泄露。
3.3 版本管理策略：别让版本乱成一锅粥
版本管理，听起来简单，做起来全是坑。我参与过一个项目，车上有十几个ECU，每个ECU都有自己的版本号。结果有一次升级，A模块升到了2.0，B模块还是1.8，两个模块之间的通信协议不兼容，整个系统直接瘫痪。
所以，版本管理不是「记个数字」那么简单。
3.3.1 版本号的规范
我建议采用语义化版本号，格式为：主版本.次版本.修订号。
- 主版本：不兼容的API或协议变更。
- 次版本：向下兼容的功能新增。
- 修订号：向下兼容的问题修复。
举个例子：2.1.3 表示主版本2，次版本1，第3次修订。
但光有版本号还不够。你想想看，如果车上同时有十几个模块，每个模块的版本号都独立增长，你怎么知道哪些版本组合是兼容的？
3.3.2 版本兼容性矩阵
我习惯在云端维护一个版本兼容性矩阵，记录每个模块版本之间的兼容关系。比如：
| 模块A版本 | 模块B版本 | 模块C版本 | 是否兼容 |
|---|---|---|---|
| 2.0.0 | 1.5.0 | 3.1.0 | 是 |
| 2.0.0 | 1.4.0 | 3.1.0 | 否 |
| 2.1.0 | 1.5.0 | 3.2.0 | 是 |
在推送升级包之前，云端先查一下这个矩阵。如果发现不兼容，就拒绝推送，或者提示用户需要同时升级其他模块。
避坑指南：我曾经遇到过一个问题：版本兼容性矩阵只记录了「正向兼容」，没记录「反向兼容」。结果有一次回滚操作，从2.0回退到1.9，发现1.9和当前其他模块不兼容。所以，兼容性矩阵一定要双向记录。
3.3.3 升级策略：灰度与回滚
版本管理还涉及到升级策略。我建议采用灰度升级：先推送给一小部分车辆，观察一段时间，确认没问题后再全量推送。
灰度比例可以这样设置：
- 第一阶段：1% 的车辆（内部测试车）
- 第二阶段：10% 的车辆（尝鲜用户）
- 第三阶段：50% 的车辆（逐步放开）
- 第四阶段：100% 的车辆（全量推送）
另外，一定要有回滚机制。如果升级后发现严重问题，要能快速回退到上一个版本。回滚包可以提前生成好，存在云端，随时可以下发。
注意：回滚不是万能的。如果升级过程中修改了分区表或者Bootloader，回滚可能会变砖。所以，关键分区（如Bootloader、Recovery）尽量不要在常规升级中修改，除非你有绝对的把握。
3.4 总结
好，这一章的内容就这些。总结一下：
- 差分升级：选对算法，注意内存消耗，设置全量/差分切换阈值。
- 签名与加密：签名防篡改，加密防泄露，公钥要存安全区。
- 版本管理：语义化版本号，维护兼容性矩阵，灰度升级+回滚机制。
下一章我们会聊升级包的存储与分发，包括CDN加速、断点续传、本地缓存策略等。到时候再细聊。