背景
此前有开发者反馈小程序发布新版本后,新版本覆盖率比较慢,因为小程序的更新机制是异步的,部分用户不会马上应用上新版本。
小程序启动会有两种情况,一种是「冷启动」,一种是「热启动」。 假如用户已经打开过某小程序,然后在一定时间内再次打开该小程序,此时无需重新启动,只需将后台态的小程序切换到前台,这个过程就是热启动;冷启动指的是用户首次打开或小程序被微信主动销毁后再次打开的情况,此时小程序需要重新加载启动。
小程序的异步更新发生在冷启动过程,当发现新版本后,会异步下载新版本的代码包,但不会马上应用上最新版本,需要等小程序下一次冷启动,才会应用上新版本。
解决思路
为了解决这个问题,我们内部也经历了数个方案的讨论,这里简单介绍下:
1. 同步检查更新(放弃):可能是最直接的解决思路,但主要问题是会影响小程序的启动速度,当下小程序的更新迭代是非常频繁的,部分用户可能每次启动都命中更新,如果需要同步检查更新+同步下载新的版本,那将会影响这部分用户的启动体验。
2. 模块热替换(放弃):从技术上来说,这是最好的方案,小程序运行起来后,在打开新页面时,马上应用新版本里的页面,但这就会存在新旧逻辑、页面共存问题,对于开发者来说,反而更不好处理,特别是涉及到全局变量时,情况会更复杂,对于我们已有的框架来说,也是一个大挑战,不过这个也是我们之后努力的方向。
3. 定时 check 新版本(目前方案):6.6.3 及以上版本的客户端,会定时 check 最近使用过的小程序是否有发布新版本;如果有,下次打开的时候会同步更新新版本再打开。这可以保证在新版本发布 24 小时后,所有小程序都能使用最新版本。(这部分是微信客户端自身优化,开发者无需关心)
4. 异步更新 + 强制更新(目前方案):同步检查更新与模块热替换两者之间的折衷方案,即还是维持异步更新机制,在异步下载完小程序代码包后,提供重启小程序的能力,这样在遇到紧急问题时可以马上解决。
异步更新 + 强制更新方案介绍
从基础库 1.9.90 开始,我们提供了 wx.getUpdateManager 接口,使用该接口,可以获知是否有新版本小程序、新版本是否下载好以及应用新版本的能力。
当小程序冷启动时,会自动向微信后台请求新版本信息,如果有新版本,会马上触发新版本的下载。开发者可以通过 wx.getUpdateManager,获知当前更新的状态。
wx.getUpdateManager 接口会返回一个 UpdateManager 实例,UpdateManager 包含了三个回调:
1. onCheckForUpdate:当小程序向后台请求完新版本信息,会通知这个版本告知检查结果
2. onUpdateReady:当新版本下载完成,会回调这个事件
3. onUpdateFailed: 当新版本下载失败,会回调这个事件
还有重启应用新版本的接口:
1. applyUpdate:当新版本下载完成(onUpdateReady),调用该方法会强制当前小程序应用上新版本并重启
具体示例:
// wx.getUpdateManager 在 1.9.90 才可用,请注意兼容
const updateManager = wx.getUpdateManager()
updateManager.onCheckForUpdate(function
(res) {
// 请求完新版本信息的回调
console.log(res.hasUpdate)
})
updateManager.onUpdateReady(function
() {
wx.showModal({
title: '更新提示',
content: '新版本已经准备好,是否马上重启小程序?',
success: function
(res) {
if
(res.confirm) {
// 新的版本已经下载好,调用 applyUpdate 应用新版本并重启
updateManager.applyUpdate()
}
}
})
})
updateManager.onUpdateFailed(function
() {
// 新的版本下载失败
})
更详细信息可以参考 UpdateManager 的详细文档
最佳实践
从用户体验上来说,我们还是建议只在非常必要时才强制用户重启更新,例如出现线上紧急 BUG。通常情况下,可以选通过 wx.showModal 弹出选择框让用户选择是否重启更新(实现请参考示例代码)。
如何调试
最新版本的微信开发者工具提供了强制更新的调试能力,通过编译模式 - 编辑编译模式 - 勾上「下次编译时模拟更新」即可在开发者工具上调试强制更新功能。
最新开发者工具下载链接 点我。
工具测试没问题,发布线上新版本并没有出现强制更新啊,老大,你们区分新版本的标准是什么??发布一个新版本就是吗?
为什么在真机上发的体验版本就会出现报错
这写的很好、
方案二,为何不能交给开发者去判断?开发者自己最清楚是否涉及到全局变量。如果没有,就采用模块热替换。这些更新方案,就可以在新版发布时提供可选项由开发者自由选择。
还是先不用这个功能了
我今天发布新版本测试,ios是正常的,但是写的wx.showModal没有生效,只是出现了类似showToast那种效果,文字是更新中。。。而安卓则没有任何反应,还是得重新删除搜索才是新版本。
ios:微信版本6.6.5
安卓:微信版本6.6.5
基础库都是1.9.94
开发工具模拟是正常的
怎么搞啊大佬们!
问两个问题:
红框1:如果是下次打开时同步更新新版本,那样不就像前面说的影响了用户的使用体验了吗?
这个“24小时”是怎么来的?如果用户24小时内不打开小程序,又怎么能保证用户一定会用上新版本小程序呢?
都说了新版本发布的24后,你发布版本没有审核通过的时间吗?
我知道它的意思是新版本发布24小时后,问题是这个24小时具体是代表什么时间?
因为它说的是6.6.3及以上版本的客户端会定时check最新使用过的小程序是否有发布新版本,但是并没有说检测到新版本就在后台静默更新掉,而是还是需要用户在“下次打开的时候”先更新版本再打开,这样不就变成了同步更新了吗?用户不就需要等待新版本下载、不就是会影响到用户体验了吗?
如果实际的更新操作依然需要用户来触发,那它又怎么能保证用户一定会在24小时之内再次访问他最新使用过的所有小程序,以保证所有小程序都能得到更新呢?
除非它这里写错了,实际的更新操作会在微信客户端check到小程序有更新之后就立即执行更新,以保证用户在下一次打开小程序时能立即使用新版本,否则它这里说的就是自相矛盾的。