小程序多端框架全面測評

最近前端屆多端框架頻出，相信不少有代碼多端運行需求的開發者都會產生一些疑惑：這些框架都有什麼優缺點？到底應該用哪一個？

做爲 Taro 開發團隊一員，筆者想在本文儘可能站在一個客觀公正的角度去評價各個框架的選型和優劣。但宥於利益相關，本文的觀點極可能是帶有偏向性的，你們能夠帶着批判的眼光去看待，權當拋磚引玉。

那麼，當咱們在討論多端框架時，咱們在談論什麼：

多端

筆者覺得，如今流行的多端框架能夠大體分爲三類：

1. 全包型

這類框架最大的特色就是從底層的渲染引擎、佈局引擎，到中層的 DSL，再到上層的框架所有由本身開發，表明框架是 Qt 和 Flutter。這類框架優勢很是明顯：性能（的上限）高；各平臺渲染結果一致。缺點也很是明顯：須要徹底從新學習 DSL（QML/Dart），以及難以適配中國特點的端：小程序。

這類框架是最原始也是最純正的的多端開發框架，因爲底層到上層每一個環節都掌握在本身手裏，也能最大可能地去保證開發和跨端體驗一致。但它們的框架研發成本巨大，渲染引擎、佈局引擎、DSL、上層框架每一個部分都須要大量人力開發維護。

2. Web 技術型

這類框架把 Web 技術（JavaScript，CSS）帶到移動開發中，自研佈局引擎處理 CSS，使用 JavaScript 寫業務邏輯，使用流行的前端框架做爲 DSL，各端分別使用各自的原生組件渲染。表明框架是 React Native 和 Weex，這樣作的優勢有：

1. 開發迅速
2. 複用前端生態
3. 易於學習上手，無論前端後端移動端，多多少少都會一點 JS、CSS

缺點有：

1. 交互複雜時難以寫出高性能的代碼，這類框架的設計就必然致使 JS 和 Native 之間須要通訊，相似於手勢操做這樣頻繁地觸發通訊就極可能使得 UI 沒法在 16ms 內及時繪製。React Native 有一些聲明式的組件能夠避免這個問題，但聲明式的寫法很難知足複雜交互的需求。
2. 因爲沒有渲染引擎，使用各端的原生組件渲染，相同代碼渲染的一致性沒有第一種高。

3. JavaScript 編譯型

這類框架就是咱們這篇文章的主角們：Taro、WePY 、uni-app 、 mpvue 、 chameleon，它們的原理也都大同小異：先以 JavaScript 做爲基礎選定一個 DSL 框架，以這個 DSL 框架爲標準在各端分別編譯爲不一樣的代碼，各端分別有一個運行時框架或兼容組件庫保證代碼正確運行。

這類框架最大優勢和創造的最大緣由就是小程序，由於第一第二種框架其實除了能夠跨系統平臺以外，也都能編譯運行在瀏覽器中。(Qt 有 Qt for WebAssembly, Flutter 有 Hummingbird，React Native 有 react-native-web, Weex 原生支持)

另一個優勢是在移動端通常會編譯到 React Native/Weex，因此它們也都擁有 Web 技術型框架的優勢。這看起來很美好，但實際上 React Native/Weex 的缺點編譯型框架也沒法避免。除此以外，編譯型框架的抽象也不是免費的：當 bug 出現時，問題的根源可能出在運行時、編譯時、組件庫以及三者依賴的庫等等各個方面。在 Taro 開源的過程當中，咱們就遇到過 Babel 的 bug，React Native 的 bug，JavaScript 引擎的 bug，固然也少不了 Taro 自己的 bug。相信其它原理相同的框架也沒法避免這一問題。

但這並不意味着這類爲了小程序而設計的多端框架就都不堪大用。首先如今各巨頭超級 App 的小程序百花齊放，框架會爲了抹平小程序作了許多工做，這些工做在大部分狀況下是不須要開發者關心的。其次是許多業務類型並不須要複雜的邏輯和交互，沒那麼容易觸發到框架底層依賴的 bug。

那麼當你的業務適合選擇編譯型框架時，在筆者看來首先要考慮的就是選擇 DSL 的起點。由於有多端需求業務一般都但願能快速開發，一個可以快速適應團隊開發節奏的 DSL 就相當重要。不論是 React 仍是 Vue（或者類 Vue）都有它們的優缺點，你們能夠根據團隊技術棧和偏好自行選擇。

若是無論什麼 DSL 都能接受，那就能夠進入下一個環節：

生態

如下內容均以各框架如今（2019 年 3 月 11日）已發佈穩定版爲標準進行討論。

開發工具

就開發工具而言 uni-app 應該是一騎絕塵，它的文檔內容最爲翔實豐富，還自帶了 IDE 圖形化開發工具，鼠標點點點就能編譯測試發佈。

其它的框架都是使用 CLI 命令行工具，但值得注意的是 chameleon 有獨立的語法檢查工具，Taro 則單獨寫了 ESLint 規則和規則集。

在語法支持方面，mpvue、uni-app、Taro 、WePY 均支持 TypeScript，四者也都能經過 typing 實現編輯器自動補全。除了 API 補全以外，得益於 TypeScript 對於 JSX 的良好支持，Taro 也能對組件進行自動補全。

CSS 方面，全部框架均支持 SASS、LESS、Stylus，Taro 則多一個 CSS Modules 的支持。

因此這一輪比拼的結果應該是：

uni-app > Taro > chameleon > WePY、mpvue

多端支持度

只從支持端的數量來看，Taro 和 uni-app 以六端略微領先（移動端、H五、微信小程序、百度小程序、支付寶小程序、頭條小程序），chameleon 少了頭條小程序緊隨其後。

但值得一提的是 chameleon 有一套自研多態協議，編寫多端代碼的體驗會好許多，能夠說是一個能戳到多端開發痛點的功能。uni-app 則有一套獨立的條件編譯語法，這套語法能同時做用於 js、樣式和模板文件。Taro 能夠在業務邏輯中根據環境變量使用條件編譯，也能夠直接使用條件編譯文件（相似 React Native 的方式）。

在移動端方面，uni-app 基於 weex 定製了一套 nvue 方案 彌補 weex API 的不足；Taro 則是暫時基於 expo 達到一樣的效果；chameleon 在移動端則有一套 SDK 配合多端協議與原生語言通訊。

H5 方面，chameleon 一樣是由多態協議實現支持，uni-app 和 Taro 則是都在 H5 實現了一套兼容的組件庫和 API。

mpvue 和 WePY 都提供了轉換各端小程序的功能，但都沒有 h5 和移動端的支持。

因此最後一輪對比的結果是：

chameleon > Taro、uni-app > mpvue、WePY

組件庫/工具庫/demo

做爲開源時間最長的框架，WePY 無論從 Demo，組件庫數量 ，工具庫來看都佔有必定優點。

uni-app 則有本身的插件市場和 UI 庫，若是算上收費的框架和插件比起 WePy 也是徹底不遑多讓的。

Taro 也有官方維護的跨端 UI 庫 taro-ui ，另外在狀態管理工具上也有很是豐富的選擇（Redux、MobX、dva），但 demo 的數量不如前兩個。但 Taro 有一個轉換微信小程序代碼爲 Taro 代碼的工具，能夠彌補這一問題。

而 mpvue 沒有官方維護的 UI 庫，chameleon 第三方的 demo 和工具庫也還基本沒有。

因此這輪的排序是：

WePY > uni-app 、taro > mpvue > chameleon

接入成本

接入成本有兩個方面：

第一是框架接入原有微信小程序生態。因爲目前微信小程序已呈一家獨大之勢，開源的組件和庫（例如 wxparse、echart、zan-ui 等）可能是基於原生微信小程序框架語法寫成的。目前看來 uni-app 、Taro、mpvue 均有文檔或 demo 在框架中直接使用原生小程序組件/庫，WePY 因爲運行機制的問題，不少狀況須要小改一下目標庫的源碼，chameleon 則是提供了一個按步驟大改目標庫源碼的遷移方式。

第二是原有微信小程序項目部分接入框架重構。在這個方面 Taro 在京東購物小程序上進行了大膽的實踐，具體能夠查看文章《Taro 在京東購物小程序上的實踐》。其它框架則沒有提到相關內容。

而對於兩種接入方式 Taro 都提供了 taro convert 功能，既能夠將原有微信小程序項目轉換爲 Taro 多端代碼，也能夠將微信小程序生態的組件轉換爲 Taro 組件。

因此這輪的排序是：

Taro > mpvue 、 uni-app > WePY > chameleon

流行度

從 GitHub 的 star 來看，mpvue 、Taro、WePY 的差距很是小。從 NPM 和 CNPM 的 CLI 工具下載量來看，是 Taro（3k/week）> mpvue (2k/w) > WePY (1k/w)。但發佈時間也恰好反過來。筆者估計三家的流行程度和案例都差不太多。

uni-app 則號稱有上萬案例，但不像其它框架同樣有一些大廠應用案例。另外從開發者的數量來看也是 uni-app 領先，它擁有 20+ 個 QQ 交流羣（最大人數 2000）。

因此從流行程度來看應該是：

uni-app > Taro、WePY、mpvue > chameleon

開源建設

一個開源做品能走多遠是由框架維護團隊和第三方開發者共同決定的。雖然開源建設不能具體地量化，但依然是衡量一個框架/庫生命力的很是重要的標準。

從第三方貢獻者數量來看，Taro 在這一方面領先，而且 Taro 的一些核心包/功能（MobX、CSS Modules、alias）也是由第三方開發者貢獻的。除此以外，騰訊開源的 omi 框架小程序部分也是基於 Taro 完成的。

WePY 在騰訊開源計劃的加持下在這一方面也有不錯的表現；mpvue 因爲停滯開發了好久就比較落後了；多是產品策略的緣由，uni-app 在開源建設上並不熱心，甚至有些部分代碼都沒有開源；chameleon 剛剛開源不久，但它的代碼和測試用例都很是規範，之後或許會有不錯的表現。

那麼這一輪的對比結果是：

Taro > WePY > mpvue > chameleon > uni-app

最後補一個總的生態對比圖表：

將來

從各框架已經公佈的規劃來看：

WePY 已經發布了 v2.0.alpha 版本，雖然沒有公開的文檔能夠查閱到 2.0 版本有什麼新功能/特性，但據其做者介紹，WePY 2.0 會放大招，是一個「對得起開發者」的版本。筆者也很是期待 2.0 正式發佈後 WePY 的表現。

mpvue 已經發布了 2.0 的版本，主要是更新了其它端小程序的支持。但從代碼提交， issue 的回覆/解決率來看，mpvue 要想在將來有做爲首先要打消社區對於 mpvue 無論不顧不更新的質疑。

uni-app 已經在生態上建設得很好了，應該會在此基礎之上繼續穩步發展。若是 uni-app 能增強開源開放，再增強與大廠的合做，相信將來還能更上一層樓。

chameleon 的規劃比較宏大，雖然是最後發的框架，但已經在規劃或正在實現的功能有：

• 快應用和端拓展協議
• 通用組件庫和垂直類組件庫
• 面向研發的圖形化開發工具
• 面向非研發的圖形化頁面搭建工具

若是 chameleon 把這些功能都作出來的話，再繼續完善生態，爭取更多第三方開發者，那麼在將來 chameleon 將大有可爲。

Taro 的將來也同樣值得憧憬。Taro 即將要發佈的 1.3 版本就會支持如下功能：

• 快應用支持
• Taro Doctor，自動化檢查項目配置和代碼合法性
• 更多的 JSX 語法支持，1.3 以後限制生產力的語法只有 只能用 map 創造循環組件 一條
• H5 打包體積大幅精簡

同時 Taro 也正在對移動端進行大規模重構；開發圖形化開發工具；開發組件/物料平臺以及圖形化頁面搭建工具。

結語

那說了那麼多，到底用哪一個呢？

若是不介意嚐鮮和學習 DSL 的話，徹底能夠嘗試 WePY 2.0 和 chameleon ，一個是醞釀了好久的 2.0 全新升級，一個有專門針對多端開發的多態協議。

uni-app 和 Taro 相比起來就更像是「水桶型」框架，從工具、UI 庫，開發體驗、多端支持等各方面來看都沒有明顯的短板。而 mpvue 因爲開發一度停滯，如今看來各個方面都不如在小程序端基於它的 uni-app 。

固然，Talk is cheap。若是對這個話題有更多興趣的同窗能夠去 GitHub 另行研究，有空看代碼，沒空看提交：

• chameleon: github.com/didi/chamel…
• mpvue: github.com/Meituan-Dia…
• Taro: github.com/NervJS/taro
• uni-app: github.com/dcloudio/un…
• WePY: github.com/Tencent/wep…

(按字母順序排序)