又是一年四月天，距離上次發(fā)布跨端開發(fā)框架深度橫評(píng)已過去整整一年。

這一年疹娶，小程序在用戶規(guī)模及商業(yè)化方面都取得了極大的成功寿谴。微信小程序日活超過3億，支付寶蛆挫、百度、字節(jié)跳動(dòng)小程序的月活也紛紛超過3億。

對(duì)應(yīng)小程序開發(fā)領(lǐng)域踱讨，這一年也發(fā)生了巨大變化。開發(fā)框架從單純的微信小程序開發(fā)砍的，過渡到多端框架成為標(biāo)配痹筛，進(jìn)一步提升開發(fā)效率成為開發(fā)者的強(qiáng)烈需求。

這一年 mpvue 停止更新廓鞠，Taro開始探索 taro next帚稠，uni-app 產(chǎn)品和生態(tài)持續(xù)完善，微信新推出了支持H5和微信小程序的 kbone 框架...

去年的深度橫評(píng)中很多老將已經(jīng)退出江湖床佳，一些新秀吸引眼球滋早，因此，是時(shí)候來一波2020版的新橫評(píng)了夕土。

評(píng)測(cè)目標(biāo)篩選

跨端框架是一個(gè)重投入工作馆衔，在各框架的1年多的比拼中，很多框架因?yàn)橥度氩蛔愣饾u被開發(fā)者放棄怨绣，uni-app和taro依靠持續(xù)的大力度投入角溃，成為了市場(chǎng)主流。

taro 在穩(wěn)定版的基礎(chǔ)之上篮撑，最近也推出了 taro next减细，這2個(gè)版本差異較大，本次會(huì)分別評(píng)測(cè)赢笨。

kbone 框架雖面世不久未蝌，但畢竟是微信官方發(fā)布驮吱，關(guān)注的人不少，故本次將 kbone 加入評(píng)測(cè)目標(biāo)萧吠。

所以左冬，本次評(píng)測(cè)的對(duì)象（按發(fā)布時(shí)間排序）：

• 微信原生開發(fā)
• taro，京東凹凸實(shí)驗(yàn)室出品纸型，官網(wǎng)地址：https://taro.jd.com/
• uni-app拇砰，DCloud出品，官網(wǎng)地址：https://uniapp.dcloud.net.cn
• kbone狰腌，騰訊微信團(tuán)隊(duì)出品除破，官網(wǎng)地址：https://wechat-miniprogram.github.io/kbone/docs/

本次評(píng)測(cè)除了運(yùn)行性能等實(shí)測(cè)數(shù)據(jù)外，盡可能得通過框架官網(wǎng)及github琼腔、掘金瑰枫、騰訊課堂等三方社區(qū)公開采集數(shù)據(jù)，希望給大家一個(gè)綜合全面的評(píng)估依據(jù)丹莲。

功能實(shí)現(xiàn)

taro 和 uni-app 是比較典型的多端框架光坝，發(fā)布到各個(gè)端均可。而 kbone 只支持微信小程序和H5圾笨。

taro 和 uni-app 均將常用接口及組件封裝了成了跨端API和跨端組件教馆，組件規(guī)范沿用微信小程序的規(guī)范，部分平臺(tái)特有API擂达，這兩個(gè)框架亦有應(yīng)對(duì)方案：

• taro：支持與小程序代碼混寫土铺，可通過混寫的方式調(diào)用框架尚未封裝的小程序新增API
• uni-app：支持條件編譯，可在條件編譯代碼塊中板鬓，隨意調(diào)用各個(gè)平臺(tái)新增的API及組件

taro 和 uni-app 可以不受限的調(diào)用各家小程序平臺(tái)所有的API及組件悲敷。

kbone 沿用web的開發(fā)習(xí)慣，使用html標(biāo)簽及js api俭令；涉及微信特有api時(shí)后德，可通過process.env.isMiniprogram判斷環(huán)境，然后編寫微信原生代碼抄腔。對(duì)于html中沒有標(biāo)簽可替代的微信內(nèi)置組件（如swiper）瓢湃，需要使用 wx-component 標(biāo)簽或者使用 wx- 前綴，這樣的內(nèi)置組件會(huì)被包裹一層自定義組件赫蛇，帶來相應(yīng)的性能開銷绵患。

除了接口、組件之外悟耘，我們以微信小程序?yàn)槔潋規(guī)讉€(gè)典型能力對(duì)比框架支持度：

補(bǔ)充說明：

• 如果在 Taro 項(xiàng)目引用了小程序原生的第三方組件，那么該項(xiàng)目將不再具備多端轉(zhuǎn)換的能力，例如筏勒，如果使用了微信小程序的第三方組件移迫，那么項(xiàng)目只能轉(zhuǎn)換成微信小程序，轉(zhuǎn)義成其他平臺(tái)會(huì)失效管行，詳見taro官網(wǎng)
• uni-app 中使用微信自定義組件的話厨埋，支持編譯發(fā)行到App/H5/微信小程序/QQ小程序4個(gè)平臺(tái)，詳見uni-app官網(wǎng)
• taro 不支持 wxs 的依據(jù)：#2959
• kbone 不支持微信三方插件的依據(jù)：#58病瞳；不支持wxs的依據(jù)：#129
• 云開發(fā)在微信平臺(tái)揽咕，三個(gè)框架都支持，但 taro/kbone僅支持微信小程序平臺(tái)套菜，uni-app支持App/H5/小程序所有平臺(tái)使用云開發(fā)，詳見下方 serverless/云開發(fā) 章節(jié)设易。

wxs是提升性能體驗(yàn)的重要利器逗柴，除了微信小程序的wxs外，還有支付寶的SJS顿肺、百度的Filter戏溺，這些高級(jí)技術(shù) uni-app 均完善支持。參考：謎之wxs屠尊，uni-app如何用它大幅提升性能

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

運(yùn)行性能

我們繼續(xù)沿用去年的測(cè)試模型旷祸，看看一年來，各家小程序開發(fā)框架的性能是否有提升讼昆。詳細(xì)如下：

• 開發(fā)內(nèi)容：開發(fā)一個(gè)仿微博小程序首頁的復(fù)雜長(zhǎng)列表托享，支持下拉刷新、上拉翻頁浸赫、點(diǎn)贊闰围。

• 界面如下：

  
  
  image

• 開發(fā)版本：一共開發(fā)了5個(gè)版本，包括微信原生版既峡、taro版羡榴、uni-app版、kbone版运敢，按照官網(wǎng)指引通過cli方式默認(rèn)安裝校仑。

• taro 目前穩(wěn)定版本是2.0版，但近期在宣傳跨框架的taro next传惠，故我們基于同樣的 react代碼迄沫，同時(shí)測(cè)試了taro 2.0 和 taro next 兩個(gè)版本的數(shù)據(jù)。

• 測(cè)試代碼開源（Github倉庫地址：https://github.com/dcloudio/test-framework）涉枫，
  Tips:若有同學(xué)覺得測(cè)試代碼寫法欠妥邢滑，歡迎提交 PR 或 Issus

• 測(cè)試機(jī)型：紅米 Redmi 6 Pro、MIUI 11.0.5 穩(wěn)定版（最新版）、微信版本 7.0.12（最新版）

• 測(cè)試環(huán)境：每個(gè)框架開始測(cè)試前困后，殺掉各App進(jìn)程乐纸、清空內(nèi)存，保證測(cè)試機(jī)環(huán)境基本一致摇予；每次從本地讀取靜態(tài)數(shù)據(jù)汽绢，屏蔽網(wǎng)絡(luò)差異。

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

長(zhǎng)列表加載

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

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

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

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

image

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

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

image

說明：以400條微博列表為例业筏，從頁面空列表開始憔杨，每隔1秒觸發(fā)一次上拉加載（新增20條微博），記錄單次耗時(shí)蒜胖，觸發(fā)20次后停止（頁面達(dá)到400條微博）消别，計(jì)算這20次的平均耗時(shí)，結(jié)果微信原生在這20次 觸發(fā)上拉 -> 渲染完成 的平均耗時(shí)為538毫秒台谢，最快的uni-app是446毫秒寻狂，最慢的kbone是4057毫秒

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

說明1：為何 taro next/kbone 測(cè)試數(shù)據(jù)不完整?

因?yàn)?taro next 和kbone 采用的是動(dòng)態(tài)渲染方案，這類方案在頁面復(fù)雜、組件較多時(shí)纠亚，會(huì)大量增加頁面 dom 節(jié)點(diǎn)數(shù)量塘慕，甚至超出微信的 dom 節(jié)點(diǎn)數(shù)限制（如下告警信息）。我們?cè)?紅米手機(jī)（Redmi 6 Pro）上實(shí)測(cè)蒂胞，頁面組件超過600個(gè)時(shí)图呢，taro next、kbone 實(shí)現(xiàn)的仿微博App就會(huì)報(bào)出運(yùn)行異常骗随，并停止渲染（頁面白屏）蛤织，故這兩個(gè)測(cè)試框架在組件較多時(shí)，測(cè)試數(shù)據(jù)不完整鸿染。這也就意味著指蚜，當(dāng)頁面組件太多時(shí)，無法使用這2個(gè)框架牡昆。

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

另外姚炕，kbone官網(wǎng)有如下介紹：

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

故taro next丢烘、kbone的測(cè)試數(shù)據(jù)，明顯和taro 2.0些椒、uni-app不是一個(gè)量級(jí)的播瞳。

如果你的應(yīng)用是長(zhǎng)列表場(chǎng)景，那taro next免糕、kbone就明顯不太合適赢乓。

說明2：為什么測(cè)試數(shù)據(jù)顯示uni-app 會(huì)比微信原生框架的性能略好呢？

這個(gè)問題在去年的測(cè)評(píng)中石窑，已解釋過牌芋。為了避免新同學(xué)迷惑，這里再次說明一下松逊。

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

例如當(dāng)前頁面有20條數(shù)據(jù)耐亏，觸發(fā)上拉加載時(shí)，會(huì)新加載20條數(shù)據(jù)沪斟，此時(shí)原生框架通過如下代碼測(cè)試時(shí)广辰，setData會(huì)傳輸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)化择吊，精簡(jiǎn)傳遞數(shù)據(jù)（每次僅傳遞變化的20條數(shù)據(jù)）李根，比如修改如下：

data: {
    listData: []
},
onReachBottom() { //上拉加載
    // 通過長(zhǎng)度獲取下一次渲染的索引
    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)化修改后朱巨，再次測(cè)試，微信原生框架性能數(shù)據(jù)如下：

image

從測(cè)試結(jié)果可看出：

• 經(jīng)過開發(fā)者手動(dòng)優(yōu)化枉长，微信原生框架可達(dá)到更好的性能冀续；
• uni-app相比微信原生，性能接近必峰，算是一個(gè)數(shù)量級(jí)洪唐；并且隨著數(shù)據(jù)量增加，性能消耗增加不明顯吼蚁，從438到454凭需，只有16毫秒的變化
• taro 2.0隨著數(shù)據(jù)量越大，性能損耗隨著增大肝匆，從595到790粒蜈，有將近200毫秒的變化；
• taro next和kbone相比之下旗国，差距就比較大了枯怖。

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

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

說明3：為何今年的性能測(cè)試數(shù)據(jù)和去年的不同肖油？

細(xì)心的同學(xué)會(huì)發(fā)現(xiàn)，同樣的測(cè)試手機(jī)臂港，同樣的測(cè)試代碼森枪，為何今年的性能數(shù)據(jù)會(huì)比去年的數(shù)據(jù)有大幅提升视搏？

• taro、uni-app及微信原生县袱，三個(gè)框架的數(shù)據(jù)都有大幅提升浑娜，400條記錄時(shí)，至少都有300毫秒的優(yōu)化
• uni-app及優(yōu)化后的微信原生式散，隨著數(shù)據(jù)量的增加筋遭，耗時(shí)數(shù)據(jù)變化并不明顯，但去年是很明顯的線性增長(zhǎng)

其實(shí)暴拄，通過微信原生工程的數(shù)據(jù)對(duì)比漓滔，就能得出結(jié)論：2019年，微信針對(duì)小程序運(yùn)行時(shí)做了大幅性能優(yōu)化乖篷。

這對(duì)開發(fā)者來說應(yīng)該是個(gè)好消息响驴，小程序性能體驗(yàn)更佳，可承載更好的用戶業(yè)務(wù)撕蔼。

復(fù)雜長(zhǎng)列表加載下一頁評(píng)測(cè)結(jié)論：微信原生開發(fā)(手動(dòng)優(yōu)化) ~ uni-app > 微信原生開發(fā)(未手動(dòng)優(yōu)化) ~ taro 2.0 > taro next > kbone

點(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é)果如下：

image

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

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

• taro next/kbone 測(cè)試數(shù)據(jù)不完整的原因同上，在組件較多時(shí)员寇，頁面已經(jīng)不再渲染了
• taro 2.0版本弄慰、uni-app和微信原生在點(diǎn)贊組件上的性能體驗(yàn)接近，但taro next和kbone有較大的性能差距蝶锋，這個(gè)也是因?yàn)閯?dòng)態(tài)運(yùn)行時(shí)框架導(dǎo)致的陆爽。

組件數(shù)據(jù)更新性能測(cè)評(píng)：uni-app ~ taro 2.0 > taro next > kbone

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

微信原生開發(fā)(手動(dòng)優(yōu)化) ~ uni-app > 微信原生開發(fā)(未手動(dòng)優(yōu)化) ~ taro 2.0 > taro next > kbone

跨端支持

這三個(gè)框架都是為了解決平臺(tái)同構(gòu)問題，跨端的比較是必需的驴剔。

taro 和 uni-app 相對(duì)比較成熟省古，支持主流的所有平臺(tái)。kbone 只支持微信小程序和 Web 端丧失。我們重點(diǎn)比較一下 taro 和 uni-app豺妓。

小程序平臺(tái)

taro 和 uni-app 均支持微信、支付寶布讹、百度琳拭、字節(jié)跳動(dòng)小程序，功能基本可以拉齊炒事。

雙方都有不少大廠案例臀栈，taro有京東、貨拉拉挠乳、淘票票等公司小程序案例权薯，uni-app有騰訊、華為睡扬、vivo盟蚣、聯(lián)想、中華英才網(wǎng)等公司小程序案例卖怜。

App平臺(tái)

• 能力方面

taro與微信小程序引擎拉齊度較低屎开，很多功能需要開發(fā)者分別在iOS和Android上做原生開發(fā)才能實(shí)現(xiàn)。比如App端很常見的三方登錄马靠、支付奄抽、分享等能力，taro并未封裝甩鳄。

uni-app則在基礎(chǔ)引擎層面提供了豐富的能力逞度，還提供了豐富的插件市場(chǎng)，可切實(shí)提升開發(fā)者的效率妙啃。

• 性能方面

taro在App端使用了react native的渲染引擎档泽，雖然渲染層ui是原生的，但在實(shí)時(shí)交互和高響應(yīng)要求的UI操作方面表現(xiàn)一直不佳揖赴，js層和視圖層的通信損耗讓很多開發(fā)者深感無力馆匿。

uni-app的App引擎同時(shí)給開發(fā)者提供了原生渲染引擎和小程序引擎的雙選方案，并且由于發(fā)明了renderjs技術(shù)燥滑，以及支持wxs渐北、bindingx等技術(shù)，解決了js層和視圖層的通信損耗問題突倍，在高響應(yīng)要求的UI操作方面有更好的性能表現(xiàn)腔稀。比如這類canvas動(dòng)畫：

image

• 開發(fā)體驗(yàn)方面

taro的開發(fā)者需自行搭建iOS/Android開發(fā)環(huán)境盆昙，比較繁瑣，（官方原文地址）：

uni-app可以做到讓前端開發(fā)者不依賴原生工程師獨(dú)立完成App焊虏。其開發(fā)的小程序淡喜，可以更平滑的變成可商用的App。

使用跨平臺(tái)開發(fā)的核心訴求在于提升效率诵闭，如果一個(gè)App的開發(fā)由前端炼团、iOS、Android等3撥工程師協(xié)作完成疏尿，其實(shí)效率反而非常低瘟芝。

另外，uni-app還提供了uni小程序sdk褥琐，這個(gè)工具可以幫助原生App快速搭建自己的小程序平臺(tái)锌俱。這是其他框架所未提供的。

H5平臺(tái)

taro的H5平臺(tái)在一年來的進(jìn)步較多敌呈，可用性大幅提升贸宏。但相比于uni-app，目前仍然缺失對(duì)wxs和小程序組件的支持磕洪。

快應(yīng)用

taro支持快應(yīng)用的時(shí)間比uni-app早吭练。

但快應(yīng)用發(fā)展到2020年有了一些變化，uni-app針對(duì)新的形勢(shì)析显，提供了2個(gè)發(fā)行到快應(yīng)用的方案（當(dāng)前兩個(gè)版本都處于社區(qū)維護(hù)狀態(tài)）：

• quickapp-vue版：使用 Vue開發(fā)快應(yīng)用鲫咽。此方案由小米主導(dǎo)，但華為快應(yīng)用暫不支持谷异。
• quickapp-light版：基于小程序架構(gòu)的快應(yīng)用（Light版）分尸，詳見https://www.hellohub.cn。此方案由華為主導(dǎo)歹嘹，但小米快應(yīng)用暫不支持寓落。

跨端靈活性

跨端開發(fā)，離不開條件編譯荞下。因?yàn)椴荒苡媒y(tǒng)一來抹殺各個(gè)平臺(tái)的特色。

優(yōu)良的條件編譯能力對(duì)各端開發(fā)的靈活度至關(guān)重要史飞，可以讓開發(fā)者在共享和個(gè)性化之間游刃有余尖昏。

taro 、uni-app和 kbone 均支持在js代碼通過process.env判斷平臺(tái)构资，然后編寫平臺(tái)特有代碼抽诉。

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

uni-app是全面可條件編譯的迹淌，目錄河绽、文件、配置唉窃、組件耙饰、js、css纹份，所有一切均可通過ifdef條件編譯苟跪。

跨端支持小結(jié)結(jié)論：uni-app > taro > kbone

開發(fā)體驗(yàn)

taro、uni-app蔓涧、kbone均支持cli模式件已，可以在主流前端工具中開發(fā)，且基本都帶有d.ts的語法提示庫元暴。三個(gè)框架均支持主流的vue或react語法篷扩，配套的ide工具鏈較豐富，著色茉盏、校驗(yàn)鉴未、格式化完善。

相比微信原生援岩，這三個(gè)開發(fā)框架的開發(fā)體驗(yàn)都更為優(yōu)秀歼狼。

但在開發(fā)工具維度上，明顯高出一截的框架是uni-app享怀，其出品公司同時(shí)也是HBuilderX的出品公司DCloud.io羽峰，HBuilderX為uni-app做了很多優(yōu)化，代碼提示添瓷、轉(zhuǎn)到定義梅屉、easycom、運(yùn)行調(diào)試...故uni-app的開發(fā)效率鳞贷、易用性非其他框架可及坯汤。

開發(fā)體驗(yàn)維度，對(duì)比結(jié)果：uni-app > taro,kbone

serverless/云開發(fā)

serverless是目前炙手可熱的一個(gè)概念搀愧，被稱為下一代的云技術(shù)惰聂，是真正的”云“。

微信率先將 serverless 技術(shù)引入小程序開發(fā)領(lǐng)域咱筛，即云開發(fā)搓幌，幫助開發(fā)者云端一體的完成業(yè)務(wù)。隨后迅箩，支付寶溉愁、百度都上線了自己的云開發(fā)。根據(jù)微信公開的數(shù)據(jù)饲趋，已經(jīng)有50萬開發(fā)者在使用微信云開發(fā)了拐揭。

不過小程序廠家主導(dǎo)的云開發(fā)存在一個(gè)天然限制撤蟆，就是和平臺(tái)綁定過緊，無法和其它平臺(tái)共享數(shù)據(jù)堂污。

我們以微信云開發(fā)為例家肯，如果你僅開發(fā)微信小程序，數(shù)據(jù)獨(dú)家存在微信平臺(tái)敷鸦，那沒問題息楔；但如果你同時(shí)還有App或其他家小程序，此時(shí)微信小程序的數(shù)據(jù)存儲(chǔ)在微信平臺(tái)扒披，其它平臺(tái)的數(shù)據(jù)存儲(chǔ)在開發(fā)者自己的服務(wù)器上值依，此時(shí)就出現(xiàn)了數(shù)據(jù)割裂。假設(shè)一個(gè)用戶先使用小程序碟案，個(gè)人數(shù)據(jù)存儲(chǔ)在微信平臺(tái)愿险；有了粘性后升級(jí)到App，此時(shí)App端無法讀取微信平臺(tái)的數(shù)據(jù)价说，則用戶就無法查看之前在小程序上的歷史數(shù)據(jù)辆亏，甚至在App平臺(tái)需要重新注冊(cè)。這種情況對(duì)開發(fā)者是不利的鳖目。

因此扮叨，跨端的 serverless 方案才是開發(fā)者的最優(yōu)解。

目前主流框架對(duì)云開發(fā)的支持情況：

• Taro：僅支持微信小程序领迈，詳見小程序云開發(fā)模板
• uni-app：DCloud 聯(lián)合阿里云彻磁、騰訊云，提供基于 serverless 模式和 js 編程的云開發(fā)平臺(tái)狸捅，支持App/H5/小程序所有平臺(tái)衷蜓，詳見uniCloud
• kbone：僅支持微信小程序，詳見云開發(fā)

serverless 維度上尘喝，uni-app大幅領(lǐng)先其它框架磁浇。

插件市場(chǎng)

一個(gè)開發(fā)框架能否成功，除了框架自身的高度產(chǎn)品化外朽褪，開發(fā)者生態(tài)的構(gòu)建也至關(guān)重要置吓。

uni-app 于2018年底率先推出插件市場(chǎng)，支持前端組件缔赠、js sdk交洗、頁面模板、項(xiàng)目模板橡淑、原生插件等多種類型，且提供了贊賞咆爽、付費(fèi)購買等手段梁棠，刺激輪子作者的創(chuàng)作激情置森。目前市場(chǎng)上已發(fā)布插件接近1500個(gè)，眾多插件下載量都在萬次以上符糊。

Taro 于 2019年5月上線物料市場(chǎng)凫海，目前市場(chǎng)上已發(fā)布物料90個(gè)；從熱門榜單來看男娄，下載量并不大行贪，下載最多的也就數(shù)百。

kbone目前還沒有插件市場(chǎng)模闲。

image

Tips:

• 插件數(shù)量及下載量數(shù)據(jù)采集時(shí)間為 2020.04.03 16：00

插件市場(chǎng)維度建瘫，uni-app獨(dú)領(lǐng)風(fēng)騷。

學(xué)習(xí)資源

除了各大框架官網(wǎng)外尸折，開發(fā)者通常還會(huì)通過視頻教程啰脚、社區(qū)博客等方式系統(tǒng)學(xué)習(xí)。

相關(guān)學(xué)習(xí)資源的豐富程度实夹，也能側(cè)面反映一個(gè)框架的受歡迎程度橄浓，故我們采集了幾個(gè)三方站點(diǎn)的數(shù)據(jù)。

視頻教程

Tips：

• 視頻教程數(shù)據(jù)采集時(shí)間為2020.04.05 22:00

開發(fā)交流

除了入門的學(xué)習(xí)資源亮航，開發(fā)期的交流也很重要荸实，這個(gè)我們主要看官方組織的社區(qū)和交流群。

社區(qū)論壇

uni-app 的問答社區(qū)缴淋，帖子豐富准给，沉淀較多；目前已沉淀2萬多相關(guān)帖子宴猾，每日更新帖子數(shù)百篇圆存，月uv百萬。

對(duì)于習(xí)慣使用 github issue反饋問題的用戶仇哆，uni-app同樣支持沦辙，目前累計(jì)有1391個(gè)issues。

Taro 早期基于github issue進(jìn)行產(chǎn)品Bug管理讹剔，目前累計(jì)已有近4898個(gè)issue油讯；后于2019年5月上線開發(fā)者社區(qū)，和物料市場(chǎng)上線時(shí)間相同延欠，目前沉淀1300+帖子陌兑，每日更新帖子在10個(gè)左右，相關(guān)數(shù)據(jù)計(jì)算方法如下：

• 帖子總數(shù)：Taro 社區(qū)頂部選擇板塊由捎，計(jì)算每個(gè)板塊下所有主題總數(shù)兔综，如下圖。
• 每日更新帖子數(shù)：根據(jù)帖子列表中的最后回復(fù)時(shí)間，計(jì)算24小時(shí)內(nèi)有回復(fù)或評(píng)論的主題總數(shù)

image

kbone 在微信開放社區(qū)中新增了一個(gè)Kbone官方框架的專區(qū)软驰，因產(chǎn)品發(fā)布較晚涧窒，目前只有一百多個(gè)帖子。

總結(jié)一下社區(qū)帖子及issue數(shù)據(jù)锭亏，情況如下（采集時(shí)間為 2020.04.03 23：00）：

image

交流群

Tips:

• Taro 有16個(gè)微信群是根據(jù) Taro 官網(wǎng)上顯示Taro 開發(fā)交流 15 群 已滿推論而出纠吴，每個(gè)微信群500人，交流群人數(shù)： 500*16 = 8000人
• uni-app 官網(wǎng) QQ群有35個(gè)慧瘤，微信群20個(gè)戴已，還有十幾個(gè)專項(xiàng)QQ群，其中有30個(gè)QQ群達(dá)到2000人锅减，交流群人數(shù)： 30 * 2000 + 5* 1000 + 20*500 + 5000 = 90000人
• kbone 在 github 的 readme中有一個(gè)qq交流群糖儡，申請(qǐng)加入時(shí)顯示500人已滿

除了交流群外，DCloud對(duì)外公布的uni-app的開發(fā)者數(shù)量達(dá)到百萬人上煤，暫未看到taro和kbone公布此類數(shù)據(jù)休玩。

總體而言，開發(fā)交流維度比較結(jié)果如下：uni-app > taro > kbone

其它指標(biāo)

github

在開源社區(qū)方面劫狠，Taro做的還是非常成功的拴疤，它吸引了更多開發(fā)者為其貢獻(xiàn)代碼、文檔独泞。

百度指數(shù)

通過index.baidu.com呐矾，可查看主流框架的搜索指數(shù)，它代表了網(wǎng)友的搜索量和相關(guān)文章的收錄量懦砂。目前kbone尚未收錄到百度指數(shù)中蜒犯，如下是近期 uni-app 和 taro的百度指數(shù)對(duì)比圖：

image

結(jié)語

所有的評(píng)測(cè)都只是提供決策依據(jù)，最后的結(jié)果還是要依賴開發(fā)者的團(tuán)隊(duì)技術(shù)棧荞膘、業(yè)務(wù)訴求罚随、未來規(guī)劃等。

不過作為一篇評(píng)測(cè)文章的結(jié)語羽资，我們還是要給出自己的建議：

• 如果你熟悉React淘菩，不懂Vue.js骨望，推薦Taro涤伐；
• 如果你熟悉Vue.js，則推薦 uni-app罪既；
• 如果你已經(jīng)有H5代碼腹暖，只想增加微信小程序平臺(tái)汇在，并且對(duì)性能要求不高，可以考慮kbone脏答；
• 如果你的業(yè)務(wù)涉及多端糕殉，更推薦 uni-app亩鬼；
• 如果你希望通過 serverless 方案快速上線業(yè)務(wù)，推薦 uni-app阿蝶。

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