dev用不了_小程式開發：用原生還是選框架
技術標籤：dev用不了uniapp 還是mpvue好uniapp開發例項githubwinform 開發用什麼框架
自 2017年1月9日微信小程式誕生以來，歷經 2 年多的迭代升級，已有數百萬小程式上線，成為繼 Web、iOS、Android 之後，第四大主流開發技術。
與之相隨，小程式的開發生態也在蓬勃發展，從最初的微信原生開發，到wepy、mpvue、taro、uni-app等框架依次出現，從刀耕火種演進為現代化開發，生態越來越豐富。
選擇多了，問題也就來了，開發小程式，該用原生還是選擇三方框架？
首先，微信原生開發的槽點大多集中如下：
原生開發對 Node、預編譯器、webpack 支援不好，影響開發效率和工程構建流程。
微信定義了一個不倫不類的語法，不如正經學 vue、react，學會了全端通用，而不是隻為微信小程式。
vue/react 生態裡有太多周邊工具，可以提高開發效率，比如 ide、校驗器、三方庫……
微信 ide 和專業編輯器相比存在一些缺點和劣勢。
同時，開發者對三方框架，又總是有各種顧慮：
怕效能不如原生。
怕有些功能框架實現不了，只能用原生。
怕框架不穩定，跳到坑裡。
以及諸多三方框架，到底該用哪個。
面對如此糾結的場景，不少熱心開發者釋出評測文章分享經驗，但感覺眾說紛紜，過期資訊太多。缺少一份非常專業的、深度的，或者按如今流行的話來講，“硬核的”評測報告。
做評測報告這件事，不同於泛泛經驗分享，其實非常花費時間。它需要：
你必須成為每一個框架的專業使用人員，而不是淺淺的瞭解一下這些框架。
真實的動手寫多個平臺的測試例，比較各個平臺的功能、效能，瞭解他們的社群情況、技術服務情況。
你要有長期跟蹤和更新報告的能力，避免半年後淪為過期資訊。
換言之：評測要想真，功夫得做深！
uni-app團隊花費 2 個周時間完成本報告，並堅持每個季度更新一次本評測報告。目前更新時間為 2019 年 5 月。
本文從面向使用者、面向開發者兩大維度七大細項，對微信原生及主流的wepy、mpvue、taro、uni-app開發框架進行橫向對比，希望給開發者在小程式框架選型時提供一種參考思路。本文基於各框架官網可採集到的公開資料及真實測試資料，希望客觀公正地評價各個框架的現狀和優劣。但宥於利益相關，本文的觀點很可能是帶有偏向性的，大家可以帶著批判的眼光來看待，如發現本文中有任何評測失真，歡迎在這裡報 issuse： https://github.com/dcloudio/test-framework
面向使用者、面向開發者維度，具體包括：
使用者：提供完整的業務實現，並保證高效能體驗。
開發者：平緩的學習曲線、現代開發體驗(工程化)、高效的社群支援、活躍的開發迭代、多端複用。
軟體開發，首要目標是向用戶提供完整、閉環的業務功能。
在 web 開發中，如果 vue、react 等框架的使用，造成開發者無法操作瀏覽器提供的所有 api，那這樣的框架肯定是不成熟的。小程式開發也一樣，任何開發框架，都不能限制底層的 api 呼叫。
而各種業務功能底層依賴微信暴漏的元件和介面(微信官網介紹的元件和 API 規範, 也即微信原生 API)，三方框架是基於微信原生進行的二次封裝，開發者此時常會有個疑問：小程式在不斷的迭代升級，如果某項業務依賴於最新的小程式 API，但三方框架尚未封裝，該怎麼辦？
實際上就像 web 開發的 vue、react 一樣，瀏覽器出了一個新 API，並不會涉及 vue、react 的升級。本評測裡的所有框架，都不會限制開發者呼叫底層能力。這裡詳細解釋下原因：
wepy：未對小程式 API 作二次封裝，API 依然使用微信原生的，框架與微信小程式是否新增 API 無關。
mpvue：支援微信的所有原生元件和 api，無限制。同時框架封裝了自己的跨端 API，使用方式類似mpvue.request()。
taro：支援微信的所有原生元件和 api，無限制。同時框架封裝了自己的跨端 API，使用方式類似Taro.request()，支援 Taro 程式碼與小程式程式碼混寫(詳見下面的連結)，可通過混寫的方式呼叫框架尚未封裝的小程式新增 API。
uni-app：支援微信的所有原生元件和 api，無限制。在跨端方面，即便仍然使用微信原生的元件和 API，也可以直接跨端編譯到 App、H5、以及支付寶百度頭條等小程式。但為了管理清晰，推薦使用 uni 封裝的 API，類似uni.request()。同時支援條件編譯(詳見下面的連結)，可在條件編譯程式碼塊中，隨意呼叫各個平臺新增的 API 及元件。
注：以上順序，按各個框架的誕生順序排序，下同。
相關連結：
Taro 程式碼與小程式程式碼混寫： https://nervjs.github.io/taro/docs/hybrid.html
條件編譯： https://uniapp.dcloud.io/platform
故，三方框架均可呼叫所有小程式 API，完成使用者的業務需求，這個維度各框架是無差別的。
然而有差別的，是效能體驗。
1.2 效能體驗三方框架，內部大多做了層層封裝，這些封裝是否會增加執行負載，導致效能下降？尤其是與原生微信小程式開發相比效能怎麼樣，這是大家普遍關心的問題。
為客觀的進行對比，我們特意搭建了一個測試模型，詳細如下：
開發內容：開發一個仿微博小程式首頁的複雜長列表，支援下拉重新整理、上拉翻頁、點贊。
介面如下：
開發版本：一共開發了 5 個版本，包括微信原生版、wepy 版、mpvue 版、taro 版、uni-app 版，按照官網指引通過
cli方式預設安裝。測試程式碼開源，Github 倉庫地址： https://github.com/dcloudio/test-framework。 Tips：若有同學覺得測試程式碼寫法欠妥，歡迎提交 PR 或 issus。issus 地址： https://github.com/dcloudio/test-framework/issues
測試機型：紅米 Redmi 6 Pro、MIUI 10.2.2.0 穩定版(最新版)、微信版本 7.0.3(最新版)。
測試環境：每個框架開始測試前，殺掉各 App 程序、清空記憶體，保證測試機環境基本一致；每次從本地讀取靜態資料，遮蔽網路差異。
我們以上述仿微博小程式為例，測試 2 個容易出效能問題的點：長列表載入、大量點贊元件的響應。
1.2.1 長列表載入仿微博的列表是一個包含很多元件的列表，這種複雜列表對效能的壓力更大，很適合做效能測試。
從觸發上拉載入到資料更新、頁面渲染完成，需要準確計時。人眼視覺計時肯定不行，我們採用程式埋點的方式，制定瞭如下計時時機：
計時開始時機：互動事件觸發，框架賦值之前，如：上拉載入(onReachBottom)函式開頭
計時結束時機：頁面渲染完畢 (微信 setData 回撥函式開頭)
Tips：setData回撥函式開頭可認為是頁面渲染完成的時間，是因為微信setData定義(具體詳見下方連結)如下：
相關連結：
微信規範： https://developers.weixin.qq.com/miniprogram/dev/reference/api/Page.html?search-key=Page.prototype.setData
測試方式：從頁面空列表開始，通過程式自動觸發上拉載入，每次新增 20 條列表，記錄單次耗時；固定間隔連續觸發 N 次上拉載入，使得頁面達到 20*N 條列表，計算這 N 次觸發上拉到渲染完成的平均耗時。
測試結果如下：
說明：以 400 條微博列表為例，從頁面空列表開始，每隔 1 秒觸發一次上拉載入(新增 20 條微博)，記錄單次耗時，觸發 20 次後停止(頁面達到 400 條微博)，計算這 20 次的平均耗時，結果微信原生在這 20 次 觸發上拉 -> 渲染完成 的平均耗時為 876 毫秒，最快的uni-app是 741 毫秒，最慢的mpvue是 4493 毫秒
大家初看這個資料，可能比較疑惑，別急，下方有詳細說明
說明 1：為何 mpvue/wepy 測試資料不完整?
mpvue、wepy 誕生之初，微信小程式尚不支援自定義元件，無法進行元件化開發；mpvue、wepy 為解決這個問題，將使用者編寫的Vue元件，編譯為WXML中的 模板(template)，變相實現了元件化開發能力，提高程式碼複用性，這在當時的技術條件下是很棒的技術方案。
但如此方案，在頁面複雜、元件較多的時，會大量增加頁面 dom 節點數量，甚至超出微信的 dom 節點數限制。我們在 紅米手機(Redmi 6 Pro)上實測，頁面元件超過 500 個時，mpvue、wepy 實現的仿微博 App 就會報出如下異常，並停止渲染，故這兩個測試框架在元件較多時，測試資料不完整。這也就意味著，當頁面元件太多時，無法使用這 2 個框架。
dom limit exceeded please check if there's any mistake you've made
Tips1：wepy官網的 CHANGELOG(詳見下方連結)，提到 v1.7.2 測試版本添加了對小程式原生元件的支援，實測坑很多，因為是測試版，官方在 issue 中也表示不推薦使用；按照官網文件，預設安裝的 v1.7.3 正式版本並不支援原生元件。
Tips2：wepy在 400 條列表以內，為何效能高於微信原生框架，這個跟自定義元件管理開銷及業務場景有關(wepy編譯為模板，不涉及元件建立及管理開銷)，後續對微博點贊，涉及元件資料傳遞時，微信原生框架的效能優勢就提現出來了，詳見下方測試資料。
相關連結：
自定義元件： 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：為什麼測試資料顯示 uni-app 會比微信原生框架的效能略好呢？
其實，在頁面上有 200 條記錄(200 個元件)時，taro 效能資料也比微信原生框架更好。
微信原生框架耗時主要在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
}) // 全量資料，傳送資料到檢視層
}
開發者使用微信原生框架，完全可以自己優化，精簡傳遞資料，比如修改如下：
data: {
listData: []
},
onReachBottom() { // 上拉載入
// 通過長度獲取下一次渲染的索引
let index = this.data.listData.length;
let newData = {}; // 新變更資料
Api.getNews().forEach((item) => {
newData['listData[' + (index++) + ']'] = item // 賦值，索引遞增
})
this.setData(newData) // 增量資料，傳送資料到檢視層
}
經過如上優化修改後，再次測試，微信原生框架效能資料如下：
從測試結果可看出，經過開發者手動優化，微信原生框架可達到更好的效能，但 uni-app、taro 相比微信原生，效能差距並不大。
這個結果，和 web 開發類似，web 開發也有原生 js 開發、vue、react 框架等情況。如果不做特殊優化，原生 js 寫的網頁，效能經常還不如 vue、react 框架的效能。
也恰恰是因為Vue、react框架的優秀，效能好，開發體驗好，所以原生 js 開發已經逐漸減少使用了。
複雜長列表載入下一頁評測結論：微信原生開發手工優化,uni-app>微信原生開發未手工優化,taro > wepy > mpvue
Tips：有人以為 uni-app 和 mpvue 是一樣的，早期 uni-app 確實使用過 mpvue，但後來因為效能和 vue 語法支援度問題已經重新開發了。
1.2.2 點贊元件響應速度長列表中的某個元件，比如點贊元件，點選時是否能及時的修改未贊和已贊狀態？是這項測試的評測點。
測試方式：
選中某微博，點選“點贊”按鈕，實現點贊狀態狀態切換(已贊高亮、未贊灰色)。
點贊按鈕 onclick函式開頭開始計時，setData回撥函式開頭結束計時。
在紅米手機(Redmi 6 Pro)上進行多次測試，求其平均值，結果如下：
說明：也就是在列表數量為 400 時，微信原生開發的應用，點贊按鈕從點選到狀態變化需要 111 毫秒。
測試結果資料說明：
wepy/mpvue 測試資料不完整的原因同上，在元件較多時，頁面已經不再渲染了。
基於微信自定義元件實現元件開發的框架(uni-app/taro)，元件資料通訊效能接近於微信原生框架，遠高於基於template實現元件開發的框架(wepy/mpvue)效能。
元件資料更新效能測評：微信原生開發,uni-app,taro > wepy > mpvue
綜上，本效能測試做了 2 個測試，長列表載入和元件狀態更新，綜合 2 個實驗，結論如下：
微信原生開發手工優化，uni-app>微信原生開發未手工優化,taro > wepy > mpvue
2. 開發者在滿足使用者業務需求的前提下，我們談談開發者的需求，從如下幾個維度比較：
平緩的學習曲線：簡單易學，最好能複用現有技術棧，豐富的學習資料。
高效的開發體驗：現代前端開發流程、工程化支援。
高效的社群支援：遇到問題，可很快的尋求到幫助。
活躍的開發迭代：框架處於積極更新升級狀態，無需擔心停更。
選擇開發團隊熟悉的、能快速上手的 DSL，是團隊框架選型的基本點。
首先微信原生的開發語法，既像React ，又像Vue，有點不倫不類，對於開發者來說，等於又要學習一套新的語法，大幅提升了學習成本，這一直被大家所詬病。
其它開發框架基本都遵循 React、Vue(類 Vue)語法，其主要目的：複用工程師的現有技術棧，降低學習成本。此時，框架對於原框架(React/Vue)語法的支援度就是一個重要的衡量標準，如果支援度較低、和原框架語法差異較大，則開發者無異於要學習一門新的框架，成本太高。
實際開發中發現，各個開發框架，都沒有完全實現Vue、React在 web 上的所有語法：
wepy開發風格接近於 Vue.js，屬於類 Vue實現，相對微信原生開發算前進了一大步，但相比完整Vue語法還有較大差距，開發時需要單獨學習它的規則；
mpvue、uni-app 框架基於 Vue.js 核心，通過修改 Vue.js 的 runtime 和 compiler，實現了在小程式端的執行。mpvue支援的 Vue 語法略少，uni-app 則基本支援絕大多數 vue 語法，如filter、複雜 JavaScript 表示式等；
taro 對於 JSX 的語法支援度，也達到了絕大多數都支援的完善程度。
DSL 語法支援評測：taro,uni-app > mpvue > wepy > 微信原生
2.1.2 學習資料完善度官方文件、問題搜尋、示例 demo 的完備度方面：
微信原生：文件豐富，API 搜尋準確，官方有示例 demo，支援官網上調起微信開發者工具，預覽執行效果 ，詳見： https://developers.weixin.qq.com/miniprogram/dev/index.html
wepy：文件只有 2 頁，沒有搜尋，元件 API 等文件都直接看微信的文件。沒有提供示例 demo，很多配置需要靠猜。詳見： https://tencent.github.io
mpvue：文件較少，但其概念不復雜，元件 API 等文件都直接看微信的文件，學習難度低。問題搜尋效果一般。沒有提供示例 demo。詳見： http://mpvue.com/
taro：基礎文件完整，具體使用問題資源較少，問題搜尋效果一般，示例 demo 只包含基礎功能，僅釋出了微信一端。詳見： https://taro.aotu.io/
uni-app：基礎文件和各種使用專題內容豐富，問題搜尋效果較好，示例 demo 功能完備，併發布為 7 端上線。詳見： https://uniapp.dcloud.io/
教學課程方面：
學習資料完善度評測：微信原生 > uni-app > mpvue , taro > wepy
2.2 現代前端開發體驗開發體驗層面，處於明顯劣勢的是微信原生開發，主要差距在於：
框架開發提供了精簡的程式碼組織(微信原生開發，一個 Page 由 4 個檔案構成，寫個程式碼要開的標籤卡太多)。
框架開發提供了更強大的元件化能力。
框架開發提供了應用狀態管理(類 Vuex/Redux/Mobx 等)。
框架開發能靈活支援各種 Sass 等 前處理器。
框架開發可提供完整的 ES Next 語法支援。
框架開發方便自定義構建策略。
其它小程式開發框架均支援cli模式，可以在主流前端工具中開發，且基本都帶有 d.ts 的語法提示庫。
由於mpvue、uni-app、taro直接支援vue、react語法，配套的 ide 工具鏈較豐富，著色、校驗、格式化完善；wepy要弱一些，有部分三方維護的 vscode 外掛。
好的開發工具，絕對可以大幅提升開發體驗，這個維度上，明顯高出一截的框架是uni-app，其出品公司同時也是 HBuilder 的出品公司，DCloud.io(https://dcloud.io/)。HBuilder 是四大主流前端開發工具(可對比百度指數，詳見下方連結)，其為uni-app做了很多優化，故uni-app的開發效率、易用性非其他框架可及。
開發體驗維度，對比結果：uni-app > taro,mpvue > wepy > 微信原生
這裡可以輸出一個結論：如果你需要工程化能力，那就直接忘了微信原生開發吧。
相關連結：
對比百度指數： http://zhishu.baidu.com/v2/main/index.html#/trend/vscode?words=vscode,hbuilder,webstorm,sublime
2.3 高效的社群支援學習、開發難免遇到問題，官方技術支援和社群活躍度很重要。
本次評測 demo 開發期間，我們的同學(同時掌握 vue 和 react)，在學習研究各個多端框架時，切實感受到由於語法、學習資料、社群的差異帶來的學習門檻，吐出了很多槽。
綜合評估，本項評測結論：微信原生 , uni-app > taro > mpvue > wepy
開發者必須關心一個問題：該專案是否有人長期維護？
這個問題可以通過 github commits 頻次、產品更新日誌(changelog)、百度搜索指數等指標來衡量和對比。
github commits 頻次
我們採集 2019 年 4 月份(時間為 4.1 ~ 4.30)，每個專案在 github 上的 master 分支有 commit 的天數，結果如下：
Tips：
微信原生是閉源的，看不到 commits 數量，但保持每月至少一次的更新節奏，詳見： https://developers.weixin.qq.com/miniprogram/dev/framework/release.html
wepy的 master 分支無 commit，最新的 2.0.x 分支在 4 月份也僅 1 天有 commit 記錄。
從 commit 的記錄來看，taro、uni-app處於更新比較活躍的狀態，wepy、mpvue則相對疲軟，呈現無人維護之態。
產品更新日誌
通過瀏覽產品更新日誌，可確認產品是否在積極迭代、增加新功能、修復使用者 bug。
我們分別檢視各框架官方連結的更新日誌(CHANGELOG)，下方是連結地址：
微信基礎庫更新日誌： https://developers.weixin.qq.com/miniprogram/dev/framework/release.html
wepy 官網 CHAGELOG： https://tencent.github.io/wepy/document.html#/changelog
mpvue 官網 Chang log： http://mpvue.com/change-log/
taro github 更新日誌： https://github.com/NervJS/taro/blob/master/CHANGELOG.md
uni-app 官網更新日誌：
http://update.dcloud.net.cn/hbuilderx/changelog/1.9.9.20190522.html
通過產品更新日誌對比，微信原生、taro、uni-app 三者更新頻繁，bug 修復、新功能補充都處於比較緊湊的狀態；而mpvue、wepy則已有長時間沒有版本釋出，wepy甚至有將近 1 年時間未釋出正式版本，開發者選型需謹慎。
2.5 多端複用隨著微信小程式的火爆，支付寶、百度、位元組跳動等公司也先後進入小程式領域，這些公司個個日活過億，坐擁海量使用者，企業主希望將自己的業務觸達每個使用者，不管這個使用者在哪個小程式中。
需求轉接到程式設計師這裡，程式設計師怎麼辦？難道真的每個平臺到處搬磚嗎？此時，一套程式碼、多端釋出就成為很多程式設計師的夢想，小程式跨端框架應運而生。
現實真能如此理想嗎？每個跨端框架能否真的像官網宣傳的那樣，實現開發一次，釋出到所有小程式平臺？甚至和 H5 平臺複用程式碼？
我們用事實說話，依然使用上述仿微博 App： https://github.com/dcloudio/test-framework 依次釋出到各平臺，驗證每個框架在各端的相容性，結果如下：
測試結果說明：
⭕ 表示支援且功能正常，❌ 表示不支援，其它則表示支援但存在部分 bug 或相容問題
通過這個簡單的例子可以看出，跨端支援度測評結論： uni-app,taro > mpvue> 原生微信小程式、wepy
但是僅有上面的測試還不全面，實際業務要比這個測試例複雜很多。但我們沒法開發很多複雜業務做評測，所以還需要再對照各家文件補充一些資訊。由於每個框架的文件中都描述了各種元件和 API 的跨端支援程度。我們過了幾家的文件，發現各家基本是以微信小程式為基線，然後把各種元件和 API 在其他端實現了一遍：
taro：H5 端實現了大部分微信的 API。
uni-app：元件、API、配置，大部分在各個端均已實現，個別 API 有說明在某些端不支援。可以看出 uni-app 是完整在 H5 端實現了一套微信模擬器。
跨端框架，一方面要考慮框架提供的通用 api 跨端支援，同時還要考慮不同端的特色差異如何相容。畢竟每個端都會有自己的特色，不可能完全一致。
taro：提供了 js 環境變數判斷和統一介面的多端檔案，可以在元件、js、檔案方面擴充套件多端，不支援其他環節的分平臺處理。
uni-app：提供了條件編譯模型，所有程式碼包括元件、js、css、配置 json、檔案、目錄，均支援條件編譯，可不受限的編寫各端差異程式碼。
跨端框架，還涉及一個 ui 框架的跨端問題，評測結果如下：
taro：官方提供了taro ui，只支援微信小程式和 H5 兩端，不支援 App，詳見：
https://taro-ui.aotu.io/#/uni-app：官方提供了uni ui，可全端執行；uni-app 還有一個外掛市場，裡面有很多三方 ui 元件，詳見：
https://ext.dcloud.net.cn/
最後補充跨端案例：
mpvue：微信端案例豐富，未見其它端案例
taro：微信端案例豐富，百度、支付寶、H5 端亦有少量案例
uni-app：多端案例豐富，官方示例已釋出到 7 端 (包括 App 端)
綜合以上資訊，本項的最終評測結論：uni-app > taro > mpvue > 原生微信小程式、wepy
這裡可以輸出一個結論，如果有多端釋出需求，微信原生開發、wepy這兩種方式可以直接排除了。
結語真實客觀的永遠是實驗和資料，而不是結論。不同需求的開發者，可以根據上述實驗資料，自行得出自己的選型結論。
但作為一篇完整的評測，我們也必須提供一份總結，雖然它可能加入了我們的主觀感受：
如果你只開發微信小程式，不做多端，那麼使用uni-app、taro是更優的選擇，他們相當於 web 世界的 vue 和 react，有了這些工具，不再需要使用原生 wxml 開發。
如果堅持微信原生開發，需要注意手動寫優化程式碼來控制setdata，並且注意其工程化能力非常弱。
如果你是react系，那就用taro。
如果是vue系，那就用uni-app，uni-app在效能、周邊生態和開發效率上更有優勢。
如果你開發多端，uni-app和taro都可以，可根據自己熟悉的技術棧選擇，相對而言uni-app的多端成熟度更高一些。
如有讀者認為本文中任何評測失真，歡迎在這裡報 issuse： https://github.com/dcloudio/test-framework
