伴隨著從2017年1月9日凌晨的夜色，張小龍和他的團(tuán)隊正式發(fā)布了微信小程序，瞬間刷爆了業(yè)內(nèi)人士的各種信息流，一個看似『銀彈』的產(chǎn)品形態(tài)被大家所熱捧，一股開發(fā)浪潮也隨之而來。而近期，微信又做成了兩個很大的突破：微信悖逆蘋果做小程序市場（應(yīng)用內(nèi)搜索已經(jīng)有『市場性質(zhì)』）和允許小程序通過社交傳播（可以通過小程序第三方平臺朋友圈和聊天傳播，二維碼可以長按識別），同時讓開發(fā)者們看到微信小程序發(fā)展的信心和前景。總之，不管是『紅利』還是『雞血』，小程序?qū)⒊蔀楫a(chǎn)品布局中重要的一個組成部分。因此，在公司內(nèi)部，將小程序開發(fā)流程統(tǒng)一化、規(guī)劃化，讓小程序開發(fā)變得優(yōu)雅是相當(dāng)有必要的。

下面，GitChator將以去哪兒網(wǎng)微信小程序?yàn)楸尘?，詳?xì)對去哪兒網(wǎng)微信小程序工程流程化方案進(jìn)行剖析，同時與讀者們進(jìn)行交流探討。

小程序開發(fā)問題的轉(zhuǎn)變

讀者們一定很奇怪，為什么先聊到『開發(fā)問題的轉(zhuǎn)變』？因?yàn)樽黾軜?gòu)、做工程流程化的目的是為了降低開發(fā)、測試、發(fā)布、運(yùn)維等一系列環(huán)節(jié)的成本的同時，解決這些環(huán)節(jié)之間存在的問題和痛點(diǎn)。所以理清開發(fā)小程序的過程中遇到的問題，才能更好的做架構(gòu)、做工程流程化。

那么，小程序開發(fā)急需解決什么問題？而問題又有什么轉(zhuǎn)變呢？

從內(nèi)測開始到半個月之前，有一個數(shù)字非常讓人頭疼 —— 1024 。這個數(shù)字代表著小程序的總 Size，小程序打包后的總體積不能超過 1024 KB （也就是 1 MB）。在這個有限的空間內(nèi)，放入更多的業(yè)務(wù)邏輯，這才是當(dāng)時小程序開發(fā)遇到的最大的問題。因此， 壓縮 是當(dāng)時首當(dāng)其沖的工作。

當(dāng)初，公司準(zhǔn)備將去哪兒酒店、去哪兒門票和去哪兒交通三個小程序中的五個業(yè)務(wù)線合并到統(tǒng)一的一個小程序中。筆者所在的團(tuán)隊接到了這個任務(wù)，并在業(yè)務(wù)線配合下，在一個星期的時間里，完成任務(wù)上線，而后又在剩余的體積內(nèi)塞入了兩個其他的業(yè)務(wù)。在當(dāng)時的情況下，每壓縮出 10KB 的體積，都是一件很令人興奮的事。

而現(xiàn)在不同了，微信將小程序的 Size 增加到 2MB ，也就是 2048 KB，足足 翻了一倍 。 由于有之前 1024 的經(jīng)驗(yàn)，翻倍后，在相同的壓縮邏輯下，已經(jīng)足夠滿足絕大多數(shù) App 的要求。例如，將去哪兒旅行 App 上的主要業(yè)務(wù)的主要流程都放進(jìn)微信小程序內(nèi)，應(yīng)該是沒問題的。

所以，在壓縮問題并不突出明顯后， 如何更好的管制作小程序控小程序的代碼 ， 如何做好業(yè)務(wù)隔離 ， 如何分配業(yè)務(wù)資源的配比 ，這些問題將會成為現(xiàn)在以及以后核心要解決的問題。當(dāng)然，壓縮也是工程流程化的一部分，只是優(yōu)先級降低而已。

最后，提出一個問題：據(jù)上文所述， 可以將去哪兒旅行 App 上的主要業(yè)務(wù)的主要流程都放進(jìn)微信小程序內(nèi) ，但是在靈活的小程序應(yīng)用場景下，這樣真的好嗎？真的適合小程序的場景嗎？這也是工程流程化要考慮和完善的一個問題。

小程序的架構(gòu)模式

對于小程序的架構(gòu)，用一句話總結(jié)就是 『類 React Native 的 MVC Web UI 架構(gòu)』。小程序的架構(gòu)思想與 React Native 類似，都是以組件化的方式和 MVC 的模式將 UI 層和 Service 層分離，在保證 UI 層的顯示效率的同時，也保持了 Service 層的一致性；而與 React Native 最大的不同是：React Native 使用的是 Native 的 UI，而微信使用的 Web UI。

相比來說，Native 的 UI 性能更好，但也更依賴系統(tǒng)和 App 本身的 Native，不易維護(hù)和進(jìn)行熱更新；而 Web UI 性能和 Native UI 有一定的差距，但是依賴少，易維護(hù)并且容易實(shí)現(xiàn)熱更新。

小程序的架構(gòu)就先簡單介紹到這里，大家可以從其他的 GitChat 文章里了解更多。這次GitChat 主要要闡述的是小程序的工程流程化問題，而為了實(shí)現(xiàn)工程流程化，在簡單了解小程序架構(gòu)的同時，也必須先了解基于這套架構(gòu)的一些技術(shù)細(xì)節(jié)，例如代碼結(jié)構(gòu)、構(gòu)建方法、調(diào)試發(fā)布方式等。

下面簡單列舉一些比較重要的點(diǎn)。

代碼結(jié)構(gòu)

首先，在工程內(nèi)有三個公共入口文件：

• app.json ：配置文件，配置路由列表、程序信息等。

• app.js ：公共入口文件，小程序啟動時的 Init 邏輯。

• app.wxss ：公共樣式文件，公共樣式用于每個視圖 View 中。

同樣的，對于每個視圖 View 都存在與其對應(yīng)的入口文件，假設(shè)此 View 為 page ，那么

• page.json ：此視圖 View 的配置。

• page.js : 此視圖的腳本邏輯。

• page.wxss : 此視圖的樣式。

其他的，不論是 JavaScript 腳本還是 Wxml 模板和 Wxss 樣式，應(yīng)被入口文件 require/import 使用。

構(gòu)建方法

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

每個腳本都會被套上如下代碼：

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

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

而對于 Wxml 和 Wxss 文件，則被開發(fā)者工具自動轉(zhuǎn)換為 JavaScript 后加載，其中：

• Wxss ：主要處理的是 import 邏輯，然后生成的 Css，通過腳本的形式插入頁面使用。

• Wxml ：和 React Naitive 的 JSX 類似，被編譯成 createElement 類似的形式。

預(yù)覽發(fā)布方式

預(yù)覽、調(diào)試、打包上傳都集成在微信提供的開發(fā)者工具中，而發(fā)布體驗(yàn)版和發(fā)布線上則在微信小程序的管理后臺中。打包上傳、發(fā)布的邏輯，都需要人工操作。

關(guān)于開發(fā)者工具的一些細(xì)節(jié)

關(guān)于小程序的打包、預(yù)覽、上傳的流程，都包含在開發(fā)者工具中，所以想要更深入得了解小程序的流程機(jī)制，必須要從開發(fā)者工具入手。

經(jīng)過簡單研究，發(fā)現(xiàn)開發(fā)者工具是基于 NW.js 構(gòu)建的，基于 Node 和 Webkit 構(gòu)建的應(yīng)用程序。對于前端來說，這是一件令人感到幸福的事，直接可以通過讀源碼來了解它的邏輯。

代碼在哪里？ 在 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ā)者工具的源碼了。

工程流程化方案

上面，我們簡單了解了小程序的一些背景知識和架構(gòu)模式，下面，GitChator 將從 問題 -> 解決方案 的方式，來說明這套工程流程化方案。

Size 問題 -> 壓縮工具

還是從老問題壓縮說起吧。雖然微信對 Size 的限制從 1024 變成了 2048，但是終有一天，代碼會增長到超過 2048，而且， Size 的大小會影響用戶加載的速度，包括下載最新版本代碼的速度和小程序初始化的速度 ，所以壓縮是一直有必要的。

雖然開發(fā)者工具，已經(jīng)支持了代碼壓縮上傳，但是 GitChator 覺得它是個『假的壓縮選項(xiàng)』。因?yàn)樵陂喿x開發(fā)者工具的源碼邏輯之后，發(fā)現(xiàn)它的壓縮，只是將 JavaScript 用 Uglify 進(jìn)行混淆壓縮。而對 Wxml 、Wxss 沒有進(jìn)行任何壓縮處理。同時，對資源路徑中的無用文件也沒有做處理。因此，我們要做的有關(guān)壓縮的事情還是很多的。例如：

合并 JavaScript 并壓縮

將所有的 JavaScript 腳本使用合并成一個文件，這樣會使 腳本壓縮效率變高 （例如 require 的長路徑?jīng)]了）、 混淆性越大 （代碼的目錄結(jié)構(gòu)沒了）。雖然 JavaScript 腳本被包裝成類 AMD 的形式，但是使用時是 同步加載同步執(zhí)行 的，因此將多個 JavaScript 腳本合并成一個并不影響小程序加載或切換視圖的效率，反而因?yàn)闇p少了 IO 次數(shù)，提升了加載效率。（現(xiàn)在 GitChator 暫時使用的是 WebPack，而使用 Rollup 會讓代碼更小，執(zhí)行效率更快）可是要如何做呢？

首先是，入口文件選?。赫蛏厦娲a結(jié)構(gòu)所說，小程序有一個統(tǒng)一的入口是 app.js ，而每個視圖 View 都有自己的入口 page.js ，將這些所有入口 require 到一個統(tǒng)一的入口文件中，進(jìn)行打包，這樣會得到一個擁有 JavaScript 腳本邏輯的 bundle.js 。

其次，要對入口文件進(jìn)行一定的修改，讓代碼被合并成一個文件后，仍能正常運(yùn)行。

對于視圖 View 的入口，必須存在 Page(PageOption) ，這樣的視圖注冊邏輯，我們只需通過正則或者 AST 將其改為自定義的注冊（Register）方法 global.__p('/path/to/page.js', pageIndex, PageOption) 即可。

實(shí)現(xiàn)如下：

global.__p = pageName, index, pageOpt) => {
    // 其他相關(guān)邏輯
    global['p' + index] = () => {
        Page(pageOpt || {});
    };
};

這樣在視圖 View 的入口文件中，只需要 global.pXX() 一段代碼即可。

對于小程序的入口 app.js ，將原本的內(nèi)容直接改為 require('bundle.js') 即可，因?yàn)樗⒉幌褚晥D入口和代碼路徑有關(guān)。

最終，形式如下：

壓縮其他文件

其他文件主要包括 Wxml 文件、 Wxss 文件和 JSON 文件。平時前端開發(fā)中，對 HTML 和 CSS 的壓縮，主要是 去除的空白字符、換行 以及 刪除注釋 。

對于 Wxml 直接兩個正則即可：

• /<!--((.|\n|\r)*?)-->/gm ：去除注釋。

• /\"\n\s*/g : 去除換行。

對與 Wxss，直接用 uglifycss 即可；對于JSON，直接 JSON.stringify(JSON.parse(...)) 。

這里，有些讀者會可能提出兩個疑問：

• 1、空白字符、換行能有多少，減不了多少吧？

• 2、開發(fā)者工具為什么不做對這些文件的壓縮？

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

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

刪除無用文件

刪除無用的 JavaScript 文件（因?yàn)橐呀?jīng)打包為 bundle.js 了，無需其他非入口文件了），刪除沒被 import 的 Wxss 和 Wxml 文件，刪除空目錄等等。

代碼級優(yōu)化

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

• 提煉公共組件、公共 API。

• 使用 ES6 時，盡量不使用依賴 Runtime/Polyfill 的語法，例如 import 和 class 。

• 圖標(biāo)使用 Iconfont。

• 等等...

多業(yè)務(wù)并行開發(fā)問題 -> 以模塊化的方式進(jìn)行業(yè)務(wù)代碼隔離

隨著小程序的諸多限制放開，越來越多的產(chǎn)品想來分此一杯羹，導(dǎo)致像去哪兒網(wǎng)這樣多業(yè)務(wù)的公司，一個小程序里承接的業(yè)務(wù)也會逐漸增多，開發(fā)人員的數(shù)量也會直線上升（一個小程序的開發(fā)者最多 30 人）。而此時，如果所有業(yè)務(wù)的開發(fā)者還在同一個項(xiàng)目里開發(fā)的話，那么這個項(xiàng)目將會非常難以管理。因此， 以模塊化的方式進(jìn)行業(yè)務(wù)代碼隔離 勢在必行。

對于模塊的劃分，很顯然應(yīng)該 按照業(yè)務(wù)來劃分 ，每個業(yè)務(wù)自己是單獨(dú)的模塊，并且 相互之間不能存在依賴關(guān)系 ， 能并且只能依賴公共模塊 。就如下圖所示。

這樣實(shí)現(xiàn)帶來最大的好處是 可插拔 ，也就是可以隨時將任意一個模塊在不影響其他業(yè)務(wù)的情況下進(jìn)行修改或刪除。

上文中提出過一個問題， 將去哪兒旅行 App 上的主要業(yè)務(wù)的主要流程都放進(jìn)微信小程序內(nèi)，真的適合小程序的場景嗎？ 。這是問題雖然是一個純產(chǎn)品上的問題，但是 可插拔 的特性，會讓這個問題 變得容易解決 ，產(chǎn)品同學(xué)可以很容易地以業(yè)務(wù)模塊為單位增減業(yè)務(wù)。假設(shè)一個業(yè)務(wù)取得的收益很小，產(chǎn)品同學(xué)可以立即在不影響其他業(yè)務(wù)的前提下，將這個業(yè)務(wù)下線，并將其的空間用于接入新業(yè)務(wù)或分配給其他線上業(yè)務(wù)。

同時，業(yè)務(wù)在開發(fā)時，本地只需要存在 Common 模塊就能運(yùn)行，降低了開發(fā)和調(diào)試的成本。

可插拔的模塊化不僅僅可以讓模塊變更的成本降低，同時也讓 以相同模塊構(gòu)建多個小程序 的成本降低，增加小程序產(chǎn)品的 靈活性 ，根據(jù)場景構(gòu)建出最適合的 即開即用 的小程序。

諸如上圖所示，用不同的模塊構(gòu)建出不同場景的小程序。

• 去哪兒出行：交通類產(chǎn)品，包括去哪兒所有的交通類業(yè)務(wù)模塊。

• 去哪兒游玩：場景是本地游，因此包括與本地游相關(guān)的業(yè)務(wù)模塊。

當(dāng)然，這只是舉例，具體情況視產(chǎn)品場景而定，但是，這種構(gòu)建方式，GitChator 個人覺得比較適合小程序這種靈活的場景。而大而全的功能，還是交給 A小程序制作pp 吧。

這里就出現(xiàn)另一個問題： 如何有效的管理模塊 。

因?yàn)橐粋€模塊，被多個小程序項(xiàng)目引用，所以它的版本化是非常重要的，否則有微信小程序appid可能出現(xiàn)，為了滿足一個小程序項(xiàng)目的需求進(jìn)行改動后，在另一個小程序內(nèi)出現(xiàn)問題。

因此，GitChator 基于公司通用的前端開發(fā)工具集 YKit 實(shí)現(xiàn)插件，配合 公司的代碼倉庫 GitLab 和 公司的打包平臺 Jenkins，實(shí)現(xiàn)了一套模塊版本的管理邏輯。

本地版本查詢:

本地安裝：

查詢頁面：

當(dāng)然，也可以用私有 NPM 倉庫實(shí)現(xiàn)模塊管理，GitChator 主要是為了和公司發(fā)布系統(tǒng)打通，才選擇這樣實(shí)現(xiàn)。

在實(shí)現(xiàn)模塊化的過程中，有兩個地方需要注意：

路由：業(yè)務(wù)模塊已經(jīng)隔離，而路由配置在統(tǒng)一的入口處，這樣會影響模塊的插拔。因此，在每個模塊的根目錄下，添加各自的 app.json 配置，用于配置模塊自己的路由，然后在工具打包的時候，將各模塊的路由進(jìn)行合并 Merge。

App.onLaunch:業(yè)務(wù)模塊有些邏輯，需要在 App 的 onLaunch 時執(zhí)行。因此，在每個模塊的根目錄下，添加各自的 app.js 腳本，完善相應(yīng)的，然后在工具打包時，將腳本注入到相應(yīng)的位置。

module.exports = () => {
    onLaunch: () => {
        // TODO Something
    }
};

最后，可插拔的模塊化對于 模塊 Size 的計算 也是非常重要的。

模塊的 Size = 小程序總 Size - 拔去此模塊時小程序的 Szie

這樣的計算方式，是十分可靠的，有利于小程序?qū)γ總€模塊進(jìn)行配額分配如何制作小程序。

人工發(fā)布問題 -> 自動化發(fā)布系統(tǒng)集成

一般比較成熟的公司，都會有自己的發(fā)布系統(tǒng)，用于項(xiàng)目的發(fā)布，在降低人工成本的同時，規(guī)避人工操作的風(fēng)險。而微信小程序后臺并沒有提供相應(yīng)的接口 API 進(jìn)行此類操作，因此，需要自己實(shí)現(xiàn)一套上傳發(fā)布邏輯。

這個邏輯主要有兩點(diǎn)： 小程序打包 和 各種掃碼驗(yàn)證 。

對于小程序打包，直接從微信開發(fā)者工具內(nèi)，將小程序打包的邏輯抽離出來即可。

// wxBuild 為開發(fā)者工具資源下 app/dist/weapp/commit/build.js
// wxPack 為開發(fā)者工具資源下 app/dist/weapp/commit/pack.js
wxBuild({
    projectpath: 'path/to/source', // 小程序項(xiàng)目路徑
    es6: true,
    postcss: true,
    minified: true
}, {
    noCompile: true
}, (err, data) => {   
    wxPack(data, 'path/to/result.wx', (err, data) => {
        // data 為產(chǎn)出物的路徑 
    });
});

對于掃碼驗(yàn)證，其實(shí)是模擬用戶的行為。Gitchator 實(shí)現(xiàn)的邏輯是，將二維碼打印在發(fā)布日志的 Job 里，管理員使用微信進(jìn)行掃碼即可。下面是發(fā)布日志的截圖。（主要用到 phantom）。

由于篇幅有限，具體的細(xì)節(jié)可以私下和 GitChator 交流。不過 GitChator 覺得，微信的同學(xué)，應(yīng)該會在今后提供相應(yīng)的上傳發(fā)布接口，自動化發(fā)布，其實(shí)是大多數(shù)公司的剛需。

打包發(fā)布完成，發(fā)給項(xiàng)目相關(guān)人，一封統(tǒng)計性郵件，也是非常有必要的。

總結(jié)

除去上面描述的幾點(diǎn)，我們還做了諸如 環(huán)境參數(shù)配置 、 項(xiàng)目參數(shù)注入 、 無埋點(diǎn)統(tǒng)計 等通用邏輯，來解決并完善開發(fā)中所遇到的問題。

總結(jié)起來，去哪兒的小程序工程流程化主要包括三部分： 本地工具 、 模塊倉庫 以及 發(fā)布系統(tǒng)關(guān)聯(lián) 。

• 本地工具：包括項(xiàng)目初始化、打包壓縮、模塊編譯、環(huán)境參數(shù)配置、項(xiàng)目參數(shù)注入、無埋點(diǎn)統(tǒng)計等等功能，主要解決開發(fā)過程中所遇到的問題和痛點(diǎn)。

• 模塊倉庫：模塊化方案的基礎(chǔ)，管理模塊的版本。保證一個小程序使用多個模塊和一個模塊被多個小程序引用時的正確性。

• 發(fā)布系統(tǒng)關(guān)聯(lián)：避免人工操作的繁瑣和易錯，自動化完成打包、上傳、發(fā)布等流程。