上周，Taro 團(tuán)隊(duì)發(fā)布了一篇《 小程序 多端框架全面測(cè)評(píng)》，讓開發(fā)者對(duì)業(yè)界主流的跨端框架，有了初步認(rèn)識(shí)。感謝 Taro 團(tuán)隊(duì)的付出。

不過(guò)橫評(píng)這件事，要想做完善，其實(shí)非常花費(fèi)時(shí)間。不是只看文檔就行，它需要：

• 真實(shí)的動(dòng)手寫多個(gè)平臺(tái)的測(cè)試demo，比較各個(gè)平臺(tái)的功能、性能，它們的實(shí)際情況到底是不是如文檔宣傳的那樣？
• 真實(shí)的學(xué)習(xí)每個(gè)框架，了解它們的學(xué)習(xí)曲線，在實(shí)際開發(fā)中遇到問(wèn)題時(shí)，感受它們的文檔、教程、社區(qū)生態(tài)和技服能力到底怎么樣？

我們? uni-app ?團(tuán)隊(duì)投入一周完成了這個(gè)深度評(píng)測(cè)，下面我們就分享下，實(shí)際開發(fā)不同框架的測(cè)試?yán)龅降膯?wèn)題，和最終的測(cè)試結(jié)果。

評(píng)測(cè)實(shí)驗(yàn)介紹

• 開發(fā)內(nèi)容：開發(fā)一個(gè)仿微博 小程序 首頁(yè)的復(fù)雜長(zhǎng)列表，支持下拉刷新、上拉翻頁(yè)、點(diǎn)贊。
• 界面如下：
  
• 開發(fā)版本：一共開發(fā)了6個(gè)版本，包括微信原生版、wepy版、mpvue版、taro版、 uni-app 版、chameleon版（以這些產(chǎn)品發(fā)布時(shí)間排序，下同），按照官網(wǎng)指引通過(guò) cli 方式默認(rèn)安裝(應(yīng)該是最新穩(wěn)定版)。
• 測(cè)試代碼開源（ Github倉(cāng)庫(kù)地址：https://github.com/dcloudio/test-framework ），
  Tips:若有同學(xué)覺(jué)得測(cè)試代碼寫法欠妥，歡迎提交 PR 或? Issus
• 測(cè)試機(jī)型：紅米 Redmi 6 Pro、MIUI 10.2.2.0 穩(wěn)定版（最新版）、微信版本 7.0.3（最新版）
• 測(cè)試環(huán)境：每個(gè)框架開始測(cè)試前，殺掉各App進(jìn)程、清空內(nèi)存，保證測(cè)試機(jī)環(huán)境基本一致；每次從本地讀取靜態(tài)數(shù)據(jù)，屏蔽網(wǎng)絡(luò)差異。
• 測(cè)試維度：
  1. 跨端支持度如何？
  2. 性能如何？
  3. 學(xué)習(xí)門檻
  4. 工具與周邊生態(tài)

1. 跨端支持度如何

開發(fā)一次，到處運(yùn)行，是每個(gè)程序員的夢(mèng)想。但現(xiàn)實(shí)往往變成開發(fā)一次，到處調(diào)錯(cuò)。

各個(gè)待評(píng)測(cè)框架，是否真得如宣傳的那樣，一次開發(fā)、多端發(fā)布？

我們將上述 仿微博App 依次發(fā)布到各平臺(tái)，驗(yàn)證每個(gè)框架在各端的兼容性，結(jié)果如下：

平臺(tái)	微信原生	wepy	mpvue	taro	uni-app	chameleon
微信 小程序	??	??	??	??	??	??
支付寶小程序	?	?	??	??	??	?
百度小程序	?	?	??	??	??	?
頭條小程序	?	?	??	??	??	?
H5端	?	?	?	上拉加載/下拉刷新失效	??	上拉加載/下拉刷新失效
App端	?	?	?	上拉加載失效	??	列表無(wú)法滾動(dòng)，無(wú)法測(cè)試上拉加載/下拉刷新

測(cè)試結(jié)果說(shuō)明：

• ? 表示支持且功能正常，? 表示不支持，其它則表示支持但存在部分bug或兼容問(wèn)題
• wepy ?2.0 宣稱版已支持其他家小程序，本測(cè)試基于 wepy 官網(wǎng)指引安裝的 wepy-cli 默認(rèn)版本為1.7.3，尚不支持多端
• chameleon 嘗鮮版宣稱支付寶、百度小程序，本測(cè)試基于 chameleon 官網(wǎng)指引安裝的 chameleon-tool 默認(rèn)版本為0.1.1，尚不支持其它小程序

通過(guò)這個(gè)簡(jiǎn)單的例子可以看出，跨端支持度測(cè)評(píng)結(jié)論： uni-app ?>? taro ?>? chameleon >? mpvue ?> wepy 、 原生微信小程序

但是僅有上面的測(cè)試還不全面，實(shí)際業(yè)務(wù)要比這個(gè)測(cè)試?yán)龔?fù)雜很多。但我們沒(méi)法開發(fā)很多復(fù)雜業(yè)務(wù)做評(píng)測(cè)，所以還需要再對(duì)照各家文檔補(bǔ)充一些信息。
由于每個(gè)框架的文檔中都描述了各種組件和API的跨端支持程度。我們過(guò)了幾家的文檔，發(fā)現(xiàn)各家基本是以微信小程序?yàn)榛€，然后把各種組件和API在其他端實(shí)現(xiàn)了一遍：

• taro ：H5端實(shí)現(xiàn)了大部分微信的API，App端和微信的差異比較大。
• uni-app ：組件、API、配置，大部分在各個(gè)端均已實(shí)現(xiàn)，個(gè)別API有說(shuō)明在某些端不支持。可以看出uni-app是完整在H5端實(shí)現(xiàn)了一套微信模擬器，在App端實(shí)現(xiàn)了一套微信小程序引擎，才達(dá)到比較完善的平臺(tái)兼容性。
• chameleon ：非常常用的一些組件和API在各端已經(jīng)實(shí)現(xiàn)，這部分的平臺(tái)差異較少。但大量組件和API需要開發(fā)者自己分平臺(tái)寫代碼。

跨端框架，一方面要考慮框架提供的通用api跨端支持，同時(shí)還要考慮不同端的特色差異如何兼容。畢竟每個(gè)端都會(huì)有自己的特色，不可能完全一致。

• taro ：提供了js環(huán)境變量判斷和統(tǒng)一接口的多端文件，可以在組件、js、文件方面擴(kuò)展多端，不支持其他環(huán)節(jié)的分平臺(tái)處理。
• uni-app ：提供了條件編譯模型，所有代碼包括組件、js、css、配置json、文件、目錄，均支持條件編譯，可不受限的編寫各端差異代碼。
• chameleon ：提供了多態(tài)方案，可以在組件、js、文件方面擴(kuò)展多端，不支持其他方式的分平臺(tái)處理。

跨端框架，還涉及一個(gè)ui框架的跨端問(wèn)題，評(píng)測(cè)結(jié)果如下：

• taro ：官方提供了 taro ui ，支持小程序(微信/支付寶/百度)、H5平臺(tái)，不支持App， 詳見
• uni-app ：官方提供了 uni ui ，可全端運(yùn)行；uni-app還有一個(gè)插件市場(chǎng)，里面有很多三方ui組件， 詳見
• chameleon ：官方提供了 cml-ui 擴(kuò)展組件庫(kù)，可全端運(yùn)行，但組件數(shù)量略少， 詳見

最后補(bǔ)充跨端案例：

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

綜合以上信息，本項(xiàng)的最終評(píng)測(cè)結(jié)論： uni-app ?>? taro ?>? chameleon ?>? mpvue ?>? wepy 、 原生微信小程序

之前曾有友商掀起一番真跨端和偽跨端之爭(zhēng)，通過(guò)本次Demo實(shí)測(cè)，這個(gè)爭(zhēng)論可以蓋棺定論了。

2. 跨端框架性能如何

跨端框架基本都是 compiler ?+? runtime 模式，引入的 runtime 是否會(huì)降低運(yùn)行性能？

尤其是與原生微信小程序開發(fā)相比性能怎么樣，這是大家普遍關(guān)心的問(wèn)題。

我們依然以上述仿微博小程序?yàn)槔瑴y(cè)試2個(gè)容易出性能問(wèn)題的點(diǎn)：長(zhǎng)列表加載、大量點(diǎn)贊組件的響應(yīng)。

2.1 長(zhǎng)列表加載

仿微博的列表是一個(gè)包含很多組件的列表，這種復(fù)雜列表對(duì)性能的壓力更大，很適合做性能測(cè)試。

從觸發(fā)上拉加載到數(shù)據(jù)更新、頁(yè)面渲染完成，需要準(zhǔn)確計(jì)時(shí)。人眼視覺(jué)計(jì)時(shí)肯定不行，我們采用程序埋點(diǎn)的方式，制定了如下計(jì)時(shí)時(shí)機(jī)：

• 計(jì)時(shí)開始時(shí)機(jī)：交互事件觸發(fā)，框架賦值之前，如：上拉加載（onReachBottom）函數(shù)開頭
• 計(jì)時(shí)結(jié)束時(shí)機(jī)：頁(yè)面渲染完畢(微信setData回調(diào)函數(shù)開頭)

Tips： setData 回調(diào)函數(shù)開頭可認(rèn)為是頁(yè)面渲染完成的時(shí)間，是因?yàn)槲⑿? setData 定義如下( 微信規(guī)范 )：

字段	類型	必填	描述
data	Object	是	這次要改變的數(shù)據(jù)
callback	Function	否	setData引起的界面更新 渲染完畢 后的回調(diào)函數(shù)

測(cè)試方式：從頁(yè)面空列表開始，通過(guò)程序自動(dòng)觸發(fā)上拉加載，每次新增20條列表，記錄單次耗時(shí)；固定間隔連續(xù)觸發(fā) N 次上拉加載，使得頁(yè)面達(dá)到 20*N 條列表，計(jì)算這 N 次 觸發(fā)上拉 -> 渲染完成 的平均耗時(shí)。

測(cè)試結(jié)果如下：

列表?xiàng)l數(shù)	微信原生	wepy	mpvue	taro	uni-app	chameleon
200	770	625	969	752	641	1261
400	876	781	4493	974	741	1970
600	1111	–	–	1250	910	2917
800	1406	–	–	1547	1113	4040
1000	1690	–	–	1878	1321	5196

說(shuō)明：以400條微博列表為例，從頁(yè)面空列表開始，每隔1秒觸發(fā)一次上拉加載（新增20條微博），記錄單次耗時(shí)，觸發(fā)20次后停止（頁(yè)面達(dá)到400條微博），計(jì)算這20次的平均耗時(shí)，結(jié)果微信原生在這20次? 觸發(fā)上拉 -> 渲染完成 ?的平均耗時(shí)為876毫秒，最快的 uni-app 是741毫秒，最慢的mpvue是4493毫秒

大家初看這個(gè)數(shù)據(jù)，可能比較疑惑，別急，下方有詳細(xì)說(shuō)明

說(shuō)明1：為何 mpvue/wepy 測(cè)試數(shù)據(jù)不完整?

mpvue 、 wepy ?誕生之初，微信小程序尚不支持 自定義組件 ，無(wú)法進(jìn)行組件化開發(fā)； mpvue 、 wepy ?為解決這個(gè)問(wèn)題，將用戶編寫的 Vue 組件，編譯為 WXML 中的 模板（template) ，變相實(shí)現(xiàn)了組件化開發(fā)能力，提高代碼復(fù)用性，這在當(dāng)時(shí)的技術(shù)條件下是很棒的技術(shù)方案。

但如此方案，在復(fù)雜組件較多的頁(yè)面，會(huì)大量增加 dom 節(jié)點(diǎn)，甚至超出微信的 dom 節(jié)點(diǎn)數(shù)限制。我們?cè)?紅米手機(jī)（Redmi 6 Pro）上實(shí)測(cè)，頁(yè)面組件超過(guò)500個(gè)時(shí)， mpvue 、 wepy ?實(shí)現(xiàn)的仿微博App就會(huì)報(bào)出如下異常，并停止渲染，故這兩個(gè)測(cè)試框架在組件較多時(shí)，測(cè)試數(shù)據(jù)不完整。這也就意味著，當(dāng)頁(yè)面組件太多時(shí)，無(wú)法使用這2個(gè)框架。

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

Tips： wepy 在400條列表以內(nèi)，為何性能高于微信原生框架，這個(gè)跟自定義組件管理開銷及業(yè)務(wù)場(chǎng)景有關(guān)（ wepy 編譯為模板，不涉及組件創(chuàng)建及管理開銷），后續(xù)對(duì)微博點(diǎn)贊，涉及組件數(shù)據(jù)傳遞時(shí)，微信原生框架的性能優(yōu)勢(shì)就提現(xiàn)出來(lái)了，詳見下方測(cè)試數(shù)據(jù)。

說(shuō)明2：uni-app 比微信原生框架性能更好？逆天了？

其實(shí)，在頁(yè)面上有200條記錄（200個(gè)組件）時(shí)， taro ?性能數(shù)據(jù)也比微信原生框架更好。

微信原生框架耗時(shí)主要在 setData 調(diào)用上，開發(fā)者若不單獨(dú)優(yōu)化，則每次都會(huì)傳遞大量數(shù)據(jù)；而? uni-app 、 taro ?都在調(diào)用 setData 之前自動(dòng)做 diff 計(jì)算，每次僅傳遞有變化的數(shù)據(jù)。

例如當(dāng)前頁(yè)面有20條數(shù)據(jù)，觸發(fā)上拉加載時(shí)，會(huì)新加載20條數(shù)據(jù)，此時(shí)原生框架通過(guò)如下代碼測(cè)試時(shí)， setData 會(huì)傳輸40條數(shù)據(jù)

1. data : {
2. listData : []
3. },
4. onReachBottom () { //上拉加載
5. let listData = this . data . listData ;
6. listData . push (... Api . getNews ()); //新增數(shù)據(jù)
7. this . setData ({
8. listData
9. }) //全量數(shù)據(jù)，發(fā)送數(shù)據(jù)到視圖層
10. }

開發(fā)者使用微信原生框架，完全可以自己優(yōu)化，精簡(jiǎn)傳遞數(shù)據(jù)，比如修改如下：

1. data : {
2. listData : []
3. },
4. onReachBottom () { //上拉加載
5. // 通過(guò)長(zhǎng)度獲取下一次渲染的索引
6. let index = this . data . listData . length ;
7. let newData = {}; //新變更數(shù)據(jù)
8. Api . getNews (). forEach (( item ) => {
9. newData [ 'listData[' + ( index ++) + ']' ] = item //賦值，索引遞增
10. })
11. this . setData ( newData ) //增量數(shù)據(jù)，發(fā)送數(shù)據(jù)到視圖層
12. }

經(jīng)過(guò)如上優(yōu)化修改后，再次測(cè)試，微信原生框架性能數(shù)據(jù)如下：

組件數(shù)量	微信原生框架（優(yōu)化前）	微信原生框架（優(yōu)化后）	uni-app	taro
200	770	572	641	752
400	876	688	741	974
600	1111	855	910	1250
800	1406	1055	1113	1547
1000	1690	1260	1321	1878

從測(cè)試結(jié)果可看出，經(jīng)過(guò)開發(fā)者手動(dòng)優(yōu)化，微信原生框架可達(dá)到更好的性能，但? uni-app 、 taro ?相比微信原生，性能差距并不大。

這個(gè)結(jié)果，和web開發(fā)類似，web開發(fā)也有原生js開發(fā)、vue、react框架等情況。如果不做特殊優(yōu)化，原生js寫的網(wǎng)頁(yè)，性能經(jīng)常還不如vue、react框架的性能。

也恰恰是因?yàn)? Vue 、 react 框架的優(yōu)秀，性能好，開發(fā)體驗(yàn)好，所以原生js開發(fā)已經(jīng)逐漸減少使用了。

復(fù)雜長(zhǎng)列表加載下一頁(yè)評(píng)測(cè)結(jié)論： 微信原生開發(fā)手工優(yōu)化 , uni-app > 微信原生開發(fā)未手工優(yōu)化 , taro ?>? chameleon ?>? wepy ?>? mpvue

2.2 點(diǎn)贊組件響應(yīng)速度

長(zhǎng)列表中的某個(gè)組件，比如點(diǎn)贊組件，點(diǎn)擊時(shí)是否能及時(shí)的修改未贊和已贊狀態(tài)？是這項(xiàng)測(cè)試的評(píng)測(cè)點(diǎn)。

測(cè)試方式：

• 選中某微博，點(diǎn)擊“點(diǎn)贊”按鈕，實(shí)現(xiàn)點(diǎn)贊狀態(tài)狀態(tài)切換（已贊高亮、未贊灰色），
• 點(diǎn)贊按鈕? onclick 函數(shù)開頭開始計(jì)時(shí)， setData 回調(diào)函數(shù)開頭結(jié)束計(jì)時(shí)；

在紅米手機(jī)（Redmi 6 Pro）上進(jìn)行多次測(cè)試，求其平均值，結(jié)果如下：

列表數(shù)量	微信原生	wepy	mpvue	taro	uni-app	chameleon
200	91	279	666	92	93	101
400	111	501	1507	125	107	145
600	144	–	–	152	148	178
800	176	–	–	214	181	236
1000	220	–	–	229	234	272

說(shuō)明：也就是在列表數(shù)量為400時(shí)，微信原生開發(fā)的應(yīng)用，點(diǎn)贊按鈕從點(diǎn)擊到狀態(tài)變化需要111毫秒。

測(cè)試結(jié)果數(shù)據(jù)說(shuō)明：

• wepy/mpvue 測(cè)試數(shù)據(jù)不完整的原因同上，在組件較多時(shí)，頁(yè)面已經(jīng)不再渲染了
• 基于微信自定義組件實(shí)現(xiàn)組件開發(fā)的框架（uni-app/taro/chameleon），組件數(shù)據(jù)通訊性能接近于微信原生框架，遠(yuǎn)高于基于 template 實(shí)現(xiàn)組件開發(fā)的框架（wepy/mpvue）性能

組件數(shù)據(jù)更新性能測(cè)評(píng)： 微信原生開發(fā) , uni-app , taro ?>? chameleon ?>? wepy ?>? mpvue

綜上，本性能測(cè)試做了2個(gè)測(cè)試，長(zhǎng)列表加載和組件狀態(tài)更新，綜合2個(gè)實(shí)驗(yàn)，結(jié)論如下：

微信原生開發(fā)手工優(yōu)化 , uni-app > 微信原生開發(fā)未手工優(yōu)化 , taro ?>? chameleon ?>>? wepy ?>? mpvue

3. 學(xué)習(xí)門檻

DSL語(yǔ)法支持度

主流跨端框架基本都遵循React、Vue（類Vue）語(yǔ)法，其主要目的：復(fù)用工程師的現(xiàn)有技術(shù)棧，降低學(xué)習(xí)成本。此時(shí)，跨端框架對(duì)于原框架（React/Vue）語(yǔ)法的支持度就是一個(gè)重要的衡量標(biāo)準(zhǔn)，如果支持度較低、和原框架語(yǔ)法差異較大，則開發(fā)者無(wú)異于要學(xué)習(xí)一門新的框架，成本太高。

實(shí)際開發(fā)中發(fā)現(xiàn)，各個(gè)多端框架，都沒(méi)有完全實(shí)現(xiàn)vue、react在web上的所有語(yǔ)法：
taro ?對(duì)于? JSX ?的語(yǔ)法支持是相對(duì)完善的，其文檔中描述未來(lái)版本計(jì)劃，

更多的 JSX 語(yǔ)法支持，1.3 之后限制生產(chǎn)力的語(yǔ)法只有只能用 map 創(chuàng)造循環(huán)組件一條

mpvue 、 uni-app ?框架基于? Vue.js ?核心，通過(guò)修改? Vue.js ?的? runtime ?和? compiler ，實(shí)現(xiàn)了在小程序端的運(yùn)行，支持絕大部分的Vue語(yǔ)法； uni-app ?編譯到微信端曾經(jīng)使用過(guò) mpvue ，但后來(lái)重寫框架，支持了更多vue語(yǔ)法如 filter 、復(fù)雜? JavaScript ?表達(dá)式等；

wepy 、 chameleon ?都是? 類Vue ?的實(shí)現(xiàn)，僅支持? Vue ?的部分語(yǔ)法，開發(fā)時(shí)需要單獨(dú)學(xué)習(xí)它們的規(guī)則；

DSL語(yǔ)法支持評(píng)測(cè)： taro , uni-app ?>? mpvue ?>? wepy , chameleon

學(xué)習(xí)資料完善度

• 官方文檔、搜索系統(tǒng)的完備度方面： uni-app 文檔內(nèi)容豐富，示例demo完備， taro 次之，其他幾個(gè)框架相對(duì)要弱一些。 mpvue 文檔雖少，但其概念不復(fù)雜，也沒(méi)有支持H5、App，組件、API文檔都可直接看微信的文檔，學(xué)習(xí)難度倒也很低。
• 教程方面： uni-app 官方有視頻教程，不少三方專業(yè)培訓(xùn)機(jī)構(gòu)也錄制的 uni-app 教程，包括騰訊課堂自家NEXT學(xué)院也錄制了 uni-app 培訓(xùn)視頻課，公開售賣； mpvue 在騰訊課堂也有三方視頻教程售賣； taro 沒(méi)有視頻教程，但官方發(fā)布了掘金小冊(cè)； wepy 和 chameleon 還沒(méi)有專業(yè)教程。

學(xué)習(xí)資料完善度評(píng)測(cè)： uni-app ?>? mpvue ?,? taro ?>? chameleon ?>? wepy

技術(shù)支持和社區(qū)活躍度

開發(fā)難免遇到問(wèn)題，官方技術(shù)支持和社區(qū)活躍度很重要。

目前看， uni-app 、 taro 、 chameleon 都有專職人員做技術(shù)支持， uni-app 因交流群過(guò)多，還單獨(dú)引入了智能客服機(jī)器人。

活躍的社區(qū)意味著你遇到問(wèn)題有人可問(wèn)、或者前人會(huì)沉淀經(jīng)驗(yàn)到文章里供你搜索。 uni-app 官方有30多個(gè)交流群（其中有很多千人大群），自建論壇中有大量交流帖子；taro和mpvue有9個(gè)500人微信群；wepy官網(wǎng)的微信已無(wú)法添加，chameleon發(fā)布較晚，用戶群還較少。除 uni-app 外，其他框架沒(méi)有自建論壇社區(qū)。

本次評(píng)測(cè)demo開發(fā)期間，我們的同學(xué)（同時(shí)掌握vue和react），在學(xué)習(xí)研究各個(gè)多端框架時(shí)，切實(shí)感受到由于語(yǔ)法、學(xué)習(xí)資料、社區(qū)的差異帶來(lái)的學(xué)習(xí)門檻，吐出了很多槽。

綜合評(píng)估，本項(xiàng)評(píng)測(cè)結(jié)論： uni-app ?>? taro ?>? mpvue ?>? wepy ?>? chameleon

Tips:本測(cè)評(píng)忽略React、Vue兩框架自身的學(xué)習(xí)門檻

4. 工具和周邊生態(tài)

工具

所有多端框架均支持 cli 模式，可以在主流前端工具中開發(fā)。
各框架基本都帶有d.ts的語(yǔ)法提示庫(kù)。
由于 mpvue 、 uni-app 、 taro 直接支持 vue 、 react 語(yǔ)法，配套的ide工具鏈較豐富，著色、校驗(yàn)、格式化完善， chameleon 針對(duì)部分編輯器推薦了插件， wepy 有一些三方維護(hù)的vscode插件。

工具屬性維度，明顯高出一截的框架是 uni-app ，其出品公司同時(shí)也是HBuilder的出品公司， DCloud.io 。
HBuilder/HBuilderX系列是國(guó)產(chǎn)開發(fā)工具，有300萬(wàn)開發(fā)者用戶。
HBuilderX為 uni-app 做了很多優(yōu)化，故 uni-app 的開發(fā)效率、易用性非其他框架可及。
當(dāng)然對(duì)于不習(xí)慣HBuilderX的開發(fā)者而言， uni-app 的這個(gè)優(yōu)勢(shì)無(wú)法體現(xiàn)。

周邊生態(tài)

一個(gè)底層框架，其周邊配套非常重要，比如ui庫(kù)、js庫(kù)、項(xiàng)目模板。

• wepy：出現(xiàn)時(shí)間久，開源項(xiàng)目多，占據(jù)一定優(yōu)勢(shì)。
• mpvue：發(fā)布時(shí)間也較早，歷史積累較多。
• taro：官方提供了taro ui，github上有一些開源項(xiàng)目。
• uni-app：提供了 插件市場(chǎng) ，ui庫(kù)、周邊模板豐富
• chameleon：還沒(méi)有形成周邊生態(tài)。

值得注意的是， uni-app 和 mpvue 的插件生態(tài)是互通的，都是vue插件。所以雙方還聯(lián)合舉辦了插件大賽。這個(gè)聯(lián)合生態(tài)的周邊豐富度，是目前各個(gè)框架中最豐富的。

順便打個(gè)廣告，歡迎有實(shí)力的同學(xué)參加? uni-app/mpvue插件開發(fā)大賽 ，領(lǐng)取iPhone Xs Max等豐厚獎(jiǎng)品。

綜上比較，工具和周邊生態(tài)評(píng)測(cè)結(jié)論： uni-app , mpvue ?>? wepy ?>? taro ?>? chameleon

其他常見評(píng)測(cè)指標(biāo)

github star：

wepy	mpvue	taro	uni-app	chameleon
17136	16650	17078	4728	4287

github star 數(shù)對(duì)比： wepy ?>? taro ?>? mpvue ?>? uni-app ?>? chameleon

Tips:

• star 數(shù)采集時(shí)間：2019.03.31 21:30
• star 數(shù)量和產(chǎn)品發(fā)布時(shí)間有關(guān)，也和用戶使用習(xí)慣有關(guān)；除 uni-app 外，其他框架的交流互動(dòng)主要是github的issus， uni-app 的開發(fā)者一般在 uni-app 的 問(wèn)答社區(qū) 中交流反饋，github頁(yè)面訪問(wèn)量較低。

百度指數(shù)

百度指數(shù)代表了開發(fā)者的搜索量和包含關(guān)鍵字的網(wǎng)頁(yè)數(shù)量。如下是各跨端框架近7天（2019-03-24 ~ 2019-03-30）的百度指數(shù)：

Tips:

• wepy 未被百度指數(shù)收錄，說(shuō)明其搜索量和包含該關(guān)鍵字的網(wǎng)頁(yè)數(shù)量都不夠多。
• taro 和 chameleon ?的名稱取自于已存在的名稱，實(shí)際指代開發(fā)框架的指數(shù)應(yīng)該更低。

案例

僅看發(fā)布到微信小程序的案例，數(shù)量和質(zhì)量綜合對(duì)比，wepy > mpvue > taro , uni-app > chameleon

如果看多端案例，綜合對(duì)比，uni-app > taro > mpvue > wepy > chameleon

除了 uni-app 外，其他跨端框架的出品方本身為一線開發(fā)商，其內(nèi)部項(xiàng)目會(huì)使用這些框架，經(jīng)受過(guò)實(shí)戰(zhàn)考驗(yàn)。但同時(shí)鮮有其他大開發(fā)商使用這類框架。

這里面有面子問(wèn)題，也有兼容問(wèn)題。很多開發(fā)商做的框架，可以滿足其自身業(yè)務(wù)需求，但對(duì)外開放后想滿足所有開發(fā)者，仍然需要投入大量工作完善產(chǎn)品，很多開發(fā)商主營(yíng)業(yè)務(wù)不在此，并沒(méi)有這么做。

這也是很多開源項(xiàng)目被稱為KPI項(xiàng)目的原因。

客觀講，凹凸實(shí)驗(yàn)室投入如此大精力打磨 taro ，讓 uni-app 團(tuán)隊(duì)也很驚訝和佩服。
chameleon 團(tuán)隊(duì)初期投入也很大，但發(fā)布時(shí)間還短，如果能長(zhǎng)期投入下去，也是令人敬佩的。
uni-app 團(tuán)隊(duì)本身就是專業(yè)做開發(fā)者服務(wù)的，案例很多，但創(chuàng)業(yè)者居多。

可以說(shuō)整個(gè)多端框架市場(chǎng)仍處于起步期，距離讓更多開發(fā)者接受，還需要所有框架作者的共同努力。

其他補(bǔ)充說(shuō)明

1. 開源和App側(cè)的補(bǔ)充說(shuō)明

有的友商在評(píng)測(cè)中提到 uni-app 的開源性不足問(wèn)題。
需要說(shuō)明下， uni-app 和其他多端框架一樣，都是前端框架，是純開源的。

除了 uni-app ，其他框架的App端，或者使用 expo (一個(gè)基于 react native 的封裝庫(kù)）、或者使用 weex 。

做過(guò)這些開發(fā)的人都知道，原生排版引擎和web排版引擎有很多差異。而且不管 react native 還是 weex ，都只是渲染器，能力部分還需要開發(fā)者寫原生代碼，這就無(wú)法跨端了。 expo 比 react native 強(qiáng)的是多封裝了一些能力，但也帶來(lái)新的限制。

uni-app 的App端，是一個(gè)真的小程序引擎，又補(bǔ)充了可選的weex引擎。這也是 uni-app 在App端能夠提供比其他跨端框架更好兼容性的原因。

而這個(gè)引擎，是另一個(gè)開源項(xiàng)目，叫 h5p ，這個(gè)引擎是部分開源狀態(tài)。

整個(gè)業(yè)內(nèi)目前還不存在一個(gè)完全開源的小程序引擎。

不過(guò) uni-app 的App端使用許可是完全免費(fèi)，可以放心使用。

其實(shí)也不用好奇為什么DCloud會(huì)有小程序引擎，因?yàn)闃I(yè)內(nèi)第一個(gè)做小程序的并不是微信，而是DCloud。

關(guān)于App端，其實(shí)可以再寫出一篇很長(zhǎng)的專業(yè)評(píng)測(cè)。后續(xù) uni-app 團(tuán)隊(duì)會(huì)再做一篇App端與 react native 、 weex 、 cordova 、 flutter 等框架的對(duì)比。

2. 轉(zhuǎn)換和混寫

taro 提供了原生小程序轉(zhuǎn)換為 taro 工程的轉(zhuǎn)換器，也支持在原生小程序里部分頁(yè)面嵌入 taro 編寫的頁(yè)面，這是 taro 的特色，其他跨端框架沒(méi)有提供。這對(duì)于降低入門門檻有不少幫助。

結(jié)語(yǔ)

真實(shí)客觀的永遠(yuǎn)是實(shí)驗(yàn)和數(shù)據(jù)，而不是結(jié)論。不同需求的開發(fā)者，可以根據(jù)上述實(shí)驗(yàn)數(shù)據(jù)，自行得出自己的選型結(jié)論。

但作為一篇完整的評(píng)測(cè)，我們也必須提供一份總結(jié)，雖然它可能加入了我們的主觀感受：

如果你想多端開發(fā)，提升效率，不想踩太多坑， uni-app 相對(duì)更完善。

如果你只開發(fā)微信小程序，不做多端，那么使用 uni-app 、微信原生開發(fā)、 taro 是更優(yōu)的選擇。

• 如果使用微信原生開發(fā)，需要注意手動(dòng)寫優(yōu)化代碼來(lái)控制 setdata
• 如果你是 react 系，那就用 taro
• 如果是 vue 系，那就用 uni-app ， uni-app 在性能、周邊生態(tài)和開發(fā)效率上更有優(yōu)勢(shì)

如果你主要為了微信端和H5端，那么 uni-app 和 taro 都可以。可以根據(jù)自己熟悉的技術(shù)棧選擇。

如果你主要需要跨App端， uni-app 兼容性更好，其他框架的App端差異過(guò)大。如果你只關(guān)心App，不關(guān)心小程序和H5，那歡迎關(guān)注我們后續(xù)的評(píng)測(cè)： uni-app 和 cordova 、 react native 、 flutter 的深度比較。

如果你主要為了各家小程序，且不用復(fù)雜組件，那除了 uni-app 和 taro ， mpvue 也是不錯(cuò)的選擇。 mpvue 發(fā)布2.0版本后，搜索指數(shù)明顯爬升，希望能持續(xù)更新，迎來(lái)二次繁榮。

chameleon 發(fā)布不久，提供的組件和API還很少，但其未來(lái)的規(guī)劃比較令人期待，值得關(guān)注。

這篇評(píng)測(cè)寫完后，小編有點(diǎn)惴惴不安。

一方面本評(píng)測(cè)不太溫和，容易得罪人。但我們相信，這樣的評(píng)測(cè)，會(huì)激起所有跨端框架從業(yè)者的斗志，讓大家投入更多去完善產(chǎn)品，這對(duì)整個(gè)產(chǎn)業(yè)、對(duì)前端開發(fā)者，是大好事。

另一方面，讀者可能會(huì)以為現(xiàn)階段的 uni-app 很完美，其實(shí)我們深知 uni-app 還有很多需要完善的地方。 uni-app 團(tuán)隊(duì)也將持續(xù)投入心血，為中國(guó)的前端開發(fā)者造福！

如有讀者認(rèn)為本文中任何評(píng)測(cè)失真，歡迎在這里報(bào) issues 。