最近做了一次关于移动端 web app 更新方案的分享，这篇文章基于这次分享展开。
keynote 下载: WepAppRelease.key
动态发布
现在 web 页面在移动端的地位越来越高，大部分主流 App 采用 native + webview 的 hybrid 模式，加载远程页面受限于网络，本地 webview 引擎，经常会出现渲染慢导致的白屏现象，体验很差，于是离线包方案应运而生。动态下载的离线包可以使得我们不需要走完整的 App 审核发布流程就完成了版本的更新。
package_update.png
设计架构预览
architecture.png
功能细节
包版本管理
由于每个版本的离线包都对应了一次小版本的发布，所在的宿主 app 和系统环境也不相同，为了发现定位问题，必须要对包版本进行管理，这时候就需要一个内部离线包管理系统：
package_manage_system.jpg
每个应用的 metadata 尽量详细，业务 owner，适用的平台，适用的系统，优先级等等都要完整定义。这里要注意的一点是，高版本的离线包可能不支持低版本的 app 环境，需要维护离线包和 app + 环境 的关系，同时，不同包之间的依赖关系也要理清。
网络
一部分 web app 可能包含大量图片资源，导致包尺寸较大，出于保护用户流量的考虑，需要设定一个网络下载策略，比如大于 100 kb 的包使用 WI-FI 下载。同时由于文件较大，失败率可能较高，需要加入重试机制比如每次启动最大下载次数，如果重试均失败则下次启动再下载，最好能支持断点续传以及分块下载。
安全
对资源进行 md5 计算以及加密解密来防止篡改，比如使用 DES + base64，当然，秘钥如果存在客户端的话，也有被调试或者注入获取到的风险。
增量更新
image.png
前后端使用 dsdiff, dspatch 来进行差分包的生成，下载，安装。每次查询同时提供全量包以及增量包的下载，优先尝试增量包可以节约流量，解决只能在 WIFI 环境下载全量包的问题。
发布
-
发布审核
需要建立一个完整的评估审核机制来管控离线包更新，需要 review 代码来评估是否有风险，受影响的功能需要走完整的 test 流程而且需要在不同版本（支持该版本离线包）的 app 上进行测试。 -
发布控制
灰度发布：离线包发布直接到达用户终端，为了确认发布的功能对用户带来的影响线，需要先观察一部分用户行为和数据。
发布回滚：发布的包如果有问题，可以回滚到先前版本的包。
停止发布：发布的包如果没有生效，也没有副作用，为了尽可能的减少影响，可以直接停止这个包的发布。
监控
发布效果监控可以查看升级百分比，也支持特定用户的对某个发布的结果查询。
全量更新由于包较大，可能有较高的下载失败率，一个版本的 app 就有可能对应不同版本的离线包，一旦线上发生问题，如果前端没有监控体系，用户对离线包版本无感知，将更难定位问题。
如果资源被篡改，无监控可能都无法感知用户显示的是否是预期的页面。
总结
一个完善的 web app 发布方案对于 app 端的动态发布以及用户体验至关重要，相比传统的发布方案也更加灵活，给不同类型的业务提供更多的选择。
博文地址: 移动端离线包发布方案
以上就是这篇文章全部内容，欢迎提出建议和指正,个人联系方式详见关于。
网友评论