第25章 OTA远程升级：差分升级算法、升级包校验、回滚机制与进度显示

各位同学，今天我们来聊聊车载系统里一个非常关键的功能——OTA远程升级。说实话，这个功能在现在的智能汽车里，已经跟手机系统更新一样重要了。你想想看，用户买了车，总不能每次升级都跑4S店吧？OTA做得好，用户体验直接拉满；做得不好，车机变砖，那可就麻烦了。

我个人习惯把OTA升级拆成四个核心模块来看：差分算法、包校验、回滚机制、进度显示。这四个模块缺一不可。今天我们就一个一个掰开揉碎了讲。

25.1 差分升级算法：为什么不用全量包？

先问大家一个问题：一个车载系统的固件，动辄几百MB甚至几个GB。如果每次升级都下载全量包，流量费不说，下载时间也受不了。所以，差分升级就派上用场了。

差分升级的核心思想是：只下载变化的部分。车载端本地已经有一个旧版本，云端只下发新旧版本之间的差异数据，然后本地用这个差异数据去“修补”旧版本，生成新版本。

常用的差分算法有bsdiff、hdiffpatch等。bsdiff是基于二进制差异的算法，它先找出新旧文件中的匹配块，然后生成一个补丁文件。这个补丁文件通常很小，可能只有全量包的10%~30%。

我在项目中遇到过一个问题：差分算法对内存要求比较高。尤其是bsdiff，它需要把新旧两个文件都加载到内存里做对比。车载嵌入式设备的内存本来就紧张，所以我们在实际项目中做了分块处理——把固件切成4MB一块，逐块差分，逐块还原。这样内存占用就降下来了。

25.2 升级包校验：别让恶意包混进来

差分补丁下载到车端之后，第一件事不是直接应用，而是校验。为什么？因为万一补丁在传输过程中被篡改了，或者下载不完整，直接应用就会把系统搞坏。

校验通常分两步走：

• 完整性校验：用MD5或SHA256计算补丁文件的哈希值，跟云端下发的哈希值对比。一致说明文件没损坏。
• 签名校验：用公钥验证补丁文件的数字签名。只有合法的签名才能通过，防止恶意包混入。

嗯，这里要注意：签名校验一定要放在完整性校验之后。因为如果文件本身已经损坏了，签名校验大概率会失败，但你也分不清是损坏还是被篡改。先做完整性校验，能帮你快速定位问题。

// 伪代码示例：校验流程
bool verifyUpdatePackage(const QString &patchPath) {
    // 1. 完整性校验
    QByteArray localHash = calculateSHA256(patchPath);
    if (localHash != expectedHash) {
        qWarning("完整性校验失败：文件可能损坏");
        return false;
    }

    // 2. 签名校验
    if (!verifySignature(patchPath, publicKey)) {
        qWarning("签名校验失败：文件可能被篡改");
        return false;
    }

    qInfo("校验通过，可以应用补丁");
    return true;
}

25.3 回滚机制：给升级留条后路

升级失败怎么办？这是每个做OTA的人必须考虑的问题。我的原则是：永远给用户留一条退路。

回滚机制通常有两种实现方式：

方式	原理	优点	缺点
A/B分区	系统有两个分区（A和B），一个运行，一个升级	升级失败不影响当前系统，回滚只需切换分区	需要双倍存储空间
备份还原	升级前备份旧系统，失败后还原	节省存储空间	还原过程耗时较长

我个人更推荐A/B分区方案。虽然多占一份存储，但用户体验好——升级失败后，系统自动切回旧分区，用户甚至感觉不到发生过问题。备份还原方案呢，我一般只在存储实在不够的入门级设备上用。

回滚的触发条件也很重要。我一般会设置三个触发点：

• 应用补丁失败：差分还原过程中出错，立即回滚
• 启动校验失败：新系统启动后，自检不通过，自动回滚
• 用户手动触发：用户觉得新版本不好用，可以手动回退

25.4 进度显示：让用户知道你没死机

最后聊聊进度显示。你可能觉得这很简单，不就是显示个进度条吗？其实不然。OTA升级过程中，最怕的就是用户看到进度条卡住，然后以为死机了，直接断电。

我建议把升级进度分成三个阶段来显示：

1. 下载阶段：显示下载百分比和速度（如“已下载 45%，剩余 2分钟”）
2. 校验阶段：显示“正在校验升级包...”并附带一个旋转动画
3. 应用阶段：显示“正在安装更新...”并给出具体步骤（如“步骤 2/5：正在应用补丁”）

这里有个细节：应用阶段一定要显示具体步骤。因为差分还原和系统写入可能耗时较长，如果只显示一个“正在安装”，用户很容易焦虑。我见过一个项目，应用阶段花了8分钟，用户等不及直接断电了，结果系统损坏。后来我们改成显示“步骤 3/5：正在写入系统分区（约需3分钟）”，用户心里有数，就不乱动了。

// 进度信号发射示例
void UpdateManager::onApplyProgress(int currentStep, int totalSteps, int percent) {
    QString msg = QString("步骤 %1/%2：正在应用补丁（%3%）")
                      .arg(currentStep)
                      .arg(totalSteps)
                      .arg(percent);
    emit progressUpdated(msg, percent);
}

25.5 整体架构图

说了这么多，我们来画一张图，把整个OTA升级的流程串起来。这样你就能一目了然地看到各个模块之间的关系。

从这张图你可以看到，整个OTA流程是一个闭环。从云端生成补丁，到车端下载、校验、应用，再到启动自检，每一步都有对应的处理逻辑。而回滚机制就像一张安全网，兜住所有可能出错的环节。

---