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

合理使用分包

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

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

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

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

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

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

減小包下載時(shí)間

我們以某個(gè)小程序?yàn)槔?，在未分包、普通分包和?dú)立分包的情況下，小程序包下載流程如下:

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

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

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

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

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

例子：

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

減小包執(zhí)行時(shí)間

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

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

具體工作如下：

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

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

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

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

分包預(yù)下載

在使用分包加載后，雖然能夠顯著提升小程序的啟動(dòng)速度，但是當(dāng)跳轉(zhuǎn)到其它分包頁面時(shí)，需要等待該分包下載完成后才能打開頁面，將會(huì)造成頁面切換的延遲，影響小程序的使用體驗(yàn)。

分包預(yù)下載（swan.loadSubPackage）可以解決首次進(jìn)入分包頁面帶來的延遲問題。使用之后，在用戶進(jìn)入分包頁面之前就預(yù)先將分包下載完成，當(dāng)用戶進(jìn)入分包頁面時(shí)就能夠更快的啟動(dòng)頁面。

以下為分包預(yù)下載過程：

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

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

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

加載流程與原理

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

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

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

合理使用 App.onLaunch

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

使用建議

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

示例 

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

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

從下圖可以明顯地看出，App.onLaunch 的耗時(shí)越長(zhǎng)，首頁面白屏的時(shí)間越長(zhǎng)。