小程序科普類的文章已經(jīng)很多了,這里講下針對小程序的優(yōu)化方法,可以有效提高小程序的響應(yīng)速度和用戶體驗。當(dāng)然,開發(fā)體驗也提高不少。1、提高頁面加載速度—— ...
小程序科普類的文章已經(jīng)很多了,這里講下針對小程序的優(yōu)化方法,可以有效提高小程序的響應(yīng)速度和用戶體驗。當(dāng)然,開發(fā)體驗也提高不少。
在小程序這個環(huán)境下,怎樣提高頁面加載速度呢? 這個問題很大,我把問題具體一下,如何縮短從用戶點擊某個鏈接,到打開新頁面的這段時間? 這里拋一個核心關(guān)鍵點:
從頁面響應(yīng)用戶點擊行為,開始跳轉(zhuǎn),到新頁面onload事件觸發(fā),存在一個延遲,這個延遲大概在100-300ms之間(安卓響應(yīng)比ios慢些)。
這個延遲說短不短,我們可以利用這段時間,預(yù)先發(fā)起新頁面所需要的網(wǎng)絡(luò)請求。這樣一來,就節(jié)省了100-300ms(或者一個網(wǎng)絡(luò)請求的時間)。
知道有這個gap后,代碼如何實現(xiàn)呢?
說白了,就是實現(xiàn)一個在A頁面預(yù)加載B頁面數(shù)據(jù)的功能。但而這種跨頁面的調(diào)用,很容易把邏輯搞復(fù)雜,將不同頁面的邏輯耦合在一起。所以,我們希望將預(yù)加載的邏輯隱藏于無形中,不增加任何的頁面間耦合,以及開發(fā)復(fù)雜度。
下面以騰訊視頻小程序為例,講解下技術(shù)實現(xiàn)。
小程序首頁:
當(dāng)用戶點擊海報圖后,會執(zhí)行以下代碼(就一行):
onPlay: function (e) {
this.$route('/pages/play/index?cid='+this._cid);
}
接下來程序會加載播放頁:
播放頁主要代碼:
fetchData: function (query) {
},
onNavigate: function (res) {
this.$put('play-detail', this.fetchData(res.query));
},
onLoad: function (query) {
this.$take('play-detail') || this.fetchData(query);
}
可以看到,不管是外部頁面的調(diào)用還是實際邏輯的實現(xiàn)都非常簡潔。在第二個頁面中,我們擴展了Page的生命周期函數(shù),增加了onNavigate方法。該方法在頁面即將被創(chuàng)建但還沒開始創(chuàng)建的時候執(zhí)行。
老司機也許會發(fā)現(xiàn)這里有點蹊蹺。在首頁點擊的時候,播放頁根本就沒有創(chuàng)建,對象都不存在,怎么訪問到里面的方法呢?
這里就要說下微信的頁面機制。
在小程序啟動時,會把所有調(diào)用Page()方法的object存在一個隊列里(如下圖)。每次頁面訪問的時候,微信會重新創(chuàng)建一個新的對象實例(實際上就是深拷貝)。也就是說,在A頁面在執(zhí)行點擊響應(yīng)事件的時候,B頁面的實例還沒創(chuàng)建,這時候調(diào)用的onNavigate方法,實際上是Page對象的原型(小程序啟動時候創(chuàng)建的那個)。而接下來馬上要被創(chuàng)建的B頁面,又是另外一個object。所以,在onNavigate和onLoad方法中,this指針指的不是同一個對象,不能把臨時數(shù)據(jù)存儲在當(dāng)前object身上。因此我們封裝了一對全局的緩存方法,$put()和$take()。
為了通用性,Page上用到的公共的方法,比如$route、$put、$take都定義在了一個Page的基類里面?;愡€同時保存了所有頁面的list,這樣就可以做到根據(jù)頁面名調(diào)用具體頁面的onNavigate方法。 當(dāng)然,并不是每個頁面都需要實現(xiàn)onNavigate方法,對于沒有定義onNavigate方法的,$route函數(shù)會跳過預(yù)加載環(huán)節(jié),直接跳轉(zhuǎn)頁面。所以對于開發(fā)者來說,不需要關(guān)心別的頁面實現(xiàn)了什么,對外看來完全透明。
在上面的例子中,我們實現(xiàn)了用戶主動點擊頁面,提前加載下一頁面數(shù)據(jù)的方法。而在某些場景下,用戶的行為可以預(yù)測,我們可以在用戶還沒點擊的時候就預(yù)加載下個頁面的數(shù)據(jù)。讓下個頁面秒開,進一步提升體驗的流暢性。
繼續(xù)以騰訊視頻小程序為例,主界面分為3個頁卡(大部分小程序都會這么設(shè)計),通過簡單的數(shù)據(jù)分析,發(fā)現(xiàn)進入首頁的用戶有50%會訪問第二個頁卡。所以預(yù)加載第二個頁卡的數(shù)據(jù)可以很大程度提高用戶下個點擊頁面的打開速度。
同樣,先看看代碼實現(xiàn)。 首頁預(yù)加載頻道頁的姿勢:
onReady: function(){
//預(yù)加載頻道頁
this.$preLoad("/pages/channel/index")
}
頻道頁的實現(xiàn)方法:
onPreload: function(req){
//拉取數(shù)據(jù)
this.fetchData({
id: req.query.channelId ? req.query.channelId : defaultId,
isPreload: true
})
}
跟第一個例子類似,這里定義了一個$preLoad()方法,同時給Page擴展了一個onPreload事件。頁面調(diào)用$preLoad()后,基類會自動找到該頁面對應(yīng)的onPreload函數(shù),通知頁面執(zhí)行預(yù)加載操作。 跟第一個例子不同,這里預(yù)加載的數(shù)據(jù)會保存在storage內(nèi),因為用戶不一定會馬上訪問頁面,而把數(shù)據(jù)存在全局變量會增加小程序占用的內(nèi)存。微信會毫不猶豫的把內(nèi)存占用過大的小程序給殺掉。
也許對于大部分有app開發(fā)經(jīng)驗的同學(xué)來說,更普遍的做法是先讓頁面展示上次緩存的數(shù)據(jù),再實時拉取新數(shù)據(jù),然后刷新頁面。這個方法在小程序上也許體驗并不太好,原因是小程序的性能以及頁面渲染速度都不如原生app。將一個大的data傳輸給UI層,是一個很重的操作。因此不建議采用這種方法。
剛剛說到,頁面打開一個新頁面時微信會深拷貝一個page對象,因此,應(yīng)該盡量減少默認data的大小,以及減少對象內(nèi)的自定義屬性。有圖有真相:
以一個100個屬性的data對象為測試用例,在iphone6上,頁面的創(chuàng)建時間會因此增加150ms。
微信沒有提供小程序的組件化方案(相信一定在實現(xiàn)中)。但開談不說組件化,寫再多代碼也枉然。這里演示一個簡單的組件化實現(xiàn)。
以騰訊視頻播放頁為例,頁面定義如下:
P('play', {
comps: [
require('../../comps/player/index'),
require("../../comps/toast/index")(),
require("../../comps/topbar/topbar")(),
require('../../comps/comment/index')(),
require('../../comps/recommend/index')(),
require('../../comps/playdesc/index')()
],
onLoad: function (query) {
}
...
}
其中,P()函數(shù)是自定義的基類。這是一個非常有用的東西,可以把所有通用的邏輯都寫在基類里面,包括pv統(tǒng)計,來源統(tǒng)計,擴展生命周期函數(shù),實現(xiàn)組件化等。
函數(shù)第一個參數(shù)是頁面名稱,作為頁面的key。第二個是page對象,其中擴展了一個comps數(shù)組,里面就是所有要加載的組件。
以播放器組件/comps/player/index.js為例:
module.exports = {
data: {
tvp: {
url: '',
state: "stop"
}
},
onLoad: function (query) {
},
tvpStartPlay: function () {
}
}
組件的定義跟一個普通Page對象一模一樣,有data屬性,onLoad、onShow等事件,也有頁面響應(yīng)的回調(diào)方法。wxml模板里定義的事件和js事件一一對應(yīng)。
基類做的事情,就是把這些組件對象的屬性和方法復(fù)制到Page對象上(淺拷貝)。其中data屬性會merge到一起。而微信預(yù)定義的生命周期函數(shù)(包括自己擴展的),則封裝成隊列按序執(zhí)行。比如當(dāng)系統(tǒng)調(diào)用onLoad方法時,實際上是執(zhí)行了所有組件的onLoad方法,最后再執(zhí)行Page的onLoad。
以上是代碼部分,至于wxml模板和wxss部分,就要手工import過去了。
wxml:
<import src="/comps/comment/index.wxml" />
<import src="/comps/recommend/index.wxml" />
<import src="/comps/player/index.wxml"/>
<import src="/comps/toast/index.wxml"/>
<import src="/comps/playdesc/index.wxml"/>
<import src="/comps/topbar/index.wxml" />
wxss:
@import "/style/tabbar.wxss";
@import "/comps/player/index.wxss";
@import "/comps/toast/index.wxss";
@import "/comps/comment/index.wxss";
@import "/style/empty.wxss";
@import "/comps/playdesc/index.wxss";
雖然小程序已經(jīng)足夠小巧,但啟動速度還是有那么2-3秒,無法做到秒開。樓主嘗試對小程序的啟動時間做優(yōu)化,但沒有找到多少有價值的優(yōu)化點。單個頁面的初始化只需要1-2ms。也許大部分時間消耗在了微信跟服務(wù)器端通信的過程中。期待微信不斷迭代優(yōu)化。
工作日 8:30-12:00 14:30-18:00
周六及部分節(jié)假日提供值班服務(wù)