|
小程序•小故事(3)——更新机制-绍兴微信小程序公众号直播商城开发为你转播《小程序•小故事》第三期同大家分享小程序「更新机制」背后的故事。 背景 此前我们有收到开发者的反馈,当小程序发布新版本后,新版本覆盖率比较慢,尤其是遇到了一些紧急的 BUG时,线上覆盖速度令人着急。 小程序的更新机制异步更新机制小程序的更新需要经过两个关键的步骤: 更新检测与下载流程通常会放在启动阶段进行,小程序平台也是如此。 超过有效时间强制同步更新机制为了尽量避免这种更新延迟情况,我们还设计了一个超过有效时间同步检查更新机制,假如用户已经超过7天没有打开过小程序了,这个时候会强制同步拉取新版本信息、下载新版本,并且使用新版本启动。 更新机制引起的问题超过有效时间同步检查更新机制能确保到发布版本7天后,绝大部分用户能用上新的版本,但问题时在 7天之内使用的用户,可能在第一次启动时遇到的是异步更新机制,需要在第二次启动时才能应用新的版本。 解决这一问题的思路为了解决这个问题,我们内部也经历了数个方案的讨论,与大家分享一下我们思考的过程: 1. 同步检查更新(放弃)可能是最直接的解决思路,但这个方案的问题在于会影响小程序的启动速度,当下小程序的更新迭代是非常频繁的,部分用户可能每次启动都命中更新,如果需要同步检查更新 + 同步下载新的版本,那将会影响这部分用户的启动体验。 2. 模块热替换(放弃)模块热替换是指小程序运行起来后,将新版本的 JS 代码与页面进行热替换,使之可以在当前版本上应用上新版本的功能。 这种方案可以解决异步更新不能在本次启动马上应用上的问题,从技术上来说,这也是最好的方案,但同时缺点也比较明显,会存在新旧逻辑、页面共存问题,对于开发者来说,反而更不好处理,特别是涉及到全局变量时,情况会更复杂。 但当然这个是我们未来努力的方向。 3. 缩小定时检查新版本轮询时间(目前方案)6.6.3 及以上版本的客户端,会定时 check 最近使用过的小程序是否有发布新版本;如果有,下次冷启动(指打开非缓存在后台的小程序)的时候会同步更新新版本再打开。 4. 异步更新 + 强制更新(目前方案)同步检查更新与模块热替换两者之间的折衷方案,即还是维持异步更新机制,在异步下载完小程序代码包后,提供重启小程序的能力,这样在遇到紧急问题时可以马上解决,详请见下文介绍。 异步更新 + 强制更新方案介绍从基础库 1.9.90 开始,我们提供了 wx.getUpdateManager 接口,使用该接口,可以获知是否有新版本小程序、新版本是否下载好以及应用新版本的能力。 当小程序冷启动时,会自动向微信后台请求新版本信息,如果有新版本,会马上触发新版本的下载。开发者可以通过 wx.getUpdateManager,获知当前更新的状态。 wx.getUpdateManager 接口会返回一个 UpdateManager 实例,UpdateManager 包含了三个回调: 1. onCheckForUpdate:当小程序向后台请求完新版本信息,会通知这个版本告知检查结果<br> 还有重启应用新版本的接口: 1. applyUpdate:当新版本下载完成(onUpdateReady),调用该方法会强制当前小程序应用上新版本并重启 具体示例: 更详细信息可以参考 UpdateManager 的详细文档 应用场景强制更新比较适合紧急修复场景, 可以确保在发布后用户能马上用上新版本。 在强制重启更新前也建议先通过 showModal 方式咨询用户意见,待用户确认下再进行重启,实现方式可参考上节示例代码。 如何调试最新版本的微信开发者工具提供了强制更新的调试能力,通过编译模式 - 编辑编译模式 - 勾上「下次编译时模拟更新」即可在开发者工具上调试强制更新功能。 最新开发者工具下载链接 点我。 - END - 这是作者的赞赏码,如果你觉得这个故事,让你们有所收获,欢迎打赏给作者。 第二期回顾:小程序•小故事(2)——代码片段 第一期回顾:小程序•小故事(1)——分包加载 如果大家有想了解的小程序相关能力的故事,欢迎在评论区留言,我们后续会考虑将这些能力背后的故事分期分享给大家。 |