小程序開發：用原生仍是選框架（wepy/mpvue/uni-app/taro）？

小程序開發：用原生仍是選框架（wepy/mpvue/uni-app/taro）？

自 2017-1-9微信小程序誕生以來，歷經2年多的迭代升級，已有數百萬小程序上線，成爲繼Web、iOS、Android以後，第四大主流開發技術。

與之相隨，小程序的開發生態也在蓬勃發展，從最初的微信原生開發，到wepy、mpvue、taro、uni-app等框架依次出現，從刀耕火種演進爲現代化開發，生態愈來愈豐富。

選擇多了，問題也就來了，開發小程序，該用原生仍是選擇三方框架？

首先，微信原生開發的槽點大多集中以下：

1. 原生開發對Node、預編譯器、webpack支持很差，影響開發效率和工程構建流程
2. 微信定義了一個不三不四的語法，不如正經學vue、react，學會了全端通用，而不是隻爲微信小程序
3. vue/react生態裏有太多周邊工具，能夠提升開發效率，好比ide、校驗器、三方庫。。。
4. 微信那個ide和專業編輯器相比實在很差用

同時，開發者對三方框架，又老是有各類顧慮：

1. 怕性能不如原生
2. 怕有些功能框架實現不了，只能用原生
3. 怕框架不穩定，跳到坑裏
4. 以及諸多三方框架，到底該用哪一個

面對如此糾結的場景，很多熱心開發者發佈評測文章分享經驗，但感受衆說紛紜，過時信息太多。缺乏一份很是專業的、深度的，或者按現在流行的話來說，「硬核的」評測報告。

作評測報告這件事，不一樣於泛泛經驗分享，其實很是花費時間。它須要：

• 你必須成爲每個框架的專業使用人員，而不是淺淺的瞭解一下這些框架
• 真實的動手寫多個平臺的測試例，比較各個平臺的功能、性能，瞭解他們的社區狀況、技術服務狀況
• 你要有長期跟蹤和更新報告的能力，避免半年後淪爲過時信息

換言之：評測要想真，功夫得作深！

uni-app團隊花費2個周時間完成本報告，並堅持每一個季度更新一次本評測報告。目前更新時間爲2019年5月。

本文從面向用戶、面向開發者兩大維度七大細項，對微信原生及主流的wepy、mpvue、taro、uni-app開發框架進行橫向對比，但願給開發者在小程序框架選型時提供一種參考思路。本文基於各框架官網可採集到的公開數據及真實測試數據，但願客觀公正地評價各個框架的現狀和優劣。但宥於利益相關，本文的觀點極可能是帶有偏向性的，你們能夠帶着批判的眼光來看待，如發現本文中有任何評測失真，歡迎在這裏報 issuse。

面向用戶、面向開發者維度，具體包括：

1. 用戶：提供完整的業務實現，並保證高性能體驗
2. 開發者：平緩的學習曲線、現代開發體驗（工程化）、高效的社區支持、活躍的開發迭代、多端複用

2. 用戶

1.1 功能實現

軟件開發，首要目標是向用戶提供完整、閉環的業務功能。

在web開發中，若是vue、react等框架的使用，形成開發者沒法操做瀏覽器提供的全部api，那這樣的框架確定是不成熟的。小程序開發也同樣，任何開發框架，都不能限制底層的api調用。

而各類業務功能底層依賴微信暴漏的組件和接口（微信官網介紹的組件和 API 規範,也即微信原生API），三方框架是基於微信原生進行的二次封裝，開發者此時常會有個疑問：小程序在不斷的迭代升級，若是某項業務依賴於最新的小程序API，但三方框架還沒有封裝，該怎麼辦？

實際上就像web開發的vue、react同樣，瀏覽器出了一個新API，並不會涉及vue、react的升級。本評測裏的全部框架，都不會限制開發者調用底層能力。這裏詳細解釋下緣由：

• wepy：未對小程序API做二次封裝，API依然使用微信原生的，框架與微信小程序是否新增API無關
• mpvue：支持微信的全部原生組件和api，無限制。同時框架封裝了本身的跨端API，使用方式相似mpvue.request()
• taro：支持微信的全部原生組件和api，無限制。同時框架封裝了本身的跨端API，使用方式相似Taro.request()，支持Taro 代碼與小程序代碼混寫，可經過混寫的方式調用框架還沒有封裝的小程序新增API
• uni-app：支持微信的全部原生組件和api，無限制。在跨端方面，即使仍然使用微信原生的組件和API，也能夠直接跨端編譯到App、H五、以及支付寶百度頭條等小程序。但爲了管理清晰，推薦使用uni封裝的API，相似uni.request()。同時支持條件編譯，可在條件編譯代碼塊中，隨意調用各個平臺新增的API及組件

注：以上順序，按各個框架的誕生順序排序，下同。

故，三方框架都可調用全部小程序API，完成用戶的業務需求，這個維度各框架是無差異的。

然而有差異的，是性能體驗。

1.2 性能體驗

三方框架，內部大多作了層層封裝，這些封裝是否會增長運行負載，致使性能降低？尤爲是與原生微信小程序開發相比性能怎麼樣，這是你們廣泛關心的問題。

爲客觀的進行對比，咱們特地搭建了一個測試模型，詳細以下：

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

 

• 開發版本：一共開發了5個版本，包括微信原生版、wepy版、mpvue版、taro版、uni-app版，按照官網指引經過cli方式默認安裝。
• 測試代碼開源（Github倉庫地址：https://github.com/dcloudio/test-framework）， Tips:如有同窗以爲測試代碼寫法欠妥，歡迎提交 PR 或 Issus
• 測試機型：紅米 Redmi 6 Pro、MIUI 10.2.2.0 穩定版（最新版）、微信版本 7.0.3（最新版）
• 測試環境：每一個框架開始測試前，殺掉各App進程、清空內存，保證測試機環境基本一致；每次從本地讀取靜態數據，屏蔽網絡差別。

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

1.2.1 長列表加載

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

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

• 計時開始時機：交互事件觸發，框架賦值以前，如：上拉加載（onReachBottom）函數開頭
• 計時結束時機：頁面渲染完畢(微信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中的模板（template)，變相實現了組件化開發能力，提升代碼複用性，這在當時的技術條件下是很棒的技術方案。

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

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

Tips1：wepy官網的CHANGELOG，提到 v1.7.2 測試版本添加了對小程序原生組件的支持，實測坑不少，由於是測試版，官方在 issue 中也表示不推薦使用；按照官網文檔，默認安裝的 v1.7.3 正式版本並不支持原生組件

Tips2：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> wepy > mpvue

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

1.2.2 點贊組件響應速度

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

測試方式：

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

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

 

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

測試結果數聽說明：

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

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

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

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

2.開發者

在知足用戶業務需求的前提下，咱們談談開發者的需求，從以下幾個維度比較：

• 平緩的學習曲線：簡單易學，最好能複用現有技術棧，豐富的學習資料
• 高效的開發體驗：現代前端開發流程、工程化支持
• 高效的社區支持：遇到問題，可很快的尋求到幫助
• 活躍的開發迭代：框架處於積極更新升級狀態，無需擔憂停更

2.1 平緩的學習曲線

2.1.1 DSL語法支持

選擇開發團隊熟悉的、能快速上手的DSL，是團隊框架選型的基本點。

首先微信原生的開發語法，既像React ，又像Vue，有點不三不四，對於開發者來講，等於又要學習一套新的語法，大幅提高了學習成本，這一直被你們所詬病。

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

實際開發中發現，各個開發框架，都沒有徹底實現Vue、React在web上的全部語法：

wepy開發風格接近於 Vue.js，屬於類Vue實現，相對微信原生開發算前進了一大步，但相比完整Vue語法還有較大差距，開發時須要單獨學習它的規則；

mpvue、uni-app 框架基於 Vue.js 核心，經過修改 Vue.js 的 runtime 和 compiler，實現了在小程序端的運行。mpvue支持的Vue語法略少，uni-app 則基本支持絕大多數vue語法，如filter、複雜 JavaScript 表達式等；

taro 對於 JSX 的語法支持度，也達到了絕大多數都支持的完善程度。

DSL語法支持評測：taro,uni-app > mpvue > wepy > 微信原生

2.1.2 學習資料完善度

官方文檔、問題搜索、示例demo的完備度方面：

• 微信原生：文檔豐富，API搜索準確，官方有示例demo，支持官網上調起微信開發者工具，預覽運行效果 詳見
• wepy：文檔只有2頁，沒有搜索，組件API等文檔都直接看微信的文檔。沒有提供示例demo，不少配置須要靠猜。詳見
• mpvue：文檔較少，但其概念不復雜，組件API等文檔都直接看微信的文檔，學習難度低。問題搜索效果通常。沒有提供示例demo。詳見
• taro：基礎文檔完整，具體使用問題資源較少，問題搜索效果通常，示例demo只包含基礎功能，僅發佈了微信一端。詳見
• uni-app：基礎文檔和各類使用專題內容豐富，問題搜索效果較好，示例demo功能完備，併發布爲7端上線。詳見

教學課程方面：

 

學習資料完善度評測：微信原生 > uni-app > mpvue , taro > wepy

2.2 現代前端開發體驗

開發體驗層面，處於明顯劣勢的是微信原生開發，主要差距在於：

• 框架開發提供了精簡的代碼組織（微信原生開發，一個Page由4個文件構成，寫個代碼要開的標籤卡太多）
• 框架開發提供了更強大的組件化能力
• 框架開發提供了應用狀態管理（類Vuex/Redux/Mobx等）
• 框架開發能靈活支持各類 Sass 等 預處理器
• 框架開發可提供完整的 ES Next 語法支持
• 框架開發方便自定義構建策略

其它小程序開發框架均支持cli模式，能夠在主流前端工具中開發，且基本都帶有d.ts的語法提示庫。

因爲mpvue、uni-app、taro直接支持vue、react語法，配套的ide工具鏈較豐富，着色、校驗、格式化完善；wepy要弱一些，有部分三方維護的vscode插件。

好的開發工具，絕對能夠大幅提高開發體驗，這個維度上，明顯高出一截的框架是uni-app，其出品公司同時也是HBuilder的出品公司，DCloud.io。HBuilder是四大主流前端開發工具（可對比百度指數），其爲uni-app作了不少優化，故uni-app的開發效率、易用性非其餘框架可及。

開發體驗維度，對比結果：uni-app > taro,mpvue > wepy > 微信原生

這裏能夠輸出一個結論：若是你須要工程化能力，那就直接忘了微信原生開發吧。

2.3 高效的社區支持

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

 

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

綜合評估，本項評測結論：微信原生 , uni-app > taro > mpvue > wepy

2.4 活躍的開發迭代

開發者必須關心一個問題：該項目是否有人長期維護？

這個問題能夠經過github commits 頻次、產品更新日誌（changelog）、百度搜索指數等指標來衡量和對比。

github commits 頻次

咱們採集2019年4月份（時間爲4.1 ~ 4.30），每一個項目在github上的master分支有commit的天數，結果以下：

 

Tips：

• 微信原生是閉源的，看不到 commits 數量，但保持每個月至少一次的更新節奏，詳見
• wepy的master分支無commit，最新的2.0.x分支在4月份也僅1天有commit記錄

從 commit 的記錄來看，taro、uni-app處於更新比較活躍的狀態，wepy、mpvue則相對疲軟，呈現無人維護之態。

產品更新日誌

經過瀏覽產品更新日誌，可確認產品是否在積極迭代、增長新功能、修復用戶bug。

咱們分別查看各框架官方連接的更新日誌（CHANGELOG），下方是連接地址：

• 微信基礎庫更新日誌
• wepy官網 CHAGELOG
• mpvue官網 Chang log
• taro github 更新日誌
• uni-app官網更新日誌

經過產品更新日誌對比，微信原生、taro、uni-app 三者更新頻繁，bug修復、新功能補充都處於比較緊湊的狀態；而mpvue、wepy則已有長時間沒有版本發佈，wepy甚至有將近1年時間未發佈正式版本，開發者選型需謹慎。

2.5 多端複用

隨着微信小程序的火爆，支付寶、百度、字節跳動等公司也前後進入小程序領域，這些公司個個日活過億，坐擁海量用戶，企業主但願將本身的業務觸達每一個用戶，無論這個用戶在哪一個小程序中。

需求轉接到程序員這裏，程序員怎麼辦？難道真的每一個平臺處處搬磚嗎？此時，一套代碼、多端發佈就成爲不少程序員的夢想，小程序跨端框架應運而生。

現實真能如此理想嗎？每一個跨端框架可否真的像官網宣傳的那樣，實現開發一次，發佈到全部小程序平臺？甚至和H5平臺複用代碼？

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

 

測試結果說明：

• ⭕ 表示支持且功能正常，❌ 表示不支持，其它則表示支持但存在部分bug或兼容問題

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

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

• taro：H5端實現了大部分微信的API
• uni-app：組件、API、配置，大部分在各個端均已實現，個別API有說明在某些端不支持。能夠看出uni-app是完整在H5端實現了一套微信模擬器

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

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

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

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

最後補充跨端案例：

• mpvue：微信端案例豐富，未見其它端案例
• taro：微信端案例豐富，百度、支付寶、H5端亦有少許案例
• uni-app：多端案例豐富，官方示例已發佈到7端(包括App端)

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

這裏能夠輸出一個結論，若是有多端發佈需求，微信原生開發、wepy這兩種方式能夠直接排除了。

結語

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

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

若是你只開發微信小程序，不作多端，那麼使用uni-app、taro是更優的選擇，他們至關於web世界的vue和react，有了這些工具，再也不須要使用原生wxml開發。

• 若是堅持微信原生開發，須要注意手動寫優化代碼來控制setdata，而且注意其工程化能力很是弱
• 若是你是react系，那就用taro
• 若是是vue系，那就用uni-app，uni-app在性能、周邊生態和開發效率上更有優點

若是你開發多端，uni-app和taro均可以，可根據本身熟悉的技術棧選擇，相對而言uni-app的多端成熟度更高一些。