- 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包信息
