应用增量更新机制纪要

更新记录

版本 日期 修改人 修改内容
1.0.0 2020年8月21日 蔺浪(510525) 新建文档
1.0.1 2020年8月26日 蔺浪(510525) 补充应用规范

更新机制

更新识别

  • 应用版本更新只能识别该应用同种类型的程序包

    exe包之间识别更新
    zip包之间识别更新
    exe与zip包之间无法识别更新

增量更新

  • 应用当前版本与最新版本之间间隔版本不超过10个

全量更新

  • 应用当前版本与最新版本之间间隔版本超过10个

增量前提

  1. 旧版本应用(exe/zip)已上线
  2. 新版本应用(exe/zip)上线

    增量包只会在新版本第一次上线时才会基于已上线的旧版本生成增量包(多线程处理,增量包生成有延迟,增量越大,耗时越多,无法预估;保险起见,新版本上线10~25分钟后再做增量测试),再次上线不会生成增量包;隐含的意思是,新版本的上线时间应该迟于旧版本!

  3. 旧版本应用(exe/zip)存在本地基础包。

增量辨识

  • 更新时,观察临时文件

    观察缓冲目录下是否有文件命名中含有“patch”字样的”.temp”临时文件生成;注意,这类临时文件,在处理完增量合并后会被清理,不会长久存在

  • 更新时,观察输出日志

    需接入DeltaUpdate-1.0.4-preview4或以上版本
    且配置文件“updatecfg.json”中“loglevel”配置为0以确保debug日志输出
    [MultiUpdateMgr] DownloadZipOrPatch log: ZipPatchUrl does not exist, code is {AppCode}, LocalVersion is {LocalVersion}, RemoteVersion is {RemoteVersion}
    该日志说明没有获取到增量包下载地址,即不会进行增量更新
    若日志中出现“Error”报错信息,取出日志反馈程序开发同学辨识

应用规范

  • 就目前“小程序”的应用方式而言,凡是需要通过小程序更新的应用包,必须确保应用包上传时,在管理平台上的版本标注与应用包中“config.ini”文件中配置的版本号一致。

  • 应用包一旦上线,不能再次修改应用包后重新上传(服务器端机制:增量包只会在新版本第一次上线时才会基于已上线的旧版本生成增量包),否则会造成后续版本的增量无法合并,因为增量的基础包已经被重新上传替换了。

  • 开发或者QA测试时,须按照应用日常发包更新的流程制作应用包和上传管理平台,不能随意制作(随意删减文件等)应用包上传测试;事实上,对于增量更新组件功能而言,文件差异是可以增量合并的(刘剑调研);但是应用程序不是一个简单的文件包,各种文件版本配置,版本记录,版本更新等都在应用程序的逻辑中,一旦应用程序无法正常运行,那么调用增量更新组件进行应用更新时,其传入的参数可能是异常的,这会导致增量更新组件无法拿到预期的增量包。

干系人清单

干系人 干系
黄家杰 服务器接口维护
刘剑 增量更新组件
蔺浪 增量更新组件
晋露丽 中小学虚拟实验播放器应用增量更新接入

相关链接