1. <i id="4oi88"></i>
    1. <acronym id="4oi88"><thead id="4oi88"></thead></acronym>

          <source id="4oi88"><mark id="4oi88"></mark></source>
          <tt id="4oi88"><small id="4oi88"></small></tt>
          1. News新聞動(dòng)態(tài)
            微信小程序開(kāi)發(fā)總結
            自 2017年1月9日微信小程序誕生以來(lái),歷經(jīng) 2 年多的迭代升級,已有數百萬(wàn)小程序上線(xiàn),成為繼 Web、iOS、Android 之后,第四大主流開(kāi)發(fā)技術(shù)。


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


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


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


            原生開(kāi)發(fā)對 Node、預編譯器、webpack 支持不好,影響開(kāi)發(fā)效率和工程構建流程。


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


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


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


            同時(shí),開(kāi)發(fā)者對三方框架,又總是有各種顧慮:


            怕性能不如原生。


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


            怕框架不穩定,跳到坑里。


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


            面對如此糾結的場(chǎng)景,不少熱心開(kāi)發(fā)者發(fā)布評測文章分享經(jīng)驗,但感覺(jué)眾說(shuō)紛紜,過(guò)期信息太多。缺少一份非常專(zhuān)業(yè)的、深度的,或者按如今流行的話(huà)來(lái)講,“硬核的”評測報告。


            做評測報告這件事,不同于泛泛經(jīng)驗分享,其實(shí)非;ㄙM時(shí)間。它需要:


            你必須成為每一個(gè)框架的專(zhuān)業(yè)使用人員,而不是淺淺的了解一下這些框架。


            真實(shí)的動(dòng)手寫(xiě)多個(gè)平臺的測試例,比較各個(gè)平臺的功能、性能,了解他們的社區情況、技術(shù)服務(wù)情況。


            你要有長(cháng)期跟蹤和更新報告的能力,避免半年后淪為過(guò)期信息。


            換言之:評測要想真,功夫得做深!


            uni-app團隊花費 2 個(gè)周時(shí)間完成本報告,并堅持每個(gè)季度更新一次本評測報告。目前更新時(shí)間為 2019 年 5 月。


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


            面向用戶(hù)、面向開(kāi)發(fā)者維度,具體包括:


            用戶(hù):提供完整的業(yè)務(wù)實(shí)現,并保證高性能體驗。


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


            1. 用戶(hù)
            1.1 功能實(shí)現
            軟件開(kāi)發(fā),首要目標是向用戶(hù)提供完整、閉環(huán)的業(yè)務(wù)功能。


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


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


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


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


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


            taro:支持微信的所有原生組件和 api,無(wú)限制。同時(shí)框架封裝了自己的跨端 API,使用方式類(lèi)似Taro.request(),支持 Taro 代碼與小程序代碼混寫(xiě)(詳見(jiàn)下面的鏈接),可通過(guò)混寫(xiě)的方式調用框架尚未封裝的小程序新增 API。


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


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


            相關(guān)鏈接:


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


            條件編譯:


            https://uniapp.dcloud.io/platform


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


            然而有差別的,是性能體驗。


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


            為客觀(guān)的進(jìn)行對比,我們特意搭建了一個(gè)測試模型,詳細如下:


            開(kāi)發(fā)內容:開(kāi)發(fā)一個(gè)仿微博小程序首頁(yè)的復雜長(cháng)列表,支持下拉刷新、上拉翻頁(yè)、點(diǎn)贊。


            界面如下:






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


            測試代碼開(kāi)源,Github 倉庫地址:https://github.com/dcloudio/test-framework。Tips:若有同學(xué)覺(jué)得測試代碼寫(xiě)法欠妥,歡迎提交 PR 或 issus。issus 地址:


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


            測試機型:紅米 Redmi 6 Pro、MIUI 10.2.2.0 穩定版(最新版)、微信版本 7.0.3(最新版)。


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


            我們以上述仿微博小程序為例,測試 2 個(gè)容易出性能問(wèn)題的點(diǎn):長(cháng)列表加載、大量點(diǎn)贊組件的響應。


             1.2.1 長(cháng)列表加載
            仿微博的列表是一個(gè)包含很多組件的列表,這種復雜列表對性能的壓力更大,很適合做性能測試。


            從觸發(fā)上拉加載到數據更新、頁(yè)面渲染完成,需要準確計時(shí)。人眼視覺(jué)計時(shí)肯定不行,我們采用程序埋點(diǎn)的方式,制定了如下計時(shí)時(shí)機:


            計時(shí)開(kāi)始時(shí)機:交互事件觸發(fā),框架賦值之前,如:上拉加載(onReachBottom)函數開(kāi)頭


            計時(shí)結束時(shí)機:頁(yè)面渲染完畢 (微信 setData 回調函數開(kāi)頭)


            Tips:setData回調函數開(kāi)頭可認為是頁(yè)面渲染完成的時(shí)間,是因為微信setData定義(具體詳見(jiàn)下方鏈接)如下:






            相關(guān)鏈接:


            微信規范:


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


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


            測試結果如下:






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


            大家初看這個(gè)數據,可能比較疑惑,別急,下方有詳細說(shuō)明


            說(shuō)明 1:為何 mpvue/wepy 測試數據不完整?


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


            但如此方案,在頁(yè)面復雜、組件較多的時(shí),會(huì )大量增加頁(yè)面 dom 節點(diǎn)數量,甚至超出微信的 dom 節點(diǎn)數限制。我們在 紅米手機(Redmi 6 Pro)上實(shí)測,頁(yè)面組件超過(guò) 500 個(gè)時(shí),mpvue、wepy  實(shí)現的仿微博 App 就會(huì )報出如下異常,并停止渲染,故這兩個(gè)測試框架在組件較多時(shí),測試數據不完整。這也就意味著(zhù),當頁(yè)面組件太多時(shí),無(wú)法使用這 2 個(gè)框架。


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


            Tips1:wepy官網(wǎng)的 CHANGELOG(詳見(jiàn)下方鏈接),提到 v1.7.2 測試版本添加了對小程序原生組件的支持,實(shí)測坑很多,因為是測試版,官方在 issue 中也表示不推薦使用;按照官網(wǎng)文檔,默認安裝的 v1.7.3 正式版本并不支持原生組件。


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


            相關(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


            說(shuō)明 2:為什么測試數據顯示 uni-app 會(huì )比微信原生框架的性能略好呢?


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


            微信原生框架耗時(shí)主要在setData調用上,開(kāi)發(fā)者若不單獨優(yōu)化,則每次都會(huì )傳遞大量數據;而 uni-app、taro 都在調用setData之前自動(dòng)做diff計算,每次僅傳遞變動(dòng)的數據。


            例如當前頁(yè)面有 20 條數據,觸發(fā)上拉加載時(shí),會(huì )新加載 20 條數據,此時(shí)原生框架通過(guò)如下代碼測試時(shí),setData會(huì )傳輸 40 條數據


            data: {
                listData: []
            },
            onReachBottom() { // 上拉加載
                let listData = this.data.listData;
                listData.push(...Api.getNews());// 新增數據
                this.setData({
                    listData
                }) // 全量數據,發(fā)送數據到視圖層
            }
            開(kāi)發(fā)者使用微信原生框架,完全可以自己優(yōu)化,精簡(jiǎn)傳遞數據,比如修改如下:


            data: {
                listData: []
            },
            onReachBottom() { // 上拉加載
                // 通過(guò)長(cháng)度獲取下一次渲染的索引
                let index = this.data.listData.length;
                let newData = {}; // 新變更數據
                Api.getNews().forEach((item) => {
                    newData['listData[' + (index++) + ']'] = item // 賦值,索引遞增
                }) 
                this.setData(newData) // 增量數據,發(fā)送數據到視圖層
            }
            經(jīng)過(guò)如上優(yōu)化修改后,再次測試,微信原生框架性能數據如下:






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


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


            也恰恰是因為Vue、react框架的優(yōu)秀,性能好,開(kāi)發(fā)體驗好,所以原生 js 開(kāi)發(fā)已經(jīng)逐漸減少使用了。


            復雜長(cháng)列表加載下一頁(yè)評測結論:微信原生開(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)因為性能和 vue 語(yǔ)法支持度問(wèn)題已經(jīng)重新開(kāi)發(fā)了。


             1.2.2 點(diǎn)贊組件響應速度
            長(cháng)列表中的某個(gè)組件,比如點(diǎn)贊組件,點(diǎn)擊時(shí)是否能及時(shí)的修改未贊和已贊狀態(tài)?是這項測試的評測點(diǎn)。


            測試方式:


            選中某微博,點(diǎn)擊“點(diǎn)贊”按鈕,實(shí)現點(diǎn)贊狀態(tài)狀態(tài)切換(已贊高亮、未贊灰色)。


            點(diǎn)贊按鈕 onclick函數開(kāi)頭開(kāi)始計時(shí),setData回調函數開(kāi)頭結束計時(shí)。


            在紅米手機(Redmi 6 Pro)上進(jìn)行多次測試,求其平均值,結果如下:






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


            測試結果數據說(shuō)明:


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


            基于微信自定義組件實(shí)現組件開(kāi)發(fā)的框架(uni-app/taro),組件數據通訊性能接近于微信原生框架,遠高于基于template實(shí)現組件開(kāi)發(fā)的框架(wepy/mpvue)性能。


            組件數據更新性能測評:微信原生開(kāi)發(fā),uni-app,taro > wepy > mpvue


            綜上,本性能測試做了 2 個(gè)測試,長(cháng)列表加載和組件狀態(tài)更新,綜合 2 個(gè)實(shí)驗,結論如下:


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


            2. 開(kāi)發(fā)者
            在滿(mǎn)足用戶(hù)業(yè)務(wù)需求的前提下,我們談(wù)勯_(kāi)發(fā)者的需求,從如下幾個(gè)維度比較:


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


            高效的開(kāi)發(fā)體驗:現代前端開(kāi)發(fā)流程、工程化支持。


            高效的社區支持:遇到問(wèn)題,可很快的尋求到幫助。


            活躍的開(kāi)發(fā)迭代:框架處于積極更新升級狀態(tài),無(wú)需擔心停更。


            2.1 平緩的學(xué)習曲線(xiàn)
             2.1.1 DSL 語(yǔ)法支持
            選擇開(kāi)發(fā)團隊熟悉的、能快速上手的 DSL,是團隊框架選型的基本點(diǎn)。


            首先微信原生的開(kāi)發(fā)語(yǔ)法,既像React ,又像Vue,有點(diǎn)不倫不類(lèi),對于開(kāi)發(fā)者來(lái)說(shuō),等于又要學(xué)習一套新的語(yǔ)法,大幅提升了學(xué)習成本,這一直被大家所詬病。


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


            實(shí)際開(kāi)發(fā)中發(fā)現,各個(gè)開(kāi)發(fā)框架,都沒(méi)有完全實(shí)現Vue、React在 web 上的所有語(yǔ)法:


            wepy開(kāi)發(fā)風(fēng)格接近于 Vue.js,屬于類(lèi) Vue實(shí)現,相對微信原生開(kāi)發(fā)算前進(jìn)了一大步,但相比完整Vue語(yǔ)法還有較大差距,開(kāi)發(fā)時(shí)需要單獨學(xué)習它的規則;


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


            taro 對于 JSX 的語(yǔ)法支持度,也達到了絕大多數都支持的完善程度。


            DSL 語(yǔ)法支持評測:taro,uni-app > mpvue > wepy > 微信原生


             2.1.2 學(xué)習資料完善度
            官方文檔、問(wèn)題搜索、示例 demo 的完備度方面:


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


            wepy:文檔只有 2 頁(yè),沒(méi)有搜索,組件 API 等文檔都直接看微信的文檔。沒(méi)有提供示例 demo,很多配置需要靠猜。詳見(jiàn):https://tencent.github.io


            mpvue:文檔較少,但其概念不復雜,組件 API 等文檔都直接看微信的文檔,學(xué)習難度低。問(wèn)題搜索效果一般。沒(méi)有提供示例 demo。詳見(jiàn):http://mpvue.com/


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


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


            教學(xué)課程方面:






            學(xué)習資料完善度評測:微信原生 > uni-app > mpvue , taro > wepy


            2.2 現代前端開(kāi)發(fā)體驗
            開(kāi)發(fā)體驗層面,處于明顯劣勢的是微信原生開(kāi)發(fā),主要差距在于:


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


            框架開(kāi)發(fā)提供了更強大的組件化能力。


            框架開(kāi)發(fā)提供了應用狀態(tài)管理(類(lèi) Vuex/Redux/Mobx 等)。


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


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


            框架開(kāi)發(fā)方便自定義構建策略。


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


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


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


            開(kāi)發(fā)體驗維度,對比結果:uni-app > taro,mpvue > wepy > 微信原生


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


            相關(guān)鏈接:


            對比百度指數:http://zhishu.baidu.com/v2/main/index.html#/trend/vscode?words=vscode,hbuilder,webstorm,sublime


            2.3 高效的社區支持
            學(xué)習、開(kāi)發(fā)難免遇到問(wèn)題,官方技術(shù)支持和社區活躍度很重要。






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


            綜合評估,本項評測結論:微信原生 , uni-app > taro > mpvue > wepy


            2.4 活躍的開(kāi)發(fā)迭代
            開(kāi)發(fā)者必須關(guān)心一個(gè)問(wèn)題:該項目是否有人長(cháng)期維護?


            這個(gè)問(wèn)題可以通過(guò) github commits 頻次、產(chǎn)品更新日志(changelog)、百度搜索指數等指標來(lái)衡量和對比。


            github commits 頻次


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






            Tips:


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


            wepy的 master 分支無(wú) commit,最新的 2.0.x 分支在 4 月份也僅 1 天有 commit 記錄。


            從 commit 的記錄來(lái)看,taro、uni-app處于更新比較活躍的狀態(tài),wepy、mpvue則相對疲軟,呈現無(wú)人維護之態(tài)。


            產(chǎn)品更新日志


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


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


            微信基礎庫更新日志: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


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


            2.5 多端復用
            隨著(zhù)微信小程序的火爆,支付寶、百度、字節跳動(dòng)等公司也先后進(jìn)入小程序領(lǐng)域,這些公司個(gè)個(gè)日活過(guò)億,坐擁海量用戶(hù),企業(yè)主希望將自己的業(yè)務(wù)觸達每個(gè)用戶(hù),不管這個(gè)用戶(hù)在哪個(gè)小程序中。


            需求轉接到程序員這里,程序員怎么辦?難道真的每個(gè)平臺到處搬磚嗎?此時(shí),一套代碼、多端發(fā)布就成為很多程序員的夢(mèng)想,小程序跨端框架應運而生。


            現實(shí)真能如此理想嗎?每個(gè)跨端框架能否真的像官網(wǎng)宣傳的那樣,實(shí)現開(kāi)發(fā)一次,發(fā)布到所有小程序平臺?甚至和 H5 平臺復用代碼?


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






            測試結果說(shuō)明:


            ⭕ 表示支持且功能正常,❌ 表示不支持,其它則表示支持但存在部分 bug 或兼容問(wèn)題


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


            但是僅有上面的測試還不全面,實(shí)際業(yè)務(wù)要比這個(gè)測試例復雜很多。但我們沒(méi)法開(kāi)發(fā)很多復雜業(yè)務(wù)做評測,所以還需要再對照各家文檔補充一些信息。由于每個(gè)框架的文檔中都描述了各種組件和 API 的跨端支持程度。我們過(guò)了幾家的文檔,發(fā)現各家基本是以微信小程序為基線(xiàn),然后把各種組件和 API 在其他端實(shí)現了一遍:


            taro:H5 端實(shí)現了大部分微信的 API。


            uni-app:組件、API、配置,大部分在各個(gè)端均已實(shí)現,個(gè)別 API 有說(shuō)明在某些端不支持?梢钥闯 uni-app 是完整在 H5 端實(shí)現了一套微信模擬器。


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


            taro:提供了 js 環(huán)境變量判斷和統一接口的多端文件,可以在組件、js、文件方面擴展多端,不支持其他環(huán)節的分平臺處理。


            uni-app:提供了條件編譯模型,所有代碼包括組件、js、css、配置 json、文件、目錄,均支持條件編譯,可不受限的編寫(xiě)各端差異代碼。


            跨端框架,還涉及一個(gè) ui 框架的跨端問(wèn)題,評測結果如下:


            taro:官方提供了taro ui,只支持微信小程序和 H5 兩端,不支持 App,詳見(jiàn):
            https://taro-ui.aotu.io/#/


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


            最后補充跨端案例:


            mpvue:微信端案例豐富,未見(jiàn)其它端案例


            taro:微信端案例豐富,百度、支付寶、H5 端亦有少量案例


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


            綜合以上信息,本項的最終評測結論:uni-app > taro > mpvue > 原生微信小程序、wepy


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


            結  語(yǔ)
            真實(shí)客觀(guān)的永遠是實(shí)驗和數據,而不是結論。不同需求的開(kāi)發(fā)者,可以根據上述實(shí)驗數據,自行得出自己的選型結論。


            但作為一篇完整的評測,我們也必須提供一份總結,雖然它可能加入了我們的主觀(guān)感受:


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


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


            如果你是react系,那就用taro。


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


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


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


            https://github.com/dcloudio/test-framework
            久久黄色视频,亚洲视频一区,JIZZ日本,樱桃视频大全免费观看,亚洲AV无码久久 开心婷婷五月激情综合社区| 亚洲av无码一区二区三区在线| 成全高清免费观看MV| 满18点此安全转入2023大象| 久久午夜夜伦痒痒想咳嗽P| 免费AV在线| 麻豆产国品一二三产品区别| 国产在aj精品| 亚洲AV无码久久精品狠狠爱浪潮| 欧美大片黑寡妇免费观看|