自 2017-1-9微信小程序誕生以來(lái)煤篙，歷經(jīng)2年多的迭代升級(jí)，已有數(shù)百萬(wàn)小程序上線毁腿，成為繼Web辑奈、iOS、Android之后狸棍，第四大主流開(kāi)發(fā)技術(shù)身害。

與之相隨，小程序的開(kāi)發(fā)生態(tài)也在蓬勃發(fā)展草戈，從最初的微信原生開(kāi)發(fā)塌鸯，到wepy、mpvue唐片、taro丙猬、uni-app等框架依次出現(xiàn)，從刀耕火種演進(jìn)為現(xiàn)代化開(kāi)發(fā)费韭，生態(tài)越來(lái)越豐富茧球。

選擇多了，問(wèn)題也就來(lái)了星持，開(kāi)發(fā)小程序抢埋，該用原生還是選擇三方框架？

首先，微信原生開(kāi)發(fā)的槽點(diǎn)大多集中如下：

1. 原生開(kāi)發(fā)對(duì)Node揪垄、預(yù)編譯器穷吮、webpack支持不好，影響開(kāi)發(fā)效率和工程構(gòu)建流程
2. 微信定義了一個(gè)不倫不類的語(yǔ)法饥努，不如正經(jīng)學(xué)vue捡鱼、react，學(xué)會(huì)了全端通用酷愧，而不是只為微信小程序
3. vue/react生態(tài)里有太多周邊工具驾诈，可以提高開(kāi)發(fā)效率，比如ide溶浴、校驗(yàn)器乍迄、三方庫(kù)。戳葵。就乓。
4. 微信那個(gè)ide和專業(yè)編輯器相比實(shí)在不好用

同時(shí)，開(kāi)發(fā)者對(duì)三方框架拱烁，又總是有各種顧慮：

1. 怕性能不如原生
2. 怕有些功能框架實(shí)現(xiàn)不了生蚁，只能用原生
3. 怕框架不穩(wěn)定，跳到坑里
4. 以及諸多三方框架戏自，到底該用哪個(gè)

• 面對(duì)如此糾結(jié)的場(chǎng)景邦投，不少熱心開(kāi)發(fā)者發(fā)布評(píng)測(cè)文章分享經(jīng)驗(yàn)，但感覺(jué)眾說(shuō)紛紜擅笔，過(guò)期信息太多志衣。缺少一份非常專業(yè)的、深度的猛们，或者按如今流行的話來(lái)講念脯，“硬核的”評(píng)測(cè)報(bào)告。

做評(píng)測(cè)報(bào)告這件事弯淘，不同于泛泛經(jīng)驗(yàn)分享绿店，其實(shí)非常花費(fèi)時(shí)間庐橙。它需要：

• 你必須成為每一個(gè)框架的專業(yè)使用人員假勿，而不是淺淺的了解一下這些框架
• 真實(shí)的動(dòng)手寫多個(gè)平臺(tái)的測(cè)試?yán)容^各個(gè)平臺(tái)的功能态鳖、性能转培，了解他們的社區(qū)情況、技術(shù)服務(wù)情況
• 你要有長(zhǎng)期跟蹤和更新報(bào)告的能力浆竭，避免半年后淪為過(guò)期信息

換言之：評(píng)測(cè)要想真浸须，功夫得做深惨寿！

本文從面向用戶、面向開(kāi)發(fā)者兩大維度七大細(xì)項(xiàng)羽戒，對(duì)微信原生及主流的wepy缤沦、mpvue虎韵、taro易稠、uni-app開(kāi)發(fā)框架進(jìn)行橫向?qū)Ρ龋Ｍo開(kāi)發(fā)者在小程序框架選型時(shí)提供一種參考思路包蓝。本文基于各框架官網(wǎng)可采集到的公開(kāi)數(shù)據(jù)及真實(shí)測(cè)試數(shù)據(jù)驶社，希望客觀公正地評(píng)價(jià)各個(gè)框架的現(xiàn)狀和優(yōu)劣。但宥于利益相關(guān)测萎，本文的觀點(diǎn)很可能是帶有偏向性的亡电，大家可以帶著批判的眼光來(lái)看待，如發(fā)現(xiàn)本文中有任何評(píng)測(cè)失真硅瞧，歡迎在這里報(bào) issuse份乒。

面向用戶、面向開(kāi)發(fā)者維度腕唧，具體包括：

1. 用戶：提供完整的業(yè)務(wù)實(shí)現(xiàn)或辖，并保證高性能體驗(yàn)
2. 開(kāi)發(fā)者：平緩的學(xué)習(xí)曲線、現(xiàn)代開(kāi)發(fā)體驗(yàn)（工程化）枣接、高效的社區(qū)支持颂暇、活躍的開(kāi)發(fā)迭代、多端復(fù)用

1. 用戶

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

軟件開(kāi)發(fā)但惶，首要目標(biāo)是向用戶提供完整耳鸯、閉環(huán)的業(yè)務(wù)功能。

在web開(kāi)發(fā)中膀曾，如果vue县爬、react等框架的使用，造成開(kāi)發(fā)者無(wú)法操作瀏覽器提供的所有api添谊，那這樣的框架肯定是不成熟的财喳。小程序開(kāi)發(fā)也一樣，任何開(kāi)發(fā)框架碉钠，都不能限制底層的api調(diào)用纲缓。

而各種業(yè)務(wù)功能底層依賴微信暴漏的組件和接口（微信官網(wǎng)介紹的組件和 API 規(guī)范,也即微信原生API），三方框架是基于微信原生進(jìn)行的二次封裝喊废，開(kāi)發(fā)者此時(shí)常會(huì)有個(gè)疑問(wèn)：小程序在不斷的迭代升級(jí)祝高，如果某項(xiàng)業(yè)務(wù)依賴于最新的小程序API，但三方框架尚未封裝污筷，該怎么辦工闺？

實(shí)際上就像web開(kāi)發(fā)的vue乍赫、react一樣，瀏覽器出了一個(gè)新API陆蟆，并不會(huì)涉及vue雷厂、react的升級(jí)。本評(píng)測(cè)里的所有框架叠殷，都不會(huì)限制開(kāi)發(fā)者調(diào)用底層能力改鲫。這里詳細(xì)解釋下原因：

• wepy：未對(duì)小程序API作二次封裝，API依然使用微信原生的林束，框架與微信小程序是否新增API無(wú)關(guān)
• mpvue：支持微信的所有原生組件和api像棘，無(wú)限制。同時(shí)框架封裝了自己的跨端API壶冒，使用方式類似mpvue.request()
• taro：支持微信的所有原生組件和api缕题，無(wú)限制。同時(shí)框架封裝了自己的跨端API胖腾，使用方式類似Taro.request()烟零，支持Taro 代碼與小程序代碼混寫，可通過(guò)混寫的方式調(diào)用框架尚未封裝的小程序新增API
• uni-app：支持微信的所有原生組件和api咸作，無(wú)限制锨阿。在跨端方面，即便仍然使用微信原生的組件和API性宏，也可以直接跨端編譯到App群井、H5、以及支付寶百度頭條等小程序毫胜。但為了管理清晰书斜，推薦使用uni封裝的API，類似uni.request()酵使。同時(shí)支持條件編譯荐吉，可在條件編譯代碼塊中，隨意調(diào)用各個(gè)平臺(tái)新增的API及組件

注：以上順序口渔，按各個(gè)框架的誕生順序排序样屠，下同。

故缺脉，三方框架均可調(diào)用所有小程序API痪欲，完成用戶的業(yè)務(wù)需求，這個(gè)維度各框架是無(wú)差別的攻礼。然而有差別的业踢，是性能體驗(yàn)。

1.2 性能體驗(yàn)

三方框架礁扮，內(nèi)部大多做了層層封裝知举，這些封裝是否會(huì)增加運(yùn)行負(fù)載瞬沦，導(dǎo)致性能下降？尤其是與原生微信小程序開(kāi)發(fā)相比性能怎么樣雇锡，這是大家普遍關(guān)心的問(wèn)題逛钻。

為客觀的進(jìn)行對(duì)比，我們特意搭建了一個(gè)測(cè)試模型锰提，詳細(xì)如下：

開(kāi)發(fā)內(nèi)容：開(kāi)發(fā)一個(gè)仿微博小程序首頁(yè)的復(fù)雜長(zhǎng)列表曙痘，支持下拉刷新、上拉翻頁(yè)欲账、點(diǎn)贊屡江。

• 界面如下：

• 開(kāi)發(fā)版本：一共開(kāi)發(fā)了5個(gè)版本，包括微信原生版赛不、wepy版、mpvue版罢洲、taro版踢故、uni-app版，按照官網(wǎng)指引通過(guò)cli方式默認(rèn)安裝惹苗。

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

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

• 測(cè)試環(huán)境：每個(gè)框架開(kāi)始測(cè)試前，殺掉各App進(jìn)程院究、清空內(nèi)存洽瞬，保證測(cè)試機(jī)環(huán)境基本一致；每次從本地讀取靜態(tài)數(shù)據(jù)业汰，屏蔽網(wǎng)絡(luò)差異伙窃。

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

1.2.1 長(zhǎng)列表加載

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

從觸發(fā)上拉加載到數(shù)據(jù)更新、頁(yè)面渲染完成跪妥，需要準(zhǔn)確計(jì)時(shí)鞋喇。人眼視覺(jué)計(jì)時(shí)肯定不行，我們采用程序埋點(diǎn)的方式骗奖，制定了如下計(jì)時(shí)時(shí)機(jī)：

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

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

測(cè)試方式：從頁(yè)面空列表開(kāi)始鄙皇，通過(guò)程序自動(dòng)觸發(fā)上拉加載芜赌，每次新增20條列表，記錄單次耗時(shí)伴逸；固定間隔連續(xù)觸發(fā) N 次上拉加載缠沈，使得頁(yè)面達(dá)到 20*N 條列表，計(jì)算這 N 次觸發(fā)上拉到渲染完成的平均耗時(shí)错蝴。

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

說(shuō)明：以400條微博列表為例洲愤，從頁(yè)面空列表開(kāi)始，每隔1秒觸發(fā)一次上拉加載（新增20條微博）顷锰，記錄單次耗時(shí)柬赐，觸發(fā)20次后停止（頁(yè)面達(dá)到400條微博），計(jì)算這20次的平均耗時(shí)官紫，結(jié)果微信原生在這20次 觸發(fā)上拉 -> 渲染完成 的平均耗時(shí)為876毫秒肛宋，最快的uni-app是741毫秒，最慢的mpvue是4493毫秒

大家初看這個(gè)數(shù)據(jù)束世，可能比較疑惑酝陈，別急，下方有詳細(xì)說(shuō)明

說(shuō)明1：為何 mpvue/wepy 測(cè)試數(shù)據(jù)不完整?

mpvue毁涉、wepy 誕生之初沉帮，微信小程序尚不支持自定義組件，無(wú)法進(jìn)行組件化開(kāi)發(fā)贫堰；mpvue穆壕、wepy 為解決這個(gè)問(wèn)題，將用戶編寫的Vue組件严嗜，編譯為WXML中的模板template粱檀，變相實(shí)現(xiàn)了組件化開(kāi)發(fā)能力，提高代碼復(fù)用性漫玄，這在當(dāng)時(shí)的技術(shù)條件下是很棒的技術(shù)方案茄蚯。

但如此方案，在頁(yè)面復(fù)雜睦优、組件較多的時(shí)渗常，會(huì)大量增加頁(yè)面 dom 節(jié)點(diǎn)數(shù)量，甚至超出微信的 dom 節(jié)點(diǎn)數(shù)限制汗盘。我們?cè)?紅米手機(jī)（Redmi 6 Pro）上實(shí)測(cè)皱碘，頁(yè)面組件超過(guò)500個(gè)時(shí)，mpvue隐孽、wepy 實(shí)現(xiàn)的仿微博App就會(huì)報(bào)出如下異常癌椿，并停止渲染健蕊，故這兩個(gè)測(cè)試框架在組件較多時(shí)，測(cè)試數(shù)據(jù)不完整踢俄。這也就意味著缩功，當(dāng)頁(yè)面組件太多時(shí)，無(wú)法使用這2個(gè)框架都办。

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

Tips1：wepy官網(wǎng)的CHANGELOG嫡锌，提到 v1.7.2 測(cè)試版本添加了對(duì)小程序原生組件的支持，實(shí)測(cè)坑很多琳钉，因?yàn)槭菧y(cè)試版势木，官方在 issue 中也表示不推薦使用；按照官網(wǎng)文檔歌懒，默認(rèn)安裝的 v1.7.3 正式版本并不支持原生組件

Tips2：wepy在400條列表以內(nèi)啦桌，為何性能高于微信原生框架，這個(gè)跟自定義組件管理開(kāi)銷及業(yè)務(wù)場(chǎng)景有關(guān)（wepy編譯為模板歼培，不涉及組件創(chuàng)建及管理開(kāi)銷）震蒋，后續(xù)對(duì)微博點(diǎn)贊，涉及組件數(shù)據(jù)傳遞時(shí)躲庄，微信原生框架的性能優(yōu)勢(shì)就提現(xiàn)出來(lái)了，詳見(jiàn)下方測(cè)試數(shù)據(jù)钾虐。

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

其實(shí)，在頁(yè)面上有200條記錄（200個(gè)組件）時(shí)效扫，taro 性能數(shù)據(jù)也比微信原生框架更好倔监。

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

例如當(dāng)前頁(yè)面有20條數(shù)據(jù)，觸發(fā)上拉加載時(shí)摹迷，會(huì)新加載20條數(shù)據(jù)疟赊，此時(shí)原生框架通過(guò)如下代碼測(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ù)到視圖層
}

開(kāi)發(fā)者使用微信原生框架近哟，完全可以自己優(yōu)化，精簡(jiǎn)傳遞數(shù)據(jù)鲫寄，比如修改如下：

data: {
    listData: []
},
onReachBottom() { //上拉加載
    // 通過(guò)長(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)過(guò)如上優(yōu)化修改后，再次測(cè)試戳玫，微信原生框架性能數(shù)據(jù)如下：

從測(cè)試結(jié)果可看出熙掺，經(jīng)過(guò)開(kāi)發(fā)者手動(dòng)優(yōu)化，微信原生框架可達(dá)到更好的性能量九，但 uni-app适掰、taro 相比微信原生，性能差距并不大荠列。

這個(gè)結(jié)果类浪，和web開(kāi)發(fā)類似，web開(kāi)發(fā)也有原生js開(kāi)發(fā)肌似、vue费就、react框架等情況。如果不做特殊優(yōu)化川队，原生js寫的網(wǎng)頁(yè)力细，性能經(jīng)常還不如vue、react框架的性能固额。

也恰恰是因?yàn)?code>Vue眠蚂、react框架的優(yōu)秀，性能好斗躏，開(kāi)發(fā)體驗(yàn)好逝慧，所以原生js開(kāi)發(fā)已經(jīng)逐漸減少使用了。

復(fù)雜長(zhǎng)列表加載下一頁(yè)評(píng)測(cè)結(jié)論：微信原生開(kāi)發(fā)手工優(yōu)化,uni-app>微信原生開(kāi)發(fā)未手工優(yōu)化,taro > wepy > mpvue

Tips：有人以為uni-app和mpvue是一樣的啄糙，早期uni-app確實(shí)使用過(guò)mpvue笛臣，但后來(lái)因?yàn)樾阅芎蛌ue語(yǔ)法支持度問(wèn)題已經(jīng)重新開(kāi)發(fā)了。

1.2.2 點(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ù)開(kāi)頭開(kāi)始計(jì)時(shí)，setData回調(diào)函數(shù)開(kāi)頭結(jié)束計(jì)時(shí)禁荒；

在紅米手機(jī)（Redmi 6 Pro）上進(jìn)行多次測(cè)試猬膨，求其平均值，結(jié)果如下：

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

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

• wepy/mpvue 測(cè)試數(shù)據(jù)不完整的原因同上，在組件較多時(shí)沛申，頁(yè)面已經(jīng)不再渲染了
• 基于微信自定義組件實(shí)現(xiàn)組件開(kāi)發(fā)的框架（uni-app/taro）劣领，組件數(shù)據(jù)通訊性能接近于微信原生框架，遠(yuǎn)高于基于template實(shí)現(xiàn)組件開(kāi)發(fā)的框架（wepy/mpvue）性能

組件數(shù)據(jù)更新性能測(cè)評(píng)：微信原生開(kāi)發(fā),uni-app,taro > wepy > mpvue

綜上铁材，本性能測(cè)試做了2個(gè)測(cè)試猾普，長(zhǎng)列表加載和組件狀態(tài)更新亩鬼，綜合2個(gè)實(shí)驗(yàn)山害，結(jié)論如下：
微信原生開(kāi)發(fā)手工優(yōu)化,uni-app>微信原生開(kāi)發(fā)未手工優(yōu)化,taro > wepy > mpvue

2.開(kāi)發(fā)者

在滿足用戶業(yè)務(wù)需求的前提下嘉涌，我們談?wù)勯_(kāi)發(fā)者的需求，從如下幾個(gè)維度比較：

• 平緩的學(xué)習(xí)曲線：簡(jiǎn)單易學(xué)饼丘，最好能復(fù)用現(xiàn)有技術(shù)棧趁桃，豐富的學(xué)習(xí)資料
• 高效的開(kāi)發(fā)體驗(yàn)：現(xiàn)代前端開(kāi)發(fā)流程、工程化支持
• 高效的社區(qū)支持：遇到問(wèn)題肄鸽，可很快的尋求到幫助
• 活躍的開(kāi)發(fā)迭代：框架處于積極更新升級(jí)狀態(tài)卫病，無(wú)需擔(dān)心停更

2.1 平緩的學(xué)習(xí)曲線

2.1.1 DSL語(yǔ)法支持

選擇開(kāi)發(fā)團(tuán)隊(duì)熟悉的、能快速上手的DSL典徘，是團(tuán)隊(duì)框架選型的基本點(diǎn)蟀苛。

• 首先微信原生的開(kāi)發(fā)語(yǔ)法，既像React 逮诲，又像Vue屹逛，有點(diǎn)不倫不類，對(duì)于開(kāi)發(fā)者來(lái)說(shuō)汛骂，等于又要學(xué)習(xí)一套新的語(yǔ)法，大幅提升了學(xué)習(xí)成本评腺，這一直被大家所詬病帘瞭。

• 其它開(kāi)發(fā)框架基本都遵循React、Vue（類Vue）語(yǔ)法蒿讥，其主要目的：復(fù)用工程師的現(xiàn)有技術(shù)棧蝶念，降低學(xué)習(xí)成本。此時(shí)芋绸，框架對(duì)于原框架（React/Vue）語(yǔ)法的支持度就是一個(gè)重要的衡量標(biāo)準(zhǔn)媒殉，如果支持度較低、和原框架語(yǔ)法差異較大摔敛，則開(kāi)發(fā)者無(wú)異于要學(xué)習(xí)一門新的框架廷蓉，成本太高。

實(shí)際開(kāi)發(fā)中發(fā)現(xiàn)马昙，各個(gè)開(kāi)發(fā)框架桃犬，都沒(méi)有完全實(shí)現(xiàn)Vue刹悴、React在web上的所有語(yǔ)法：

• wepy開(kāi)發(fā)風(fēng)格接近于 Vue.js，屬于類Vue實(shí)現(xiàn)攒暇，相對(duì)微信原生開(kāi)發(fā)算前進(jìn)了一大步土匀，但相比完整Vue語(yǔ)法還有較大差距，開(kāi)發(fā)時(shí)需要單獨(dú)學(xué)習(xí)它的規(guī)則形用；

• mpvue就轧、uni-app 框架基于 Vue.js 核心，通過(guò)修改 Vue.js 的 runtime 和 compiler田度，實(shí)現(xiàn)了在小程序端的運(yùn)行妒御。mpvue支持的Vue語(yǔ)法略少，uni-app 則基本支持絕大多數(shù)vue語(yǔ)法每币，如filter携丁、復(fù)雜 JavaScript 表達(dá)式等；

• taro 對(duì)于 JSX 的語(yǔ)法支持度兰怠，也達(dá)到了絕大多數(shù)都支持的完善程度梦鉴。

• DSL語(yǔ)法支持評(píng)測(cè)：taro,uni-app > mpvue > wepy > 微信原生

2.1.2 學(xué)習(xí)資料完善度

官方文檔、問(wèn)題搜索揭保、示例demo的完備度方面：

• 微信原生：文檔豐富肥橙，API搜索準(zhǔn)確，官方有示例demo秸侣，支持官網(wǎng)上調(diào)起微信開(kāi)發(fā)者工具存筏，預(yù)覽運(yùn)行效果 詳見(jiàn)
• wepy：文檔只有2頁(yè)，沒(méi)有搜索味榛，組件API等文檔都直接看微信的文檔椭坚。沒(méi)有提供示例demo，很多配置需要靠猜搏色。詳見(jiàn)
• mpvue：文檔較少善茎，但其概念不復(fù)雜，組件API等文檔都直接看微信的文檔频轿，學(xué)習(xí)難度低垂涯。問(wèn)題搜索效果一般。沒(méi)有提供示例demo航邢。詳見(jiàn)
• taro：基礎(chǔ)文檔完整耕赘，具體使用問(wèn)題資源較少，問(wèn)題搜索效果一般膳殷，示例demo只包含基礎(chǔ)功能操骡，僅發(fā)布了微信一端。詳見(jiàn)
• uni-app：基礎(chǔ)文檔和各種使用專題內(nèi)容豐富，問(wèn)題搜索效果較好当娱，示例demo功能完備吃既，并發(fā)布為7端上線。詳見(jiàn)

教學(xué)課程方面：

學(xué)習(xí)資料完善度評(píng)測(cè)：微信原生 > uni-app > mpvue , taro > wepy

2.2 現(xiàn)代前端開(kāi)發(fā)體驗(yàn)

開(kāi)發(fā)體驗(yàn)層面跨细，處于明顯劣勢(shì)的是微信原生開(kāi)發(fā)鹦倚，主要差距在于：

• 框架開(kāi)發(fā)提供了精簡(jiǎn)的代碼組織（微信原生開(kāi)發(fā)，一個(gè)Page由4個(gè)文件構(gòu)成冀惭，寫個(gè)代碼要開(kāi)的標(biāo)簽卡太多）
• 框架開(kāi)發(fā)提供了更強(qiáng)大的組件化能力
• 框架開(kāi)發(fā)提供了應(yīng)用狀態(tài)管理（類Vuex/Redux/Mobx等）
• 框架開(kāi)發(fā)能靈活支持各種 Sass 等 預(yù)處理器
• 框架開(kāi)發(fā)可提供完整的 ES Next 語(yǔ)法支持
• 框架開(kāi)發(fā)方便自定義構(gòu)建策略

其它小程序開(kāi)發(fā)框架均支持cli模式震叙，可以在主流前端工具中開(kāi)發(fā)，且基本都帶有d.ts的語(yǔ)法提示庫(kù)散休。

由于mpvue媒楼、uni-app、taro直接支持vue戚丸、react語(yǔ)法划址，配套的ide工具鏈較豐富，著色限府、校驗(yàn)夺颤、格式化完善；wepy要弱一些胁勺，有部分三方維護(hù)的vscode插件世澜。

好的開(kāi)發(fā)工具，絕對(duì)可以大幅提升開(kāi)發(fā)體驗(yàn)署穗，這個(gè)維度上寥裂，明顯高出一截的框架是uni-app，其出品公司同時(shí)也是HBuilder的出品公司案疲，DCloud.io封恰。HBuilder是四大主流前端開(kāi)發(fā)工具（可對(duì)比百度指數(shù)，其為uni-app做了很多優(yōu)化褐啡，故uni-app的開(kāi)發(fā)效率俭驮、易用性非其他框架可及。

開(kāi)發(fā)體驗(yàn)維度春贸，對(duì)比結(jié)果：uni-app > taro,mpvue > wepy > 微信原生

這里可以輸出一個(gè)結(jié)論：如果你需要工程化能力，那就直接忘了微信原生開(kāi)發(fā)吧遗遵。

2.3 高效的社區(qū)支持

學(xué)習(xí)萍恕、開(kāi)發(fā)難免遇到問(wèn)題，官方技術(shù)支持和社區(qū)活躍度很重要车要。

本次評(píng)測(cè)demo開(kāi)發(fā)期間允粤，我們的同學(xué)（同時(shí)掌握vue和react），在學(xué)習(xí)研究各個(gè)多端框架時(shí)，切實(shí)感受到由于語(yǔ)法类垫、學(xué)習(xí)資料司光、社區(qū)的差異帶來(lái)的學(xué)習(xí)門檻，吐出了很多槽悉患。

綜合評(píng)估残家，本項(xiàng)評(píng)測(cè)結(jié)論：微信原生 , uni-app > taro > mpvue > wepy

2.4 活躍的開(kāi)發(fā)迭代

開(kāi)發(fā)者必須關(guān)心一個(gè)問(wèn)題：該項(xiàng)目是否有人長(zhǎng)期維護(hù)？

這個(gè)問(wèn)題可以通過(guò)github commits 頻次售躁、產(chǎn)品更新日志（changelog）坞淮、百度搜索指數(shù)等指標(biāo)來(lái)衡量和對(duì)比。

github commits 頻次

我們采集2019年4月份（時(shí)間為4.1 ~ 4.30）陪捷，每個(gè)項(xiàng)目在github上的master分支有commit的天數(shù)回窘，結(jié)果如下：

Tips：

• 微信原生是閉源的，看不到 commits 數(shù)量市袖，但保持每月至少一次的更新節(jié)奏啡直，詳見(jiàn)
• wepy的master分支無(wú)commit，最新的2.0.x分支在4月份也僅1天有commit記錄

從 commit 的記錄來(lái)看苍碟，taro酒觅、uni-app處于更新比較活躍的狀態(tài)，wepy驰怎、mpvue則相對(duì)疲軟阐滩，呈現(xiàn)無(wú)人維護(hù)之態(tài)。

產(chǎn)品更新日志

通過(guò)瀏覽產(chǎn)品更新日志县忌，可確認(rèn)產(chǎn)品是否在積極迭代掂榔、增加新功能、修復(fù)用戶bug症杏。

我們分別查看各框架官方鏈接的更新日志（CHANGELOG）装获，下方是鏈接地址：

• 微信基礎(chǔ)庫(kù)更新日志
• wepy官網(wǎng) CHAGELOG
• mpvue官網(wǎng) Chang log
• taro github 更新日志
• uni-app官網(wǎng)更新日志

通過(guò)產(chǎn)品更新日志對(duì)比，微信原生厉颤、taro穴豫、uni-app 三者更新頻繁，bug修復(fù)逼友、新功能補(bǔ)充都處于比較緊湊的狀態(tài)精肃；而mpvue、wepy則已有長(zhǎng)時(shí)間沒(méi)有版本發(fā)布帜乞，wepy甚至有將近1年時(shí)間未發(fā)布正式版本司抱，開(kāi)發(fā)者選型需謹(jǐn)慎。

2.5 多端復(fù)用

隨著微信小程序的火爆黎烈，支付寶习柠、百度匀谣、字節(jié)跳動(dòng)等公司也先后進(jìn)入小程序領(lǐng)域，這些公司個(gè)個(gè)日活過(guò)億资溃，坐擁海量用戶武翎，企業(yè)主希望將自己的業(yè)務(wù)觸達(dá)每個(gè)用戶，不管這個(gè)用戶在哪個(gè)小程序中溶锭。

需求轉(zhuǎn)接到程序員這里宝恶，程序員怎么辦？難道真的每個(gè)平臺(tái)到處搬磚嗎暖途？此時(shí)卑惜，一套代碼、多端發(fā)布就成為很多程序員的夢(mèng)想驻售，小程序跨端框架應(yīng)運(yùn)而生露久。

現(xiàn)實(shí)真能如此理想嗎？每個(gè)跨端框架能否真的像官網(wǎng)宣傳的那樣欺栗，實(shí)現(xiàn)開(kāi)發(fā)一次毫痕，發(fā)布到所有小程序平臺(tái)？甚至和H5平臺(tái)復(fù)用代碼迟几？

我們用事實(shí)說(shuō)話消请，依然使用上述仿微博App，依次發(fā)布到各平臺(tái)类腮，驗(yàn)證每個(gè)框架在各端的兼容性臊泰，結(jié)果如下：

測(cè)試結(jié)果說(shuō)明：

• ? 表示支持且功能正常，? 表示不支持蚜枢，其它則表示支持但存在部分bug或兼容問(wèn)題

通過(guò)這個(gè)簡(jiǎn)單的例子可以看出缸逃，跨端支持度測(cè)評(píng)結(jié)論： uni-app,taro > mpvue> 原生微信小程序、wepy

但是僅有上面的測(cè)試還不全面厂抽，實(shí)際業(yè)務(wù)要比這個(gè)測(cè)試?yán)龔?fù)雜很多需频。但我們沒(méi)法開(kāi)發(fā)很多復(fù)雜業(yè)務(wù)做評(píng)測(cè)，所以還需要再對(duì)照各家文檔補(bǔ)充一些信息筷凤。 由于每個(gè)框架的文檔中都描述了各種組件和API的跨端支持程度昭殉。我們過(guò)了幾家的文檔，發(fā)現(xiàn)各家基本是以微信小程序?yàn)榛€藐守，然后把各種組件和API在其他端實(shí)現(xiàn)了一遍：

• taro：H5端實(shí)現(xiàn)了大部分微信的API
• uni-app：組件挪丢、API、配置卢厂，大部分在各個(gè)端均已實(shí)現(xiàn)吃靠，個(gè)別API有說(shuō)明在某些端不支持∽阆可以看出uni-app是完整在H5端實(shí)現(xiàn)了一套微信模擬器

跨端框架巢块，一方面要考慮框架提供的通用api跨端支持，同時(shí)還要考慮不同端的特色差異如何兼容巧号。畢竟每個(gè)端都會(huì)有自己的特色族奢，不可能完全一致。

• taro：提供了js環(huán)境變量判斷和統(tǒng)一接口的多端文件丹鸿，可以在組件越走、js、文件方面擴(kuò)展多端靠欢，不支持其他環(huán)節(jié)的分平臺(tái)處理廊敌。
• uni-app：提供了條件編譯模型，所有代碼包括組件门怪、js骡澈、css、配置json掷空、文件肋殴、目錄，均支持條件編譯坦弟，可不受限的編寫各端差異代碼护锤。

跨端框架，還涉及一個(gè)ui框架的跨端問(wèn)題酿傍，評(píng)測(cè)結(jié)果如下：

• taro：官方提供了taro ui烙懦，只支持微信小程序和H5兩端，不支持App赤炒，詳見(jiàn)
• uni-app：官方提供了uni ui氯析，可全端運(yùn)行；uni-app還有一個(gè)插件市場(chǎng)可霎，里面有很多三方ui組件魄鸦，詳見(jiàn)

最后補(bǔ)充跨端案例：

• mpvue：微信端案例豐富，未見(jiàn)其它端案例
• taro：微信端案例豐富癣朗，百度拾因、支付寶、H5端亦有少量案例
• uni-app：多端案例豐富旷余，官方示例已發(fā)布到7端(包括App端)

綜合以上信息绢记，本項(xiàng)的最終評(píng)測(cè)結(jié)論：uni-app > taro > mpvue > 原生微信小程序、wepy

這里可以輸出一個(gè)結(jié)論正卧，如果有多端發(fā)布需求蠢熄，微信原生開(kāi)發(fā)、wepy這兩種方式可以直接排除了炉旷。

結(jié)語(yǔ)

真實(shí)客觀的永遠(yuǎn)是實(shí)驗(yàn)和數(shù)據(jù)签孔，而不是結(jié)論叉讥。不同需求的開(kāi)發(fā)者，可以根據(jù)上述實(shí)驗(yàn)數(shù)據(jù)饥追，自行得出自己的選型結(jié)論图仓。

但作為一篇完整的評(píng)測(cè)，我們也必須提供一份總結(jié)但绕，雖然它可能加入了我們的主觀感受：

如果你只開(kāi)發(fā)微信小程序救崔，不做多端，那么使用uni-app捏顺、taro是更優(yōu)的選擇六孵，他們相當(dāng)于web世界的vue和react，有了這些工具幅骄，不再需要使用原生wxml開(kāi)發(fā)劫窒。

• 如果堅(jiān)持微信原生開(kāi)發(fā)，需要注意手動(dòng)寫優(yōu)化代碼來(lái)控制setdata昌执，并且注意其工程化能力非常弱
• 如果你是react系烛亦，那就用taro
• 如果是vue系，那就用uni-app懂拾，uni-app在性能煤禽、周邊生態(tài)和開(kāi)發(fā)效率上更有優(yōu)勢(shì)

如果你開(kāi)發(fā)多端，uni-app和taro都可以岖赋，可根據(jù)自己熟悉的技術(shù)棧選擇檬果，相對(duì)而言uni-app的多端成熟度更高一些。