wepy/mpvue/taro/uni-app，小程序開發框架哪家強？

微信小程序如火如荼，各家小程序快速跟進，繼App、H5以後，小程序平臺已躍升爲第三大流量平臺，那現階段快速開發小程序的更優方案是什麼？選擇原生開發，仍是藉助跨端框架？每一個框架又有何差別？

本文經受權轉載，以下爲原文，enjoy!

以前 Taro 團隊發佈了一篇《小程序多端框架全面測評》，讓開發者對業界主流的跨端框架，有了初步認識。感謝 Taro 團隊的付出。

不過橫評這件事，要想獲得更精確的結論，其實很是花費時間。它須要：

• 真實的動手寫多個平臺的測試demo，比較各個平臺的功能、性能，它們的實際狀況究竟是不是如文檔宣傳的那樣？
• 真實的學習每一個框架，瞭解它們的學習曲線，在實際開發中遇到問題時，感覺它們的文檔、教程、社區生態和技服能力到底怎麼樣？

咱們 uni-app 團隊投入兩週完成了這個深度評測，下面咱們就分享下，實際開發不一樣框架的測試例時遇到的問題，以及在各端的兼容測試結果。在本文裏，咱們團隊基於真實測試數據及各框架官網可採集到的公開數據，但願客觀公正地評價各個框架的選型和優劣。但宥於利益相關，本文的觀點極可能是帶有偏向性的，你們能夠帶着批判的眼光去看待。

評測實驗介紹

• 開發內容：開發一個仿微博小程序首頁的複雜長列表，支持下拉刷新、上拉翻頁、點贊。

• 界面以下：
  

• 開發版本：一共開發了6個版本，包括微信原生版、wepy版、mpvue版、taro版、uni-app版、chameleon版（以這些產品發佈時間排序，下同），按照官網指引經過cli方式默認安裝。

• 測試代碼開源（Github倉庫地址：https://github.com/dcloudio/test-framework），
  Tips:如有同窗以爲測試代碼寫法欠妥，歡迎提交 PR 或 Issus

• 測試機型：紅米 Redmi 6 Pro、MIUI 10.2.2.0 穩定版（最新版）、微信版本 7.0.3（最新版）

• 測試環境：每一個框架開始測試前，殺掉各App進程、清空內存，保證測試機環境基本一致；每次從本地讀取靜態數據，屏蔽網絡差別。

• 測試維度：
  1. 跨端支持度如何？
  2. 性能如何？
  3. 學習門檻
  4. 工具與周邊生態

1. 跨端支持度如何

開發一次，處處運行，是每一個程序員的夢想。但現實每每變成開發一次，處處調錯。

各個待評測框架，是否真得如宣傳的那樣，一次開發、多端發佈？

咱們將上述仿微博App依次發佈到各平臺，驗證每一個框架在各端的兼容性，結果以下：

測試結果說明：

• ⭕ 表示支持且功能正常，❌ 表示不支持，其它則表示支持但存在部分bug或兼容問題
• wepy 2.0 宣稱版已支持其餘家小程序，本測試基於wepy官網指引安裝的wepy-cli版本爲1.7.3，尚不支持多端
• chameleon官網未找到stopPullDownRefresh定義，中止頁面下拉刷新需分平臺編寫

經過這個簡單的例子能夠看出，跨端支持度測評結論：uni-app > taro > chameleon > mpvue >wepy、原生微信小程序

可是僅有上面的測試還不全面，實際業務要比這個測試例複雜不少。但咱們無法開發不少複雜業務作評測，因此還須要再對照各家文檔補充一些信息。
因爲每一個框架的文檔中都描述了各類組件和API的跨端支持程度。咱們過了幾家的文檔，發現各家基本是以微信小程序爲基線，而後把各類組件和API在其餘端實現了一遍：

• taro：H5端實現了大部分微信的API，App端和微信的差別比較大。
• uni-app：組件、API、配置，大部分在各個端均已實現，個別API有說明在某些端不支持。能夠看出uni-app是完整在H5端實現了一套微信模擬器，在App端實現了一套微信小程序引擎，才達到比較完善的平臺兼容性。
• chameleon：很是經常使用的一些組件和API在各端已經實現，這部分的平臺差別較少。但大量組件和API須要開發者本身分平臺寫代碼。

跨端框架，一方面要考慮框架提供的通用api跨端支持，同時還要考慮不一樣端的特點差別如何兼容。畢竟每一個端都會有本身的特點，不可能徹底一致。

• taro：提供了js環境變量判斷和統一接口的多端文件，能夠在組件、js、文件方面擴展多端，不支持其餘環節的分平臺處理。
• uni-app：提供了條件編譯模型，全部代碼包括組件、js、css、配置json、文件、目錄，均支持條件編譯，可不受限的編寫各端差別代碼。
• chameleon：提供了多態方案，能夠在組件、js、文件方面擴展多端，不支持其餘方式的分平臺處理。

跨端框架，還涉及一個ui框架的跨端問題，評測結果以下：

• taro：官方提供了taro ui，只支持微信小程序和H5兩端，不支持App，詳見
• uni-app：官方提供了uni ui，可全端運行；uni-app還有一個插件市場，裏面有不少三方ui組件，詳見
• chameleon：官方提供了cml-ui擴展組件庫，可全端運行，但組件數量略少，詳見

最後補充跨端案例：

• mpvue：微信端案例豐富，未見其它端案例
• taro：微信端案例豐富，百度、支付寶、H5端亦有少許案例
• uni-app：微信、App、H5三端案例豐富，官方示例已發佈到6端
• chameleon：未看到任何端案例

綜合以上信息，本項的最終評測結論：uni-app > taro > chameleon > mpvue > wepy、原生微信小程序

2. 跨端框架性能如何

跨端框架基本都是compiler + runtime模式，引入的runtime是否會下降運行性能？

尤爲是與原生微信小程序開發相比性能怎麼樣，這是你們廣泛關心的問題。

咱們依然以上述仿微博小程序爲例，測試2個容易出性能問題的點：長列表加載、大量點贊組件的響應。

2.1 長列表加載

仿微博的列表是一個包含不少組件的列表，這種複雜列表對性能的壓力更大，很適合作性能測試。

從觸發上拉加載到數據更新、頁面渲染完成，須要準確計時。人眼視覺計時確定不行，咱們採用程序埋點的方式，制定了以下計時時機：

• 計時開始時機：交互事件觸發，框架賦值以前，如：上拉加載（onReachBottom）函數開頭
• 計時結束時機：頁面渲染完畢(微信setData回調函數開頭)

Tips：setData回調函數開頭可認爲是頁面渲染完成的時間，是由於微信setData定義以下(微信規範)：

字段	類型	必填	描述
data	Object	是	此次要改變的數據
callback	Function	否	setData引發的界面更新渲染完畢後的回調函數

測試方式：從頁面空列表開始，經過程序自動觸發上拉加載，每次新增20條列表，記錄單次耗時；固定間隔連續觸發 N 次上拉加載，使得頁面達到 20*N 條列表，計算這 N 次觸發上拉到渲染完成的平均耗時。

測試結果以下：

說明：以400條微博列表爲例，從頁面空列表開始，每隔1秒觸發一次上拉加載（新增20條微博），記錄單次耗時，觸發20次後中止（頁面達到400條微博），計算這20次的平均耗時，結果微信原生在這20次 觸發上拉 -> 渲染完成 的平均耗時爲876毫秒，最快的uni-app是741毫秒，最慢的mpvue是4493毫秒

你們初看這個數據，可能比較疑惑，別急，下方有詳細說明

說明1：爲什麼 mpvue/wepy 測試數據不完整?

mpvue、wepy 誕生之初，微信小程序尚不支持自定義組件，沒法進行組件化開發；mpvue、wepy 爲解決這個問題，將用戶編寫的Vue組件，編譯爲WXML中的模板（template)，變相實現了組件化開發能力，提升代碼複用性，這在當時的技術條件下是很棒的技術方案。

但如此方案，在頁面複雜、組件較多的時，會大量增長頁面 dom 節點數量，甚至超出微信的 dom 節點數限制。咱們在 紅米手機（Redmi 6 Pro）上實測，頁面組件超過500個時，mpvue、wepy 實現的仿微博App就會報出以下異常，並中止渲染，故這兩個測試框架在組件較多時，測試數據不完整。這也就意味着，當頁面組件太多時，沒法使用這2個框架。

dom limit exceeded please check if there's any mistake you've made

Tips：wepy在400條列表之內，爲什麼性能高於微信原生框架，這個跟自定義組件管理開銷及業務場景有關（wepy編譯爲模板，不涉及組件建立及管理開銷），後續對微博點贊，涉及組件數據傳遞時，微信原生框架的性能優點就提現出來了，詳見下方測試數據。

說明2：爲何測試數據顯示uni-app 會比微信原生框架的性能略好呢？

其實，在頁面上有200條記錄（200個組件）時，taro 性能數據也比微信原生框架更好。

微信原生框架耗時主要在setData調用上，開發者若不單獨優化，則每次都會傳遞大量數據；而 uni-app、taro 都在調用setData以前自動作diff計算，每次僅傳遞變更的數據。

例如當前頁面有20條數據，觸發上拉加載時，會新加載20條數據，此時原生框架經過以下代碼測試時，setData會傳輸40條數據

data: {
    listData: []
},
onReachBottom() { //上拉加載
    let listData = this.data.listData;
    listData.push(...Api.getNews());//新增數據
    this.setData({
        listData
    }) //全量數據，發送數據到視圖層
}

開發者使用微信原生框架，徹底能夠本身優化，精簡傳遞數據，好比修改以下：

data: {
    listData: []
},
onReachBottom() { //上拉加載
    // 經過長度獲取下一次渲染的索引
    let index = this.data.listData.length;
    let newData = {}; //新變動數據
    Api.getNews().forEach((item) => {
        newData['listData[' + (index++) + ']'] = item //賦值，索引遞增
    }) 
    this.setData(newData) //增量數據，發送數據到視圖層
}

通過如上優化修改後，再次測試，微信原生框架性能數據以下：

從測試結果可看出，通過開發者手動優化，微信原生框架可達到更好的性能，但 uni-app、taro 相比微信原生，性能差距並不大。

這個結果，和web開發相似，web開發也有原生js開發、vue、react框架等狀況。若是不作特殊優化，原生js寫的網頁，性能常常還不如vue、react框架的性能。

也偏偏是由於Vue、react框架的優秀，性能好，開發體驗好，因此原生js開發已經逐漸減小使用了。

複雜長列表加載下一頁評測結論：微信原生開發手工優化,uni-app>微信原生開發未手工優化,taro > chameleon > wepy > mpvue

注：有人覺得uni-app和mpvue是同樣的，早期uni-app確實使用過mpvue，但後來由於性能和vue語法支持度問題已經從新開發了。

2.2 點贊組件響應速度

長列表中的某個組件，好比點贊組件，點擊時是否能及時的修改未贊和已贊狀態？是這項測試的評測點。

測試方式：

• 選中某微博，點擊「點贊」按鈕，實現點贊狀態狀態切換（已贊高亮、未贊灰色），
• 點贊按鈕 onclick函數開頭開始計時，setData回調函數開頭結束計時；

在紅米手機（Redmi 6 Pro）上進行屢次測試，求其平均值，結果以下：

說明：也就是在列表數量爲400時，微信原生開發的應用，點贊按鈕從點擊到狀態變化須要111毫秒。

測試結果數聽說明：

• wepy/mpvue 測試數據不完整的緣由同上，在組件較多時，頁面已經再也不渲染了
• 基於微信自定義組件實現組件開發的框架（uni-app/taro/chameleon），組件數據通信性能接近於微信原生框架，遠高於基於template實現組件開發的框架（wepy/mpvue）性能

組件數據更新性能測評：微信原生開發,uni-app,taro > chameleon > wepy > mpvue

綜上，本性能測試作了2個測試，長列表加載和組件狀態更新，綜合2個實驗，結論以下：

微信原生開發手工優化,uni-app>微信原生開發未手工優化,taro > chameleon >> wepy > mpvue

3. 學習門檻

DSL語法支持度

主流跨端框架基本都遵循React、Vue（類Vue）語法，其主要目的：複用工程師的現有技術棧，下降學習成本。此時，跨端框架對於原框架（React/Vue）語法的支持度就是一個重要的衡量標準，若是支持度較低、和原框架語法差別較大，則開發者無異於要學習一門新的框架，成本過高。

實際開發中發現，各個多端框架，都沒有徹底實現vue、react在web上的全部語法：
taro 對於 JSX 的語法支持是相對完善的，其文檔中描述將來版本計劃，

更多的 JSX 語法支持，1.3 以後限制生產力的語法只有只能用 map 創造循環組件一條

mpvue、uni-app 框架基於 Vue.js 核心，經過修改 Vue.js 的 runtime 和 compiler，實現了在小程序端的運行，支持絕大部分的Vue語法；uni-app 編譯到微信端曾經使用過mpvue，但後來從新編寫，支持了更多vue語法如filter、複雜 JavaScript 表達式等；

wepy、chameleon 都是 類Vue 的實現，僅支持 Vue 的部分語法，開發時須要單獨學習它們的規則；

DSL語法支持評測：taro,uni-app > mpvue > wepy,chameleon

學習資料完善度

• 官方文檔、問題搜索、示例demo的完備度方面：
• wepy：文檔只有2頁，也無需搜索。僅支持微信，因此組件API等文檔都直接看微信的文檔。沒有提供示例demo。詳見
• mpvue：文檔較少，但其概念不復雜，也沒有支持H五、App，因此組件API等文檔都直接看微信的文檔，學習難度低。問題搜索效果通常。沒有提供示例demo。詳見
• taro：基礎API文檔完整，具體使用問題資源較少，問題搜索效果通常，示例demo只包含基礎功能，僅發佈了微信一端。詳見
• uni-app：基礎文檔和各類使用專題內容豐富，問題搜索效果較好，示例demo功能完備，併發布爲7端上線。詳見

• chameleon：基礎API文檔完整，具體使用問題資源較少，問題搜索效果通常，示例demo只包含基礎功能，僅發佈了微信一端。詳見

• 教學課程方面：

學習資料完善度評測：uni-app > mpvue , taro > chameleon > wepy

技術支持和社區活躍度

開發不免遇到問題，官方技術支持和社區活躍度很重要。

本次評測demo開發期間，咱們的同窗（同時掌握vue和react），在學習研究各個多端框架時，切實感覺到因爲語法、學習資料、社區的差別帶來的學習門檻，吐出了不少槽。

綜合評估，本項評測結論：uni-app > taro > mpvue > wepy > chameleon

Tips:本測評忽略React、Vue兩框架自身的學習門檻

4. 工具和周邊生態

工具

全部多端框架均支持cli模式，能夠在主流前端工具中開發。
各框架基本都帶有d.ts的語法提示庫。
因爲mpvue、uni-app、taro直接支持vue、react語法，配套的ide工具鏈較豐富，着色、校驗、格式化完善，chameleon針對部分編輯器推薦了插件，wepy的有一些三方維護的vscode插件。

工具屬性維度，明顯高出一截的框架是uni-app，其出品公司同時也是HBuilder的出品公司，DCloud.io。
HBuilder/HBuilderX系列是四大主流前端開發工具（可對比百度指數），其爲uni-app作了不少優化，故uni-app的開發效率、易用性非其餘框架可及。
固然對於不習慣HBuilderX的開發者而言，uni-app的這個優點沒法體現。

周邊生態

一個底層框架，其周邊配套很是重要，好比ui庫、js庫、項目模板。

• wepy：出現時間久，開源項目多，佔據必定優點。
• mpvue：發佈時間也較早，歷史積累較多。
• taro：官方提供了taro ui，github上有一些開源項目。不過taro ui只支持小程序和H5，不支持App端
• uni-app：提供了插件市場，ui庫、周邊模板豐富
• chameleon：尚未造成周邊生態。

值得注意的是，uni-app和mpvue的插件生態是互通的，都是vue插件。因此雙方還聯合舉辦了插件大賽。這個聯合生態的周邊豐富度，是目前各個框架中最豐富的。

綜上比較，工具和周邊生態評測結論：uni-app,mpvue > wepy > taro > chameleon

其餘常見評測指標

github star：

github star 數對比： taro > wepy >mpvue > uni-app > chameleon

Tips:

• star 數採集時間：2019.04.08 16:30

百度指數

百度指數表明了開發者的搜索量和包含關鍵字的網頁數量。以下是各跨端框架近7天（2019-03-24 ~ 2019-03-30）的百度指數：

Tips:

• wepy未被百度指數收錄，說明其搜索量和包含該關鍵字的網頁數量都不夠多。

能夠看出一個較大的衝突就是uni-app的star數量較少，而百度指數較高。

根據咱們分析，star數量和產品發佈時間有關，也和用戶使用習慣有關。大多框架的交流互動主要是github的issus，而uni-app的開發者在其問答社區交流，github頁面訪問量較低。另外咱們觀察了一週的star的增速，每週star新增量，uni-app是最多的。

案例

咱們對比了每一個框架公佈的案例，以下的框架名稱的超連接已指向其案例頁面，能夠直接訪問。

僅看發佈到微信小程序的案例，數量和質量綜合對比，wepy > mpvue > taro , uni-app > chameleon

若是看多端案例，綜合對比，uni-app > taro > mpvue > wepy > chameleon

• wepy：的知名案例較多，包括不少一線互聯網公司。
• mpvue、taro：跨端框架的出品方自己爲一線互聯網公司，其內部項目會使用這些框架，經受過實戰考驗。除內部項目外，暫無其餘一線互聯網公司使用。
• uni-app：案例不少，官方數據已經超過10w+。但以創業者和政企單位爲主，暫無一線開發者使用。
• chameleon：未找到案例，沒法參與本評測。

其餘補充說明

1. App側的補充說明

目前有taro、uni-app、chameleon三家框架支持App端。但在App端大可能是三方產品，好比taro使用expo(一個基於react native的封裝庫），chameleon使用weex。

無論react native仍是weex，其架構與小程序架構徹底不一樣，從排版到API能力都差異很大，因此這類產品跨App端時兼容性較差。

uni-app的App端，內置一個完整小程序引擎，並補充了可選的weex引擎給對性能要求更高的開發者。這也是uni-app在App端可以正常運行微信小程序代碼的緣由。

整個業內目前還不存在一個徹底開源的小程序引擎（微信、百度、支付寶、頭條的小程序引擎源碼均未開源）。uni-app的小程序引擎不是全開源，而是能力層開源，中控未開源。

因此可能各家的多端框架，在App端都有不完美的地方，須要開發者使用時注意。

其實App引擎並不是前端領域，是原生領域的另外一個競技場。後續uni-app會再出一個與cordova、react native、weex、flutter的橫評。

2. 轉換和混寫

taro提供了原生小程序轉換爲taro工程的轉換器，也支持在原生小程序裏部分頁面嵌入taro編寫的頁面。uni-app和chameleon提供了轉換的文檔，沒有轉換工具。

結語

真實客觀的永遠是實驗和數據，而不是結論。不一樣需求的開發者，能夠根據上述實驗數據，自行得出本身的選型結論。

但做爲一篇完整的評測，咱們也必須提供一份總結，雖然它可能加入了咱們的主觀感覺：

• 若是你只開發微信小程序，不作多端，uni-app仍然是最好的選擇，除非你有興趣手動優化原生小程序的代碼，或者對react很是熟悉不肯意學習vue也可使用taro。

• 若是你主要爲了統一各家小程序，uni-app仍然是最好的選擇，taro次之。

• 若是你還須要跨端到H5側，那麼uni-app是最好的選擇。

• 若是你還須要跨端到App側，那麼uni-app是惟一可商用的選擇。

固然，uni-app也距離完美尚遠，只是在參比框架中相對有優點。uni-app團隊也仍繼續大力投入，持續填坑，幫助開發者提高投入產出、提高開發體驗！

若有讀者認爲本文中任何評測失真，歡迎在這裏報 issuse。