歡迎您光臨深圳塔燈網(wǎng)絡(luò)科技有限公司！
余先生：13699882642
余先生：13699882642
8年
專注物流供應(yīng)鏈系統(tǒng)
余先生：13699882642
發(fā)表日期：2019-11 文章編輯：小燈 瀏覽次數(shù)：16214
小程序原生開發(fā)有不少槽點：
作為前端工程師，除了微信小程序，還要開發(fā)web、其他小程序甚至App，人們不喜歡來回切換開發(fā)工具和變更語法思考方式。
uni-app自然可以解決這些問題，但開發(fā)者又經(jīng)常有些顧慮：
本文從開發(fā)者關(guān)心的功能、性能、學(xué)習(xí)門檻、開發(fā)體驗、生態(tài)、可擴(kuò)展性等維度，逐個分析對比，給予說明。
開發(fā)者最常問的問題：如果小程序迭代升級，新增了一批API，但uni-app框架未及時更新，該怎么辦？
其實這是誤解，uni-app不限制底層API 調(diào)用；在小程序端，uni-app支持直接編寫微信原生代碼。
類比傳統(tǒng)web開發(fā)，如果vue、react等框架的使用，造成開發(fā)者無法操作瀏覽器提供的所有api，那這樣的框架肯定是不成熟的。小程序開發(fā)也一樣，uni-app框架中，同樣可調(diào)用微信提供的所有原生代碼。
故如果存在某些API（平臺特有或新增API），uni-app尚未封裝，開發(fā)者可直接在uni-app中編寫微信原生API，即wx.開頭的各種API。
舉個例子，目前uni-app雖然尚未封裝跨平臺的廣告（ad）組件，但開發(fā)者在小程序端依然可以使用微信<ad>組件來展現(xiàn)廣告，代碼示例如下：
企業(yè)建站知識
推廣知識
小程序
微信營銷
APP開發(fā)
<view>
<view class="title">微信官方banner廣告</view>
<view style="min-height: 50px;">
<!-- uni-app尚未封裝，但可直接使用微信原生的ad組件-->
<ad unit-id="adunit-01b7axxxbf53d74e"></ad>
</view>
<view class="title">微信官方視頻廣告</view>
<view style="min-height: 50px;">
<!-- uni-app尚未封裝，但可直接使用微信原生的ad組件-->
<ad unit-id="adunit-9f340xxx64533" ad-type="video" ad-theme="white"></ad>
</view>
</view>小程序端運(yùn)行效果如下：
包括微信小程序自定義組件、WXS、云開發(fā)這些復(fù)雜用法，在uni-app里一樣全面支持。
所以，結(jié)論是：使用uni-app框架開發(fā)，在功能上和原生小程序開發(fā)沒有區(qū)別，不會有任何限制。
開發(fā)者常問的第二個問題：三方框架，內(nèi)部大多做了層層封裝，這些封裝是否會增加運(yùn)行負(fù)載，導(dǎo)致性能下降？
同樣是多慮了，uni-app不會導(dǎo)致性能下載，甚至對很多環(huán)節(jié)做了自動優(yōu)化，很多場景下性能體驗比微信原生開發(fā)更好。
類似使用vue.js開發(fā)web，不但不會造成性能比原生js差，反而由于虛擬dom和差量更新技術(shù)的運(yùn)用，在大多數(shù)場景下，比開發(fā)者手動寫代碼操作dom的性能還好。
小程序中需要頻繁的寫setData代碼來更新數(shù)據(jù)，這里很重要的就是差量數(shù)據(jù)更新。如果不做差量，代碼性能不好，如果每處邏輯都判斷差量數(shù)據(jù)更新，那代碼寫起來太麻煩了。
使用uni-app，底層自動差量數(shù)據(jù)更新，簡單而高性能。
我們從優(yōu)化理論、實測數(shù)據(jù)兩個維度來仔細(xì)說明。
為提高性能體驗，小程序從架構(gòu)設(shè)計層面做了很多工作：
通過這些規(guī)范約束，大幅提升了小程序的整體性能體驗，但依然存在不少性能坑點，其中以setData最為頻繁普遍。
這里引用微信官方的描述，簡單介紹一下setData背后的工作原理：
小程序的視圖層目前使用 WebView 作為渲染載體，而邏輯層是由獨立的 JavascriptCore 作為運(yùn)行環(huán)境。在架構(gòu)上，WebView 和 JavascriptCore 都是獨立的模塊，并不具備數(shù)據(jù)直接共享的通道。當(dāng)前，視圖層和邏輯層的數(shù)據(jù)傳輸，實際上通過兩邊提供的 evaluateJavascript 所實現(xiàn)。
為簡化開發(fā)，微信將evaluateJavascript調(diào)用封裝成了setData JS方法，實現(xiàn)視圖層和邏輯層的數(shù)據(jù)傳輸，數(shù)據(jù)流示意圖如下：
setData的執(zhí)行會受到很多因素的影響，setData每次傳遞數(shù)據(jù)量過大或頻繁被調(diào)用（見微信官方介紹），都可能引發(fā)性能體驗問題。
幸運(yùn)的是，uni-app在這兩個方面都有優(yōu)化。
假設(shè)當(dāng)前頁面有一個列表（初始值為a,b,c,d），現(xiàn)在要向列表后追加4個新列表項（e,f,g,h），我們分別以微信原生、uni-app 兩種模式編寫代碼。
小程序原生代碼：
page({
data:{
list:['a','b','c','d']
},
change:function(){
let newData = ['e','f','g','h'];
this.data.list.push(...newData);
this.setData({
list:this.data.list
})
}
})如上微信原生代碼，change方法執(zhí)行時，會將list中的a,b,c,d,e,f,g,h8個列表項通過setData全部傳輸過去。
uni-app 代碼：
export default{
data(){
return {
list:['a','b','c','d']
}
},
methods:{
change:function(){
let newData = ['e','f','g','h'];
this.list.push(...newData)
}
}
}如上uni-app代碼，change方法執(zhí)行時，僅會將list中的e,f,g,h4個新增列表項傳輸過去，實現(xiàn)了setData傳輸量的極簡化。
uni-app借鑒了 westore JSON Diff庫，在調(diào)用setData之前，會先比對歷史數(shù)據(jù)，精確、高效計算出有變化的差量數(shù)據(jù)，然后再調(diào)用setData，僅傳輸變化的數(shù)據(jù)，這樣就實現(xiàn) setData 傳遞數(shù)據(jù)量的最小化，大幅提高通訊性能。
Tips：也許有些同學(xué)對傳遞數(shù)據(jù)從a,b,c,d,e,f,g,h8個列表項優(yōu)化為e,f,g,h4個列表項，不以為然，但我們提醒，不要小看這個機(jī)制，上述只是demo示例。
假設(shè)我們有更改多個變量值的需求，我們分別以微信原生、uni-app 兩種模式編寫代碼。
小程序原生代碼：
change:function(){
this.setData({a:1});
this.setData({b:2});
this.setData({c:3});
this.setData({d:4});
}如上四次調(diào)用setData，就會引發(fā)4次邏輯層、視圖層數(shù)據(jù)通訊
uni-app 代碼：
change:function(){
this.a = 1;
this.b = 2;
this.c = 3;
this.d = 4;
}如上uni-app的代碼，最后會被合并成{"a":1,"b":2,"c":3,"d":4}一條數(shù)據(jù)，然后僅調(diào)用一次setData完成所有數(shù)據(jù)傳遞，大幅降低了setData的調(diào)用頻次。
uni-app之所以有這樣的優(yōu)勢，是因為 uni-app 基于 Vue Runtime 深度定制實現(xiàn)，并借助了 Vue 的 nextTick 機(jī)制。
有了如上的理論分析，我們接著進(jìn)行真機(jī)實測，用數(shù)據(jù)來對比。
測試模型如下：
仿微博的列表是一個包含很多組件的列表，這種復(fù)雜列表對性能的壓力更大，很適合做性能測試。
cli方式默認(rèn)安裝。Tips:若有同學(xué)覺得測試代碼寫法欠妥，歡迎提交 PR 或 Issus，本項目下還有其它框架的測試代碼，開發(fā)者可忽略
從觸發(fā)上拉加載到數(shù)據(jù)更新、頁面渲染完成，需要準(zhǔn)確計時。人眼視覺計時肯定不行，我們采用程序埋點的方式，制定了如下計時時機(jī)：
Tips：setData回調(diào)函數(shù)開頭可認(rèn)為是頁面渲染完成的時間，是因為微信setData定義如下(微信規(guī)范)：
| 字段 | 類型 | 必填 | 描述 |
|---|---|---|---|
| data | Object | 是 | 這次要改變的數(shù)據(jù) |
| callback | Function | 否 | setData引起的界面更新渲染完畢后的回調(diào)函數(shù) |
測試方式：從頁面空列表開始，通過程序自動觸發(fā)上拉加載，每次新增20條列表，記錄單次耗時；固定間隔連續(xù)觸發(fā) N 次上拉加載，使得頁面達(dá)到 20*N 條列表，計算這 N 次觸發(fā)上拉到渲染完成的平均耗時。
測試結(jié)果如下：
| 列表條數(shù) | 微信原生 | uni-app |
|---|---|---|
| 200 | 770 | 641 |
| 400 | 876 | 741 |
| 600 | 1111 | 910 |
| 800 | 1406 | 1113 |
| 1000 | 1690 | 1321 |
說明：以400條微博列表為例，從頁面空列表開始，每隔1秒觸發(fā)一次上拉加載（新增20條微博），記錄單次耗時，觸發(fā)20次后停止（頁面達(dá)到400條微博），計算這20次的平均耗時，結(jié)果微信原生在這20次 觸發(fā)上拉 -> 渲染完成 的平均耗時為876毫秒，uni-app是741毫秒。
這個數(shù)據(jù)，可能違反了很多人的直覺，uni-app 的性能竟然比微信原生還好！
不必疑惑，這就是上面理論分析章節(jié)中，減少setData傳遞數(shù)據(jù)量優(yōu)化方案的結(jié)果；微信原生每次傳遞全量數(shù)據(jù)，而uni-app在調(diào)用setData之前會自動做diff計算，每次僅傳遞變動的數(shù)據(jù)。
開發(fā)者使用微信原生框架，完全可以自己優(yōu)化，精簡傳遞數(shù)據(jù)，比如修改如下：
data: {
listData: []
},
onReachBottom() { //上拉加載
// 通過長度獲取下一次渲染的索引
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)化修改后，再次測試，微信原生框架性能數(shù)據(jù)如下：
| 組件數(shù)量 | 微信原生框架（優(yōu)化前） | 微信原生框架（優(yōu)化后） | uni-app |
|---|---|---|---|
| 200 | 770 | 572 | 641 |
| 400 | 876 | 688 | 741 |
| 600 | 1111 | 855 | 910 |
| 800 | 1406 | 1055 | 1113 |
| 1000 | 1690 | 1260 | 1321 |
從測試結(jié)果可看出，經(jīng)過開發(fā)者手動優(yōu)化，微信原生框架可達(dá)到更好的性能，但 uni-app相比微信原生，性能差距并不大。
但原生開發(fā)需要開發(fā)者熟悉小程序通訊機(jī)制，有意識的去編寫代碼，精簡數(shù)據(jù)；uni-app自動處理，自然是更省心。
這個結(jié)果，和web開發(fā)類似，web開發(fā)也有原生js開發(fā)、vue、react框架等情況。如果不做特殊優(yōu)化，原生js寫的網(wǎng)頁，性能經(jīng)常還不如vue、react框架的性能。
也恰恰是因為Vue、react框架的優(yōu)秀，性能好，開發(fā)體驗好，所以原生js開發(fā)已經(jīng)逐漸減少使用了。
通過本章節(jié)性能優(yōu)化的理論分析及數(shù)據(jù)實測，我們可以輸出這么個結(jié)論：
小程序是脫離web自造生態(tài)，很多web生態(tài)中輪子無法使用。
微信小程序還是有周邊生態(tài)的，而其他幾家小程序平臺的生態(tài)基本沒建起來。
uni-app的周邊生態(tài)非常豐富，在插件市場有近800個插件，詳見 ext.dcloud.net.cn。
首先uni-app兼容小程序的生態(tài)，各種自定義組件均可直接引入使用。在此基礎(chǔ)上，uni-app的插件市場，有更多vue組件，同時可跨多端使用，并且性能優(yōu)秀。
這使得uni-app的生態(tài)成為最豐富的小程序開發(fā)生態(tài)。
比如富文本解析、圖表等組件，uni-app的插件性能均超過了wxparse、wx-echart等微信小程序組件。
如果開發(fā)者需要豐富和高性能的組件，更應(yīng)該使用uni-app，而不是原生小程序開發(fā)。
uni-app官方有 70 個開發(fā)者QQ/微信交流群（大多2千人群，近10萬開發(fā)者），三方群更多。
問答社區(qū)，每天有數(shù)百篇帖子。活躍度與微信小程序官方論壇相同，遠(yuǎn)超過其他小程序官方論壇。
uni-app三方培訓(xùn)活躍，騰訊課堂官方都為uni-app制作了課程，各種培訓(xùn)網(wǎng)站到處可見免費或收費的uni-app培訓(xùn)視頻教程。
首先微信原生的開發(fā)語法，既像React ，又像Vue，有點不倫不類，對于開發(fā)者來說，等于又要學(xué)習(xí)一套新的語法，大幅提升了學(xué)習(xí)成本，這一直被大家所詬病。
uni-app則對開發(fā)者更為友好，簡單來說是 vue的語法 + 小程序的api。
它遵循Vue.js語法規(guī)范，組件和API遵循微信小程序命名，這些都屬于通用技術(shù)棧，學(xué)習(xí)它們是前端必備技能，uni-app沒有太多額外學(xué)習(xí)成本。
有一定 Vue.js 和微信小程序開發(fā)經(jīng)驗的開發(fā)者可快速上手 uni-app 。
沒學(xué)過vue的同學(xué)，也不用掌握vue的全部，只需了解vue基礎(chǔ)語法、數(shù)據(jù)綁定、列表渲染、組件等，其他如路由、loader、cli、node.js、webpack并不需要學(xué)。
因為HBuilderX工具搭配uni-app可以免終端開發(fā)，可視化創(chuàng)建項目、可視化安裝組件和擴(kuò)展編譯器，也就是uni-app的學(xué)習(xí)門檻，比web開發(fā)的vue.js還低。
開發(fā)體驗層面，微信原生開發(fā)相比uni-app有較大差距，主要體現(xiàn)在：
開發(fā)工具維度，差距更大：
uni-app的出品公司，同時也是HBuilder的出品公司，DCloud.io。HBuilder/HBuilderX系列是四大主流前端開發(fā)工具（可對比百度指數(shù)），其為uni-app做了很多優(yōu)化，故uni-app的開發(fā)效率、易用性非微信原生開發(fā)可及。這里可以輸出一個結(jié)論：如果你需要工程化能力，那就直接忘了微信原生開發(fā)吧。
雖然當(dāng)前產(chǎn)品僅要求發(fā)布到微信小程序，但若有一天，老板和外來的一個和尚喝完咖啡，轉(zhuǎn)身就要求覆蓋阿里、百度、字節(jié)跳動等各家小程序平臺，此時程序員該怎么辦？
難道真的每個平臺到處搬磚嗎？
此時，uni-ap的跨端功能將成為程序員的自救神器，基于uni-app開發(fā)的小程序，無需修改，即可同時發(fā)布到多家小程序，甚至App、H5平臺。這不是夢想，而是現(xiàn)實。大家可依次掃描如下8個二維碼，親自體驗最全面的跨平臺效果！。
| uni-app | 微信 | |
|---|---|---|
| 功能 | 相同 | 相同 |
| 性能 | 常規(guī)場景更優(yōu) | 需要自己編寫復(fù)雜代碼才能提高性能 |
| 社區(qū)生態(tài) | 豐富，更多高性能組件 | 豐富 |
| 開發(fā)體驗 | 純vue體驗，高效、統(tǒng)一；工程化能力強(qiáng) | 語法私有化；工程化能力弱 |
| 多端能力 | 同時支持H5、多家小程序、跨平臺App | 只能用于微信小程序 |
結(jié)論：只開發(fā)微信小程序，也應(yīng)該使用uni-app
