微信小程序依靠微信巨大的用戶流量?jī)?yōu)勢(shì)，吸引來了眾多第三方開發(fā)者。幾乎每個(gè)公司都會(huì)想通過小程序拉到新的用戶群體。3月份接到公司任務(wù)，需要將公司各業(yè)務(wù)線小程序整合到一個(gè)小程序中。但擺在面前的問題是空間完全不夠。當(dāng)時(shí)微信小程序的使用空間是 1024KB（現(xiàn)在已升為 2M），各個(gè)業(yè)務(wù)線獨(dú)立的小程序都不小，『機(jī)票火車票汽車票』小程序更是超過 900KB。如何整合和壓縮才能使 size 達(dá)標(biāo)，成了最大的挑戰(zhàn)。

我們經(jīng)過考慮，準(zhǔn)備從兩個(gè)方面進(jìn)行整合和壓縮，一是通過工程化的方式實(shí)現(xiàn)代碼復(fù)用——提取公共業(yè)務(wù)邏輯，公共組件；二是通過工具進(jìn)行自定義化代碼打包壓縮處理。

工程規(guī)范制定

為了節(jié)省開發(fā)時(shí)間，我們盡量整合現(xiàn)有業(yè)務(wù)線小程序代碼，減少業(yè)務(wù)改動(dòng)。

目錄結(jié)構(gòu)

同時(shí)為了后期計(jì)算各業(yè)務(wù)占用空間情況方便，我們直接將各業(yè)務(wù)線小程序工程代碼拷貝到各自業(yè)務(wù)線目錄下，最終的目錄結(jié)構(gòu)如下：

.
├── common # 通用模塊/公共業(yè)務(wù)
├── home   # 首頁
├── flight # 機(jī)票
├── train  # 火車票
├── bus    # 汽車票
├── hotel  # 酒店
└── ticket # 門票

公共組件、API

微信小程序其實(shí)并沒有提供組件化開發(fā)的方式。只是提供了 template 的方式，所以我們只提供了為數(shù)不多的頁面及組件，例如：城市定位、日歷組件等。但是收益卻是非常明顯的，像這些頁面大小都在 20KB~30KB，如果每個(gè)業(yè)務(wù)自己整一套可能將徒增上百 KB 代碼。

公共 API 我們提供了統(tǒng)一的 Watcher 監(jiān)控、 Requester 請(qǐng)求、 Loading 加載轉(zhuǎn)態(tài)、 Navigation 導(dǎo)航等。這些公共邏輯的抽取，為整個(gè)項(xiàng)目整合節(jié)省了巨大的空間，使 size 達(dá)標(biāo)看起來不那么難了。

工程復(fù)用上節(jié)省了很大一部分空間。但是空間是有限的，業(yè)務(wù)需求是無限的。而且，size 的大小會(huì)影響用戶加載的速度，包括下載最新版本代碼的速度和小程序初始化的速度，所以還需要進(jìn)一步進(jìn)行代碼壓縮。

打包壓縮工具

微信開發(fā)者工具

我們知道微信小程序開發(fā)者工具本身提供了『代碼壓縮上傳』功能。

 

但是個(gè)人覺得它是個(gè)『假的壓縮選項(xiàng)』。因?yàn)樵陂喿x開發(fā)者工具的源碼邏輯之后，發(fā)現(xiàn)它的壓縮，只是將 JavaScript 用 uglify 進(jìn)行混淆壓縮。而對(duì) WXML、WXSS 沒有進(jìn)行任何壓縮處理。同時(shí)，對(duì)資源路徑中的無用文件也沒有做處理。

小程序的構(gòu)建

在小程序開發(fā)者工具的 Sources 面板，查看 JavaScript 腳本，會(huì)發(fā)現(xiàn)：項(xiàng)目中所有的 JavaScript 都會(huì)被 同步加載 ，不管是否被 require 。

每個(gè)腳本都會(huì)被套上如下代碼：

define("some.js", function(require,module){
    // 原本的代碼
});

這種加載方式類似 AMD，但是跟標(biāo)準(zhǔn)的 AMD 又有些不同，缺少了依賴部分的聲明。

而對(duì)于 WXSS 和 WXML 文件，則被開發(fā)者工具自動(dòng)轉(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ā)者工具時(shí)，會(huì)自動(dòng)啟動(dòng)針對(duì)『開發(fā)者工具』的開發(fā)者工具，并可以通過它調(diào)試微信的開發(fā)者工具。

• 在打印日志時(shí)，不要用 console.log ，請(qǐng)使用 global.contentWindow.console.log 。這樣，才能輸出到上面所說的開發(fā)者工具的開發(fā)者工具的控制臺(tái)里。（NW.js 的 Node JS Context 和 Webkit JS Context 是分開的， JavaScript 腳本運(yùn)行在 Node 的 JS Context 中，因此，打印其實(shí)打印在 Node 的輸出中，并不在 Webkit 的開發(fā)者工具的控制臺(tái)中。 global.contentWindow 獲取的是 Webkit 的 JS Context 里的 Window）

使用這兩點(diǎn)技巧，讀者們可以優(yōu)雅地去閱讀微信開發(fā)者工具的源碼了。

在閱讀源碼，知道小程序的內(nèi)部加載構(gòu)建方式之后，我們可以針對(duì)性的對(duì) JavaScript、WXML、WXSS 等代碼文件進(jìn)行打包壓縮。

壓縮 JavaScript

由于微信只是將 js 進(jìn)行了混淆壓縮，并沒有打包合并成一個(gè)文件。所以我們提供了打包壓縮工具將 js 文件合并壓縮成一個(gè) bundle.js 文件。合并成一個(gè)文件有以下好處：

• require 的長(zhǎng)路徑?jīng)]了，腳本壓縮效率變高
• 代碼合并在一起，混淆性越大
• 文件合并，減少了 IO 次數(shù)，提升了加載效率

上文說了 JavaScript 都會(huì)被同步加載，所以不用擔(dān)心打包成一個(gè)文件后會(huì)延長(zhǎng)小程序加載時(shí)間。

那么打包壓縮工具具體做了什么工作呢？

1. 小程序有一個(gè)統(tǒng)一的入口是 app.js ，而每個(gè)頁面都有自己的入口 page.js

2. 利用 AST，將 page.js 里頁面注冊(cè) Page(pageOpt) 代碼改成 global.YPage(pageName, pageIndex)(pageOpt)

   pageName 頁面路由

   pageIndex 是打包工具根據(jù)頁面路由內(nèi)部自動(dòng)維護(hù)的

   // global.YPage 函數(shù)
   global.YPage = (pageName, index)=> {
       return (pageOpt) => {
           // 其他處理邏輯
           global['p' + index] = ()=> {
               Page(pageOpt);
           }
       }
   }
   

   這樣 page.js 里實(shí)際是這樣的代碼

   global['p' + index] = ()=> {
          Page(pageOpt);
   }
   

   這樣并不會(huì)執(zhí)行 Page(pageOpt) ，頁面也沒注冊(cè)啊。這就是要達(dá)到的目的，繼續(xù)往后看。

3. 將所有這些入口 require 到一個(gè)統(tǒng)一的入口文件中，然后用 webpack 打包壓縮輸出到 bundle.js 。

   require('app.js')
   require('page1.js')
   require('page2.js')
   ...
   

4. 現(xiàn)在 page.js 里的代碼都打包到單一文件 bundle.js 里了。將 page.js 內(nèi)容替換成 global['p' + index]() ，這樣第三步中的 Page(pageOpt) 不就可以執(zhí)行注冊(cè)頁面了。

5. 最后一步，替換 app.js 內(nèi)容為 require('./bundle.js') 即大功告成。

壓縮 WXML、WXSS、JSON

WXML

• /<!--((.|\n|\r)*?)-->/gm 去除注釋
• /\"\n\s*/g 去除換行

WXSS

• 直接用 uglifycss

JSON

• 直接 JSON.stringify(JSON.parse(...))

這里，有些讀者會(huì)可能提出兩個(gè)疑問：

1. 空白字符、換行能有多少，減不了多少吧？
2. 開發(fā)者工具為什么不做對(duì)這些文件的壓縮？

關(guān)于第一個(gè)問題，一個(gè)約 1000KB 的代碼，空白字符和換行大概有 10KB。在有上限的情況之下，10 KB 也是要珍惜的。

關(guān)于第二個(gè)問題，個(gè)人認(rèn)為微信開發(fā)者工具的開發(fā)者覺得沒有必要去做。因?yàn)?，WXML 和 WXSS 都會(huì)被轉(zhuǎn)義成 JavaScript 腳本，在此過程中，不管 WXML 和 WXSS 是否被壓縮，它們的轉(zhuǎn)化結(jié)果是相同的。因此，壓縮與否，對(duì)于最終產(chǎn)物是沒有影響的（最終產(chǎn)物指在服務(wù)器二次打包后的結(jié)果，也是用戶真正使用的）。但是，Size 是以本地打包上傳的內(nèi)容進(jìn)行計(jì)算的，不進(jìn)行此步壓縮，會(huì)使微信服務(wù)端判定的 Size 增大。

刪除無用文件

工程龐大了，肯定會(huì)存在很多無用的空目錄，空文件，沒有被 import 的 js 、 wxml 、 wxss 文件。

刪除這些無用文件不僅可以減小 size，還可以提升小程序加載時(shí)間。上文說了這些文件都會(huì)被轉(zhuǎn)成 JavaScript 進(jìn)行加載的，是會(huì)占用加載時(shí)間的。

刪除無用 JavaScript

由于通過 webpack 打包，除了 page.js 、 bundle .js 文件，其他 js 文件都可以刪掉。

刪除無用 WXML

打包壓縮工具在打包時(shí)，已經(jīng)記錄了所有頁面的路由。遍歷分析所有路由下的 wxml 文件，通過 xmldom 解析代碼記錄其他被 import 的 wxml 文件。最后遍歷所有 wxml 文件，刪除不在 import 列表里的無用 wxml 文件。

刪除無用 WXSS

類似處理 WXML。遍歷分析所有路由下的 wxss 文件，通過正則 /@import\s*["']([^"']+)["']/g 分析代碼記錄其他被 import 的 wxss 文件。最后遍歷所有 wxss 文件，刪除不在 import 列表里的無用 wxss 文件。

 

代碼級(jí)優(yōu)化

除了利用工具進(jìn)行壓縮，在編寫代碼時(shí)，也可以通過一些方法來減小體積，在這里簡(jiǎn)單列幾點(diǎn)：

• 使用 ES6 時(shí)，盡量不使用依賴 Runtime/Polyfill 的語法，例如 import 和 class 。
• 圖標(biāo)使用 Iconfont。
• 等等…

最終效果

經(jīng)過打包工具的極限壓縮處理，還有代碼設(shè)計(jì)上的可復(fù)用性，目前我們七個(gè)業(yè)務(wù)線的小程序整合后代碼編譯包大小維持在 1300KB 左右。

 

還剩余 730KB 的可用空間。

結(jié)語

希望此次在小程序整合上做的，工程化抽取公共邏輯、規(guī)范業(yè)務(wù)代碼，通過工具進(jìn)行針對(duì)性的代碼打包壓縮的實(shí)踐能給大家?guī)硪欢ǖ膸椭?/p>