小程序跨端框架(taro/uni-app/kbone)橫評之2020版
微信竟然推出了跨端的kbone,說明跨端的開發已經深入人心;又是新的一年過去了,小程序開發領域又有哪些新的變化?我們來看如下最新的評測文章,可惜沒有wepy 2.0的測評。
本文經授權轉載,如下爲原文,enjoy!
又是一年四月天,距離上次發佈跨端開發框架深度橫評已過去整整一年。
這一年,小程序在用戶規模及商業化方面都取得了極大的成功。微信小程序日活超過3億,支付寶、百度、字節跳動小程序的月活也紛紛超過3億。
對應小程序開發領域,這一年也發生了巨大變化。開發框架從單純的微信小程序開發,過渡到多端框架成爲標配,進一步提升開發效率成爲開發者的強烈需求。
這一年 mpvue
停止更新,Taro
開始探索 taro next
,uni-app
產品和生態持續完善,微信新推出了支持H5和微信小程序的 kbone
框架...
去年的深度橫評中很多老將已經退出江湖,一些新秀吸引眼球,因此,是時候來一波2020版的新橫評了。
評測目標篩選
跨端框架是一個重投入工作,在各框架的1年多的比拼中,很多框架因爲投入不足而逐漸被開發者放棄,uni-app
和taro
依靠持續的大力度投入,成爲了市場主流。
taro
在穩定版的基礎之上,最近也推出了 taro next
,這2個版本差異較大,本次會分別評測。
kbone
框架雖面世不久,但畢竟是微信官方發佈,關注的人不少,故本次將 kbone
加入評測目標。
所以,本次評測的對象(按發佈時間排序):
- 微信原生開發
- taro,京東凹凸實驗室出品,官網地址:https://taro.jd.com/
- uni-app,DCloud出品,官網地址:https://uniapp.dcloud.net.cn
- kbone,騰訊微信團隊出品,官網地址:https://wechat-miniprogram.github.io/kbone/docs/
本次評測除了運行性能等實測數據外,儘可能得通過框架官網及github、掘金、騰訊課堂等三方社區公開採集數據,希望給大家一個綜合全面的評估依據。
功能實現
taro
和 uni-app
是比較典型的多端框架,發佈到各個端均可。而 kbone
只支持微信小程序和H5。
taro
和 uni-app
均將常用接口及組件封裝了成了跨端API和跨端組件,組件規範沿用微信小程序的規範,部分平臺特有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
其它指標
github
框架 | star | 貢獻者 |
---|---|---|
taro | 24.6k | 122 |
uni-app | 19.7k | 72 |
kbone | 2.7k | 7 |
在開源社區方面,Taro
做的還是非常成功的,它吸引了更多開發者爲其貢獻代碼、文檔。
百度指數
通過index.baidu.com,可查看主流框架的搜索指數,它代表了網友的搜索量和相關文章的收錄量。目前kbone
尚未收錄到百度指數中,如下是近期 uni-app
和 taro
的百度指數對比圖:
結語
所有的評測都只是提供決策依據,最後的結果還是要依賴開發者的團隊技術棧、業務訴求、未來規劃等。
不過作爲一篇評測文章的結語,我們還是要給出自己的建議:
- 如果你熟悉React,不懂Vue.js,推薦Taro;
- 如果你熟悉Vue.js,則推薦 uni-app;
- 如果你已經有H5代碼,只想增加微信小程序平臺,並且對性能要求不高,可以考慮kbone;
- 如果你的業務涉及多端,更推薦 uni-app;
- 如果你希望通過 serverless 方案快速上線業務,推薦 uni-app。
如有讀者認爲本文中任何評測失真,歡迎在這裏報 issuse。