应用版本管理和增量/全量升级方案及实现

• 1 升级功能
• 2 升级流程
• 3 OTA包结构和配置文件
• 4 增量升级
• 5 全量升级
• 6 升级包设计
• 7 功能实现
  • 7.1 升级包生成（通用）
  • 7.2 升级流程实现（示例）
• 8 最后
• 9 参考资料

1 升级功能

• OTA升级
• 升级方式
  • 根据升级配置文件指定升级内容
  • 全覆盖升级
  • 支持全量升级
  • 支持增量升级
• 支持tar、zip打包方式
• 支持升级失败版本回滚
• 支持版本OTA降级
  • 支持增量降级版本
  • 支持全量降级到指定版本

2 升级流程

主应用：

• 收到云端升级指令和升级包信息
• 开始下载升级包
• 发送升级信息（升级包绝对路径+校验和）到独立的升级管理程序
• 如果升级成功，启动时发送当前版本至云端

升级管理及状态监控应用：

• 校验升级包
• 解压缩升级包
• 备份原程序和相关资源(包含中间生成文件)
• 开始升级（前提是待升级程序需停止运行）
  • 全量升级：目前较为粗暴，删除所有旧文件，替换新文件，如果配置相关文件在程序根目录范围内，配置也会被重置
  • 增量升级：需要校验旧版本是否与升级要求的旧版本号一致 && 要求升级前后应用根路径一致
• 升级完成重启应用
• 监控升级后应用启动运行状态，是否升级成功
  • 失败，外部做回滚操作
  • 升级成功，删除原备份版本和升级包及中间临时文件

注意：主应用 和 升级管理及状态监控应用 不能放于同一根目录下，防止操作冲突。

3 OTA包结构和配置文件

主要包含三个部分：

• 主程序
• 其他资源和配置文件
• 当前版本升级信息文件：ota_info.json

4 增量升级

对于增量升级我们需要考虑有：

• 支持最小单位的增量升级，比如具体到某个模型或者某个配置文件
• 升级完成，保证整个应用程序包是一个最小内容，即无升级后的遗留垃圾文件存在
• 确保增量升级过程中的版本管理，即不会出现升级后出现无法启动，最小升级单位不匹配的问题
• 做到减少版本管理的复杂度，免除人工校验的工作
• 版本回滚时，升级包的完整性
• 版本升级过程的衔接
• 升级备份

5 全量升级

对于全量升级我们需要考虑有：

• 升级后前版本的配置能够决定是否保留
• 升级备份

6 升级包设计

核心：

• 必须拥有前一个OTA包信息，保证版本的无缝升级
• 当前OTA包信息