是不是經常為不知道何時能夠升級到最新的小程式包而頭疼？是不是好奇小程式包的收斂速度到底如何？這一切的一切，到底有無蹤跡可循？ ——今天我們將撥開層層迷霧，一起探索小程式包更新的現有機制～
背景
小程式包分發 & 安裝方式依託於百度App，具有分發效率高、安裝速度快等特點。但小程式包與傳統App一樣，依舊存在版本收斂率等問題。由於小程式包更新是非同步進行的，部分使用者無法在當次啟動小程式時立即使用最新版本。
令開發者經常感到困惑的痛點是： 使用者何時能夠升級到最新的小程式包？以及小程式包的收斂速度又是如何？
為了便於後續對內容進行闡述，首先對小程式的啟動方式簡單說明一下：
冷啟動
在以下情況下會觸發小程式的冷啟動：
- 當小程式首次開啟；
- 切換後臺的小程式自動銷燬後再次開啟；
- 活動的小程式達到一定數量（當前為6個）再次開啟新的小程式。
冷啟動時的小程式會載入頁面，且小程式相關資源均會被重新載入。
熱啟動
小程式切換後臺時（手機物理返回按鈕或小程式右上方關閉按鈕觸發）不會立即進行銷燬，而是會等待一定的時間（當前為5分鐘）才自動銷燬。如果此時使用者再次調起，小程式不會重新載入，而是將後臺的小程式喚醒至前臺，此時觸發的則是熱啟動。
設計思路
小程式包的更新機制應當是一個綜合舉措： 一方面需要兼顧小程式包的收斂速度，另一方面要儘量減少小程式每次啟動時下載、安裝小程式包的次數。
小程式啟動和首屏效能將直接影響使用者體驗，而小程式包的下載、安裝是啟動過程中較為耗時的一環。因此，現有小程式包的更新機制設計思路是找到一個既能照顧小程式包收斂速度又能避免每次啟動都要下載安裝的一個折中方案。
現有機制
-
小程式包冷啟動非同步更新：小程式每次冷啟動時，非同步查詢雲端是否有有小程式包更新並下載安裝小程式。並在下次冷啟動小程式時生效。
-
小程式包maxAge失效：與cookie的maxAge工作原理類似，百度App本地已下載的小程式包有效期受maxAge控制（maxAge值雲端可控，當前為5天），maxAge每個計算週期的起始時間為最近一次下載更新小程式包的時間，若本地小程式包已過期，則當次小程式啟動會同步查詢雲端小程式包的狀態，當此時有更新則繼續等待小程式包下載完成後再開啟小程式。maxAge方式能夠保證開發者最新發布的小程式包時間記為T，在（T+maxAge）內小程式包能夠有效收斂到較高水平。
-
閒時更新：增加小程式閒時場景覆蓋
典型場景：首頁二樓小程式入口、使用者個人中心入口、Feed卡片等。
在小程式開啟前預先對小程式包進行更新，從而一定程度解決小程式包非同步載入包收斂率問題。此方式是非同步更新和maxAge方式的一個有效補充。
- 標記更新：對使用者當前使用過的小程式的更新狀態進行統一標記，確定需要更新的小程式包列表。
如：在百度App宿主每次冷啟動拉取配置時，對當前使用者使用過的小程式的更新狀態進行標記。被標記為需要更新的列表則可以通過閒時更新方式觸發小程式包的更新；對於不需要更新包的小程式則可優化掉當maxAge過期時同步等待查詢小程式包更新狀態的請求。
-
其他方式，如：利用長連線通道雲端推送使用者歷史小程式包的更新，未完待續~~~
-
強制更新 getUpdateManager API： 以上方式均對開發者透明，為小程式通用機制。但為了方便開發者能夠對小程式包升級有足夠的控制能力，我們提供swan.getUpdateManager更新API供開發者選擇。開發者可以在小程式包內預埋此能力，在遇到重大版本更新或者緊急問題需要立即修復時可以採用此方式。關於swan.getUpdateManager使用請猛戳連結。
總結
如上介紹了諸多現有機制，最後附上腦圖一張便於大家理解：
