作者 | 崔紅保編輯 | 王瑩

自 2017年1月9日微信小程序誕生以來，歷經(jīng) 2 年多的迭代升級(jí)，已有數(shù)百萬小程序上線，成為繼 Web、iOS、Android 之后，第四大主流開發(fā)技術(shù)。

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

選擇多了，問題也就來了，開發(fā)小程序，該用原生還是選擇三方框架？

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

原生開發(fā)對(duì) Node、預(yù)編譯器、webpack 支持不好，影響開發(fā)效率和工程構(gòu)建流程。

微信定義了一個(gè)不倫不類的語法，不如正經(jīng)學(xué) vue、react，學(xué)會(huì)了全端通用，而不是只為微信小程序。

vue/react 生態(tài)里有太多周邊工具，可以提高開發(fā)效率，比如 ide、校驗(yàn)器、三方庫……

微信 ide 和專業(yè)編輯器相比存在一些缺點(diǎn)和劣勢(shì)。

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

怕性能不如原生。

怕有些功能框架實(shí)現(xiàn)不了，只能用原生。

怕框架不穩(wěn)定，跳到坑里。

以及諸多三方框架，到底該用哪個(gè)。

面對(duì)如此糾結(jié)的場(chǎng)景，不少熱心開發(fā)者發(fā)布評(píng)測(cè)文章分享經(jīng)驗(yàn)，但感覺眾說紛紜，過期信息太多。缺少一份非常專業(yè)的、深度的，或者按如今流行的話來講，“硬核的”評(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)?#xff0c;比較各個(gè)平臺(tái)的功能、性能，了解他們的社區(qū)情況、技術(shù)服務(wù)情況。

• 你要有長(zhǎng)期跟蹤和更新報(bào)告的能力，避免半年后淪為過期信息。

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

uni-app團(tuán)隊(duì)花費(fèi) 2 個(gè)周時(shí)間完成本報(bào)告，并堅(jiān)持每個(gè)季度更新一次本評(píng)測(cè)報(bào)告。目前更新時(shí)間為 2019 年 5 月。

本文從面向用戶、面向開發(fā)者兩大維度七大細(xì)項(xiàng)，對(duì)微信原生及主流的wepy、mpvue、taro、uni-app開發(fā)框架進(jìn)行橫向?qū)Ρ?#xff0c;希望給開發(fā)者在小程序框架選型時(shí)提供一種參考思路。本文基于各框架官網(wǎng)可采集到的公開數(shù)據(jù)及真實(shí)測(cè)試數(shù)據(jù)，希望客觀公正地評(píng)價(jià)各個(gè)框架的現(xiàn)狀和優(yōu)劣。但宥于利益相關(guān)，本文的觀點(diǎn)很可能是帶有偏向性的，大家可以帶著批判的眼光來看待，如發(fā)現(xiàn)本文中有任何評(píng)測(cè)失真，歡迎在這里報(bào) issuse：https://github.com/dcloudio/test-framework

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

用戶：提供完整的業(yè)務(wù)實(shí)現(xiàn)，并保證高性能體驗(yàn)。

開發(fā)者：平緩的學(xué)習(xí)曲線、現(xiàn)代開發(fā)體驗(yàn)(工程化)、高效的社區(qū)支持、活躍的開發(fā)迭代、多端復(fù)用。

1. 用戶 1.1 功能實(shí)現(xiàn)

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

在 web 開發(fā)中，如果 vue、react 等框架的使用，造成開發(fā)者無法操作瀏覽器提供的所有 api，那這樣的框架肯定是不成熟的。小程序開發(fā)也一樣，任何開發(fā)框架，都不能限制底層的 api 調(diào)用。

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

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

• wepy：未對(duì)小程序 API 作二次封裝，API 依然使用微信原生的，框架與微信小程序是否新增 API 無關(guān)。

• mpvue：支持微信的所有原生組件和 api，無限制。同時(shí)框架封裝了自己的跨端 API，使用方式類似mpvue.request()。

• taro：支持微信的所有原生組件和 api，無限制。同時(shí)框架封裝了自己的跨端 API，使用方式類似Taro.request()，支持 Taro 代碼與小程序代碼混寫(詳見下面的鏈接)，可通過混寫的方式調(diào)用框架尚未封裝的小程序新增 API。

• uni-app：支持微信的所有原生組件和 api，無限制。在跨端方面，即便仍然使用微信原生的組件和 API，也可以直接跨端編譯到 App、H5、以及支付寶百度頭條等小程序。但為了管理清晰，推薦使用 uni 封裝的 API，類似uni.request()。同時(shí)支持條件編譯(詳見下面的鏈接)，可在條件編譯代碼塊中，隨意調(diào)用各個(gè)平臺(tái)新增的 API 及組件。

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

相關(guān)鏈接：

Taro 代碼與小程序代碼混寫：https://nervjs.github.io/taro/docs/hybrid.html

條件編譯：

https://uniapp.dcloud.io/platform

故，三方框架均可調(diào)用所有小程序 API，完成用戶的業(yè)務(wù)需求，這個(gè)維度各框架是無差別的。

然而有差別的，是性能體驗(yàn)。

1.2 性能體驗(yàn)

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

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

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

• 界面如下：

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

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

  https://github.com/dcloudio/test-framework/issues

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

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

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

1.2.1 長(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)槲⑿舠etData定義(具體詳見下方鏈接)如下：

相關(guān)鏈接：

微信規(guī)范：

https://developers.weixin.qq.com/miniprogram/dev/reference/api/Page.html?search-key=Page.prototype.setData

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

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

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

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

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

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

但如此方案，在頁面復(fù)雜、組件較多的時(shí)，會(huì)大量增加頁面 dom 節(jié)點(diǎn)數(shù)量，甚至超出微信的 dom 節(jié)點(diǎn)數(shù)限制。我們?cè)?紅米手機(jī)(Redmi 6 Pro)上實(shí)測(cè)，頁面組件超過 500 個(gè)時(shí)，mpvue、wepy ?實(shí)現(xiàn)的仿微博 App 就會(huì)報(bào)出如下異常，并停止渲染，故這兩個(gè)測(cè)試框架在組件較多時(shí)，測(cè)試數(shù)據(jù)不完整。這也就意味著，當(dāng)頁面組件太多時(shí)，無法使用這 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è)跟自定義組件管理開銷及業(yè)務(wù)場(chǎng)景有關(guān)(wepy編譯為模板，不涉及組件創(chuàng)建及管理開銷)，后續(xù)對(duì)微博點(diǎn)贊，涉及組件數(shù)據(jù)傳遞時(shí)，微信原生框架的性能優(yōu)勢(shì)就提現(xiàn)出來了，詳見下方測(cè)試數(shù)據(jù)。

相關(guān)鏈接：

自定義組件：

https://developers.weixin.qq.com/miniprogram/dev/framework/custom-component/

模板(template)：

https://developers.weixin.qq.com/miniprogram/dev/framework/view/wxml/template.html

CHANGELOG：https://tencent.github.io/wepy/document.html#/changelog

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

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

微信原生框架耗時(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ù)，比如修改如下：

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ù)如下：

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

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

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

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

Tips：有人以為 uni-app 和 mpvue 是一樣的，早期 uni-app 確實(shí)使用過 mpvue，但后來因?yàn)樾阅芎?vue 語法支持度問題已經(jīng)重新開發(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ù)開頭開始計(jì)時(shí)，setData回調(diào)函數(shù)開頭結(jié)束計(jì)時(shí)。

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

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

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

• wepy/mpvue 測(cè)試數(shù)據(jù)不完整的原因同上，在組件較多時(shí)，頁面已經(jīng)不再渲染了。

• 基于微信自定義組件實(shí)現(xiàn)組件開發(fā)的框架(uni-app/taro)，組件數(shù)據(jù)通訊性能接近于微信原生框架，遠(yuǎn)高于基于template實(shí)現(xiàn)組件開發(fā)的框架(wepy/mpvue)性能。

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

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

微信原生開發(fā)手工優(yōu)化，uni-app>微信原生開發(fā)未手工優(yōu)化,taro > wepy > mpvue

2. 開發(fā)者

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

• 平緩的學(xué)習(xí)曲線：簡(jiǎn)單易學(xué)，最好能復(fù)用現(xiàn)有技術(shù)棧，豐富的學(xué)習(xí)資料。

• 高效的開發(fā)體驗(yàn)：現(xiàn)代前端開發(fā)流程、工程化支持。

• 高效的社區(qū)支持：遇到問題，可很快的尋求到幫助。

• 活躍的開發(fā)迭代：框架處于積極更新升級(jí)狀態(tài)，無需擔(dān)心停更。

2.1 平緩的學(xué)習(xí)曲線2.1.1 DSL 語法支持

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

首先微信原生的開發(fā)語法，既像React ，又像Vue，有點(diǎn)不倫不類，對(duì)于開發(fā)者來說，等于又要學(xué)習(xí)一套新的語法，大幅提升了學(xué)習(xí)成本，這一直被大家所詬病。

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

實(shí)際開發(fā)中發(fā)現(xiàn)，各個(gè)開發(fā)框架，都沒有完全實(shí)現(xiàn)Vue、React在 web 上的所有語法：

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

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

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

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

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

官方文檔、問題搜索、示例 demo 的完備度方面：

• 微信原生：文檔豐富，API 搜索準(zhǔn)確，官方有示例 demo，支持官網(wǎng)上調(diào)起微信開發(fā)者工具，預(yù)覽運(yùn)行效果 ，詳見：https://developers.weixin.qq.com/miniprogram/dev/index.html

• wepy：文檔只有 2 頁，沒有搜索，組件 API 等文檔都直接看微信的文檔。沒有提供示例 demo，很多配置需要靠猜。詳見：https://tencent.github.io

• mpvue：文檔較少，但其概念不復(fù)雜，組件 API 等文檔都直接看微信的文檔，學(xué)習(xí)難度低。問題搜索效果一般。沒有提供示例 demo。詳見：http://mpvue.com/

• taro：基礎(chǔ)文檔完整，具體使用問題資源較少，問題搜索效果一般，示例 demo 只包含基礎(chǔ)功能，僅發(fā)布了微信一端。詳見：https://taro.aotu.io/

• uni-app：基礎(chǔ)文檔和各種使用專題內(nèi)容豐富，問題搜索效果較好，示例 demo 功能完備，并發(fā)布為 7 端上線。詳見：https://uniapp.dcloud.io/

教學(xué)課程方面：

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

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

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

• 框架開發(fā)提供了精簡(jiǎn)的代碼組織(微信原生開發(fā)，一個(gè) Page 由 4 個(gè)文件構(gòu)成，寫個(gè)代碼要開的標(biāo)簽卡太多)。

• 框架開發(fā)提供了更強(qiáng)大的組件化能力。

• 框架開發(fā)提供了應(yīng)用狀態(tài)管理(類 Vuex/Redux/Mobx 等)。

• 框架開發(fā)能靈活支持各種 Sass 等 預(yù)處理器。

• 框架開發(fā)可提供完整的 ES Next 語法支持。

• 框架開發(fā)方便自定義構(gòu)建策略。

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

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

好的開發(fā)工具，絕對(duì)可以大幅提升開發(fā)體驗(yàn)，這個(gè)維度上，明顯高出一截的框架是uni-app，其出品公司同時(shí)也是 HBuilder 的出品公司，DCloud.io(https://dcloud.io/)。HBuilder 是四大主流前端開發(fā)工具(可對(duì)比百度指數(shù)，詳見下方鏈接)，其為uni-app做了很多優(yōu)化，故uni-app的開發(fā)效率、易用性非其他框架可及。

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

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

相關(guān)鏈接：

對(duì)比百度指數(shù)：http://zhishu.baidu.com/v2/main/index.html#/trend/vscode?words=vscode,hbuilder,webstorm,sublime

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

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

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

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

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

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

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

github commits 頻次

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

Tips：

• 微信原生是閉源的，看不到 commits 數(shù)量，但保持每月至少一次的更新節(jié)奏，詳見：https://developers.weixin.qq.com/miniprogram/dev/framework/release.html

• wepy的 master 分支無 commit，最新的 2.0.x 分支在 4 月份也僅 1 天有 commit 記錄。

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

產(chǎn)品更新日志

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

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

• 微信基礎(chǔ)庫更新日志：https://developers.weixin.qq.com/miniprogram/dev/framework/release.html

• wepy 官網(wǎng) CHAGELOG：https://tencent.github.io/wepy/document.html#/changelog

• mpvue 官網(wǎng) Chang log：http://mpvue.com/change-log/

• taro github 更新日志：https://github.com/NervJS/taro/blob/master/CHANGELOG.md

• uni-app 官網(wǎng)更新日志：
  http://update.dcloud.net.cn/hbuilderx/changelog/1.9.9.20190522.html

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

2.5 多端復(fù)用

隨著微信小程序的火爆，支付寶、百度、字節(jié)跳動(dòng)等公司也先后進(jìn)入小程序領(lǐng)域，這些公司個(gè)個(gè)日活過億，坐擁海量用戶，企業(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)開發(fā)一次，發(fā)布到所有小程序平臺(tái)？甚至和 H5 平臺(tái)復(fù)用代碼？

我們用事實(shí)說話，依然使用上述仿微博 App：https://github.com/dcloudio/test-framework依次發(fā)布到各平臺(tái)，驗(yàn)證每個(gè)框架在各端的兼容性，結(jié)果如下：

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

• ? 表示支持且功能正常，? 表示不支持，其它則表示支持但存在部分 bug 或兼容問題

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

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

• taro：H5 端實(shí)現(xiàn)了大部分微信的 API。

• uni-app：組件、API、配置，大部分在各個(gè)端均已實(shí)現(xiàn)，個(gè)別 API 有說明在某些端不支持。可以看出 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 框架的跨端問題，評(píng)測(cè)結(jié)果如下：

• taro：官方提供了taro ui，只支持微信小程序和 H5 兩端，不支持 App，詳見：
  https://taro-ui.aotu.io/#/

• uni-app：官方提供了uni ui，可全端運(yùn)行；uni-app 還有一個(gè)插件市場(chǎng)，里面有很多三方 ui 組件，詳見：
  https://ext.dcloud.net.cn/

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

• mpvue：微信端案例豐富，未見其它端案例

• taro：微信端案例豐富，百度、支付寶、H5 端亦有少量案例

• uni-app：多端案例豐富，官方示例已發(fā)布到 7 端 (包括 App 端)

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

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

結(jié)? 語

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

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

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

• 如果堅(jiān)持微信原生開發(fā)，需要注意手動(dòng)寫優(yōu)化代碼來控制setdata，并且注意其工程化能力非常弱。

• 如果你是react系，那就用taro。

• 如果是vue系，那就用uni-app，uni-app在性能、周邊生態(tài)和開發(fā)效率上更有優(yōu)勢(shì)。

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

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

https://github.com/dcloudio/test-framework

---

點(diǎn)個(gè)在看少個(gè) bug ?

總結(jié)

以上是生活随笔為你收集整理的mpvue 微信小程序api_第三方框架与原生微信小程序开发框架性能之比较 | Q荐读...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。