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

崔紅保發表於2020-04-16

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

這一年,小程式在使用者規模及商業化方面都取得了極大的成功。微信小程式日活超過3億,支付寶、百度、位元組跳動小程式的月活也紛紛超過3億。

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

這一年 mpvue 停止更新,Taro開始探索 taro nextuni-app 產品和生態持續完善,微信新推出了支援H5和微信小程式的 kbone 框架...

去年的深度橫評中很多老將已經退出江湖,一些新秀吸引眼球,因此,是時候來一波2020版的新橫評了。

評測目標篩選

跨端框架是一個重投入工作,在各框架的1年多的比拼中,很多框架因為投入不足而逐漸被開發者放棄,uni-apptaro依靠持續的大力度投入,成為了市場主流。

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

kbone 框架雖面世不久,但畢竟是微信官方釋出,關注的人不少,故本次將 kbone 加入評測目標。

所以,本次評測的物件(按釋出時間排序):

本次評測除了執行效能等實測資料外,儘可能得通過框架官網及github、掘金、騰訊課堂等三方社群公開採集資料,希望給大家一個綜合全面的評估依據。

功能實現

tarouni-app 是比較典型的多端框架,釋出到各個端均可。而 kbone 只支援微信小程式和H5。

tarouni-app 均將常用介面及元件封裝了成了跨端API和跨端元件,元件規範沿用微信小程式的規範,部分平臺特有API,這兩個框架亦有應對方案:

  • taro:支援與小程式程式碼混寫,可通過混寫的方式呼叫框架尚未封裝的小程式新增API
  • uni-app:支援條件編譯,可在條件編譯程式碼塊中,隨意呼叫各個平臺新增的API及元件

tarouni-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 nextkbone 採用的是動態渲染方案,這類方案在頁面複雜、元件較多時,會大量增加頁面 dom 節點數量,甚至超出微信的 dom 節點數限制(如下告警資訊)。我們在 紅米手機(Redmi 6 Pro)上實測,頁面元件超過600個時,taro nextkbone 實現的仿微博App就會報出執行異常,並停止渲染(頁面白屏),故這兩個測試框架在元件較多時,測試資料不完整。這也就意味著,當頁面元件太多時,無法使用這2個框架。

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

另外,kbone官網有如下介紹:

kbone 是使用一定的效能損耗來換取更為全面的 Web 端特性支援。

taro nextkbone的測試資料,明顯和taro 2.0uni-app不是一個量級的。

如果你的應用是長列表場景,那taro nextkbone就明顯不太合適。

說明2:為什麼測試資料顯示uni-app 會比微信原生框架的效能略好呢?

這個問題在去年的測評中,已解釋過。為了避免新同學迷惑,這裡再次說明一下。

微信原生框架耗時主要在setData呼叫上,開發者若不單獨優化,則每次都會傳遞大量資料;而 uni-apptaro 都在呼叫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 nextkbone相比之下,差距就比較大了。

這個結果,和web開發類似,web開發也有原生js開發、vuereact框架等情況。如果不做特殊優化,原生js寫的網頁,效能經常還不如vuereact框架的效能。

也恰恰是因為Vuereact框架的優秀,效能好,開發體驗好,所以原生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

跨端支援

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

tarouni-app 相對比較成熟,支援主流的所有平臺。kbone 只支援微信小程式和 Web 端。我們重點比較一下 tarouni-app

小程式平臺

tarouni-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。此方案由華為主導,但小米快應用暫不支援。

跨端靈活性

跨端開發,離不開條件編譯。因為不能用統一來抹殺各個平臺的特色。

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

tarouni-appkbone 均支援在js程式碼通過process.env判斷平臺,然後編寫平臺特有程式碼。

taro額外支援統一介面的多端檔案編碼方式,以及在樣式檔案中使用ifdef條件編譯。

uni-app是全面可條件編譯的,目錄、檔案、配置、元件、js、css,所有一切均可通過ifdef條件編譯。

跨端支援小結結論:uni-app > taro > kbone

開發體驗

tarouni-appkbone均支援cli模式,可以在主流前端工具中開發,且基本都帶有d.ts的語法提示庫。三個框架均支援主流的vuereact語法,配套的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的開發者數量達到百萬人,暫未看到tarokbone公佈此類資料。

總體而言,開發交流維度比較結果如下: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-apptaro的百度指數對比圖:

結語

所有的評測都只是提供決策依據,最後的結果還是要依賴開發者的團隊技術棧、業務訴求、未來規劃等。

不過作為一篇評測文章的結語,我們還是要給出自己的建議:

  • 如果你熟悉React,不懂Vue.js,推薦Taro;
  • 如果你熟悉Vue.js,則推薦 uni-app;
  • 如果你已經有H5程式碼,只想增加微信小程式平臺,並且對效能要求不高,可以考慮kbone;
  • 如果你的業務涉及多端,更推薦 uni-app;
  • 如果你希望通過 serverless 方案快速上線業務,推薦 uni-app。

如有讀者認為本文中任何評測失真,歡迎在這裡報 issuse

相關文章