【深入測試】主流多端框架大比武

之前 Taro 團隊釋出了一篇《小程式多端框架全面測評》，介紹了taro、uni-app、 chameleon、 mpvue 等業界主流的跨端框架，讓開發者有了初步認識。感謝 Taro 團隊的付出。

不過橫評這件事，要想得到更精確的結論，其實非常花費時間。它需要：

• 真實地動手寫多個平臺的測試Demo，比較各個平臺的功能、效能，它們的實際情況到底是不是如文件所寫？
• 真實地學習每個框架，瞭解它們的學習曲線，在實際開發中遇到問題時，感受它們的文件、教程、社群生態和技服能力到底怎麼樣？

我們 uni-app 團隊投入一週完成了這個深度評測，下面我們分享下實際開發不同框架的測試例時遇到的問題，以及在各端的相容測試結果。在本文裡，我們團隊基於真實測試資料及各框架官網可採集到的公開資料，希望客觀公正地評價各個框架的選型和優劣。但宥於利益相關，本文的觀點很可能是帶有偏向性的，大家可以帶著批判的眼光去看待。

評測實驗介紹

開發內容：開發一個仿微博小程式首頁的複雜長列表，支援下拉重新整理、上拉翻頁、點贊。

開發版本：一共開發了6個版本，包括微信原生版、WePY版、Mpvue版、Taro版、uni-app版、Chameleon版（以這些產品釋出時間排序，下同），按照官網指引通過cli方式預設安裝。

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

測試環境：每個框架開始測試前，殺掉各App程式、清空記憶體，保證測試機環境基本一致；每次從本地讀取靜態資料，遮蔽網路差異。

測試維度：

 

1. 跨端支援度如何？
2. 效能如何？
3. 學習門檻。
4. 工具與周邊生態。

測試介面：

 

 

跨端支援度如何

開發一次，到處執行，是每個程式設計師的夢想。但現實往往變成開發一次，到處調錯。

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

我們將上述仿微博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：提供了JavaScript環境變數判斷和統一介面的多端檔案，可以在元件、JavaScript、檔案方面擴充套件多端，不支援其他環節的分平臺處理。
• uni-app：提供了條件編譯模型，所有程式碼包括元件、JavaScript、CSS、配置Json、檔案、目錄，均支援條件編譯，可不受限的編寫各端差異程式碼。
• Chameleon：提供了多型方案，可以在元件、JavaScript、檔案方面擴充套件多端，不支援其他方式的分平臺處理。

跨端框架，還涉及一個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、原生微信小程式

跨端框架效能如何

跨端框架基本都是Compiler + Runtime模式，引入的Runtime是否會降低執行效能？

尤其是與原生微信小程式開發相比效能怎麼樣，這是大家普遍關心的問題。

我們依然以上述仿微博小程式為例，測試2個容易出效能問題的點：長列表載入、大量點贊元件的響應。

長列表載入

仿微博的列表是一個包含很多元件的列表，這種複雜列表對效能的壓力更大，很適合做效能測試。

從觸發上拉載入到資料更新、頁面渲染完成，需要準確計時。人眼視覺計時肯定不行，我們採用程式埋點的方式，制定瞭如下計時時機：

1. 計時開始時機：互動事件觸發，框架賦值之前，如：上拉載入（onReachBottom）函式開頭
2. 計時結束時機：頁面渲染完畢(微信setData回撥函式開頭)

Tips：setData回撥函式開頭可認為頁面渲染完成的時間，是因為微信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中的模板，變相實現了元件化開發能力，提高程式碼複用性，這在當時的技術條件下是很棒的技術方案。

但如此方案，在複雜元件較多的頁面，會大量增加 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

點贊元件響應速度

長列表中的某個元件，比如點贊元件，點選時是否能及時的修改未贊和已贊狀態？

測試方式：

• 選中某微博，點選“點贊”按鈕，實現點贊狀態狀態切換（已贊高亮、未贊灰色），
• 點贊按鈕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

學習門檻

DSL語法支援度

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

實際開發中發現，各個多端框架，都沒有完全實現Vue、React在Web上的所有語法：

Taro對於JS 的語法支援是相對完善的，其文件中描述未來版本計劃：

更多的 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

學習資料完善度

官方文件、搜尋系統的完備度方面（詳見各官網）：

• WePY：文件只有2頁，也無需搜尋。僅支援微信，所以元件API等文件都直接看微信的文件。沒有提供示例Demo。
• Mpvue：文件較少，但其概念不復雜，也沒有支援H5、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兩框架自身的學習門檻

工具和周邊生態

工具

所有多端框架均支援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上有一些開源專案。

uni-app：提供了外掛市場，UI庫、周邊模板豐富

Chameleon：還沒有形成周邊生態。

值得注意的是，uni-app和Mpvue的外掛生態是互通的，都是Vue外掛。所以雙方還聯合舉辦了外掛大賽。這個聯合生態的周邊豐富度，是目前各個框架中最豐富的。

綜上比較，工具和周邊生態評測結論：uni-app，Mpvue > WePY > Taro > Chameleon

其他常見評測指標

GitHub Star：

 

GitHub Star 數對比：Taro > Wepy > Mpvue > uni-app > Chameleon

（Star數採集時間：2019.04.08 16:30）

百度指數

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

 

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

案例

僅看釋出到微信小程式的案例，數量和質量綜合對比，WePY > Mpvue > Taro , uni-app > Chameleon

如果看多端案例，綜合對比，uni-app > Taro > Mpvue > Wepy > Chameleon

• Wepy：的知名案例較多，包括很多一線網際網路公司。
• Mpvue、Taro：跨端框架的出品方本身為一線網際網路公司，其內部專案會使用這些框架，經受過實戰考驗。除內部專案外，暫無其他一線網際網路公司使用。
• uni-app：案例很多，官方資料已經超過10w+。但以創業者和政企單位為主，暫無一線開發者使用。
• Chameleon：未找到案例，無法參與本評測。

其他補充說明

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引擎並非前端領域，是原生領域的另一個競技場。

轉換和混寫

Taro提供了原生小程式轉換為Taro工程的轉換器，也支援在原生小程式裡部分頁面嵌入Taro編寫的頁面。這是Taro的特色，其他跨端框架沒有提供。這對於降低入門門檻有不少幫助。

結語

真實客觀的永遠是實驗和資料，而不是結論。不同需求的開發者，可以根據上述實驗資料，自行得出自己的選型結論。

但作為一篇完整的評測，我們也必須提供一份總結，雖然它可能加入了我們的主觀感受：

如果你只開發微信小程式，不做多端，那麼使用微信原生開發、uni-app、Taro是更優的選擇。

如果使用微信原生開發，需要注意手動寫優化程式碼來控制setData。

如果你是React系，那就用Taro。

如果是Vue系，那就用uni-app，uni-app在效能、周邊生態和開發效率上更有優勢。

如果你主要為了各家小程式，且不用複雜元件，那除了uni-app和Taro，Mpvue也是不錯的選擇。Mpvue釋出2.0版本後，搜尋指數明顯爬升，希望能持續更新，迎來二次繁榮。

如果你主要為了微信端和H5端，那麼uni-app和Taro都可以。可以根據自己熟悉的技術棧選擇。

如果你只關心App，不關心小程式和H5，那歡迎關注我們後續的評測：uni-app和Cordova、React Native、Weex、Flutter的深度比較。

Chameleon釋出時間還短，完善度不如其他框架，但其未來的規劃比較令人期待，值得關注。

測試程式碼：

GitHub：https://github.com/dcloudio/test-framework

結語

真實客觀的永遠是實驗和資料，而不是結論。不同需求的開發者，可以根據上述實驗資料，自行得出自己的選型結論。

但作為一篇完整的評測，我們也必須提供一份總結，雖然它可能加入了我們的主觀感受：

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

• 如果你主要為了統一各家小程式，uni-app仍然是最好的選擇，taro次之。

• 如果你還需要跨端到H5側，那麼uni-app是最好的選擇。taro也可以，但還需要開發者做不少工作。

• 如果你還需要跨端到App側，那麼uni-app是唯一可商用的選擇。

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

【參考文件】

跨端開發框架深度橫評 - https://blog.csdn.net/hbcui1984/article/details/88945790

微信閱讀：https://mp.weixin.qq.com/s?__biz=MjM5NjExMjc4NA==&mid=2649704486&idx=1&sn=6eb7df193b41d51e94d81e5bf008bba6&chksm=bef5d8d9898251cfda8e6d21cf435f9d18811b0736d622b93a29708f4568591619232fbf2fa4&scene=0&xtrack=1&key=41320631896c4008c6f5faa53b23a47a0342f2cbfae9bb9eaa8dfa9cc5c2164a30fef0063d3369292d2493d511a1271e98315b11d926262c126f83d4d39e7265d27c2359702cdb1fd6a5eaa9870c60b2&ascene=1&uin=MTU5ODQ1NDI2MA%3D%3D&devicetype=Windows+7&version=62060739&lang=zh_CN&pass_ticket=HjzusDG3R4e6QY8DWDxdGKSdn0UlM0PSNzxs%2BePpL2vwxsT4XakUhuk8MtD3bIZv