微信小程序性能優(yōu)化技巧有哪些

微信小程序性能優(yōu)化技巧有哪些，很多新手對此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

微信小程序如果想要優(yōu)化性能，有關(guān)鍵性的兩點(diǎn)：

• 提高加載性能

• 提高渲染性能

接下來分別來介紹一下：

提高加載性能

首先，問一個(gè)問題，當(dāng)用戶點(diǎn)擊小程序后發(fā)生了什么？

上圖中的三個(gè)狀態(tài)，我們經(jīng)常遇到，它們分別對應(yīng)小程序的下面三個(gè)狀態(tài)：

• 有三個(gè)點(diǎn)的白屏（左側(cè)）： 下載代碼包的階段

• 沒有三個(gè)點(diǎn)的白屏（中間）： 業(yè)務(wù)代碼注入和渲染的階段

• 加載中（右邊）： 業(yè)務(wù)代碼中異步請求數(shù)據(jù)

總的來說，小程序呈現(xiàn)到用戶面前，實(shí)際上經(jīng)歷了下面兩個(gè)階段：

• 運(yùn)行環(huán)境的加載

• 下載代碼包

下面具體介紹這兩個(gè)階段：

運(yùn)行環(huán)境預(yù)加載

這步是微信做的。微信會在用戶打開小程序之前就已經(jīng)準(zhǔn)備好環(huán)境，用戶點(diǎn)擊小程序入口后，直接下載小程序的代碼包即可。

下載代碼包啟動小程序

小程序代碼包里面的代碼，不是小程序的源代碼，而是編譯、壓縮、打包之后的代碼包。

下圖中，左側(cè)的“預(yù)加載”對應(yīng)的是運(yùn)行環(huán)境的預(yù)加載，右側(cè)的“小程序啟動” 對應(yīng)的是下載代碼包啟動小程序。

小程序提供的運(yùn)行環(huán)境，分為邏輯層（AppService）和 視圖層（webView），邏輯層是執(zhí)行javascript的地方，視圖層是渲染頁面的地方。當(dāng)小程序的代碼包下載完畢后，業(yè)務(wù)代碼分別注入邏輯層和渲染層。

提升加載性能的最最最關(guān)鍵性一點(diǎn)是，控制包的大小，這個(gè)也是微信官方的說法。

控制包的大小

提升體驗(yàn)最直接的方法是控制小程序包的大小，基本上可以說，1M的代碼包，下載耗時(shí)1秒左右。

控制包的大小的措施

• 壓縮代碼，清理無用的代碼

• 圖片放在cdn

• 采用分包策略

• 分包預(yù)加載

• 獨(dú)立分包（版本要求有點(diǎn)高）

除了上面講的控制包的大小，對異步請求的優(yōu)化也很重要。

對異步請求的優(yōu)化

• onLoad 階段就可以發(fā)起請求，不用等ready

• 請求結(jié)果放在緩存中, 下次接著用

• 請求中可以先展示骨架圖

• 先反饋，再請求。比如說，點(diǎn)贊的按鈕，可以先改變按鈕的樣式，再發(fā)起異步請求。

提升渲染性能

setData 干了啥

每調(diào)用一次setData, 都是邏輯層向渲染層的一次通訊，這個(gè)通信還不是直接傳給webView, 而是通過走了native層，通訊的開銷很大。

渲染層收到通訊后，還需要重新渲染出來，所以，emmm, 一次setData帶來兩次開銷：通信的開銷 + webview更新的開銷。

在數(shù)據(jù)傳輸時(shí)，邏輯層會執(zhí)行一次JSON.stringify來去除掉setData數(shù)據(jù)中不可傳輸?shù)牟糠郑髮?shù)據(jù)發(fā)送給視圖層。同時(shí)，邏輯層還會將setData所設(shè)置的數(shù)據(jù)字段與data合并，使開發(fā)者可以用this.data讀取到變更后的數(shù)據(jù)。

減少setData的數(shù)據(jù)量

如果一個(gè)數(shù)據(jù)不能會影響渲染層，則不用放在setData里面

合并setData的請求，減少通訊的次數(shù)

這個(gè)很好理解吧

列表的局部更新

在一個(gè)列表中，有n條數(shù)據(jù)，采用上拉加載更多的方式，假如這個(gè)時(shí)候想對其中某一個(gè)數(shù)據(jù)進(jìn)行點(diǎn)贊操作，還能及時(shí)看到點(diǎn)贊的效果

此時(shí)，可以采用setData全局刷新，點(diǎn)贊完成之后，重新獲取數(shù)據(jù)，再次進(jìn)行全局重新渲染，這樣做的優(yōu)點(diǎn)是：方便，快捷！缺點(diǎn)是：用戶體驗(yàn)極其不好，當(dāng)用戶刷量100多條數(shù)據(jù)后，重新渲染量大會出現(xiàn)空白期（沒有渲染過來）

如果采用布局刷新，將點(diǎn)贊的id傳過去，知道點(diǎn)的是那一條數(shù)據(jù), 將點(diǎn)贊的id傳過去，知道點(diǎn)的是那一條數(shù)據(jù)。

重新獲取數(shù)據(jù)，查找相對應(yīng)id的那條數(shù)據(jù)的下標(biāo)（index是不會改變的），用setData進(jìn)行局部刷新

this.setData({
    list[index] = newList[index]
})

小心后臺頁面的js

小程序中可能有n個(gè)頁面，所有的這些頁面，雖然都擁有自己的webview(渲染層)， 但是卻共享同一個(gè)js運(yùn)行環(huán)境。也就是說，當(dāng)你跳到了另外一個(gè)頁面（假設(shè)是B頁面），本頁面（假設(shè)是A頁面）的定時(shí)器等js操作仍在進(jìn)行，并且不會被銷毀，并且會搶占B頁面的資源。

在h6的環(huán)境中，當(dāng)我們跳轉(zhuǎn)到其他頁面，老頁面的js環(huán)境會被自動銷毀，定時(shí)器什么都被銷毀掉了，因此我們不需要關(guān)心老頁面中，還有哪些js代碼可能還會執(zhí)行。但是在小程序中，我們必須手動的“清理”掉這樣的代碼。

小心onPageScroll

pageScroll 事件，也是一次通訊，是webview層向js邏輯層的通訊。這次通訊也是開銷較大，如果考慮到這個(gè)事件被頻繁的調(diào)用，回調(diào)函數(shù)如果有復(fù)雜的setData的話，emmmmm， 性能就會很差了。

小心獲取節(jié)點(diǎn)位置

在h6 中的環(huán)境中，為了實(shí)現(xiàn)懶加載、下拉加載，我們不得不去獲取節(jié)點(diǎn)的位置。

為啥說不得不，是因?yàn)槲覀儽究梢杂眯碌腶pi ——intersectionObject去輕松實(shí)現(xiàn)（google等主流瀏覽器都已經(jīng)支持了），但是微信的內(nèi)置X5瀏覽器很遺憾的不支持。

沒想到，在小程序的環(huán)境中，微信竟然良心發(fā)現(xiàn)，支持intersectionObject api, 因此獲取節(jié)點(diǎn)的信息，盡量還是用這api 吧。

盡可能使用小程序組件

自定義組件的更新只在組件內(nèi)部進(jìn)行，不受頁面其他不能分內(nèi)容的影響；比如一些運(yùn)營活動的定時(shí)模塊可以單獨(dú)抽出來，做成一個(gè)定時(shí)組件，定時(shí)組件的更新并不會影響頁面上其他元素的更新；各個(gè)組件也將具有各自獨(dú)立的邏輯空間。每個(gè)組件都分別擁有自己的獨(dú)立的數(shù)據(jù)、setData調(diào)用

優(yōu)化心得

相比于上面的優(yōu)化策略，最重要的是找出小程序中的性能瓶頸。在自己的優(yōu)化實(shí)踐中，遇到了下面的問題：

下拉加載更多，特別特別卡，通過列表局部更新的技巧，發(fā)現(xiàn)性能改善不大。 后來發(fā)現(xiàn)，是因?yàn)槭醉撔枰O(jiān)聽scroll事件，導(dǎo)致scroll事件被頻繁的觸發(fā)，回調(diào)函數(shù)中有耗時(shí)操作，導(dǎo)致onreachBottom事件被阻塞了，也就是說，要等大概1~2秒才會去發(fā)起下一頁的請求。 取消掉scroll事件的監(jiān)聽，原本>4s的加載時(shí)間，控制在1s之內(nèi)。

一些坑

• 在微信開發(fā)者工具沒有辦法復(fù)現(xiàn)某些性能問題，是因?yàn)閺倪壿媽拥絯ebview的通訊，開發(fā)者工具底層是通過onpostMessage, 微信ios好像是微信自己實(shí)現(xiàn)的橋接。所以強(qiáng)烈建議使用真機(jī)進(jìn)行調(diào)試

• 微信開發(fā)者工具，沒有辦法在【network】里面看到圖片資源的加載，通過【trace】面板連接安卓真機(jī)也沒有辦法看到。如果想測試懶加載的效果，就比較麻煩，需要通過設(shè)置微信開發(fā)者工具的代理到127.0.0.1，通過charles可以抓包看到（截止2018年11月1日是這樣的）

搞微信小程序遇到的這些坑，雖然可以收獲滿滿的填坑經(jīng)驗(yàn)，但是這些填坑經(jīng)驗(yàn)并不算是真正的計(jì)算機(jī)知識，因?yàn)檫@些知識的并不是基于對本質(zhì)底層的理解，而是依靠經(jīng)驗(yàn)，而經(jīng)驗(yàn)是很快就會過時(shí)，可能下一次小程序api來一次大的升級，小程序優(yōu)化手段馬上就會換成另外一種。

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注億速云行業(yè)資訊頻道，感謝您對億速云的支持。