WeGeek Talk| WePY 開源框架

今天前來專欄分享的極客，是騰訊微信支付團隊。

小程序公測一個月時，微信支付團隊開源了小程序上的組件化開發框架 WePY，在 Github 上一經發布便受到了衆多開發者的追捧，網上搜索「微信小程序 WePY 開源框架資源彙總」滿是網友們自發分享的相關乾貨。

儘管 WePY 開源框架現在倍受推崇，回憶起開源的初衷，來自微信支付團隊的 Gcaufy 仍是表示：「WePY 開源框架的對外開源並非要去分享一個很成功的解決方案，而是我認爲這套方案可以解決在小程序開發中遇到的一些實際問題，而且但願能借助外界的力量去幫助一塊兒完善這套方案。」

接下來，讓咱們一塊兒看看 WePY 開源框架背後的開發故事吧。

正文

若是你有必定的開發經驗，會明顯感覺到小程序的開發十分容易上手——小程序自己提供一些特性如：模塊化，模板，數據綁定等，極大地方便了習慣使用 MVVM 框架的用戶。但同時，因爲運行環境有限，小程序尚不能使用市面上的流行框架。

在幾個月的開發歷程裏，做者 Gcaufy 便一直但願能夠設計出一套方案，更大可能地讓小程序開發貼近於當下開發習慣，WePY 開源框架應運而生。

WePY 開源框架的原理很簡單：經過 WePY 開源框架開發的代碼在通過編譯後，能生成一份完美運行在小程序端的代碼，使得小程序開發更貼近於傳統 H5 框架開發，能夠像開發 H5 同樣支持引入 npm 包，而且支持組件化開發以及支持 JS 新特性等，實現類 Vue 的開發體驗。

WePY 開源框架實現小程序的預加載

咱們知道，傳統的 H5 能夠經過預加載來提高用戶體驗，那麼小程序可以實現嗎？

答案是確定的。在小程序中使用預加載，比在 H5 中實現起來更爲簡單方便，但也更容易被開發者忽視。

傳統 H5 在啓動時，page1.html 只會加載 page1.html 的頁面與邏輯代碼，當 page1.html 跳轉至 page2.html 時，page1 全部的 Javascript 數據將會從內存中消失。在 page1 與 page2 之間的數據通訊只能經過 URL 參數傳遞或者瀏覽器的 cookie，localStorge 存儲處理。

而小程序在啓動時，會直接加載全部頁面邏輯代碼進內存。即使 page2 可能都不會被使用，在 page1 跳轉至 page2 時，page1 的邏輯代碼 Javascript 數據也不會從內存中消失。page2 甚至能夠直接訪問 page1 中的數據。

小程序的這種機制差別正好能夠更好的實現預加載。

一般狀況下，咱們習慣將數據拉取寫在 onLoad 事件中。可是小程序的 page1 跳轉到 page2，到 page2 的 onLoad 存在一個 300ms ~ 400ms 的延時。以下圖：

由於小程序的特性，徹底能夠在 page1 中預先拿取數據，而後在 page2 中直接使用，這樣就能夠避開 redirecting 的 300ms ~ 400ms了。以下圖：

對於上述問題，WePY 開源框架中封裝了兩種概念去解決：

·預加載數據

用於小程序中 page1 主動傳遞數據給 page2，好比 page2 須要加載一份耗時很長的數據。我能夠在 page1 閒時先加載好，進入 page2 時直接就可使用。 ·預查詢數據 用於避免於 redirecting 延時，在跳轉時調用 page2 預查詢。

WePY 開源框架添加了 onPrefetch 事件，會在 redirect 之時被主動調用，這一改進擴展了生命週期；同時 onLoad 事件也添加了一個參數，用於接收預加載或者是預查詢的數據：

// params
// data.from: 來源頁面，page1
// data.prefetch: 預查詢數據
// data.preload: 預加載數據
onLoad (params, data) {}
複製代碼

WePY 開源框架實現小程序的數據優化

可能有開發者還不瞭解，其實小程序的視圖層與邏輯層是徹底分離的，這兩者之間的通訊全都依賴於 WeixinJSBridge 實現。如：

· 開發者工具中是基於 window.postMessage

· iOS 中基於 window.webkit.messageHandlers.invokeHandler.postMessage

· Android 中基於 WeixinJSCore.invokeHandler

數據綁定方法 this.setData() 亦然，因而很容易想到，頻繁的數據綁定會不會致使通訊的成本大大增長呢？

爲了驗證 setData() 存在性能問題，微信支付團隊作了一個相關測試：動態綁定 1000 條數據的列表進行性能測試，主要針對如下三種狀況：

· 最優綁定: 在內存中添加完畢後最後執行 setData() 操做。

· 最差綁定: 在添加一條記錄執行一次 setData() 操做。

· 最智能綁定：無論中間進行了什麼操做，在運行結束時執行一次髒檢查，對須要設置的數據進行 setData() 操做。

通過十次刷新運行測試後得出瞭如下結果：

從測試結果能夠明顯看出，實現一樣的邏輯，性能數據卻相差 40 倍左右。經過分析測試結果，咱們能夠得知，在開發過程當中，應當儘可能避免同一流程內屢次 setData() 操做。

那麼有什麼優化方式呢？

採起人工維護確定可以實現，但當頁面邏輯負責起來以後，即使花很大的精力去維護也不必定能保證每一個流程只存在一次 setData()，可維護性也不高。所以，WePY 開源框架選擇了使用髒檢查去作數據綁定優化。

雖然 WePY 開源框架在語法上借鑑了 Vue，原理則是徹底不一樣的。好比 WePY 開源框架使用的是 ng 的髒檢查設計，而不是使用的 Vue 的 getter，setter 等。用戶不用再擔憂在流程裏，數據被修改了多少次，只用在流程最後作一次髒檢查，而且按需執行 setData() 便可。

使用 WePY 開源框架在開發效率上的提高

除了上述基於性能上作出的優化之外，WePY 開源框架也做出了一系列開發效率上的優化。

支持豐富的編譯器

· js 能夠選擇用 Babel 或者 TypeScript 編譯。

· wxml 能夠選擇使用 Pug(原Jade)。

· wxss 能夠選擇使用 Less、Sass、Styus。

支持豐富的插件處理

· 能夠經過配置插件對生成的js進行壓縮混淆，壓縮圖片，壓縮 wxml 和 json 已節省空間等等。

支持 ESLint 語法檢查

添加一行配置就能夠支持 ESLint 語法檢查，能夠避免低級語法錯誤以及統一項目代碼的風格。

生命週期優化

· WePY 開源框架添加了 onRoute 的生命週期。用於頁面跳轉後觸發。 這一優化項是由於小程序中並不存在一個頁面跳轉事件。onShow 事件能夠用做頁面跳轉事件，但同時也存在負做用，好比按 HOME 鍵後切回來，或者拉起支付後取消，拉起分享後取消都會觸發 onShow 事件。

優化事件傳參

原有的傳參寫法：

<view data-alpha-beta="1" data-alphaBeta="2" bindtap="bindViewTap"> DataSet Test </view>
Page({
  bindViewTap:function(event){
    event.target.dataset.alphaBeta === 1 // - 會轉爲駝峯寫法
    event.target.dataset.alphabeta === 2 // 大寫會轉爲小寫
  }
})
複製代碼

優化後：

<view @tap="bindViewTap("1", "2")"> DataSet Test </view>
methods: {
  bindViewTap(p1, p2, event) {
    p1 === "1";
    p2 === "2";
  }
}
複製代碼

更多詳情能夠參看 WePY 開源框架文檔：tencent.github.io/wepy/index.…

WePY 開源框架2.0 計劃

目前 WePY 開源框架主要由微信支付團隊內相關人員利用業餘時間，與幾個外部貢獻者一塊兒來維護。技術社區中有很多熱心的貢獻者，不只本身參與，也會帶來了一些新的貢獻者力量，不時還會提供一些比較核心的功能。

當被問及「WePY 開源框架 2.0 進度」問題時，微信支付團隊表示現已將進入了 WePY 2.0 內測階段，相信不久後就將與你們正式見面。

「但願 2.0 是一個全新的，對得起開發者的版本。」

瞭解更多微信小程序開發者內容，歡迎掃碼關注微信公衆號——微信極客WeGeek