背景
此前有开发者反馈小程序发布新版本后，新版本覆盖率比较慢，因为小程序的更新机制是异步的，部分用户不会马上应用上新版本。
小程序启动会有两种情况，一种是「冷启动」，一种是「热启动」。 假如用户已经打开过某小程序，然后在一定时间内再次打开该小程序，此时无需重新启动，只需将后台态的小程序切换到前台，这个过程就是热启动；冷启动指的是用户首次打开或小程序被微信主动销毁后再次打开的情况，此时小程序需要重新加载启动。
小程序的异步更新发生在冷启动过程，当发现新版本后，会异步下载新版本的代码包，但不会马上应用上最新版本，需要等小程序下一次冷启动，才会应用上新版本。
解决思路
为了解决这个问题，我们内部也经历了数个方案的讨论，这里简单介绍下：
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用户, 在新版小游戏发布以后, 无论是冷启动还是热启动都进的是旧版的程序..
冷启动的方式是[杀掉微信], 重新进入微信, 再点击小游戏, 还是进的旧版.
只有点击别的用户分享的[新版游戏的分享], 才激发了程序更新.
感觉这样和官方描述的, 冷启动就激活更新的行为不一致?
我觉得，一般情况下，小程序不会强制用户更新的，但是有紧急bug的时候，就需要强制更新了，但是，什么时候有紧急bug需要强制更新还需要开发者自己提供接口去检查，增加了很多中小开发者的成本，最好还是平台能够提供这种能力，在发布的时候有此选项。用户使用时，可以无感知的更新到最新版，可能首次会慢一点，但是比弹框再强制更新好多了。
1. 同步检查更新（放弃）：可能是最直接的解决思路，但主要问题是会影响小程序的启动速度，当下小程序的更新迭代是非常频繁的，部分用户可能每次启动都命中更新，如果需要同步检查更新+同步下载新的版本，那将会影响这部分用户的启动体验。
“如果需要同步检查更新+同步下载新的版本，那将会影响这部分用户的启动体验。”
不同意这个观点，如果用户使用旧版本，那才是影响用户体验。我们要做的就是让用户每次都使用新版本
企业微信环境打开小程序，为何安卓没有提示版本升级，但是ios却有？？是兼容性问题还是BUG，有没有官方的解答下呢？！！！ios每次都能触发更新！！！，！！！安卓不行！！！
从基础库 1.9.90 开始，我们提供了 wx.getUpdateManager 接口，使用该接口，可以获知是否有新版本小程序、新版本是否下载好以及应用新版本的能力。
这句中的，是否有新版本的判断标准是什么？开发者有新的审核通过并发布？还是设置过小程序的版本库？还是其它什么，望各位大神回复。
调用updateManager.onCheckForUpdate返回true后，是否会立即下载最新版本，再调用updateManager.onUpdateReady
这篇文档比较详细啊,看懂了
我想知道我写了强制更新这个触发事件,然后在我的开发工具里面模拟版本更新的场景也是有出现提示更新的弹框的,但是我刚才发布到线上之后,却没看到这个时间触发,是咋回事
后面我是直接点发布,不要登录体验版的小程序,然后过一会再去登录正式的小程序,就看到了
有个应用上的问题，开发者如何区分该次更新是需要强制更新的版本？不知这个问题官方有什么建议，从提供的代码示例来看，无法区分是否包含“紧急修复线上严重bug“急需要强制更新的场景。
有啊，如果你发布的是测试版api，紧不紧急