百度智能小程序 加速initData的生成

合理使用分包

基礎庫 3.60.2 及以上版本開始支持獨立分包頁面，3.170.3 及以上版本開始支持獨立分包頁面引用自定義組件。

Tips：在搜索結果和信息流頁面，小程序底層框架將預先下載主包的邏輯與資源，請將小程序分發(fā)和重要的頁面放到主包里，其它頁面合理的劃分到其它分包中。

結合智能小程序的啟動流程，包下載與解析是整個啟動過程中的一種重要階段，該階段耗時與小程序頁面所屬包大小呈正相關，將直接影響到 initData 完成收集的時間，從而影響首屏渲染。

因此，可以采用分包相關技術：普通分包、獨立分包、分包預下載，來優(yōu)化包處理的幾個關鍵階段，以減小 initData 的準備時間，最大程度提前首屏渲染起始點。

下述案例對比了未使用分包、使用普通分包、使用獨立分包三種不同方式的資源下載耗時（實際可能受網(wǎng)絡影響，但耗時趨勢一致）。

接下來，我們將介紹使用分包將帶來的優(yōu)勢。

減小包下載時間

我們以某個小程序為例，在未分包、普通分包和獨立分包的情況下，小程序包下載流程如下:

從上圖可以了解小程序包下載流程大致過程，總結為：

1. 如果沒有分包，首次啟動將下載小程序完整包；
2. 首次啟動普通分包中的頁面時，宿主客戶端將會下載主包和該頁面分包資源；
3. 首次啟動獨立分包中的頁面時，宿主客戶端只下載該頁面分包資源。

當清楚小程序包下載過程之后，我們可以將頁面進行合理的分包，然后最大程度節(jié)省當前頁面所屬包的下載時間。

當小程序發(fā)布時，小程序的業(yè)務代碼將被打包在一起，在小程序啟動時一次性下載完成。如果使用分包策略，小程序的代碼將會被劃分為一個主包（包含小程序啟動時會馬上打開的頁面代碼和相關資源）和其余分包（包含分包頁面的代碼和資源）。

當啟動小程序時（假設打開頁面在主包內(nèi)），則主包下載完成后將會立即啟動小程序，節(jié)省其它分包代碼的加載時間。

例子：

假設有一個資訊類小程序，其中最主要的頁面是主頁和資訊詳情頁，可以使用分包策略，將主頁和資訊詳情頁劃分到主包，其它頁面（工具頁和非主要頁面）合理劃分到其它分包，當啟動主頁或者資訊詳情頁時，宿主App將只下載主包，隨后立即開始邏輯加載。

減小包執(zhí)行時間

當下載完小程序包之后，其邏輯代碼會被加載到適當?shù)木€程中執(zhí)行，執(zhí)行過程中將會調(diào)用基礎庫底層接口完成初始化工作。

從以下圖可以看出三種分包情況下，頁面注冊與初始化工作耗時情況：

具體工作如下：

• 如果沒有使用分包，將進行以下工作：
  • 執(zhí)行所有頁面 JS 文件及其依賴所有文件；
  • 注冊所有頁面，調(diào)用所有頁面的 Page 構造器方法，來記錄頁面的基礎信息（包括初始數(shù)據(jù)、方法，以及其它的合成過程）；
  • 所有頁面需要的其它初始化工作。

在此過程中，我們不難看出，除某些高頻可能被隨即打開的頁面，其它頁面的邏輯加載執(zhí)行都是比較浪費啟動過程資源的。

• 如果合理使用分包，在啟動過程將只會執(zhí)行該頁面所屬包的相關邏輯：
  • 執(zhí)行該頁面所屬包中的 JS 文件及其依賴文件；
  • 注冊該包中的頁面，調(diào)用該包中頁面的 Page 構造器方法，來記錄頁面的基礎信息（包括初始數(shù)據(jù)、方法，以及其它的合成過程）；
  • 包中頁面需要的其它初始化工作。

從以上執(zhí)行流程，我們可以了解到合理使用分包將會最大程度減小初始化時間。

分包預下載

在使用分包加載后，雖然能夠顯著提升小程序的啟動速度，但是當跳轉到其它分包頁面時，需要等待該分包下載完成后才能打開頁面，將會造成頁面切換的延遲，影響小程序的使用體驗。

分包預下載（swan.loadSubPackage）可以解決首次進入分包頁面帶來的延遲問題。使用之后，在用戶進入分包頁面之前就預先將分包下載完成，當用戶進入分包頁面時就能夠更快的啟動頁面。

以下為分包預下載過程：

開發(fā)者可以預先配置某個頁面可能會跳轉到的分包（當啟動頁面為獨立分包頁面時，也可以預下載主包），在進入小程序某個頁面時，由基礎庫在后臺自動預下載可能需要的分包。用戶在進行頁面跳轉時，該分包通常已經(jīng)下載完成，無需額外等待，可以有效提升進入后續(xù)分包頁面時的啟動速度。

合理使用動態(tài)庫

動態(tài)庫，是指可被添加到小程序內(nèi)直接使用的功能組件。開發(fā)者可直接在小程序內(nèi)使用動態(tài)庫，無需重復開發(fā)，為用戶提供更豐富的服務。具體動態(tài)庫使用請參考動態(tài)庫的使用。

加載流程與原理

我們從 智能小程序的啟動流程 章節(jié)可以了解到，動態(tài)庫的獨立資源將在邏輯和渲染層分別進行加載，在此過程中將會加載動態(tài)庫的全部代碼（邏輯和樣式），然后解析執(zhí)行，但實際上引用的動態(tài)庫中往往包含大量未使用的邏輯，導致加載過程中大量資源的浪費，從而阻塞 initData 的收集時間，進而直接影響到頁面渲染。

針對于此，我們提出以下使用建議：

• 充分了解所使用的動態(tài)庫功能，如果只需要少部分功能，則不必引用其龐大的動態(tài)庫拖慢整個加載過程，可以選擇在小程序中編寫功能邏輯；
• 正確引用動態(tài)庫中的自定義組件，參考 合理使用自定義組件。

合理使用 App.onLaunch

App.onLaunch是進入小程序的第一個生命周期函數(shù)，很多開發(fā)者會在App.onLaunch中執(zhí)行一些初始化操作。如果使用不當，會顯著影響首屏顯示速度。

使用建議

1. 避免在 App.onLaunch 中執(zhí)行耗時很長的任務。有可能的話，將任務推移到頁面顯示完成后執(zhí)行。
2. 減少、避免在 App.onLaunch 中調(diào)用一些同步 API。使用異步 API 代替同步，并盡量減少、延后首頁面顯示非必需的 API 調(diào)用。
3. 將 App.onLaunch 中的頁面請求放在 Page.onInit 生命周期中：一些開發(fā)者為了提前首頁面網(wǎng)絡請求，會將數(shù)據(jù)請求代碼放到 App.onLaunch 中執(zhí)行；高版本的基礎庫提供了 Page.onInit，如果 App.onLaunch 耗時較短，則可以認為將頁面網(wǎng)絡請求放在自身的 Page.onInit 中，效果與 App.onLaunch 近似。

示例 

在開發(fā)者工具中打開

App({
    onLaunch: function () {
        const key = 'app-launch-id';
        // 模擬長任務
        let count = 3000;
        while (count--) {
            const value = swan.getStorageSync(key);
            swan.getStorageSync(key, value ? +value : 1);
        }
    }
});

從下圖可以明顯地看出，App.onLaunch 的耗時越長，首頁面白屏的時間越長。