微信小程序壓縮實(shí)踐
微信小程序依靠微信巨大的用戶流量優(yōu)勢，吸引來了眾多第三方開發(fā)者。幾乎每個公司都會想通過小程序拉到新的用戶群體。3月份接到公司任務(wù)，需要將公司各業(yè)務(wù)線小程序整合到一個小程序中。但擺在面前的問題是空間完全 ...
微信小程序依靠微信巨大的用戶流量優(yōu)勢，吸引來了眾多第三方開發(fā)者。幾乎每個公司都會想通過小程序拉到新的用戶群體。3月份接到公司任務(wù)，需要將公司各業(yè)務(wù)線小程序整合到一個小程序中。但擺在面前的問題是空間完全不夠。當(dāng)時微信小程序的使用空間是 1024KB（現(xiàn)在已升為 2M），各個業(yè)務(wù)線獨(dú)立的小程序都不小，『機(jī)票火車票汽車票』小程序更是超過 900KB。如何整合和壓縮才能使 size 達(dá)標(biāo)，成了最大的挑戰(zhàn)。
我們經(jīng)過考慮，準(zhǔn)備從兩個方面進(jìn)行整合和壓縮，一是通過工程化的方式實(shí)現(xiàn)代碼復(fù)用——提取公共業(yè)務(wù)邏輯，公共組件；二是通過工具進(jìn)行自定義化代碼打包壓縮處理。
工程規(guī)范制定
為了節(jié)省開發(fā)時間，我們盡量整合現(xiàn)有業(yè)務(wù)線小程序代碼，減少業(yè)務(wù)改動。
目錄結(jié)構(gòu)
同時為了后期計(jì)算各業(yè)務(wù)占用空間情況方便，我們直接將各業(yè)務(wù)線小程序工程代碼拷貝到各自業(yè)務(wù)線目錄下，最終的目錄結(jié)構(gòu)如下：
.
├── common # 通用模塊/公共業(yè)務(wù)
├── home # 首頁
├── flight # 機(jī)票
├── train # 火車票
├── bus # 汽車票
├── hotel # 酒店
└── ticket # 門票
common 模塊即工程的復(fù)用部分，具體業(yè)務(wù)代碼都在各自目錄下?？傮w架構(gòu)如下：
公共組件、API
微信小程序其實(shí)并沒有提供組件化開發(fā)的方式。只是提供了 template 的方式，所以我們只提供了為數(shù)不多的頁面及組件，例如：城市定位、日歷組件等。但是收益卻是非常明顯的，像這些頁面大小都在 20KB~30KB，如果每個業(yè)務(wù)自己整一套可能將徒增上百 KB 代碼。
公共 API 我們提供了統(tǒng)一的 Watcher 監(jiān)控、 Requester 請求、 Loading 加載轉(zhuǎn)態(tài)、 Navigation 導(dǎo)航等。這些公共邏輯的抽取，為整個項(xiàng)目整合節(jié)省了巨大的空間，使 size 達(dá)標(biāo)看起來不那么難了。
工程復(fù)用上節(jié)省了很大一部分空間。但是空間是有限的，業(yè)務(wù)需求是無限的。而且，size 的大小會影響用戶加載的速度，包括下載最新版本代碼的速度和小程序初始化的速度，所以還需要進(jìn)一步進(jìn)行代碼壓縮。
打包壓縮工具
微信開發(fā)者工具
我們知道微信小程序開發(fā)者工具本身提供了『代碼壓縮上傳』功能。
但是個人覺得它是個『假的壓縮選項(xiàng)』。因?yàn)樵陂喿x開發(fā)者工具的源碼邏輯之后，發(fā)現(xiàn)它的壓縮，只是將 JavaScript 用 uglify 進(jìn)行混淆壓縮。而對 WXML、WXSS 沒有進(jìn)行任何壓縮處理。同時，對資源路徑中的無用文件也沒有做處理。
小程序的構(gòu)建
在小程序開發(fā)者工具的 Sources 面板，查看 JavaScript 腳本，會發(fā)現(xiàn)：項(xiàng)目中所有的 JavaScript 都會被 同步加載 ，不管是否被 require 。
每個腳本都會被套上如下代碼：
define("some.js", function(require,module){
// 原本的代碼
});
這種加載方式類似 AMD，但是跟標(biāo)準(zhǔn)的 AMD 又有些不同，缺少了依賴部分的聲明。
而對于 WXSS 和 WXML 文件，則被開發(fā)者工具自動轉(zhuǎn)換為 JavaScript 后加載，其中：
WXSS：主要處理的是 import 邏輯，然后生成的 CSS，通過腳本的形式插入頁面使用。
WXML：類似于 React Naitive 的 JSX，被編譯成 createElement 類似的形式。
一些技巧
在 MacOS 系統(tǒng)中，右鍵開發(fā)者工具『Show Contents』（顯示包內(nèi)容），就能在 Resources/app.nw/ 下找到相應(yīng)的源碼，完成路徑如下： /Applications/wechatwebdevtools.app/Contents/Resources/app.nw/ 。
源碼都是壓縮過后的 JavaScript 腳本，可以使用 js-beautity 進(jìn)行格式化，以便于閱讀。
// 在源碼目錄的 app 目錄下執(zhí)行
find . -type f -name '*.js' -exec js-beautify -r -s 2 -p -f '{}' \;
-
在資源目錄下: app/dist/app.js 的第 37 行
window.addEventListener("resize", function() {})之前，加入nw.Window.get().showDevTools();。之后每次打開微信開發(fā)者工具時，會自動啟動針對『開發(fā)者工具』的開發(fā)者工具，并可以通過它調(diào)試微信的開發(fā)者工具。 -
在打印日志時，不要用
console.log，請使用global.contentWindow.console.log。這樣，才能輸出到上面所說的開發(fā)者工具的開發(fā)者工具的控制臺里。（NW.js 的 Node JS Context 和 Webkit JS Context 是分開的， JavaScript 腳本運(yùn)行在 Node 的 JS Context 中，因此，打印其實(shí)打印在 Node 的輸出中，并不在 Webkit 的開發(fā)者工具的控制臺中。global.contentWindow獲取的是 Webkit 的 JS Context 里的 Window）
使用這兩點(diǎn)技巧，讀者們可以優(yōu)雅地去閱讀微信開發(fā)者工具的源碼了。
在閱讀源碼，知道小程序的內(nèi)部加載構(gòu)建方式之后，我們可以針對性的對 JavaScript、WXML、WXSS 等代碼文件進(jìn)行打包壓縮。
壓縮 JavaScript
由于微信只是將 js 進(jìn)行了混淆壓縮，并沒有打包合并成一個文件。所以我們提供了打包壓縮工具將 js 文件合并壓縮成一個 bundle.js 文件。合并成一個文件有以下好處：
-
require的長路徑?jīng)]了，腳本壓縮效率變高 - 代碼合并在一起，混淆性越大
- 文件合并，減少了 IO 次數(shù)，提升了加載效率
上文說了 JavaScript 都會被同步加載，所以不用擔(dān)心打包成一個文件后會延長小程序加載時間。
那么打包壓縮工具具體做了什么工作呢？
-
小程序有一個統(tǒng)一的入口是
app.js，而每個頁面都有自己的入口page.js -
利用 AST，將
page.js里頁面注冊Page(pageOpt)代碼改成global.YPage(pageName, pageIndex)(pageOpt)pageName頁面路由pageIndex是打包工具根據(jù)頁面路由內(nèi)部自動維護(hù)的// global.YPage 函數(shù) global.YPage = (pageName, index)=> { return (pageOpt) => { // 其他處理邏輯 global['p' + index] = ()=> { Page(pageOpt); } } }這樣
page.js里實(shí)際是這樣的代碼global['p' + index] = ()=> { Page(pageOpt); }這樣并不會執(zhí)行
Page(pageOpt)，頁面也沒注冊啊。這就是要達(dá)到的目的，繼續(xù)往后看。 -
將所有這些入口
require到一個統(tǒng)一的入口文件中，然后用 webpack 打包壓縮輸出到bundle.js。require('app.js') require('page1.js') require('page2.js') ... -
現(xiàn)在
page.js里的代碼都打包到單一文件bundle.js里了。將page.js內(nèi)容替換成global['p' + index]()，這樣第三步中的Page(pageOpt)不就可以執(zhí)行注冊頁面了。 -
最后一步，替換
app.js內(nèi)容為require('./bundle.js')即大功告成。
壓縮 WXML、WXSS、JSON
WXML
-
/<!--((.|\n|\r)*?)-->/gm去除注釋 -
/\"\n\s*/g去除換行
WXSS
- 直接用 uglifycss
JSON
-
直接
JSON.stringify(JSON.parse(...))
這里，有些讀者會可能提出兩個疑問：
- 空白字符、換行能有多少，減不了多少吧？
- 開發(fā)者工具為什么不做對這些文件的壓縮？
關(guān)于第一個問題，一個約 1000KB 的代碼，空白字符和換行大概有 10KB。在有上限的情況之下，10 KB 也是要珍惜的。
關(guān)于第二個問題，個人認(rèn)為微信開發(fā)者工具的開發(fā)者覺得沒有必要去做。因?yàn)?，WXML 和 WXSS 都會被轉(zhuǎn)義成 JavaScript 腳本，在此過程中，不管 WXML 和 WXSS 是否被壓縮，它們的轉(zhuǎn)化結(jié)果是相同的。因此，壓縮與否，對于最終產(chǎn)物是沒有影響的（最終產(chǎn)物指在服務(wù)器二次打包后的結(jié)果，也是用戶真正使用的）。但是，Size 是以本地打包上傳的內(nèi)容進(jìn)行計(jì)算的，不進(jìn)行此步壓縮，會使微信服務(wù)端判定的 Size 增大。
刪除無用文件
工程龐大了，肯定會存在很多無用的空目錄，空文件，沒有被 import 的 js 、 wxml 、 wxss 文件。
刪除這些無用文件不僅可以減小 size，還可以提升小程序加載時間。上文說了這些文件都會被轉(zhuǎn)成 JavaScript 進(jìn)行加載的，是會占用加載時間的。
刪除無用 JavaScript
由于通過 webpack 打包，除了 page.js 、 bundle .js 文件，其他 js 文件都可以刪掉。
刪除無用 WXML
打包壓縮工具在打包時，已經(jīng)記錄了所有頁面的路由。遍歷分析所有路由下的 wxml 文件，通過 xmldom 解析代碼記錄其他被 import 的 wxml 文件。最后遍歷所有 wxml 文件，刪除不在 import 列表里的無用 wxml 文件。
刪除無用 WXSS
類似處理 WXML。遍歷分析所有路由下的 wxss 文件，通過正則 /@import\s*["']([^"']+)["']/g 分析代碼記錄其他被 import 的 wxss 文件。最后遍歷所有 wxss 文件，刪除不在 import 列表里的無用 wxss 文件。
代碼級優(yōu)化
除了利用工具進(jìn)行壓縮，在編寫代碼時，也可以通過一些方法來減小體積，在這里簡單列幾點(diǎn)：
-
使用 ES6 時，盡量不使用依賴 Runtime/Polyfill 的語法，例如
import和class。 - 圖標(biāo)使用 Iconfont。
- 等等…
最終效果
經(jīng)過打包工具的極限壓縮處理，還有代碼設(shè)計(jì)上的可復(fù)用性，目前我們七個業(yè)務(wù)線的小程序整合后代碼編譯包大小維持在 1300KB 左右。
還剩余 730KB 的可用空間。
結(jié)語
希望此次在小程序整合上做的，工程化抽取公共邏輯、規(guī)范業(yè)務(wù)代碼，通過工具進(jìn)行針對性的代碼打包壓縮的實(shí)踐能給大家?guī)硪欢ǖ膸椭?/p>
