• 減少主包體積
  • 為何要減少主包體積
  • 主包里都包含什么內(nèi)容
  • 減少主包體積的方式
  • 方式1：減少主包中包含的頁面
    • 思考1：主包中應(yīng)該包含什么內(nèi)容呢？
    • 思考2：如何在不影響外部推廣的情況下，剔除主包中的部分頁面？
      • 注意：
    • 思考3：主包中的內(nèi)容是越少越好么？
    • 思考4：其他的頁面分成幾個子包合適？
      • 1、【并行下載子包數(shù)量】
      • 2、【包體積與下載失敗率】
      • 3、【分包頁面與主包頁面緊密程度、頁面入口pv】
  • 方式2：減少自定義組件
    • 1、減少共用的自定義組件
    • 2、減少非共用的自定義組件
• 方式3：優(yōu)化公共資源
  • 1、優(yōu)化 fn.js 文件
  • 2、優(yōu)化公共資源中的 css
  • 3、優(yōu)化公共資源中的圖片

減少主包體積

為何要減少主包體積

從前文小程序的啟動流程得知，在打開小程序的頁面時會經(jīng)過【下載小程序包】、【加載主包資源】、【執(zhí)行頁面邏輯】等過程，如果主包中內(nèi)容較多，會影響【下載小程序包】和【加載主包資源】的時長，頁面展示就會變慢，fmp 也會升高。在性能優(yōu)化中，我們需要找到各種辦法降低fmp。

主包里都包含什么內(nèi)容

我們先來看看小程序的編譯邏輯：

來源	內(nèi)容	編譯后去向
主包	.swan / .js / .css / .json	主包
分包	.swan / .js / .css / .json	分包
自定義組件	.swan / .js / .css / .json	主包
公共資源中	.js	整個項目中，引用次數(shù)大于1的文件編譯在 主包 中，其他在分包中
	.css	編譯到引用的各個頁面中，編譯后當(dāng)前css內(nèi)容的體積會成倍增長
	圖片 / .json	主包
npm包	服務(wù)組件 / 插件 / 動態(tài)庫	主包
	utils方法	整個項目中，引用次數(shù)大于1的文件，編譯在 主包 中，其他在分包中
	模板	如果模板被開發(fā)者放入主包中，編譯后就在主包中；如果放入分包中，編譯后就在分包中

從上表中的編譯邏輯可以分析出：

• 自定義組件（插件、動態(tài)庫等）編譯時都會打包到主包中，目前還不支持依賴分析，這些內(nèi)容的體積會影響主包大小
• 公共資源中的圖片在編譯時無法進(jìn)行依賴分析，所以會直接劃分到主包中

減少主包體積的方式

方式1：減少主包中包含的頁面

思考1：主包中應(yīng)該包含什么內(nèi)容呢？

首先按官網(wǎng)規(guī)定，app.json - tabBar 中設(shè)置的頁面，是必須要放在主包中的，其次重點頁面也需要放在主包中。從 fmp 計算方式可知，我們需要知道小程序中哪些是入口頁面。這方面的信息，從開發(fā)者平臺的數(shù)據(jù)中可以查到。在開發(fā)者平臺找到目標(biāo)小程序的【數(shù)據(jù)分析-行為分析】，我們可以按入口頁次數(shù)排序，找到訪問量大的頁面，這些就是需要放在主包中的頁面。

需要注意的是，如果小程序入口較為分散，則需要計算出多少個頁面對小程序整體 fmp 有較大影響。

思考2：如何在不影響外部推廣的情況下，剔除主包中的部分頁面？

如果主包中已經(jīng)包括了很多不重要的頁面，且不確定是否有外部推廣，不敢隨意改動真是路徑，我們可以選擇通過自定義路由來映射 path 與真實頁面路徑，從而在不影響外部推廣的前提下，把這部分頁面從主包中劃分出去，減少主包體積。
以某政務(wù)小程序為例，主包中的頁面從訪問量小的開始算，從主包中使用自定義路由移除48個頁面，fmp提升了5%左右。在使用自定義路由后，項目上線時需要注意小程序基礎(chǔ)庫版本的升級。

注意：

• 自定義路由雖然可以讓我們很方便的分包，但過多的自定義路由配置，會增加小程序初始化時長，從而增加整體 fmp 時長。所以自定義路由在必須配置的前提下，越少越好。以某政務(wù)小程序為例，增加50個自定義路由配置后，fmp 增加了15ms。
• app.json中在設(shè)置 app.json - preloadRule 時，key值并沒有用處，所以增加路由后，key 值寫成 path 還是真實路徑都可以，小程序框架框架中只會讀取 value 值。

思考3：主包中的內(nèi)容是越少越好么？

這就要結(jié)合小程序的主包、分包下載機(jī)制來看，如果頁面在分包中的話，打開頁面時會同時需要下載主包和分包。

入口	下載內(nèi)容
入口為主包頁面	主包
入口為分包a中的頁面	主包、分包a

思考4：其他的頁面分成幾個子包合適？

這要從小程序并行下載子包數(shù)量、包體積與下載失敗率的關(guān)系、分包頁面與主包頁面緊密程度、頁面入口 pv 等幾個方面來綜合衡量。

1、【并行下載子包數(shù)量】

小程序雙端并發(fā)下載數(shù)量較少，大概率都是串行下載，所以分包數(shù)量不宜過多。

2、【包體積與下載失敗率】

雙端下載失敗率均在千分之幾以內(nèi)，按經(jīng)驗來說，如果待下載的內(nèi)容在 1M 以下的體積，下載失敗率可以忽略不計

3、【分包頁面與主包頁面緊密程度、頁面入口pv】

這是個需要具體小程序具體分析的問題。以某政務(wù)小程序為例：

• 某政務(wù)小程序小程序頁面很多，首先我們分出了頁面月總pv在500的以下，這些訪問量很小的頁面被分在 lower 分包中
• 從開發(fā)者可查詢到主包頁面的跳轉(zhuǎn)依賴的頁面數(shù)據(jù)，這些依賴頁面打在 mainDep 包中，其中刨除掉 lower 中已有的
• lower 分包中的頁面由于訪問量很小，在 app.json - preloadRule 中設(shè)置需要下載的分包時，不設(shè)置 lower 分包
• 綜合考慮后某政務(wù)小程序分為 mainDep 和 lower 2個 分包

方式2：減少自定義組件

1、減少共用的自定義組件

根據(jù)編譯邏輯可知，小程序中使用的所有自定義組件目前還無法按需加載，這些自定義組件暫時都會編譯到主包中。由于分包頁面都不是重點頁面，只在分包中使用的自定義組件，可以考慮直接放在分包各頁面的模板中，減少主包體積。

2、減少非共用的自定義組件

只有一個頁面使用的自定義組件，可以直接合并到頁面模板中，減少初始化和創(chuàng)建自定義組件的損耗。

方式3：優(yōu)化公共資源

1、優(yōu)化 fn.js 文件

fn.js 文件就是我們常說的公共資源或者 utils 中的 js 文件，根據(jù)編譯邏輯可知，這種 js 文件如果被引用大于1次，就會編譯到主包中。開發(fā)中往往我們的 fn.js 文件中，都會包含很多個方法，導(dǎo)致頁面無法精確的引用，從而不能更精確的編譯打包。建議每個方法寫在一個文件中，方便更精準(zhǔn)的編譯打包。

2、優(yōu)化公共資源中的 css

根據(jù)編譯邏輯可知，公共資源中的 css 文件，被頁面 css 文件引用后，編譯時會自動合并到每個頁面的 css 中。也就是說，公共資源中的css看起來是寫了一份，但編譯后會成倍復(fù)制，分別merge到引用的頁面中，所以公共資源中的 css 只提取必要內(nèi)容的即可。盡量減少引用公共資源中的 css 后，又在頁面 css 中覆蓋一遍的情況。

3、優(yōu)化公共資源中的圖片

根據(jù)編譯邏輯可知，所有在非分包頁面文件夾中的圖片，都會被打到主包中。所以需要逐個對我們的圖片做篩選，如果圖片較大，可以選擇放在 CDN 上，盡量減少主包體積。同時，壓縮圖片也是必不可少的。

網(wǎng)頁名稱：創(chuàng)新互聯(lián)百度小程序教程：減少主包體積
網(wǎng)站鏈接：http://www.5511xx.com/article/cdchhig.html