背景

我們都知道微信小程序有包體積限制，整個(gè)小程序所有分包大小不超過 20M，單個(gè)分包/主包大小不能超過 2M。然而面對業(yè)務(wù)的不斷更新迭代，代碼和資源會越來越多，如果不盡早規(guī)劃包體積的治理，勢必有一天會對業(yè)務(wù)的發(fā)展造成阻礙。所以如何在有效支持業(yè)務(wù)邏輯的同時(shí)，盡量減少資源占用，在小程序開發(fā)環(huán)境中顯得尤為重要。

代碼包體積是其中的一個(gè)重要方面，本文將就此進(jìn)行分析與探討。

常規(guī)治理策略

資源動態(tài)化

這個(gè)方法常常是小程序體積前期膨脹的主要原因和最有效壓縮方式。

把一些非核心不緊急的資源文件，特別是圖片、音頻、視頻等體積較大的媒體文件，可以移至cdn服務(wù)器，需要時(shí)再下載。

頁面動態(tài)化

把非核心不緊急的頁面，轉(zhuǎn)成h5，通過webview來進(jìn)行顯示。一個(gè)兩個(gè)頁面看不出什么差別，但是如果有10個(gè)8個(gè)的就很明顯了，起碼能節(jié)省出幾十kb。

靜態(tài)數(shù)據(jù)線上化

有時(shí)開發(fā)中我們會把一些不變的數(shù)據(jù)放到小程序項(xiàng)目內(nèi)，比如城市地址信息，服務(wù)條款等，這樣的數(shù)據(jù)盡量能走線上就走線上，當(dāng)首次加載完后可以緩存到本地。

及時(shí)清理廢棄資源

已下線或者已棄用的文件資源應(yīng)及時(shí)清理，包括npm包、組件、頁面、媒體資源等。若后續(xù)需要重新上線/重新使用，可以通過git等版本控制工具找回。這部分資源不需要持續(xù)占用代碼包空間。

去除重復(fù)代碼

可以使用sonar對項(xiàng)目代碼進(jìn)行分析，找到哪些代碼是重復(fù)的，可以針對進(jìn)行優(yōu)化。

提取公共模塊

業(yè)務(wù)實(shí)現(xiàn)做到通用，提取公共的業(yè)務(wù)組件，比如不同的活動可以采用統(tǒng)一模板，同一個(gè)組件，而不必每次增加新代碼。

樣式層面保持統(tǒng)一，使用統(tǒng)一的基礎(chǔ)組件， 比如可以統(tǒng)一彈窗規(guī)范，而不引入五花八門的零碎彈窗組件。

設(shè)計(jì)開發(fā)層面減少重復(fù)，多提取公共模塊，減少重復(fù)造輪子。

慎用三方插件

盡量少用第三方的插件，比如象echart，你可能只要它的1%功能，一個(gè)曲線圖，卻不得不打包它，使整個(gè)項(xiàng)目體積驟升。

配置分包（普通分包）

分包是小程序給出的類似web異步引入的一個(gè)方案，把一些初始進(jìn)入時(shí)不需要的頁面可以放進(jìn)分包里，跳轉(zhuǎn)到對應(yīng)頁面時(shí)才去下載分包，將這些頁面及其附屬資源放到分包里可以有效減少主包體積。

配置獨(dú)立分包

獨(dú)立分包是小程序中一種特殊類型的分包，可以獨(dú)立于主包和其他分包運(yùn)行。從獨(dú)立分包中頁面進(jìn)入小程序時(shí)，不需要下載主包。當(dāng)用戶進(jìn)入普通分包或主包內(nèi)頁面時(shí)，主包才會被下載。

我們可以按需將某些具有一定功能獨(dú)立性的頁面配置到獨(dú)立分包中。當(dāng)小程序從普通的分包頁面啟動時(shí)，需要首先下載主包；而獨(dú)立分包不依賴主包即可運(yùn)行，可以很大程度上提升分包頁面的啟動速度。

分包精細(xì)化

這個(gè)策略主要是為了控制和減少主包的體積，使主包體積最優(yōu)，防止一些主包未使用的資源被放入主包，而占用主包體積。

• 把只被分包使用的資源收集到分包里，比如圖片，js模塊，組件，npm包 等
• 為了確保主包體積最優(yōu)，對于組件和靜態(tài)資源，如果他們被多個(gè)分包所引用且未在主包中引用，可以將這些資源生成多份副本分別輸出到對應(yīng)分包中，而不會占用主包體積。

體積分析

在遇到主包體積偏大后，我們需要弄明白，主包里有哪些東西？它們?yōu)槭裁催@么大？

可以使用原生小程序開發(fā)者工具自帶的分析工具或者可以借助 webpack-bundle-analyzer 這樣一個(gè)webpack插件去做輔助分析，它可以直觀分析打包出的文件包含哪些，大小占比如何，模塊包含關(guān)系，依賴項(xiàng)，文件是否重復(fù)，壓縮后大小如何，我們可以做針對性優(yōu)化。

終極大招

啟動圖方案

啟動圖在app上見的最多，雖然在小程序上確很少見，卻是一個(gè)很不錯(cuò)的方案。

這也是滴滴小程序的優(yōu)化方案，為小程序配一個(gè)啟動圖，頁面一旦渲染，便立即跳轉(zhuǎn)到其他分包頁面，主包只有一個(gè)啟動圖頁面和整個(gè)項(xiàng)目用到的基礎(chǔ)庫，這樣主包的體積就基本固定了，業(yè)務(wù)持續(xù)迭代也不會增加主包的體積。

雖然這個(gè)方案是行之有效的，但需要評估是否適合自身業(yè)務(wù)，這種體驗(yàn)是否可以被接受。

不過筆者來來回回體驗(yàn)了下滴滴小程序的啟動到頁面的出現(xiàn)，感覺還是很贊的。

邏輯動態(tài)化

這個(gè)算是終極大招了，不過技術(shù)實(shí)現(xiàn)難度也很有挑戰(zhàn)。就是把代碼放到遠(yuǎn)程，然后運(yùn)行時(shí)拉取代碼到本地并執(zhí)行然后進(jìn)行渲染頁面。這樣只需要內(nèi)置一個(gè)運(yùn)行時(shí)sdk用來執(zhí)行遠(yuǎn)程js代碼，而業(yè)務(wù)代碼放在遠(yuǎn)程不會占用包體積。

當(dāng)然這個(gè)方案目前業(yè)內(nèi)使用較少，社區(qū)內(nèi)也有一些相關(guān)的參考資料，不過不太多，需要很多的基礎(chǔ)建設(shè)。有興趣的小伙伴可以自己研究一下。

總結(jié)

由于輕量級特性，小程序開發(fā)環(huán)境中，對代碼包體積的控制是十分必要且十分有意義的。常規(guī)體積優(yōu)化策略也就是盡量只將最核心最必要最緊急的內(nèi)容放在代碼包內(nèi)。其它資源過多占用代碼包空間時(shí)，則考慮通過搬移/刪除/壓縮/合并等方式予以釋放。

但在業(yè)務(wù)的持續(xù)迭代下，代碼量也會不斷增多，仍然無法突破小程序的限制，所以仍然存在體積隱患。

當(dāng)然還有一些特殊的處理方式可以更大程度的解決這個(gè)隱患，主要就是啟動圖方案和終極大招邏輯動態(tài)化（突破限制）。

參考資料：

https://juejin.cn/post/6844904191362596878

https://mp.weixin.qq.com/s/YXM5gqHzTZlMgQD0DImImA