移动端离线包发布方案

最近做了一次关于移动端 web app 更新方案的分享,这篇文章基于这次分享展开。
keynote 下载: WepAppRelease.key

动态发布

现在 web 页面在移动端的地位越来越高,大部分主流 App 采用 native + webview 的 hybrid 模式,加载远程页面受限于网络,本地 webview 引擎,经常会出现渲染慢导致的白屏现象,体验很差,于是离线包方案应运而生。动态下载的离线包可以使得我们不需要走完整的 App 审核发布流程就完成了版本的更新。

dynamic release

设计架构预览

architecture & pipelin

功能细节

包版本管理

由于每个版本的离线包都对应了一次小版本的发布,所在的宿主 app 和系统环境也不相同,为了发现定位问题,必须要对包版本进行管理,这时候就需要一个内部离线包管理系统:

package management system

每个应用的 metadata 尽量详细,业务 owner,适用的平台,适用的系统,优先级等等都要完整定义。这里要注意的一点是,高版本的离线包可能不支持低版本的 app 环境,需要维护离线包和 app + 环境 的关系,同时,不同包之间的依赖关系也要理清。

网络

一部分 web app 可能包含大量图片资源,导致包尺寸较大,出于保护用户流量的考虑,需要设定一个网络下载策略,比如大于 100 kb 的包使用 WI-FI 下载。同时由于文件较大,失败率可能较高,需要加入重试机制比如每次启动最大下载次数,如果重试均失败则下次启动再下载,最好能支持断点续传以及分块下载。

安全

对资源进行 md5 计算以及加密解密来防止篡改,比如使用 DES + base64,当然,秘钥如果存在客户端的话,也有被调试或者注入获取到的风险。

增量更新

diff package

前后端使用 dsdiff, dspatch 来进行差分包的生成,下载,安装。每次查询同时提供全量包以及增量包的下载,优先尝试增量包可以节约流量,解决只能在 WIFI 环境下载全量包的问题。

发布

  • 发布审核

需要建立一个完整的评估审核机制来管控离线包更新,需要 review 代码来评估是否有风险,受影响的功能需要走完整的 test 流程而且需要在不同版本(支持该版本离线包)的 app 上进行测试。

  • 发布控制

灰度发布:离线包发布直接到达用户终端,为了确认发布的功能对用户带来的影响线,需要先观察一部分用户行为和数据。
发布回滚:发布的包如果有问题,可以回滚到先前版本的包。
停止发布:发布的包如果没有生效,也没有副作用,为了尽可能的减少影响,可以直接停止这个包的发布。

监控

发布效果监控可以查看升级百分比,也支持特定用户的对某个发布的结果查询。
全量更新由于包较大,可能有较高的下载失败率,一个版本的 app 就有可能对应不同版本的离线包,一旦线上发生问题,如果前端没有监控体系,用户对离线包版本无感知,将更难定位问题。
如果资源被篡改,无监控可能都无法感知用户显示的是否是预期的页面。

总结

一个完善的 web app 发布方案对于 app 端的动态发布以及用户体验至关重要,相比传统的发布方案也更加灵活,给不同类型的业务提供更多的选择。

以上就是这篇文章全部内容,欢迎提出建议和指正,个人联系方式详见关于

Comments
Write a Comment