# 啟動性能 小程序啟動是小程序用戶體驗中極為重要的一環，啟動耗時過長會造成小程序用戶流失。 > 本章節的啟動只包括小程序冷啟動，不包括小程序后臺切前臺的熱啟動。 ## 一、啟動流程 在進行啟動優化之前，先簡單介紹以下小程序的啟動過程。在小程序啟動過程中，主要包括以下幾個方面： * 注 1：小程序啟動的這些部分不是串行完成的，會盡可能的并行進行。 * 注 2：小程序啟動各部分不是每次啟動都完整進行的，會盡可能的利用緩存。 ### 1\. 資源準備 #### 1.1 小程序相關信息準備 在用戶訪問小程序時，微信客戶端需要從微信后臺獲取小程序的配置、版本、權限等相關信息，以對小程序進行必要的版本管理、權限控制和校驗等。 **對啟動耗時的影響** 信息的獲取和更新會影響小程序的啟動耗時，尤其體現在用戶首次訪問小程序時。 為了在盡量降低影響啟動耗時的情況下保證信息的實時性，這些信息會在本地緩存，并通過一定的機制定期進行更新。 #### 1.2 小程序運行環境準備 在執行小程序代碼之前，微信客戶端需要準備小程序運行的基礎環境。 小程序的運行環境包括小程序進程、原生部分的 UI 元素（如 導航欄、tabBar等）、渲染頁面使用的 WebView 容器、運行開發者 JS 代碼的 JS 引擎、小程序基礎庫等等。 **對啟動耗時的影響** 運行環境的準備耗時較長，對小程序的啟動耗時有明顯影響。 為了盡可能的降低運行環境準備對啟動耗時的影響，微信客戶端會根據用戶的使用場景和設備資源的使用情況，提前對運行環境進行部分地預加載。但由于受到設備資源和操作系統調度的影響，目前很難保證每次小程序啟動時都有預加載的環境。 #### 1.3 小程序代碼包準備 小程序啟動時需要從服務器獲取代碼包地址、下載小程序代碼包，并對代碼包進行校驗。根據小程序頁面所在分包和使用的插件不同，一次啟動可能需要下載多個代碼包或插件包。 當小程序版本發生更新時，微信客戶端還需要對代碼包進行增量更新。 **對啟動耗時的影響** 下載耗時是啟動耗時中的重要瓶頸，與代碼包或增量包的體積正相關。微信采用 ZSTD 算法對小程序代碼包進行壓縮，以盡可能降低下載過程中傳輸的數據量。 考慮到包大小對用戶體驗的影響，平臺限制單個代碼包的大小上限為 2M。代碼包上限的增加對于開發者來說，能夠實現更豐富的功能，但對于用戶來說，也增加了下載流量和本地空間的占用。為了保證啟動速度，開發者應該盡可能的控制代碼包大小。 ### 2\. 開發者代碼注入（邏輯層） 小程序啟動時需要從代碼包內讀取小程序的配置和代碼，并注入到 JS 引擎中。在主包代碼注入過程中，會觸發小程序的?App.onLaunch?和首次?App.onShow?生命周期。在開發者代碼注入完成后，框架側會根據用戶訪問的頁面進行一些頁面數據初始化工作，觸發首頁的?Page.onLoad,?Page.onShow?事件。 **對啟動耗時的影響** 開發者代碼的注入耗時直接影響小程序的啟動耗時。在主流的 JS 引擎中，代碼注入耗時包括編譯和執行等環節，代碼量、同步接口調用和一些復雜的計算，都會影響注入耗時。 由于首頁渲染需要使用邏輯層發送的數據，如果開發者代碼注入耗時過長，也會延遲首頁渲染開始的時間。 在部分平臺上，微信客戶端會使用 V8 引擎的 Code Caching 技術對代碼編譯結果進行緩存，降低二次注入時的編譯耗時。 ### 3\. 開發者代碼注入（渲染層） 開發者的 wxss 和 wxml 會經過編譯注入到渲染層，包含頁面渲染需要的頁面結構和樣式信息。渲染層的注入耗時主要和頁面結構復雜度和使用的自定義組件數量有關。 渲染層和邏輯層的開發者代碼注入是并行進行的。 **對啟動耗時的影響** 由于首頁渲染需要使用渲染層的頁面結構和樣式信息，如果開發者代碼注入耗時過長，會延遲首頁渲染開始的時間。 ### 4\. 首頁（初次）渲染 在開發者代碼注入完成后，結合邏輯層得到的數據和渲染層得到的頁面結構和樣式信息，小程序框架會進行小程序首頁的渲染，展示小程序首屏，并觸發首頁的?Page.onReady?事件。Page.onReady?事件觸發標志小程序啟動過程完成。 **對啟動耗時的影響** 首頁渲染耗時主要受頁面結構和參與渲染的數據量影響。 ## 二、關鍵概念 在討論小程序啟動耗時時，需要明確幾個概念： ### 1\. 小程序首屏渲染完成 從開發者角度看，小程序首屏渲染完成的標志是首頁?Page.onReady?事件觸發。 從框架的角度來說，小程序的首屏的內容是基于小程序的初始數據，以及在渲染開始前到達的 setData 數據渲染的。 首屏渲染完成不表示小程序頁面一定有完整內容，開發者觸發的?setData（例如通過?wx.request?異步請求數據）不一定能參與到首屏渲染中。 由于框架和啟動流程的差異，小程序定義的首屏渲染完成不等同于瀏覽器的 load 事件。 ### 2\. 小程序啟動階段 從用戶點擊訪問小程序到小程序首屏渲染完成（首頁?Page.onReady?事件觸發）。 ### 3\. 打開率/到達率 小程序首屏渲染完成 PV 與 用戶點擊訪問小程序 PV 的比值。流失率 = 1 - 打開率 ## 三、啟動性能優化 在啟動流程中，小程序代碼包準備、開發者代碼注入和首頁渲染是與開發者相關的，開發者可以進行一定的優化工作。其他部分目前開發者暫時無法干預，框架側負責進行持續的優化。 ### 1\. 小程序代碼包優化 代碼包優化的核心手段是降低代碼包大小，代碼包大小直接影響了下載耗時，影響用戶啟動小程序時的體驗。 開發者可以采取以下手段優化代碼包大小： #### 1.1 分包加載 使用?[分包加載](https://www.w3cschool.cn/weixinapp/weixinapp-jmfc390f.html#)?是**優化小程序啟動耗時效果最明顯的手段**。建議開發者按照功能劃分，將小程序的功能按使用頻率和場景拆分成分包，實現代碼包的按需加載。 分包加載具有以下優勢： * 承載更多功能：小程序單個代碼包的體積上限為 2M，使用分包可以提升小程序代碼包總體積上限，承載更多的功能與服務。 * 降低代碼包下載耗時：使用分包后可以顯著啟動時需要下載的代碼包大小，在不影響功能正常使用的前提下明顯提升啟動耗時。 * 降低開發者代碼注入耗時：小程序啟動時會一次性注入全部的開發者代碼，使用分包后可以降低注入的代碼量，從而降低注入耗時。 * 降低頁面渲染耗時 此外，結合分包加載的幾個擴展功能，可以進一步優化啟動耗時： [分包預下載](https://www.w3cschool.cn/weixinapp/weixinapp-fzrm390g.html) 在使用「分包加載」后，雖然能夠顯著提升小程序的啟動速度，但是當用戶在使用小程序過程中跳轉到分包內頁面時，需要等待分包下載完成后才能進入頁面，造成頁面切換的延遲，影響小程序的使用體驗。分包預下載便是為了解決首次進入分包頁面時的延遲問題而設計的。 [獨立分包](https://www.w3cschool.cn/weixinapp/weixinapp-js3i390h.html) 但小程序中的某些場景（如廣告頁、活動頁、支付頁等），通常功能不是很復雜且相對獨立，對啟動性能有很高的要求。獨立分包可以獨立于主包和其他分包運行。從獨立分包中頁面進入小程序時，不需要下載主包。建議開發者將部分對啟動性能要求很高的頁面放到特殊的獨立分包中。 獨立分包和分包預下載可以配合使用，獲得更好的效果，詳情請參考[獨立分包與分包預下載教程](https://developers.weixin.qq.com/community/develop/doc/000e44abb2c7e89c2287f84b956c09) #### 1.2 代碼重構和優化 通過代碼重構，降低代碼冗余。在使用如 Webpack 等打包工具時，要盡量利用 tree-shaking 等特性去除冗余代碼，也要注意防止打包時引入不需要的庫和依賴。 #### 1.3 控制代碼包內圖片等資源 避免在代碼包中包含或在 WXSS 中使用 base64 內聯過多、過大的圖片，應盡量采用網絡圖片。代碼包內的圖片一般應只包含一些體積較小的圖標。聲音、視頻等其他類型的資源應盡量避免放到代碼包中。 小程序代碼包在下載時會使用 ZSTD 算法進行壓縮，降低下載時傳輸的數據量。這些資源文件會占用大量代碼包體積，并且通常難以進一步被壓縮，對于下載耗時的影響比代碼文件大得多。 #### 1.4 及時清理沒有使用到的代碼和資源 在日常開發的時候，我們可能引入了一些新的庫文件，而過了一段時間后，由于各種原因又不再使用這個庫了，我們常常會只是去掉了代碼里的引用，而忘記刪掉這類庫文件了。 目前小程序打包是會將工程下所有文件都打入代碼包內，也就是說，這些沒有被實際使用到的庫文件和資源也會被打入到代碼包里，從而影響到整體代碼包的大小。 ### 2\. 開發者代碼注入優化 開發者代碼注入的優化可以從優化執行耗時和優化代碼量兩部分著手。 #### 2.1 減少啟動過程的同步調用 在小程序啟動流程中，會注入開發者代碼并順序同步執行?`App.onLaunch,?App.onShow,?Page.onLoad,?Page.onShow`。在小程序初始化代碼（Page，App 定義之外的內容）和啟動相關的幾個生命周期中，應避免執行復雜的計算邏輯或過度使用Sync結尾的同步API，如?wx.getStorageSync，wx.getSystemInfoSync?等。對于?getSystemInfo,?getSystemInfoSync?的結果應進行緩存，避免重復調用。 #### 2.2 使用懶注入 通常情況下，在小程序啟動時，啟動頁面所在分包和主包（獨立分包除外）的所有JS代碼會全部合并注入，包括其他未訪問的頁面以及未用到自定義組件，造成很多沒有使用的代碼注入到小程序運行環境中，影響注入耗時和內存占用。 自基礎庫版本 2.11.1 起，小程序支持僅注入當前頁面需要的自定義組件和當前頁面代碼，以降低小程序的啟動時間和運行時內存。開發者可以在?app.json?中配置： ~~~ { "lazyCodeLoading": "requiredComponents" } ~~~ 注意：添加這項配置后，未使用到的代碼文件將不被執行。 ### 3\. 頁面渲染優化 #### 3.1 提前首屏數據請求 大部分小程序在渲染首頁時，需要依賴服務端的接口數據，小程序為開發者提供了提前發起數據請求的能力： * [數據預拉取](https://www.w3cschool.cn/weixinapp/weixinapp-gik9390i.html#)：能夠在小程序冷啟動的時候通過微信后臺提前向第三方服務器拉取業務數據，當代碼包加載完時可以更快地渲染頁面，減少用戶等待時間，從而提升小程序的打開速度。 * [周期性更新](https://www.w3cschool.cn/weixinapp/weixinapp-u5k7390j.html#)：在用戶未打開小程序的情況下，也能從服務器提前拉取數據，當用戶打開小程序時可以更快地渲染頁面，減少用戶等待時間。 #### 3.2 骨架屏 在頁面數據未準備好時（如需要通過網絡獲取），盡量避免展示空白頁面，應先通過骨架屏展示頁面的大致結構，請求數據返回后在進行頁面更新。以提升用戶的等待意愿。 #### 3.3 緩存請求數據 小程序提供了wx.setStorage、wx.getStorage等讀寫本地緩存的能力，數據存儲在本地，返回的會比網絡請求快。如果開發者基于某些原因無法采用數據預拉取與周期性更新，我們推薦優先從緩存中獲取數據來渲染視圖，等待網絡請求返回后進行更新。 #### 3.4 精簡首屏數據 我們推薦開發者延遲請求非關鍵渲染數據，與視圖層渲染無關的數據盡量不要放在 data 中，加快頁面渲染完成時間。 ## 四、啟動性能分析 ### 1\. 性能數據獲取 #### 1.1 小程序助手「性能分析」板塊 > 小程序管理后臺的性能數據還沒有更新，正在規劃改版中，建議在改版完成前開發者以小程序助手的性能數據為準。 建議開發者使用[小程序助手](https://www.w3cschool.cn/weixinapp/weixinapp-dmjr390k.html?RECACHE=1)中「性能分析」板塊，持續關注小程序性能。性能分析從?**啟動性能、運行性能和網絡性能**?三個維度提供性能數據，供開發者根據平臺、機型、網絡環境和訪問來源等條件做精細化分析。