4、升级流程与策略：全量升级 vs 增量升级、静默升级 vs 交互升级、回滚机制、断点续传
各位同学，今天我们来聊聊升级策略。说实话，这部分内容在量产项目中特别重要。我见过不少团队，代码写得漂亮，但一到升级环节就翻车。为什么？因为策略没选对。
升级策略选得好，用户无感，系统稳定。选得不好，轻则升级失败，重则把车刷成砖。嗯，咱们一个一个来看。
4.1 全量升级 vs 增量升级
先说说最基础的选择：全量升级还是增量升级？
全量升级，说白了就是把整个系统镜像全部替换掉。比如你的ADAS系统有2GB，每次升级都下载完整的2GB包。好处是简单粗暴，不容易出兼容性问题。坏处嘛，你想想看，每次都要下载这么大一个包，流量和耗时都受不了。
增量升级就不一样了。它只下载变化的部分。比如这次只改了3个动态库和2个配置文件，那就只推送这5个文件。我做过一个项目，全量包1.8GB，增量包只有120MB。差距有多大？你自己感受一下。
核心对比：
| 维度 | 全量升级 | 增量升级 |
|---|---|---|
| 包体大小 | 大（完整镜像） | 小（仅差异部分） |
| 升级耗时 | 长 | 短 |
| 流量消耗 | 高 | 低 |
| 兼容性风险 | 低 | 高（依赖基线版本） |
| 实现复杂度 | 低 | 高 |
我个人习惯是：首次升级或跨大版本升级用全量，小版本迭代用增量。比如从1.0升到2.0，全量更稳妥。从2.0.1升到2.0.2，增量就够了。
避坑指南：我曾经在一个项目里全用增量升级，结果有个车从1.0直接跳到2.5，中间跳过了好几个版本。增量包依赖的基线文件根本对不上，升级直接失败。后来我加了个版本链校验，强制要求不能跨版本升级。
4.2 静默升级 vs 交互升级
接下来是用户体验的分水岭：静默升级还是交互升级？
静默升级，就是用户完全无感知。车在后台下载、校验、安装，用户该开车开车，该停车停车。升级完成后，下次启动时自动切换到新版本。我参与的一个L2+项目，静默升级成功率能做到99.7%以上。
交互升级就不一样了。它会弹窗问用户：「检测到新版本，是否立即升级？」用户点了确认，车才能开始升级。升级过程中，车辆通常不可用。
你可能会问：那肯定选静默升级啊，用户体验多好！
别急，这里有个关键问题：安全。自动驾驶系统升级过程中，如果车辆正在行驶，突然重启了怎么办？所以静默升级有个前提条件——必须确保升级过程不影响行车安全。
重要提醒：涉及安全关键模块（如制动、转向、感知）的升级，我建议用交互升级。让用户停在安全位置后再操作。非安全模块（如娱乐系统、导航地图）可以用静默升级。
我在实际项目中是这样做的：
- 安全相关升级：交互式，要求车辆P档、电量充足、停在安全区域
- 非安全升级：静默式，后台下载，下次启动时生效
- 混合升级：如果一次升级包含安全和非安全模块，整体走交互流程
4.3 回滚机制
升级失败了怎么办？这就是回滚机制要解决的问题。
说实话，回滚机制是我最看重的一块。为什么？因为升级失败是必然会发生的事。网络断了、存储满了、校验不过、安装过程中断电……各种意外都可能发生。
我设计的回滚方案通常包含三层：
- A/B分区方案：系统有两个分区，A分区跑当前版本，B分区安装新版本。安装完成后，切换启动分区。如果新版本启动失败，自动切回A分区。这是最可靠的方案。
- 备份还原方案：升级前备份关键文件和配置。升级失败时，用备份恢复。适合文件系统级别的升级。
- 版本回退方案：保留最近3个版本的镜像。用户或运维可以手动选择回退到某个版本。
我推荐的做法：
升级流程：
1. 下载新版本到B分区
2. 校验完整性（MD5/SHA256）
3. 标记B分区为待激活
4. 重启系统
5. 引导程序检查B分区状态
6. 如果B分区启动成功 → 标记为当前版本
7. 如果B分区启动失败 → 自动切回A分区
8. 上报升级结果到云端嗯，这里要注意：回滚不是万能的。如果升级过程中把引导程序写坏了，那就真成砖了。所以引导程序区域我一般会做写保护，只允许通过特殊方式更新。
个人经验：我曾经遇到一个案例，升级过程中车辆断电，A/B分区都损坏了。后来我加了个「救援分区」，只有几MB大小，专门用来恢复系统。虽然这种情况很少见，但关键时刻能救命。
4.4 断点续传
最后说说断点续传。这个功能在车联网环境下特别实用。
你想想看，车辆可能在地下车库、隧道、偏远地区行驶，网络信号时好时坏。一个2GB的全量包，下载到一半断网了，难道要重新下载？那用户体验得多差。
断点续传的原理很简单：把大文件分成若干小块（chunk），每个小块独立下载。下载过程中记录已完成的块。断网后重新连接，从断点处继续下载，而不是从头开始。
具体实现上，我一般用HTTP Range请求：
// 客户端请求示例
GET /update/adas_v2.0.bin HTTP/1.1
Host: ota.example.com
Range: bytes=1048576-2097151
// 服务端返回
HTTP/1.1 206 Partial Content
Content-Range: bytes 1048576-2097151/2147483648
Content-Length: 1048576每个chunk下载完成后，要校验它的完整性。我习惯用256KB或1MB作为一个chunk，太大容易失败，太小管理开销大。
注意事项：断点续传要配合存储管理。如果车辆存储空间不足，下载到一半可能因为空间不够而失败。我建议在升级前预留至少1.5倍全量包大小的空间。
另外，断点续传还有个隐藏问题：版本过期。如果下载过程中云端发布了新版本，你下载到一半的旧版本还要不要继续？我一般会加个版本有效期检查，超过24小时就放弃旧版本，重新下载新版本。
好了，这四种策略讲完了。总结一下我的建议：
- 全量 vs 增量：大版本全量，小版本增量
- 静默 vs 交互：安全模块交互，非安全模块静默
- 回滚：A/B分区最可靠，再加个救援分区保底
- 断点续传：必须做，chunk大小选256KB-1MB
下一章我们聊聊升级安全与校验，这部分内容直接关系到你的车会不会被黑客攻击。嗯，到时候见。