前言

在 web 開發場景，減少代碼體積雖然是性能優化的一個方向，還沒到錙銖必較的程度。但是在小程序場景，由于代碼包上傳階段限制了主包 2M 和總包 16M（近期微信官方正在內測將總包上限調整至 20M ）的尺寸，超過就會面臨無法發版的風險，代碼包體積的優化就變得特別重要了。 京喜小程序首頁作為微信購物的大入口，承載大量流量，功能復雜模塊眾多，又要與其他核心業務和公共組件共享 2M 的主包空間，因此代碼包瘦身的工作在持續不斷進行，否則無法滿足業務的快速增長。本文將結合以往優化策略與最近一次的瘦身實踐，分享小程序代碼瘦身的經驗與思考。

常見的瘦身方式

京喜首頁項目是一個優化良好的項目，對于常見的優化措施，已經有過很好的實踐，就讓我們我們先回顧一下有哪些常見的優化策略吧：

代碼分包：將相對獨立的頁面和組件拆分到分包，可以解決主包體積受限問題；

依賴分析：移除未引用的頁面、組件和其他文件；

避免使用本地資源：除了兜底圖片，其他都盡可能使用 url 的方式，由于 base64 圖本質上是將信息編碼成長字符串，也會占用很多空間，不建議使用；

對所有類型的文件都進行壓縮并清理注釋，包括了：js、wxml、wxss、json；

此外，京喜首頁團隊還針對 Taro 開發場景進行了如下優化：

分析出編譯后每個文件的高頻重復代碼（如處理兼容性的 pollyfill 代碼），拆分生成公共文件，替換原引用以實現共用。

標準和工具

在開始正式介紹瘦身實踐之前，我們先來明確一下代碼包體積的衡量標準和統計方式吧。

小程序上傳代碼以代碼包尺寸為準，所謂 2M 的限制，就是指該尺寸不能超過 2048KB。

從信息傳輸角度來說，Gzip 等壓縮工具可以進行很多信息化編碼優化，因此一些內容重復是可以容忍的，但是由于我們的目標是為了解決小程序上傳限制，就只有對代碼包尺寸錙銖必較了。

在開發者工具-詳情-基本信息-上次預覽或上次上傳，可以查看到最近一次的代碼包體積，本文接下來所介紹的優化都是以縮小這個體積為目的。

但是代碼上傳生成模板速度很慢，如果每次都要根據這里的數據來統計體積變化，效率太低了。

在未改動項目配置的情況下，我們就可以間接以代碼目錄的文件體積大小作為變化參照。怎么方便的統計文件體積呢？這里我用了tree-cli，利用它提供的參數，可以輸出具備尺寸統計和排序功能的代碼文件清單：

npm install -g tree-cli // 目標目錄 cd target-directory // 輸出文件為 size-analysis.md tree -s --sort=size -o size-analysis.md

清單內容格式如下：

. ├── [ 1000] index.js ├── [ 500] index.wxss ├── [ 500] index.wxml ├── [ 500] index.json ├── [ 4000] components │ ├── [ 4000] child │ │ ├── [ 1000] index.js │ │ ├── [ 1000] index.wxml │ │ ├── [ 1000] index.wxss └── └── └── [ 1000] index.json6500 bytes used in 2 directories, 8 files

瘦身實踐

前面說到京喜首頁優化措施都做的很好了，下面即將分享的是一些不那么常見的優化方式，優化空間有大有小，想要優化小程序代碼包，建議先盡量完成前文提到的優化方案，這樣獲得的收益最明顯，然后再來看接下來提到的這些方式吧~

一、字體和顏色的全局共用

小程序文檔內關于繼承樣式的說明為：繼承樣式，如font,color, 會從組件外繼承到組件內。

分析項目現狀，我們通常會把字體定義放在公共 css 文件內，隨著頁面或組件引入公共 css，font 也將被重復引入，可以通過改造，把 font 的定義僅放在 app.wxss 內，取消組件和頁面的引入，可以達到減少整體代碼包體積的目的。

關于這一項首頁項目體積減少1%，預估整個項目還有 20kb 左右的 font 定義可清理。

如果有全局的顏色定義，也可以進行類似的優化。

二、樣式補全功能的使用

作為 web 開發者，對 -webkit- 這種前綴一定不陌生，為了適配不同瀏覽器內核，通常我們會在編譯階段使用 autoprefixer 進行樣式的自動補全。

而小程序開發者工具也提供了樣式補全的能力：詳情-本地設置-可以勾選「上傳代碼時樣式自動補全」

這個補全和我們在編譯時做的有什么不同嗎？

關鍵在于它實現的時機：如果是本地模板上傳前，那么應該和我們編譯的補全效果一樣；如果是在上傳模板后，也許可以借此減掉補全內容所占的尺寸。

結合小程序代碼包傳遞過程和樣式補全時機，大概有以下3種情況：

階段一補全：

階段二：

或者是階段三：

為了驗證猜想，來做一個實驗吧，比較「 項目編譯不補全樣式+開發者工具設置樣式補全」 vs「 項目編譯補全樣式+開發者工具不設置樣式補全」，模板體積統計如下：

可見前者比后者少了 58kb，這說明，開發者工具提供的樣式補全不是在階段一做的，不然模板體積應該和我們自己做的編譯補全基本一致。

那么，就可以愉快的去掉編譯補全，使用小程序開發者工具提供的能力了。

不過這樣改動會出現一個小問題，開發者工具內的樣式是未經補全處理的，個別樣式會有點問題，測試就發現 mask-border-source 無效，而相應真機因為已添加樣式補全沒有問題。為了不出現預覽誤會，建議給這種尚未支持的樣式手動寫上 -webkit- 前綴，保證開發和真機表現一致。

三、小心 Sass!

sass/less 等工具使得 css 的編寫變得更加流暢，函數和變量的引入也讓 css 有了一點工程化的意味。但是你有沒有觀察過 sass 的編譯實現呢？

// a.scss，作為被引用方 .banner { // 樣式定義color: red; } $COLOR = red // 變量定義（函數定義類似）// b.scss，作為使用方 @import 'a.scss'; .banner_wrapper {background: white;color:$COLOR; }

關注b.sass的編譯后：

// a.scss的引用消失了，內容被整合到文件內.banner { // a.scss內的樣式定義會被拷貝進來color: red; } .banner_wrapper {background: white;color:red; //變量定義會被按值替換 }

這里出現的問題是：我們是否需要.banner被拷貝進來呢

為了避免多引入不需要的樣式定義，有以下幾個方向：

按功能拆分 a.scss 內的樣式定義，按需引入。

使用 @include 語法，將 banner 的定義變成一個變量，按需引入。

而在小程序場景，wxss 語法支持 @import，實現了極弱版的模塊化，使得我們可以再加一個角度解決上面的問題：

繞過 sass 編譯，使用小程序的 @import 語法，引入需要的樣式定義。（關于如何繞開 sass 編譯，可以考慮使用注釋片段，或者白名單篩選識別）

四、多端場景的冗余代碼移除

京喜首頁項目使用 Taro 開發，需要適配 H5/微信小程序/QQ小程序等多端場景，利用 Taro 提供的環境變量能力，可以在方法內部實現多端差異處理，比如下面這段：

init(){if(process.env.TARO_ENV === 'weapp'{// 微信小程序邏輯this.initWeapp()}else if(process.env.TARO_ENV === 'h5'){// H5頁面邏輯this.initH5()} } initWeapp(){...} initH5(){...}

小程序端打包后代碼：

init(){this.initWeapp() } initWeapp(){...} initH5(){...}

但是，環境變量方式沒辦法處理 initH5 這種方法定義，導致也被打包進來了。

因此，我們需要更強大的差異打包：京喜首頁利用內部的 wxa-cli 工具提供的條件編譯能力，通過注釋段落標記，圈注出多端內容，實現了代碼片段層面的差異打包，細節如下：

init(){if(process.env.TARO_ENV === 'weapp'{// 微信小程序邏輯this.initWeapp()}else if(process.env.TARO_ENV === 'h5'){// H5頁面邏輯this.initH5()} } initWeapp(){...} /* wxa if:type=='h5' */ 標記h5端代碼開始位置 initH5(){...} /* /wxa */ 標記注釋結束位置

打包后代碼：

init(){ // weapp內this.initWeapp() } initWeapp(){...}

initH5 消失了，代碼更瘦了

五、整理 log

為了調試方便，你的項目內有沒有打很長的 log，類似于這種：

console.log('==============xx接口異常============')

經過測試，首頁代碼文件內有 5KB 的內容是 log 語句，可以試著優化一下：

及時移除開發調試用 log

信息類 log 約定長度更短的格式

六、良好的編碼策略

有沒有同樣的邏輯需求，可以用更短更優雅的寫法來實現呢？

關于代碼分析是個很復雜的話題，暫時列一個結論相對明確的寫法吧

格式化數據時數據的存取和中間變量問題

function format(list){let result = []list.forEach(item => {const {a,b,c: f,d,e,} = itemresult.push({a,b,f,d,e,})})return result

可以利用 lodash 的 pick 方法改寫成：

import { pick } from 'lodash/pick'function format(list){return list.map(item=>({...pick(item,'a','b','d','e'),f:item.c}))

七、樣式命名編譯優化

京喜首頁項目由于 H5 端混搭老項目，為了避免類名沖突，采用了形如block-name__element--modifier的 bem 命名規則。在開發中進一步發現，一些類似 navbar-content__item 的常見命名偶爾撞車，為了避免沖突，類名就越寫越長，而小程序代碼包的尺寸影響也在悄悄增大。

為了解決命名沖突的問題，將類名 hash 化是個好辦法，css-modules 就是個成熟的插件，可以通過配置規則，對樣式名編譯出「文件名+內容相關」的獨特化 hash。

但是研究下它的實現，會發現對代碼尺寸的影響不容樂觀，看一個編譯后例子：

import style from './index.module.map.scss.js' //js文件，增加一句jsMap的引入<view className={style.banner}></view> // wxml文件，每處類名都比原類名增加了`style.`的引用 .hash { xx } // wxss文件， 類名被hash化，減少的具體尺寸為:原類名-hash module.exports = { banner : hash } // 新增了一個map文件，實現原名與hash名的映射，增加的具體尺寸為:原類名+hash

計算整體內容變化：

js 內新增引入 map 語句：增加一句代碼

wxml 內：原為 n 個類名，現為 n 個「style.+原類名」，增量為 n 個style.

map 文件 與 wxss 文件合計：map 內有 n 個原類名與 hash 映射， wxss 現為 n 個 hash ， 減去原來的 n 個原類名 ，合計增量為 2n 個 hash

可見引入 css-modules 會導致整體代碼尺寸增加。

會不會覺得這個新增的 map 文件的作用特別熟悉呢？

在我們壓縮 js 文件時，會有一個 sourceMap 文件，它保留了原始命名和代碼位置，可以方便定位和 debug。

css-modules 實現的 map 文件，在我看來作用和 sourceMap 的命名索引差不多，對于代碼邏輯來說，除了保持原類名的引用信息，它好像也沒什么用了，在尺寸敏感場景，就可以考慮去掉 map 文件，還是上文的示例，如果可以實現成這樣就好了：

// import style from './index.module.map.scss.js' js文件取消map的引入// wxml文件 <view className="hash"></view> // 對style.banner進行求值并替換 // wxss文件 .hash { xx } // 這里不變module.exports = { banner : hash } // 刪掉不要

網上遍尋沒有相關的處理，只能自己造輪子開搞了。

由于當前主要目的是對小程序代碼瘦身，H5 端文件處理和小程序也有一些差異，所以暫時只對小程序場景造了插件，取名 weapp-css-modules ，github 地址在這里：https://github.com/o2team/weapp-css-modules

大概思路是：

完成小程序的 css-modules 實現

在此基礎上進行 map 移除的相關簡化邏輯

進一步的，考慮到小程序組件內默認樣式隔離的特性，對 hash 化的命名再次縮短，變成單字母編排。

如果是只開發小程序端，可以借此實現小程序樣式命名相關的代碼瘦身，而對于 Taro 開發的多端場景，還可以同時解決 h5 端的命名沖突問題。

還是上面的例子，下面是 weapp-css-modules 編譯后效果：

// js文件 let style = {} // 不引用map，加入對不規范引入style的兼容// wxml文件 <view className="a"></view> // 對style.banner進行求值并替換，加入單字母編排// wxss文件 .a { xx } // 因為小程序組件樣式隔離，所以可以最短化類名module.exports = { banner : hash } // 刪掉不要

京喜首頁項目通過改造組件采用 css-modules 寫法，加上 weapp-css-modules 編譯，代碼相對尺寸減少了 10%，還是很有效果的，感興趣的同學可以試用一下。

總結

關于代碼瘦身，想提一下信息學中熵的概念：熵反映信息的無序程度，一段信息無序程度越低，它的熵值越低，可被壓縮的空間越大；無序程度越高，熵值越高，可被壓縮的空間越小。而數據壓縮或者是代碼瘦身的過程，就是通過優化信息存儲方式以逼近它真實的熵值。

從這個角度來說：

• 「字體和顏色的全局共用」和「樣式補全功能的使用」是借用小程序提供的能力，信息量沒變；

• 「小心 Sass」、「多端場景的冗余代碼移除」是減少不用的信息；

• 「整理 log」和「樣式命名編譯優化」是凝練有效信息；

看起來最不好歸類的是「良好的編碼策略」，它是在編碼階段對信息的梳理和整合，也算凝練有效信息吧。

以上就是京喜首頁項目這次代碼瘦身的主要方式了，除此之外的刪除不用文件、整合公共文件這些體力活，我就不再啰嗦了。通過以上方式，京喜首頁代碼在原本優化良好的基礎上，實現了再次減重30%的目標，希望能給小程序開發者們帶來有價值的信息和思考。

參考資料

[1] CSS Modules: https://github.com/css-modules/css-modules

[2] Tree-Cli: https://github.com/MrRaindrop/tree-cli

[3] 小程序工程化探索: https://mp.weixin.qq.com/s/_NSJTQ-4-8gTnwTVK-tn0A

[4] 微信小程序 限制2M的瘦身技巧與方法詳解: https://blog.csdn.net/wlanye/article/details/73457700

---

歡迎關注凹凸實驗室博客：aotu.io

或者關注凹凸實驗室，不定時推送文章。

總結

以上是生活随笔為你收集整理的newduba首页怎么去掉_京喜小程序首页瘦身实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。