什么是增量更新
简略的说, 便是用户本地有个文件X, 当时版别是A, 巨细100M. 现在这个文件需求晋级到版别B, 巨细110m.
用户能够直接下载版别B, 覆盖本地的版别A, 完结晋级. 这是普通晋级. 运用流量110M.
用户还能够只下载版别B和版别A之间的差异包, 然后在本地将差异包和版别A结合, 生成版别B. 完结晋级. 运用流量或许只有10M左右. 这便是”增量更新”了
Archiv-Patcher
完成增量更新的计划许多, 通过初步了解和比较, 咱们挑选google的 Archive-Pather
挑选它的原因:
- 事务层逻辑是纯java的. 简单接入Android.
- 在开源的代码中, 中心部分也有java完成. 简单修正
- 压缩中心运用zlib. 虽然是native的, 在各个系统中都有安稳完成.
- 不需求从头签名, 用户侧能够运用
问题
由于是纯java的代码, 所以接入和运用都十分简略. 可是实践仍是遇到了一些问题.
zlib版别更新.
实验发现安卓11上兼并操作是必定失利的. 设备上兼并的成果和实践方针截然不同.
翻阅源码的issues, 发现已经有人提了这个问题, 可是google方面似乎并没想解决. 有人提到是由于zlib的版别不同导致.
回头再从头翻看源码的ReadMe. 确实提到了zlib版别等环境问题会导致兼并成果异常, 并且供给了一个”适配窗口”来做环境查看. 能通过检测阐明能够运用, 不然不能. 果然在Android 11以上的设备里, 检测没有通过.
定位到了问题, 那就解决它. 之前调研的时分也说了, 挑选Archive-pather是由于它好改好移植, 与Android兼容性强. 咱们找到一个可用的zlib版别. 将他内嵌到app中编译成so库. 别的由于zlib是通过java.util.zip包引入的, 所以java.util.zip的包也要移植到app内, 以保证运用的自家的zlib.
有专业的jni大佬支撑, 整个移植进程还比较顺利. 由于运用的是自家移植的zlib. 所以不再有Android版别适配的问题, 都能够正常通过适配窗口的测试.
兼并异常
解决了zlib版别问题, 发现仍是有兼并异常. 这些异常都发生在正常兼并完毕后, md5校验失利. 阐明兼并流程是正常履行完毕的, 可是兼并的成果有问题.
这就需求剖析Archive-patcher的兼并流程了. 除了剖析出流程外, 还需求在兼并中刺进要害日志, 以协助咱们剖析用户兼并失利的原因. 好在源码ReadMe中比较具体的介绍了patcher文件的格局. 结合源码, 渐渐啃到一些符号数据. 需求进一步剖析进程, 试验验证.
题外
写文章的时分, 从头翻看issues, 发现有推荐sfpatcher. 当时遇到这个问题的时分还没有这个谈论. 是一个比Archive-patcher更高效安稳的增量计划. 只发布了编译东西和文档. 需求商业授权. 从文档看, 确实供给了许多高效的思路:
- 以一种类似流的方法生成和运用补丁. 指定缓存的巨细, 比照流内容, 并更新到方针文件
- archive-patcher十分耗费硬盘空间. 是能够要点优化的点.
- 中心算法能够代替. java/c/c++都能够
- 能够商业化, 属实意外.
