跨端開發框架深度橫評之2020版

時間 2020-04-11

標籤開發框架深度简体版

原文原文鏈接

又是一年四月天，距離上次發佈跨端開發框架深度橫評已過去整整一年。javascript

這一年，小程序在用戶規模及商業化方面都取得了極大的成功。微信小程序日活超過3億，支付寶、百度、字節跳動小程序的月活也紛紛超過3億。css

對應小程序開發領域，這一年也發生了巨大變化。開發框架從單純的微信小程序開發，過渡到多端框架成爲標配，進一步提高開發效率成爲開發者的強烈需求。html

這一年 mpvue 中止更新，Taro開始探索 taro next，uni-app 產品和生態持續完善，微信新推出了支持H5和微信小程序的 kbone 框架...前端

去年的深度橫評中不少老將已經退出江湖，一些新秀吸引眼球，所以，是時候來一波2020版的新橫評了。vue

評測目標篩選

跨端框架是一個重投入工做，在各框架的1年多的比拼中，不少框架由於投入不足而逐漸被開發者放棄，uni-app和taro依靠持續的大力度投入，成爲了市場主流。java

taro 在穩定版的基礎之上，最近也推出了 taro next，這2個版本差別較大，本次會分別評測。react

kbone 框架雖面世不久，但畢竟是微信官方發佈，關注的人很多，故本次將 kbone 加入評測目標。android

因此，本次評測的對象（按發佈時間排序）：git

微信原生開發
taro，京東凹凸實驗室出品，官網地址：https://taro.jd.com/
uni-app，DCloud出品，官網地址：https://uniapp.dcloud.net.cn
kbone，騰訊微信團隊出品，官網地址：https://wechat-miniprogram.github.io/kbone/docs/

本次評測除了運行性能等實測數據外，儘量得經過框架官網及github、掘金、騰訊課堂等三方社區公開採集數據，但願給你們一個綜合全面的評估依據。github

功能實現

taro 和 uni-app 是比較典型的多端框架，發佈到各個端都可。而 kbone 只支持微信小程序和H5。

taro 和 uni-app 均將經常使用接口及組件封裝了成了跨端API和跨端組件，組件規範沿用微信小程序的規範，部分平臺特有API，這兩個框架亦有應對方案：

taro：支持與小程序代碼混寫，可經過混寫的方式調用框架還沒有封裝的小程序新增API
uni-app：支持條件編譯，可在條件編譯代碼塊中，隨意調用各個平臺新增的API及組件

taro 和 uni-app 能夠不受限的調用各家小程序平臺全部的API及組件。

kbone 沿用web的開發習慣，使用html標籤及js api；涉及微信特有api時，可經過process.env.isMiniprogram判斷環境，而後編寫微信原生代碼。對於html中沒有標籤可替代的微信內置組件（如swiper），須要使用 wx-component 標籤或者使用 wx- 前綴，這樣的內置組件會被包裹一層自定義組件，帶來相應的性能開銷。

除了接口、組件以外，咱們以微信小程序爲例，找幾個典型能力對比框架支持度：

框架	taro	uni-app	kbone
微信自定義組件	⭕️	⭕️	⭕️
三方插件	⭕️	⭕️	❌
分包加載	⭕️	⭕️	⭕️
sitemap	⭕️	⭕️	⭕️
wxs	❌	⭕️	❌
雲開發	⭕️	⭕️	⭕️

補充說明：

若是在 Taro 項目引用了小程序原生的第三方組件，那麼該項目將再也不具有多端轉換的能力，例如，若是使用了微信小程序的第三方組件，那麼項目只能轉換成微信小程序，轉義成其餘平臺會失效，詳見taro官網
uni-app 中使用微信自定義組件的話，支持編譯發行到App/H5/微信小程序/QQ小程序4個平臺，詳見uni-app官網
taro 不支持 wxs 的依據：#2959
kbone 不支持微信三方插件的依據：#58；不支持wxs的依據：#129
雲開發在微信平臺，三個框架都支持，但 taro/kbone僅支持微信小程序平臺，uni-app支持App/H5/小程序全部平臺使用雲開發，詳見下方 serverless/雲開發 章節。

wxs是提高性能體驗的重要利器，除了微信小程序的wxs外，還有支付寶的SJS、百度的Filter，這些高級技術 uni-app 均完善支持。參考：謎之wxs，uni-app如何用它大幅提高性能

從如上功能對比來看：微信原生 ~ uni-app > taro > kbone

運行性能

咱們繼續沿用去年的測試模型，看看一年來，各家小程序開發框架的性能是否有提高。詳細以下：

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

開發版本：一共開發了5個版本，包括微信原生版、taro版、uni-app版、kbone版，按照官網指引經過cli方式默認安裝。
taro 目前穩定版本是2.0版，但近期在宣傳跨框架的taro next，故咱們基於一樣的 react代碼，同時測試了taro 2.0 和 taro next 兩個版本的數據。
測試代碼開源（Github倉庫地址：https://github.com/dcloudio/test-framework），

Tips:如有同窗以爲測試代碼寫法欠妥，歡迎提交 PR 或 Issus

測試機型：紅米 Redmi 6 Pro、MIUI 11.0.5 穩定版（最新版）、微信版本 7.0.12（最新版）
測試環境：每一個框架開始測試前，殺掉各App進程、清空內存，保證測試機環境基本一致；每次從本地讀取靜態數據，屏蔽網絡差別。

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

長列表加載

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

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

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

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

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

測試結果以下：

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

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

說明1：爲什麼 taro next/kbone 測試數據不完整?

由於 taro next 和kbone 採用的是動態渲染方案，這類方案在頁面複雜、組件較多時，會大量增長頁面 dom 節點數量，甚至超出微信的 dom 節點數限制（以下告警信息）。咱們在紅米手機（Redmi 6 Pro）上實測，頁面組件超過600個時，taro next、kbone 實現的仿微博App就會報出運行異常，並中止渲染（頁面白屏），故這兩個測試框架在組件較多時，測試數據不完整。這也就意味着，當頁面組件太多時，沒法使用這2個框架。

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

另外，kbone官網有以下介紹：

kbone 是使用必定的性能損耗來換取更爲全面的 Web 端特性支持。

故taro next、kbone的測試數據，明顯和taro 2.0、uni-app不是一個量級的。

若是你的應用是長列表場景，那taro next、kbone就明顯不太合適。

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

這個問題在去年的測評中，已解釋過。爲了不新同窗迷惑，這裏再次說明一下。

微信原生框架耗時主要在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
    }) //全量數據，發送數據到視圖層
}

開發者使用微信原生框架，徹底能夠本身優化，精簡傳遞數據（每次僅傳遞變化的20條數據），好比修改以下：

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

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

從測試結果可看出：

通過開發者手動優化，微信原生框架可達到更好的性能；
uni-app相比微信原生，性能接近，算是一個數量級；而且隨着數據量增長，性能消耗增長不明顯，從438到454，只有16毫秒的變化
taro 2.0隨着數據量越大，性能損耗隨着增大，從595到790，有將近200毫秒的變化；
taro next和kbone相比之下，差距就比較大了。

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

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

說明3：爲什麼今年的性能測試數據和去年的不一樣？

細心的同窗會發現，一樣的測試手機，一樣的測試代碼，爲什麼今年的性能數據會比去年的數據有大幅提高？

taro、uni-app及微信原生，三個框架的數據都有大幅提高，400條記錄時，至少都有300毫秒的優化
uni-app及優化後的微信原生，隨着數據量的增長，耗時數據變化並不明顯，但去年是很明顯的線性增加

其實，經過微信原生工程的數據對比，就能得出結論：2019年，微信針對小程序運行時作了大幅性能優化。

這對開發者來講應該是個好消息，小程序性能體驗更佳，可承載更好的用戶業務。

複雜長列表加載下一頁評測結論：微信原生開發(手動優化) ~ uni-app > 微信原生開發(未手動優化) ~ taro 2.0 > taro next > kbone

點贊組件響應速度

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

測試方式：

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

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

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

測試結果數聽說明：

taro next/kbone 測試數據不完整的緣由同上，在組件較多時，頁面已經再也不渲染了
taro 2.0版本、uni-app和微信原生在點贊組件上的性能體驗接近，但taro next和kbone有較大的性能差距，這個也是由於動態運行時框架致使的。

組件數據更新性能測評：uni-app ~ taro 2.0 > taro next > kbone

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

微信原生開發(手動優化) ~ uni-app > 微信原生開發(未手動優化) ~ taro 2.0 > taro next > kbone

跨端支持

這三個框架都是爲了解決平臺同構問題，跨端的比較是必需的。

taro 和 uni-app 相對比較成熟，支持主流的全部平臺。kbone 只支持微信小程序和 Web 端。咱們重點比較一下 taro 和 uni-app。

小程序平臺

taro 和 uni-app 均支持微信、支付寶、百度、字節跳動小程序，功能基本能夠拉齊。

雙方都有很多大廠案例，taro有京東、貨拉拉、淘票票等公司小程序案例，uni-app有騰訊、華爲、vivo、聯想、中華英才網等公司小程序案例。

App平臺

能力方面

taro與微信小程序引擎拉齊度較低，不少功能須要開發者分別在iOS和Android上作原生開發才能實現。好比App端很常見的三方登陸、支付、分享等能力，taro並未封裝。

uni-app則在基礎引擎層面提供了豐富的能力，還提供了豐富的插件市場，可切實提高開發者的效率。

性能方面

taro在App端使用了react native的渲染引擎，雖然渲染層ui是原生的，但在實時交互和高響應要求的UI操做方面表現一直不佳，js層和視圖層的通訊損耗讓不少開發者深感無力。

uni-app的App引擎同時給開發者提供了原生渲染引擎和小程序引擎的雙選方案，而且因爲發明了renderjs技術，以及支持wxs、bindingx等技術，解決了js層和視圖層的通訊損耗問題，在高響應要求的UI操做方面有更好的性能表現。好比這類canvas動畫：

開發體驗方面

taro的開發者需自行搭建iOS/Android開發環境，比較繁瑣，（官方原文地址）：

uni-app能夠作到讓前端開發者不依賴原生工程師獨立完成App。其開發的小程序，能夠更平滑的變成可商用的App。

使用跨平臺開發的核心訴求在於提高效率，若是一個App的開發由前端、iOS、Android等3撥工程師協做完成，其實效率反而很是低。

另外，uni-app還提供了uni小程序sdk，這個工具能夠幫助原生App快速搭建本身的小程序平臺。這是其餘框架所未提供的。

H5平臺

taro的H5平臺在一年來的進步較多，可用性大幅提高。但相比於uni-app，目前仍然缺失對wxs和小程序組件的支持。

快應用

taro支持快應用的時間比uni-app早。

但快應用發展到2020年有了一些變化，uni-app針對新的形勢，提供了2個發行到快應用的方案（當前兩個版本都處於社區維護狀態）：

quickapp-vue版：使用 Vue開發快應用。此方案由小米主導，但華爲快應用暫不支持。
quickapp-light版：基於小程序架構的快應用（Light版），詳見https://www.hellohub.cn。此方案由華爲主導，但小米快應用暫不支持。

跨端靈活性

跨端開發，離不開條件編譯。由於不能用統一來抹殺各個平臺的特點。

優良的條件編譯能力對各端開發的靈活度相當重要，可讓開發者在共享和個性化之間遊刃有餘。

taro 、uni-app和 kbone 均支持在js代碼經過process.env判斷平臺，而後編寫平臺特有代碼。

taro額外支持統一接口的多端文件編碼方式，以及在樣式文件中使用ifdef條件編譯。

uni-app是全面可條件編譯的，目錄、文件、配置、組件、js、css，全部一切都可經過ifdef條件編譯。

跨端支持小結結論：uni-app > taro > kbone

開發體驗

taro、uni-app、kbone均支持cli模式，能夠在主流前端工具中開發，且基本都帶有d.ts的語法提示庫。三個框架均支持主流的vue或react語法，配套的ide工具鏈較豐富，着色、校驗、格式化完善。

相比微信原生，這三個開發框架的開發體驗都更爲優秀。

但在開發工具維度上，明顯高出一截的框架是uni-app，其出品公司同時也是HBuilderX的出品公司DCloud.io，HBuilderX爲uni-app作了不少優化，代碼提示、轉到定義、easycom、運行調試...故uni-app的開發效率、易用性非其餘框架可及。

開發體驗維度，對比結果：uni-app > taro,kbone

serverless/雲開發

serverless是目前煊赫一時的一個概念，被稱爲下一代的雲技術，是真正的」雲「。

微信率先將 serverless 技術引入小程序開發領域，即雲開發，幫助開發者雲端一體的完成業務。隨後，支付寶、百度都上線了本身的雲開發。根據微信公開的數據，已經有50萬開發者在使用微信雲開發了。

不太小程序廠家主導的雲開發存在一個自然限制，就是和平臺綁定過緊，沒法和其它平臺共享數據。

咱們以微信雲開發爲例，若是你僅開發微信小程序，數據獨家存在微信平臺，那沒問題；但若是你同時還有App或其餘家小程序，此時微信小程序的數據存儲在微信平臺，其它平臺的數據存儲在開發者本身的服務器上，此時就出現了數據割裂。假設一個用戶先使用小程序，我的數據存儲在微信平臺；有了粘性後升級到App，此時App端沒法讀取微信平臺的數據，則用戶就沒法查看以前在小程序上的歷史數據，甚至在App平臺須要從新註冊。這種狀況對開發者是不利的。

所以，跨端的 serverless 方案纔是開發者的最優解。

目前主流框架對雲開發的支持狀況：

Taro：僅支持微信小程序，詳見小程序雲開發模板
uni-app：DCloud 聯合阿里雲、騰訊雲，提供基於 serverless 模式和 js 編程的雲開發平臺，支持App/H5/小程序全部平臺，詳見uniCloud
kbone：僅支持微信小程序，詳見雲開發

serverless 維度上，uni-app大幅領先其它框架。

插件市場

一個開發框架可否成功，除了框架自身的高度產品化外，開發者生態的構建也相當重要。

uni-app 於2018年末率先推出插件市場，支持前端組件、js sdk、頁面模板、項目模板、原生插件等多種類型，且提供了讚揚、付費購買等手段，刺激輪子做者的創做激情。目前市場上已發佈插件接近1500個，衆多插件下載量都在萬次以上。

Taro 於 2019年5月上線物料市場，目前市場上已發佈物料90個；從熱門榜單來看，下載量並不大，下載最多的也就數百。

kbone目前尚未插件市場。

Tips:

插件數量及下載量數據採集時間爲 2020.04.03 16：00

插件市場維度，uni-app獨領風騷。

學習資源

除了各大框架官網外，開發者一般還會經過視頻教程、社區博客等方式系統學習。

相關學習資源的豐富程度，也能側面反映一個框架的受歡迎程度，故咱們採集了幾個三方站點的數據。

視頻教程

框架	騰訊課堂	網易雲課堂	慕課網
taro	4	1	2
uni-app	16	16	1

Tips：

視頻教程數據採集時間爲2020.04.05 22:00

開發交流

除了入門的學習資源，開發期的交流也很重要，這個咱們主要看官方組織的社區和交流羣。

社區論壇

uni-app 的問答社區，帖子豐富，沉澱較多；目前已沉澱2萬多相關帖子，每日更新帖子數百篇，月uv百萬。

對於習慣使用 github issue反饋問題的用戶，uni-app一樣支持，目前累計有1391個issues。

Taro 早期基於github issue進行產品Bug管理，目前累計已有近4898個issue；後於2019年5月上線開發者社區，和物料市場上線時間相同，目前沉澱1300+帖子，每日更新帖子在10個左右，相關數據計算方法以下：

帖子總數：Taro 社區頂部選擇板塊，計算每一個板塊下全部主題總數，以下圖。
每日更新帖子數：根據帖子列表中的最後回覆時間，計算24小時內有回覆或評論的主題總數

kbone 在微信開放社區中新增了一個Kbone官方框架的專區，因產品發佈較晚，目前只有一百多個帖子。

總結一下社區帖子及issue數據，狀況以下（採集時間爲 2020.04.03 23：00）：

交流羣

框架	微信羣	QQ羣	交流羣開發者（預估）
taro	16	-	8k
uni-app	20	40+	90k
kbone	-	1	0.5k

Tips:

Taro 有16個微信羣是根據 Taro 官網上顯示Taro 開發交流 15 羣已滿推論而出，每一個微信羣500人，交流羣人數： 500*16 = 8000人
uni-app 官網 QQ羣有35個，微信羣20個，還有十幾個專項QQ羣，其中有30個QQ羣達到2000人，交流羣人數： 30 2000 + 5 1000 + 20*500 + 5000 = 90000人
kbone 在 github 的 readme中有一個qq交流羣，申請加入時顯示500人已滿

除了交流羣外，DCloud對外公佈的uni-app的開發者數量達到百萬人，暫未看到taro和kbone公佈此類數據。

整體而言，開發交流維度比較結果以下：uni-app > taro > kbone