科技獵跨端開發(fā)框架深度橫評
上周，Taro 團隊發(fā)布了一篇《 小程序 多端框架全面測評》，讓開發(fā)者對業(yè)界主流的跨端框架，有了初步認識。感謝 Taro 團隊的付出。
不過橫評這件事，要想做完善，其實非常花費時間。不是只看文檔就行，它需要：
- 真實的動手寫多個平臺的測試demo，比較各個平臺的功能、性能，它們的實際情況到底是不是如文檔宣傳的那樣？
- 真實的學習每個框架，了解它們的學習曲線，在實際開發(fā)中遇到問題時，感受它們的文檔、教程、社區(qū)生態(tài)和技服能力到底怎么樣？
我們?
uni-app
?團隊投入一周完成了這個深度評測，下面我們就分享下，實際開發(fā)不同框架的測試例遇到的問題，和最終的測試結(jié)果。
評測實驗介紹
- 開發(fā)內(nèi)容：開發(fā)一個仿微博 小程序 首頁的復雜長列表，支持下拉刷新、上拉翻頁、點贊。
-
界面如下：
-
開發(fā)版本：一共開發(fā)了6個版本，包括微信原生版、wepy版、mpvue版、taro版、
uni-app
版、chameleon版（以這些產(chǎn)品發(fā)布時間排序，下同），按照官網(wǎng)指引通過
cli方式默認安裝(應該是最新穩(wěn)定版)。 -
測試代碼開源（
Github倉庫地址：https://github.com/dcloudio/test-framework
），
Tips:若有同學覺得測試代碼寫法欠妥，歡迎提交 PR 或? Issus - 測試機型：紅米 Redmi 6 Pro、MIUI 10.2.2.0 穩(wěn)定版（最新版）、微信版本 7.0.3（最新版）
- 測試環(huán)境：每個框架開始測試前，殺掉各App進程、清空內(nèi)存，保證測試機環(huán)境基本一致；每次從本地讀取靜態(tài)數(shù)據(jù)，屏蔽網(wǎng)絡差異。
-
測試維度：
- 跨端支持度如何？
- 性能如何？
- 學習門檻
- 工具與周邊生態(tài)
1. 跨端支持度如何
開發(fā)一次，到處運行，是每個程序員的夢想。但現(xiàn)實往往變成開發(fā)一次，到處調(diào)錯。
各個待評測框架，是否真得如宣傳的那樣，一次開發(fā)、多端發(fā)布？
我們將上述 仿微博App 依次發(fā)布到各平臺，驗證每個框架在各端的兼容性，結(jié)果如下：
| 平臺 | 微信原生 | wepy | mpvue | taro | uni-app | chameleon |
|---|---|---|---|---|---|---|
| 微信 小程序 | ?? | ?? | ?? | ?? | ?? | ?? |
| 支付寶小程序 | ? | ? | ?? | ?? | ?? | ? |
| 百度小程序 | ? | ? | ?? | ?? | ?? | ? |
| 頭條小程序 | ? | ? | ?? | ?? | ?? | ? |
| H5端 | ? | ? | ? | 上拉加載/下拉刷新失效 | ?? | 上拉加載/下拉刷新失效 |
| App端 | ? | ? | ? | 上拉加載失效 | ?? | 列表無法滾動，無法測試上拉加載/下拉刷新 |
測試結(jié)果說明：
- ? 表示支持且功能正常，? 表示不支持，其它則表示支持但存在部分bug或兼容問題
-
wepy?2.0 宣稱版已支持其他家小程序，本測試基于wepy官網(wǎng)指引安裝的wepy-cli默認版本為1.7.3，尚不支持多端 -
chameleon嘗鮮版宣稱支付寶、百度小程序，本測試基于chameleon官網(wǎng)指引安裝的chameleon-tool默認版本為0.1.1，尚不支持其它小程序
通過這個簡單的例子可以看出，跨端支持度測評結(jié)論：
uni-app
?>?
taro
?>?
chameleon
>?
mpvue
?>
wepy
、
原生微信小程序
但是僅有上面的測試還不全面，實際業(yè)務要比這個測試例復雜很多。但我們沒法開發(fā)很多復雜業(yè)務做評測，所以還需要再對照各家文檔補充一些信息。
由于每個框架的文檔中都描述了各種組件和API的跨端支持程度。我們過了幾家的文檔，發(fā)現(xiàn)各家基本是以微信小程序為基線，然后把各種組件和API在其他端實現(xiàn)了一遍：
-
taro：H5端實現(xiàn)了大部分微信的API，App端和微信的差異比較大。 -
uni-app：組件、API、配置，大部分在各個端均已實現(xiàn)，個別API有說明在某些端不支持。可以看出uni-app是完整在H5端實現(xiàn)了一套微信模擬器，在App端實現(xiàn)了一套微信小程序引擎，才達到比較完善的平臺兼容性。 -
chameleon：非常常用的一些組件和API在各端已經(jīng)實現(xiàn)，這部分的平臺差異較少。但大量組件和API需要開發(fā)者自己分平臺寫代碼。
跨端框架，一方面要考慮框架提供的通用api跨端支持，同時還要考慮不同端的特色差異如何兼容。畢竟每個端都會有自己的特色，不可能完全一致。
-
taro：提供了js環(huán)境變量判斷和統(tǒng)一接口的多端文件，可以在組件、js、文件方面擴展多端，不支持其他環(huán)節(jié)的分平臺處理。 -
uni-app：提供了條件編譯模型，所有代碼包括組件、js、css、配置json、文件、目錄，均支持條件編譯，可不受限的編寫各端差異代碼。 -
chameleon：提供了多態(tài)方案，可以在組件、js、文件方面擴展多端，不支持其他方式的分平臺處理。
跨端框架，還涉及一個ui框架的跨端問題，評測結(jié)果如下：
-
taro：官方提供了taro ui，支持小程序(微信/支付寶/百度)、H5平臺，不支持App， 詳見 -
uni-app：官方提供了uni ui，可全端運行；uni-app還有一個插件市場，里面有很多三方ui組件， 詳見 -
chameleon：官方提供了cml-ui擴展組件庫，可全端運行，但組件數(shù)量略少， 詳見
最后補充跨端案例：
- mpvue：微信端案例豐富，未見其它端案例
- taro：微信端案例豐富，百度、支付寶、H5端亦有少量案例
- uni-app：微信、App、H5三端案例豐富，官方示例已發(fā)布到6端
- chameleon：未看到任何端案例
綜合以上信息，本項的最終評測結(jié)論：
uni-app
?>?
taro
?>?
chameleon
?>?
mpvue
?>?
wepy
、
原生微信小程序
之前曾有友商掀起一番真跨端和偽跨端之爭，通過本次Demo實測，這個爭論可以蓋棺定論了。
2. 跨端框架性能如何
跨端框架基本都是
compiler
?+?
runtime
模式，引入的
runtime
是否會降低運行性能？
尤其是與原生微信小程序開發(fā)相比性能怎么樣，這是大家普遍關心的問題。
我們依然以上述仿微博小程序為例，測試2個容易出性能問題的點：長列表加載、大量點贊組件的響應。
2.1 長列表加載
仿微博的列表是一個包含很多組件的列表，這種復雜列表對性能的壓力更大，很適合做性能測試。
從觸發(fā)上拉加載到數(shù)據(jù)更新、頁面渲染完成，需要準確計時。人眼視覺計時肯定不行，我們采用程序埋點的方式，制定了如下計時時機：
- 計時開始時機：交互事件觸發(fā)，框架賦值之前，如：上拉加載（onReachBottom）函數(shù)開頭
- 計時結(jié)束時機：頁面渲染完畢(微信setData回調(diào)函數(shù)開頭)
Tips：
setData
回調(diào)函數(shù)開頭可認為是頁面渲染完成的時間，是因為微信
setData
定義如下(
微信規(guī)范
)：
| 字段 | 類型 | 必填 | 描述 | |
|---|---|---|---|---|
| data | Object | 是 | 這次要改變的數(shù)據(jù) | |
| callback | Function | 否 | setData引起的界面更新 渲染完畢 后的回調(diào)函數(shù) |
測試方式：從頁面空列表開始，通過程序自動觸發(fā)上拉加載，每次新增20條列表，記錄單次耗時；固定間隔連續(xù)觸發(fā) N 次上拉加載，使得頁面達到 20*N 條列表，計算這 N 次
觸發(fā)上拉 -> 渲染完成
的平均耗時。
測試結(jié)果如下：
| 列表條數(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 |
說明：以400條微博列表為例，從頁面空列表開始，每隔1秒觸發(fā)一次上拉加載（新增20條微博），記錄單次耗時，觸發(fā)20次后停止（頁面達到400條微博），計算這20次的平均耗時，結(jié)果微信原生在這20次?
觸發(fā)上拉 -> 渲染完成
?的平均耗時為876毫秒，最快的
uni-app
是741毫秒，最慢的mpvue是4493毫秒
大家初看這個數(shù)據(jù)，可能比較疑惑，別急，下方有詳細說明
說明1：為何 mpvue/wepy 測試數(shù)據(jù)不完整?
mpvue
、
wepy
?誕生之初，微信小程序尚不支持
自定義組件
，無法進行組件化開發(fā)；
mpvue
、
wepy
?為解決這個問題，將用戶編寫的
Vue
組件，編譯為
WXML
中的
模板（template)
，變相實現(xiàn)了組件化開發(fā)能力，提高代碼復用性，這在當時的技術條件下是很棒的技術方案。
但如此方案，在復雜組件較多的頁面，會大量增加 dom 節(jié)點，甚至超出微信的 dom 節(jié)點數(shù)限制。我們在 紅米手機（Redmi 6 Pro）上實測，頁面組件超過500個時，
mpvue
、
wepy
?實現(xiàn)的仿微博App就會報出如下異常，并停止渲染，故這兩個測試框架在組件較多時，測試數(shù)據(jù)不完整。這也就意味著，當頁面組件太多時，無法使用這2個框架。
dom limit exceeded please check if there’s any mistake you’ve made
Tips：
wepy
在400條列表以內(nèi)，為何性能高于微信原生框架，這個跟自定義組件管理開銷及業(yè)務場景有關（
wepy
編譯為模板，不涉及組件創(chuàng)建及管理開銷），后續(xù)對微博點贊，涉及組件數(shù)據(jù)傳遞時，微信原生框架的性能優(yōu)勢就提現(xiàn)出來了，詳見下方測試數(shù)據(jù)。
說明2：uni-app 比微信原生框架性能更好？逆天了？
其實，在頁面上有200條記錄（200個組件）時，
taro
?性能數(shù)據(jù)也比微信原生框架更好。
微信原生框架耗時主要在
setData
調(diào)用上，開發(fā)者若不單獨優(yōu)化，則每次都會傳遞大量數(shù)據(jù)；而?
uni-app
、
taro
?都在調(diào)用
setData
之前自動做
diff
計算，每次僅傳遞有變化的數(shù)據(jù)。
例如當前頁面有20條數(shù)據(jù)，觸發(fā)上拉加載時，會新加載20條數(shù)據(jù)，此時原生框架通過如下代碼測試時，
setData
會傳輸40條數(shù)據(jù)
-
data : { -
listData : [] -
}, -
onReachBottom () { //上拉加載 -
let listData = this . data . listData ; -
listData . push (... Api . getNews ()); //新增數(shù)據(jù) -
this . setData ({ -
listData -
}) //全量數(shù)據(jù)，發(fā)送數(shù)據(jù)到視圖層 -
}
開發(fā)者使用微信原生框架，完全可以自己優(yōu)化，精簡傳遞數(shù)據(jù)，比如修改如下：
-
data : { -
listData : [] -
}, -
onReachBottom () { //上拉加載 -
// 通過長度獲取下一次渲染的索引 -
let index = this . data . listData . length ; -
let newData = {}; //新變更數(shù)據(jù) -
Api . getNews (). forEach (( item ) => { -
newData [ 'listData[' + ( index ++) + ']' ] = item //賦值，索引遞增 -
}) -
this . setData ( newData ) //增量數(shù)據(jù)，發(fā)送數(shù)據(jù)到視圖層 -
}
經(jīng)過如上優(yōu)化修改后，再次測試，微信原生框架性能數(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 |
從測試結(jié)果可看出，經(jīng)過開發(fā)者手動優(yōu)化，微信原生框架可達到更好的性能，但?
uni-app
、
taro
?相比微信原生，性能差距并不大。
這個結(jié)果，和web開發(fā)類似，web開發(fā)也有原生js開發(fā)、vue、react框架等情況。如果不做特殊優(yōu)化，原生js寫的網(wǎng)頁，性能經(jīng)常還不如vue、react框架的性能。
也恰恰是因為
Vue
、
react
框架的優(yōu)秀，性能好，開發(fā)體驗好，所以原生js開發(fā)已經(jīng)逐漸減少使用了。
復雜長列表加載下一頁評測結(jié)論：
微信原生開發(fā)手工優(yōu)化
,
uni-app
>
微信原生開發(fā)未手工優(yōu)化
,
taro
?>?
chameleon
?>?
wepy
?>?
mpvue
2.2 點贊組件響應速度
長列表中的某個組件，比如點贊組件，點擊時是否能及時的修改未贊和已贊狀態(tài)？是這項測試的評測點。
測試方式：
- 選中某微博，點擊“點贊”按鈕，實現(xiàn)點贊狀態(tài)狀態(tài)切換（已贊高亮、未贊灰色），
-
點贊按鈕?
onclick函數(shù)開頭開始計時，setData回調(diào)函數(shù)開頭結(jié)束計時；
在紅米手機（Redmi 6 Pro）上進行多次測試，求其平均值，結(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 |
說明：也就是在列表數(shù)量為400時，微信原生開發(fā)的應用，點贊按鈕從點擊到狀態(tài)變化需要111毫秒。
測試結(jié)果數(shù)據(jù)說明：
- wepy/mpvue 測試數(shù)據(jù)不完整的原因同上，在組件較多時，頁面已經(jīng)不再渲染了
-
基于微信自定義組件實現(xiàn)組件開發(fā)的框架（uni-app/taro/chameleon），組件數(shù)據(jù)通訊性能接近于微信原生框架，遠高于基于
template實現(xiàn)組件開發(fā)的框架（wepy/mpvue）性能
組件數(shù)據(jù)更新性能測評：
微信原生開發(fā)
,
uni-app
,
taro
?>?
chameleon
?>?
wepy
?>?
mpvue
綜上，本性能測試做了2個測試，長列表加載和組件狀態(tài)更新，綜合2個實驗，結(jié)論如下：
微信原生開發(fā)手工優(yōu)化
,
uni-app
>
微信原生開發(fā)未手工優(yōu)化
,
taro
?>?
chameleon
?>>?
wepy
?>?
mpvue
3. 學習門檻
DSL語法支持度
主流跨端框架基本都遵循React、Vue（類Vue）語法，其主要目的：復用工程師的現(xiàn)有技術棧，降低學習成本。此時，跨端框架對于原框架（React/Vue）語法的支持度就是一個重要的衡量標準，如果支持度較低、和原框架語法差異較大，則開發(fā)者無異于要學習一門新的框架，成本太高。
實際開發(fā)中發(fā)現(xiàn)，各個多端框架，都沒有完全實現(xiàn)vue、react在web上的所有語法：
taro
?對于?
JSX
?的語法支持是相對完善的，其文檔中描述未來版本計劃，
更多的 JSX 語法支持，1.3 之后限制生產(chǎn)力的語法只有只能用 map 創(chuàng)造循環(huán)組件一條
mpvue
、
uni-app
?框架基于?
Vue.js
?核心，通過修改?
Vue.js
?的?
runtime
?和?
compiler
，實現(xiàn)了在小程序端的運行，支持絕大部分的Vue語法；
uni-app
?編譯到微信端曾經(jīng)使用過
mpvue
，但后來重寫框架，支持了更多vue語法如
filter
、復雜?
JavaScript
?表達式等；
wepy
、
chameleon
?都是?
類Vue
?的實現(xiàn)，僅支持?
Vue
?的部分語法，開發(fā)時需要單獨學習它們的規(guī)則；
DSL語法支持評測：
taro
,
uni-app
?>?
mpvue
?>?
wepy
,
chameleon
學習資料完善度
-
官方文檔、搜索系統(tǒng)的完備度方面：
uni-app文檔內(nèi)容豐富，示例demo完備，taro次之，其他幾個框架相對要弱一些。mpvue文檔雖少，但其概念不復雜，也沒有支持H5、App，組件、API文檔都可直接看微信的文檔，學習難度倒也很低。 -
教程方面：
uni-app官方有視頻教程，不少三方專業(yè)培訓機構(gòu)也錄制的uni-app教程，包括騰訊課堂自家NEXT學院也錄制了uni-app培訓視頻課，公開售賣；mpvue在騰訊課堂也有三方視頻教程售賣；taro沒有視頻教程，但官方發(fā)布了掘金小冊；wepy和chameleon還沒有專業(yè)教程。
學習資料完善度評測：
uni-app
?>?
mpvue
?,?
taro
?>?
chameleon
?>?
wepy
技術支持和社區(qū)活躍度
開發(fā)難免遇到問題，官方技術支持和社區(qū)活躍度很重要。
目前看，
uni-app
、
taro
、
chameleon
都有專職人員做技術支持，
uni-app
因交流群過多，還單獨引入了智能客服機器人。
活躍的社區(qū)意味著你遇到問題有人可問、或者前人會沉淀經(jīng)驗到文章里供你搜索。
uni-app
官方有30多個交流群（其中有很多千人大群），自建論壇中有大量交流帖子；taro和mpvue有9個500人微信群；wepy官網(wǎng)的微信已無法添加，chameleon發(fā)布較晚，用戶群還較少。除
uni-app
外，其他框架沒有自建論壇社區(qū)。
本次評測demo開發(fā)期間，我們的同學（同時掌握vue和react），在學習研究各個多端框架時，切實感受到由于語法、學習資料、社區(qū)的差異帶來的學習門檻，吐出了很多槽。
綜合評估，本項評測結(jié)論：
uni-app
?>?
taro
?>?
mpvue
?>?
wepy
?>?
chameleon
Tips:本測評忽略React、Vue兩框架自身的學習門檻
4. 工具和周邊生態(tài)
工具
所有多端框架均支持
cli
模式，可以在主流前端工具中開發(fā)。
各框架基本都帶有d.ts的語法提示庫。
由于
mpvue
、
uni-app
、
taro
直接支持
vue
、
react
語法，配套的ide工具鏈較豐富，著色、校驗、格式化完善，
chameleon
針對部分編輯器推薦了插件，
wepy
有一些三方維護的vscode插件。
工具屬性維度，明顯高出一截的框架是
uni-app
，其出品公司同時也是HBuilder的出品公司，
DCloud.io
。
HBuilder/HBuilderX系列是國產(chǎn)開發(fā)工具，有300萬開發(fā)者用戶。
HBuilderX為
uni-app
做了很多優(yōu)化，故
uni-app
的開發(fā)效率、易用性非其他框架可及。
當然對于不習慣HBuilderX的開發(fā)者而言，
uni-app
的這個優(yōu)勢無法體現(xiàn)。
周邊生態(tài)
一個底層框架，其周邊配套非常重要，比如ui庫、js庫、項目模板。
- wepy：出現(xiàn)時間久，開源項目多，占據(jù)一定優(yōu)勢。
- mpvue：發(fā)布時間也較早，歷史積累較多。
- taro：官方提供了taro ui，github上有一些開源項目。
- uni-app：提供了 插件市場 ，ui庫、周邊模板豐富
- chameleon：還沒有形成周邊生態(tài)。
值得注意的是，
uni-app
和
mpvue
的插件生態(tài)是互通的，都是vue插件。所以雙方還聯(lián)合舉辦了插件大賽。這個聯(lián)合生態(tài)的周邊豐富度，是目前各個框架中最豐富的。
順便打個廣告，歡迎有實力的同學參加? uni-app/mpvue插件開發(fā)大賽 ，領取iPhone Xs Max等豐厚獎品。
綜上比較，工具和周邊生態(tài)評測結(jié)論：
uni-app
,
mpvue
?>?
wepy
?>?
taro
?>?
chameleon
其他常見評測指標
github star：
| wepy | mpvue | taro | uni-app | chameleon |
|---|---|---|---|---|
| 17136 | 16650 | 17078 | 4728 | 4287 |
github star 數(shù)對比：
wepy
?>?
taro
?>?
mpvue
?>?
uni-app
?>?
chameleon
Tips:
- star 數(shù)采集時間：2019.03.31 21:30
-
star 數(shù)量和產(chǎn)品發(fā)布時間有關，也和用戶使用習慣有關；除
uni-app外，其他框架的交流互動主要是github的issus，uni-app的開發(fā)者一般在uni-app的 問答社區(qū) 中交流反饋，github頁面訪問量較低。
百度指數(shù)
百度指數(shù)代表了開發(fā)者的搜索量和包含關鍵字的網(wǎng)頁數(shù)量。如下是各跨端框架近7天（2019-03-24 ~ 2019-03-30）的百度指數(shù)：
Tips:
-
wepy未被百度指數(shù)收錄，說明其搜索量和包含該關鍵字的網(wǎng)頁數(shù)量都不夠多。 -
taro和chameleon?的名稱取自于已存在的名稱，實際指代開發(fā)框架的指數(shù)應該更低。
案例
僅看發(fā)布到微信小程序的案例，數(shù)量和質(zhì)量綜合對比，wepy > mpvue > taro , uni-app > chameleon
如果看多端案例，綜合對比，uni-app > taro > mpvue > wepy > chameleon
除了
uni-app
外，其他跨端框架的出品方本身為一線開發(fā)商，其內(nèi)部項目會使用這些框架，經(jīng)受過實戰(zhàn)考驗。但同時鮮有其他大開發(fā)商使用這類框架。
這里面有面子問題，也有兼容問題。很多開發(fā)商做的框架，可以滿足其自身業(yè)務需求，但對外開放后想滿足所有開發(fā)者，仍然需要投入大量工作完善產(chǎn)品，很多開發(fā)商主營業(yè)務不在此，并沒有這么做。
這也是很多開源項目被稱為KPI項目的原因。
客觀講，凹凸實驗室投入如此大精力打磨
taro
，讓
uni-app
團隊也很驚訝和佩服。
chameleon
團隊初期投入也很大，但發(fā)布時間還短，如果能長期投入下去，也是令人敬佩的。
uni-app
團隊本身就是專業(yè)做開發(fā)者服務的，案例很多，但創(chuàng)業(yè)者居多。
可以說整個多端框架市場仍處于起步期，距離讓更多開發(fā)者接受，還需要所有框架作者的共同努力。
其他補充說明
1. 開源和App側(cè)的補充說明
有的友商在評測中提到
uni-app
的開源性不足問題。
需要說明下，
uni-app
和其他多端框架一樣，都是前端框架，是純開源的。
除了
uni-app
，其他框架的App端，或者使用
expo
(一個基于
react native
的封裝庫）、或者使用
weex
。
做過這些開發(fā)的人都知道，原生排版引擎和web排版引擎有很多差異。而且不管
react native
還是
weex
，都只是渲染器，能力部分還需要開發(fā)者寫原生代碼，這就無法跨端了。
expo
比
react native
強的是多封裝了一些能力，但也帶來新的限制。
uni-app
的App端，是一個真的小程序引擎，又補充了可選的weex引擎。這也是
uni-app
在App端能夠提供比其他跨端框架更好兼容性的原因。
而這個引擎，是另一個開源項目，叫
h5p
，這個引擎是部分開源狀態(tài)。
整個業(yè)內(nèi)目前還不存在一個完全開源的小程序引擎。
不過
uni-app
的App端使用許可是完全免費，可以放心使用。
其實也不用好奇為什么DCloud會有小程序引擎，因為業(yè)內(nèi)第一個做小程序的并不是微信，而是DCloud。
關于App端，其實可以再寫出一篇很長的專業(yè)評測。后續(xù)
uni-app
團隊會再做一篇App端與
react native
、
weex
、
cordova
、
flutter
等框架的對比。
2. 轉(zhuǎn)換和混寫
taro
提供了原生小程序轉(zhuǎn)換為
taro
工程的轉(zhuǎn)換器，也支持在原生小程序里部分頁面嵌入
taro
編寫的頁面，這是
taro
的特色，其他跨端框架沒有提供。這對于降低入門門檻有不少幫助。
結(jié)語
真實客觀的永遠是實驗和數(shù)據(jù)，而不是結(jié)論。不同需求的開發(fā)者，可以根據(jù)上述實驗數(shù)據(jù)，自行得出自己的選型結(jié)論。
但作為一篇完整的評測，我們也必須提供一份總結(jié)，雖然它可能加入了我們的主觀感受：
如果你想多端開發(fā)，提升效率，不想踩太多坑，
uni-app
相對更完善。
如果你只開發(fā)微信小程序，不做多端，那么使用
uni-app
、微信原生開發(fā)、
taro
是更優(yōu)的選擇。
-
如果使用微信原生開發(fā)，需要注意手動寫優(yōu)化代碼來控制
setdata -
如果你是
react系，那就用taro -
如果是
vue系，那就用uni-app，uni-app在性能、周邊生態(tài)和開發(fā)效率上更有優(yōu)勢
如果你主要為了微信端和H5端，那么
uni-app
和
taro
都可以。可以根據(jù)自己熟悉的技術棧選擇。
如果你主要需要跨App端，
uni-app
兼容性更好，其他框架的App端差異過大。如果你只關心App，不關心小程序和H5，那歡迎關注我們后續(xù)的評測：
uni-app
和
cordova
、
react native
、
flutter
的深度比較。
如果你主要為了各家小程序，且不用復雜組件，那除了
uni-app
和
taro
，
mpvue
也是不錯的選擇。
mpvue
發(fā)布2.0版本后，搜索指數(shù)明顯爬升，希望能持續(xù)更新，迎來二次繁榮。
chameleon
發(fā)布不久，提供的組件和API還很少，但其未來的規(guī)劃比較令人期待，值得關注。
這篇評測寫完后，小編有點惴惴不安。
一方面本評測不太溫和，容易得罪人。但我們相信，這樣的評測，會激起所有跨端框架從業(yè)者的斗志，讓大家投入更多去完善產(chǎn)品，這對整個產(chǎn)業(yè)、對前端開發(fā)者，是大好事。
另一方面，讀者可能會以為現(xiàn)階段的
uni-app
很完美，其實我們深知
uni-app
還有很多需要完善的地方。
uni-app
團隊也將持續(xù)投入心血，為中國的前端開發(fā)者造福！
如有讀者認為本文中任何評測失真，歡迎在這里報 issues 。