本主題雖然在其它地方講了很多次，但還是有非常多新內(nèi)容。因?yàn)楹芏鄸|西正在做或者想要做。本次分享主要分為以下幾個部分：

WePY 的介紹
WePY 的用戶

上面展示的 WePY 用戶不是全部的數(shù)據(jù)。因?yàn)闆]有辦法讓 WePY 用戶主動上報(bào)自己在操作 WePY，所以我只列了我知道的在操作 WePY 的企業(yè)，數(shù)據(jù)比較局限。

就我所知道的，最近有一個刷爆朋友圈的微信小程序 —— 騰訊疫苗，前端采用的 WePY，后端用了騰訊開源的 TARS 項(xiàng)目。微信支付內(nèi)部也有大量微信小程序在操作 WePY 框架。

右邊貼的聊天記錄是我在 WePY 交流群收集到的用戶反饋，就反饋的內(nèi)容來看，有很多感謝的話，說明 WePY 這個框架確實(shí)能幫助搭建者提高自己的搭建效率。嘿嘿，我沒有貼 WePY 的負(fù)面反饋，因?yàn)槲覔?dān)心一頁 PPT 不夠貼 :eyes:。

WePY 的數(shù)據(jù)

WePY 項(xiàng)目在 Github 上現(xiàn)在有13900多個 Star。拿其它前端框架對比，Vue、React 等 Star 數(shù)可能達(dá)到了 10W+，但是它們都是國際的項(xiàng)目。WePY 這個項(xiàng)目由于微信小程序的原因，算是一個國內(nèi)項(xiàng)目，能有13000多個 Star 還是相當(dāng)不錯的。Star 數(shù)多不一定典型 WePY 這個框架好，但是能表明微信小程序這塊流量很大，搭建微信小程序也非常有前景。 搭建者們需要 WePY 這樣的框架來提供幫助。這也是為什么后來出現(xiàn)了 Taro、mpvue 等類似的非常優(yōu)秀的框架。

issues 目前有1300多個。這意味著我每天起床都有超過10條 to-do list 需要處理。加上每天還有企業(yè)的其它事情需要處理，比較頭大。

pull requests 目前有320多條。相比其它開源項(xiàng)目，這個 PR 數(shù)量相當(dāng)不錯，非常感謝為 WePY 作貢獻(xiàn)的搭建者們。

用戶數(shù)有4000多。這個數(shù)據(jù)的來源我是統(tǒng)計(jì)的我建立的 WePY 交流群，目前這個交流群里有 4000 多人。

WePY 是什么

將 Web App 和微信小程序進(jìn)行對比。Web App 和微信小程序在功能上類似， Web App 在搭建的時候，可能操作 Vue.js 作為其核心庫，用 Webpack 進(jìn)行打包。在微信小程序中，大家可以簡單的將 WePY 理解為 Web App 里的 Vue.js + Webpack 的合體。

WePY 的特色

WePY 在搭建中到底幫助搭建者做了什么事情呢？WePY 又都有哪些特色呢？

1. 腳手架：它提供了一個相當(dāng)于 vue-cli 的腳手架，一行命令生成簡單的 demo 項(xiàng)目。用戶可以基于這個 demo 進(jìn)行搭建，省去了啟動項(xiàng)目前繁瑣的配置。
2. 編譯打包：原生搭建微信小程序缺失了許多能力，比如 LESS、SASS。很多用戶面對這個問題都是做一個簡單的 Gulp 編譯。WePY 自帶了編譯打包能力，想用 LESS、SASS、NPM 等可以直接操作 WePY 的打包工具輸出微信小程序可以運(yùn)行的代碼。
3. 核心庫：核心庫類似 Vue、React 等。WePY 核心庫包含一些簡單的 API 封裝幫助處理一些事情。
4. 特性與優(yōu)化：搭建上，WePY 提供了一些語法糖，可以簡單方便的實(shí)現(xiàn)一些復(fù)雜功能。性能上，微信小程序本身的性能有一些問題，WePY 把性能上的問題抹平了，搭建者不用關(guān)心性能這部分。
5. 復(fù)用與擴(kuò)展：復(fù)用方面，原生小程序怎么用 npm 資源需要將相對應(yīng)的資源下載并放到代碼目錄中，利用 WePY 可以直接安裝 npm 包并操作。擴(kuò)展方面，在編譯過程中，可以隨意添加和擴(kuò)展編譯手段，比如 LESS、SASS、編譯插件等。
6. 多端：利用 WePY 可以將一份代碼運(yùn)行在微信小程序、H5 等端。

WePY 的規(guī)劃

16年8月參加微信小程序內(nèi)測，10月份開始著手代碼轉(zhuǎn)換相關(guān)的工作。在不停的迭代中，我發(fā)現(xiàn)還有很多事情可以做。比如可以將相關(guān)的工作抽象出來提供給其它搭建者。于是在11月我對代碼進(jìn)行了重構(gòu)，將 Gulp 編譯部分拋棄重寫并于 Github 開源1.1版本。

開源之后有很多人關(guān)注到這個項(xiàng)目，說明還是有不少人遇到了相應(yīng)的問題。因此我做了更加具體的優(yōu)化，在1.1版本上又一次重構(gòu)，把編譯流程抽象，提出了編譯器和插件兩個概念，方便用戶進(jìn)行擴(kuò)展。

17年1月份發(fā)布1.4版本，對整個搭建流程和搭建者操作框架時的體驗(yàn)進(jìn)行了更多優(yōu)化，包含性能優(yōu)化等。

1.6 版本開始考慮多端問題：微信小程序一套代碼多端復(fù)用。

17年11月左右，微信小程序推出了原生組件。WePY 本身就是為了解決微信小程序組件的問題，原生組件發(fā)布之后，WePY 的操作場景就沒有以前那么強(qiáng)了，所以我開始思考， WePY 需要做一個完全重構(gòu)的版本。

18年2月份啟動了該重構(gòu)版本，這個版本主要是為了解決微信小程序原生組件相關(guān)的問題，是一個全新的重構(gòu)版本。但由于各種原因，這個版本還沒有正式公布。敬請期待！

WePY 的實(shí)現(xiàn)原理

接下來我會講一下 WePY 在技術(shù)上的實(shí)現(xiàn)原理。

WePY 解決的問題

任何一個項(xiàng)目都是發(fā)現(xiàn)問題，解決問題的過程，WePY 要解決的問題就是：

1. 組件化搭建：微信小程序原生組件出現(xiàn)之前，微信小程序沒有很好的組件化搭建商業(yè)模式。比如我自己實(shí)現(xiàn)了一套 dialog，別人想操作的時候可能要把我的代碼拷貝一份。實(shí)現(xiàn)了組件化之后，我只要把這個組件給他就好了。
2. npm 資源：Web 發(fā)展至今，npm 庫上有非常龐大的資源。但是原生微信小程序沒有操作 npm 資源的能力，WePY 提供了這個功能。
3. 前端工程化：前面提及的打包構(gòu)建部分
4. 性能優(yōu)化
5. 友好的搭建體驗(yàn)：體驗(yàn)優(yōu)化
6. 跨網(wǎng)站支持：多端這部分

總的來說，WePY 解決的問題就是搭建中遇到的痛苦問題。

WePY 的架構(gòu)

上面是我寫的兩個核心的部分：CLI 以及 Core。Core 通過 CLI 編譯，生成微信小程序端運(yùn)行的代碼。CLI 部分又分為 wepy、wepy-web ，分別負(fù)責(zé) wepy 的編譯和 wepy-web 的編譯。其上又分為編譯器和插件兩部分，編譯器涉及到目前主流的預(yù)處理器，類似 Webpack 的 loader 。插件是在編譯之后要做的事情，類似于 Webpack 的 plugin。Core 部分分為 wepy 核心庫、微信小程序核心庫和 wepy-web 核心庫。wepy-web 核心庫比微信小程序多了 wepy components 和 wepy API 。微信小程序本身的一些內(nèi)置組件，比如彈窗組件，想要多端運(yùn)行都需要封裝起來放在 wepy components 。微信小程序原生 API 需要通過 wepy API 封裝。

web 本身還分很多網(wǎng)站種類，比如 browser、微信 h5、QQ h5，這些都需要分別適配，所以 wepy-web 之上是一個適配層。

整個 Core 之上，是用戶封裝的一些組件，比如上報(bào)、異步。還有一些功能組件，比如用戶做的彈窗、toast、imageloader 等。

縱觀整個 WePY，我的代碼會通過 CLI 基于 Core 輸出微信小程序端運(yùn)行的代碼。

WePY 的編譯過程

WePY 本身定義了一個文件后綴 .wpy 。編譯時將該文件解析并拆分為 Style、Template、Script。拆分時，會解析并記錄組件關(guān)系，包含事件、引用等。每個節(jié)點(diǎn)的信息都會被記錄，在注入時生成到 JS 中，在 JS 中就可以知道組件關(guān)系并進(jìn)行調(diào)用。生成完之后進(jìn)入到 plugin，plugin 是用戶自定義的，需要進(jìn)行圖片壓縮、JS 混淆、wxml 壓縮等處理。依次做完這些處理之后才會得到可以在微信小程序中運(yùn)行的代碼。

以上就是 WePY 的整個編譯過程。

多端的實(shí)現(xiàn)

在實(shí)現(xiàn)多端方面，面臨著以下問題：

• 搭建商業(yè)模式

  開發(fā)小程序商業(yè)模式自成一派，與現(xiàn)有搭建商業(yè)模式都不相同。好在操作 WePY 搭建時，WePY 操作的是類 Vue 的搭建語法，跟 Vue 搭建商業(yè)模式很貼近，所以搭建商業(yè)模式問題借助 WePY 非常好解決。

• 標(biāo)簽與樣式

  微信小程序與 H5 的標(biāo)簽不一樣，但是可以直接做一些簡單的轉(zhuǎn)換處理。比如 <view> 轉(zhuǎn)換為 <div> 。樣式上微信小程序有一個 rpx 單位，在 750 px 的情況下直接 /2 將 rpx 轉(zhuǎn)為 px。

• 模版語法

  微信小程序有自己的模版語法，比如 <wx-if> 等，解析時可以做簡單的轉(zhuǎn)換。

• 模塊化

  微信小程序原生可以操作 require ,但是H5不可以。好在有很多工具值得借鑒，比如 webpack,browserify。

• 內(nèi)置組件及內(nèi)置 API

  WePY 本身操作的是類 Vue 的語法，要轉(zhuǎn)換為 Vue 運(yùn)行在 Web 端的話，內(nèi)置組件直接操作 Vue 的形式編寫，操作時直接引入這個 Vue 組件。內(nèi)置 API 操作 WePY 提供的 JSSDK 去模擬微信端、H5等提供的 API。

因此，多端實(shí)現(xiàn)完全可行。咱們的一些項(xiàng)目完全利用 WePY 實(shí)現(xiàn)多端。

生態(tài)

左邊是在 Github 上看到的一些 UI 庫，大家在操作 WePY 搭建的時候可以直接利用這些 UI 庫進(jìn)行二次搭建。右邊是網(wǎng)上收集到的搭建資源，包含搭建組件、第三方模塊等。Github 上 WePY 關(guān)鍵字搜索結(jié)果有900多頁。從用戶反饋來看，用戶選擇 WePY 的一個原因也是 WePY 誕生的時間長，生態(tài)比較完善。

WePY 的規(guī)劃
現(xiàn)有問題

WePY 目前存在的核心問題是

• 靜態(tài)組件編譯

  WePY 項(xiàng)目做的比較倉促，花了大概一個多月就上線了。最開始只是為了解決組件化的問題。因此它采用了靜態(tài)組件編譯這套規(guī)劃，在編譯組件時，直接將我寫的組件進(jìn)行靜態(tài)替換，將我寫的組件注入到頁面中，做了一些隔離相關(guān)的事情。這導(dǎo)致動態(tài) repeat 時會出現(xiàn)比較嚴(yán)重的 BUG。這是設(shè)計(jì)上的缺陷，也是急需解決的問題。

• 語法解析

  xml 的解析用了一個存在問題的庫，導(dǎo)致 xml 解析時經(jīng)常出錯。js 的解析設(shè)計(jì)之初沒有考慮用語法樹解析，而是操作正則進(jìn)行解析。因?yàn)槟壳皟H涉及解析和語法注入，實(shí)現(xiàn)起來都比較簡單，所以沒有考慮用 AST 語法樹進(jìn)行解析，導(dǎo)致用戶沒有按照規(guī)范寫的一些代碼在解析時會出現(xiàn)錯誤。

• 類 Vue 語法

  從用戶的反饋來看，大家更希望用 Vue 的語法而不是類 Vue 語法。這兩個之間還是有一些差異的。

• 數(shù)據(jù)綁定性能優(yōu)化

  數(shù)據(jù)綁定時做了一些優(yōu)化和處理。但這些優(yōu)化和處理是通過臟數(shù)據(jù)進(jìn)行的，幫助用戶減少 setDate 的次數(shù)。但是后來再看，這塊還是有可以優(yōu)化的空間。

• 錯誤處理機(jī)制

  目前 WePY 的錯誤處理還比較簡單，沒有一個通用的錯誤處理機(jī)制。用戶在操作和編譯時的報(bào)錯很難追溯和定位。后面希望能做到在報(bào)錯時可以定位到報(bào)錯的文件和代碼。

• 測試用例覆蓋度

  WePY 目前只有核心庫被測試用例覆蓋。CLI 部分很復(fù)雜沒有做測試用例覆蓋。這導(dǎo)致目前大部分問題都和 CLI 相關(guān)。在下一個版本要全部被測試用例覆蓋。

編譯

上圖是2.0版本編譯部分的對比。左邊是 1.0 的編譯，右邊是2.0正在做的事。前面有講到1.0的編譯是把.wpy 文件放到 CLI 中進(jìn)行編譯。CLI 本身涉及編譯器和插件。在2.0中，將文件編譯修改為了入口編譯，從 App 入口，通過 CLI 自動解析依賴，CLI 中也只有插件，所有的核心功能都將通過插件實(shí)現(xiàn)。最后生成的除了微信小程序文件，還有 Vendor 文件（Vendor 文件是指所有的 npm 包都會打包到這個文件內(nèi)）、資源文件以及自己引用的模塊的文件。

插件化

編譯的核心部分是參考 Webpack 做的插件化編譯。插件化的概念參考我上面做的圖：固定一塊板子，板子上有固定數(shù)量的掛鉤，每個掛鉤都可以掛不同的東西。每個掛鉤放什么不清楚，但是每個掛鉤都可以實(shí)現(xiàn)不同的功能。我只需要規(guī)定編譯的流程，通過在掛鉤中寫不同的內(nèi)容實(shí)現(xiàn)整個編譯流程。所以整個編譯過程變?yōu)椋号渲贸跏蓟?arrow_right:核心編譯:arrow_right:輸出文件。

插件化可以提供更高的擴(kuò)展性和可復(fù)用性。所有的核心功能都依賴插件進(jìn)行。用戶覺得某個功能不合適的時候，完全可以自己寫一個插件替換掉核心功能。用戶可以對編譯的任何一個環(huán)節(jié)進(jìn)行修改。

數(shù)據(jù)綁定v1

v1 的數(shù)據(jù)綁定：在初始化的時候?qū)?shù)據(jù)進(jìn)行深拷貝做數(shù)據(jù)備份。每個流程都會預(yù)置 apply 動作，比如有一個點(diǎn)擊事件，點(diǎn)擊事件對數(shù)據(jù)進(jìn)行修改后進(jìn)入到 apply 流程，在 apply 流程中進(jìn)行深比較得到臟數(shù)據(jù)，臟數(shù)據(jù)最終進(jìn)入到 setDate 中。

右邊是比較簡單易懂的圖：小明對文件 B 進(jìn)行修改得到 B+,老師將 B+ 和 B 進(jìn)行對比，得到修改的數(shù)據(jù)。這是一個同步流程。當(dāng)小明叫小紅修改 C 文件時，如果老師不再，需要小紅主動叫老師對 C 文件進(jìn)行對比。即手動調(diào)用 apply 流程。

數(shù)據(jù)綁定v2

2.0 操作了 Vue 的數(shù)據(jù)綁定機(jī)制。在初始化時生成 Render Watcher，每個數(shù)據(jù)初始化時都會添加 observer。修改數(shù)據(jù)時記錄修改的 key-path 并加入隊(duì)列中，所有的修改動作都會觸發(fā) Watcher。在一個 nextTick 時間內(nèi)會清空隊(duì)列，并在 Render Watcher 中進(jìn)行 setDate。setDate 環(huán)節(jié)根據(jù)記錄的 key-path 進(jìn)行 setDate。

相比小明和老師的故事：小明在修改文件時會主動記錄修改的內(nèi)容并發(fā)起通知，小紅的操作方式與小明一致。當(dāng)老師收到通知時，根據(jù)小明、小紅的修改記錄對修改的內(nèi)容進(jìn)行 setDate 的處理。

這種優(yōu)化方式不需要手動調(diào)用 apply,也不需要關(guān)心異步流程。

質(zhì)量

第二個版本會先在內(nèi)部項(xiàng)目運(yùn)用，內(nèi)部實(shí)踐之后沒有問題再開源。另外2.0版本測試用例覆蓋度要完全覆蓋。

開源經(jīng)驗(yàn)分享
規(guī)范

如何保證開源項(xiàng)目的質(zhì)量？

第一是文檔規(guī)范。Readme 部分要言簡意賅的講明這個項(xiàng)目能干什么，一個簡單的示例說明如何啟動項(xiàng)目。Readme 要簡潔，大家一眼能看到他想要的東西。

第二是 CI。將對應(yīng)的狀態(tài)放在 Readme，讓搭建者可以更安心的操作這個項(xiàng)目。

第三是 license。

還有 contributer 文檔，代碼規(guī)范、Git 規(guī)范等。

測試操作了 Mocha 和 Istanbul，集成操作了 TravisCI，部署操作了 npm 和 lerna。

推廣運(yùn)營

推廣運(yùn)營方面主要靠自己發(fā)文章，做外鏈。另外我在微信公眾號和微信群推了自己的文章。微信群做了一個機(jī)器人放入群碼。

還做了文檔監(jiān)控，官方文檔修改之后，我可以第一時間知道官方文檔都修改了什么。以及監(jiān)控報(bào)告，每天都會給我的微信推送今日項(xiàng)目有多少 star 、多少 issue 。