在 web 開發(fā)場景，減少代碼體積雖然是性能優(yōu)化的一個方向，還沒到錙銖必較的程度。但是在小程序場景，由于代碼包上傳階段限制了主包 2M 和總包 16M（近期微信官方正在內(nèi)測將總包上限調(diào)整至 20M ）的尺寸，超過就會面臨無法發(fā)版的風(fēng)險，代碼包體積的優(yōu)化就變得特別重要了。

京喜小程序首頁作為微信購物的大入口，承載大量流量，功能復(fù)雜模塊眾多，又要與其他核心業(yè)務(wù)和公共組件共享 2M 的主包空間，因此代碼包瘦身的工作在持續(xù)不斷進(jìn)行，否則無法滿足業(yè)務(wù)的快速增長。本文將結(jié)合以往優(yōu)化策略與最近一次的瘦身實踐，分享小程序代碼瘦身的經(jīng)驗與思考。

常見的瘦身方式

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

1. 代碼分包：將相對獨立的頁面和組件拆分到分包，可以解決主包體積受限問題；
2. 依賴分析：移除未引用的頁面、組件和其他文件；
3. 避免使用本地資源：除了兜底圖片，其他都盡可能使用 url 的方式，由于 base64 圖本質(zhì)上是將信息編碼成長字符串，也會占用很多空間，不建議使用；
4. 對所有類型的文件都進(jìn)行壓縮并清理注釋，包括了：js、wxml、wxss、json；

此外，京喜首頁團(tuán)隊還針對 Taro 開發(fā)場景進(jìn)行了如下優(yōu)化：

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

標(biāo)準(zhǔn)和工具

在開始正式介紹瘦身實踐之前，我們先來明確一下代碼包體積的衡量標(biāo)準(zhǔn)和統(tǒng)計方式吧。

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

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

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

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

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

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

清單內(nèi)容格式如下：

.
├── [      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.json
  
6500 bytes used in 2 directories, 8 files

瘦身實踐

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

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

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

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

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

如果有全局的顏色定義，也可以進(jìn)行類似的優(yōu)化。

二、樣式補全功能的使用

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

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

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

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

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

階段一補全：

階段二：

或者是階段三：

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

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

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

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

三、小心 Sass!

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

// a.scss，作為被引用方
.banner {         // 樣式定義
    color: red;
}
$COLOR = red     //  變量定義（函數(shù)定義類似）

// b.scss，作為使用方
@import 'a.scss';
.banner_wrapper {
    background: white;
    color:$COLOR;
}

關(guān)注b.sass的編譯后：

// a.scss的引用消失了，內(nèi)容被整合到文件內(nèi)

.banner {              // a.scss內(nèi)的樣式定義會被拷貝進(jìn)來
    color: red;
}
.banner_wrapper {
    background: white;
    color:red;           //變量定義會被按值替換
}

這里出現(xiàn)的問題是：我們是否需要.banner被拷貝進(jìn)來呢

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

1. 按功能拆分 a.scss 內(nèi)的樣式定義，按需引入。
2. 使用 @include 語法，將 banner 的定義變成一個變量，按需引入。

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

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

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

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

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(){...}

但是，環(huán)境變量方式?jīng)]辦法處理 initH5 這種方法定義，導(dǎo)致也被打包進(jìn)來了。

因此，我們需要更強(qiáng)大的差異打包：京喜首頁利用內(nèi)部的 wxa-cli 工具提供的條件編譯能力，通過注釋段落標(biāo)記，圈注出多端內(nèi)容，實現(xiàn)了代碼片段層面的差異打包，細(xì)節(jié)如下：

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

打包后代碼：

init(){          // weapp內(nèi)
    this.initWeapp()
}
initWeapp(){...}

initH5 消失了，代碼更瘦了

五、整理 log

為了調(diào)試方便，你的項目內(nèi)有沒有打很長的 log，類似于這種：

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

經(jīng)過測試，首頁代碼文件內(nèi)有 5KB 的內(nèi)容是 log 語句，可以試著優(yōu)化一下：

1. 及時移除開發(fā)調(diào)試用 log
2. 信息類 log 約定長度更短的格式

六、良好的編碼策略

有沒有同樣的邏輯需求，可以用更短更優(yōu)雅的寫法來實現(xiàn)呢？

關(guān)于代碼分析是個很復(fù)雜的話題，暫時列一個結(jié)論相對明確的寫法吧

格式化數(shù)據(jù)時數(shù)據(jù)的存取和中間變量問題

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

    result.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
 }))


七、樣式命名編譯優(yōu)化

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

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

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

import style from './index.module.map.scss.js' //js文件，增加一句jsMap的引入

  // wxml文件，每處類名都比原類名增加了`style.`的引用 

.hash { xx }   // wxss文件， 類名被hash化，減少的具體尺寸為:原類名-hash 

module.exports = { banner : hash }  // 新增了一個map文件，實現(xiàn)原名與hash名的映射，增加的具體尺寸為:原類名+hash

計算整體內(nèi)容變化：

1. js 內(nèi)新增引入 map 語句：增加一句代碼
2. wxml 內(nèi)：原為 n 個類名，現(xiàn)為 n 個「style.+原類名」，增量為 n 個style.
3. map 文件 與 wxss 文件合計：map 內(nèi)有 n 個原類名與 hash 映射， wxss 現(xiàn)為 n 個 hash ， 減去原來的 n 個原類名 ，合計增量為 2n 個 hash

可見引入 css-modules 會導(dǎo)致整體代碼尺寸增加。

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

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

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

// import style from './index.module.map.scss.js'   js文件取消map的引入

// wxml文件
"hash">   // 對style.banner進(jìn)行求值并替換  

// wxss文件
.hash { xx }    // 這里不變

module.exports = { banner : hash }   // 刪掉不要

網(wǎng)上遍尋沒有相關(guān)的處理，只能自己造輪子開搞了。

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

大概思路是：

1. 完成小程序的 css-modules 實現(xiàn)
2. 在此基礎(chǔ)上進(jìn)行 map 移除的相關(guān)簡化邏輯
3. 進(jìn)一步的，考慮到小程序組件內(nèi)默認(rèn)樣式隔離的特性，對 hash 化的命名再次縮短，變成單字母編排。

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

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

// js文件
let style = {}    // 不引用map，加入對不規(guī)范引入style的兼容

// wxml文件
"a">   // 對style.banner進(jìn)行求值并替換，加入單字母編排

// wxss文件
.a { xx }     // 因為小程序組件樣式隔離，所以可以最短化類名

module.exports = { banner : hash }        // 刪掉不要

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

總結(jié)

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

從這個角度來說：

• 「字體和顏色的全局共用」和「樣式補全功能的使用」是借用小程序提供的能力，信息量沒變；
• 「小心 Sass」、「多端場景的冗余代碼移除」是減少不用的信息；
• 「整理 log」和「樣式命名編譯優(yōu)化」是凝練有效信息；

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

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

文章轉(zhuǎn)載自：segmentfault  作者：凹凸實驗室