了解百度小程序的更新机制，能够解决你一些常见的问题，比如有时候进去会重新加载，有时候又不会重新加载，这一些都源于百度小程序包的更新机制。是不是经常为不知道何时能够升级到最新的小程序包而头疼？是不是好奇小程序包的收敛速度到底如何？这一切的一切，到底有无踪迹可循？ ——今天我们将拨开层层迷雾，一起探索小程序包更新的现有机制。
背景
小程序包分发 & 安装方式依托于百度App，具有分发效率高、安装速度快等特点。但小程序包与传统App一样，依旧存在版本收敛率等问题。由于小程序包更新是异步进行的，部分用户无法在当次启动小程序时立即使用最新版本。令开发者经常感到困惑的痛点是： 用户何时能够升级到最新的小程序包？以及小程序包的收敛速度又是如何？为了便于后续对内容进行阐述，首先对小程序的启动方式简单说明一下：
冷启动
在以下情况下会触发小程序的冷启动：
- 当小程序首次打开；
- 切换后台的小程序自动销毁后再次打开；
- 活动的小程序达到一定数量（当前为6个）再次打开新的小程序。
冷启动时的小程序会加载页面，且小程序相关资源均会被重新加载。
热启动
小程序切换后台时（手机物理返回按钮或小程序右上方关闭按钮触发）不会立即进行销毁，而是会等待一定的时间（当前为5分钟）才自动销毁。如果此时用户再次调起，小程序不会重新加载，而是将后台的小程序唤醒至前台，此时触发的则是热启动。
设计思路
小程序包的更新机制应当是一个综合举措： 一方面需要兼顾小程序包的收敛速度，另一方面要尽量减少小程序每次启动时下载、安装小程序包的次数。小程序启动和首屏性能将直接影响用户体验，而小程序包的下载、安装是启动过程中较为耗时的一环。因此，现有小程序包的更新机制设计思路是找到一个既能照顾小程序包收敛速度又能避免每次启动都要下载安装的一个折中方案。
现有机制
1. 小程序包冷启动异步更新：小程序每次冷启动时，异步查询云端是否有有小程序包更新并下载安装小程序。并在下次冷启动小程序时生效。2. 小程序包maxAge失效：与cookie的maxAge工作原理类似，百度App本地已下载的小程序包有效期受maxAge控制（maxAge值云端可控，当前为5天），maxAge每个计算周期的起始时间为最近一次下载更新小程序包的时间，若本地小程序包已过期，则当次小程序启动会同步查询云端小程序包的状态，当此时有更新则继续等待小程序包下载完成后再打开小程序。maxAge方式能够保证开发者最新发布的小程序包时间记为T，在（T+maxAge）内小程序包能够有效收敛到较高水平。3. 闲时更新：增加小程序闲时场景覆盖（典型场景：首页二楼小程序入口、用户个人中心入口、Feed卡片等），在小程序打开前预先对小程序包进行更新，从而一定程度解决小程序包异步加载包收敛率问题。此方式是异步更新和maxAge方式的一个有效补充。4. 标记更新：对用户当前使用过的小程序的更新状态进行统一标记，确定需要更新的小程序包列表。如：在百度App宿主每次冷启动拉取配置时，对当前用户使用过的小程序的更新状态进行标记。被标记为需要更新的列表则可以通过闲时更新方式触发小程序包的更新；对于不需要更新包的小程序则可优化掉当maxAge过期时同步等待查询小程序包更新状态的请求。5. 其他方式，如：利用长连接通道云端推送用户历史小程序包的更新，未完待续~6. 强制更新 getUpdateManager API：以上方式均对开发者透明，为小程序通用机制。但为了方便开发者能够对小程序包升级有足够的控制能力，我们提供swan.getUpdateManager更新API供开发者选择。开发者可以在小程序包内预埋此能力，在遇到重大版本更新或者紧急问题需要立即修复时可以采用此方式。关于swan.getUpdateManager使用请猛戳链接。
总结
如上介绍了诸多现有机制，最后附上脑图一张便于大家理解：