微信定制開發(fā)|小程序性能優(yōu)化進(jìn)階指南
為什么要做性能優(yōu)化？
一切性能優(yōu)化都是為了體驗(yàn)優(yōu)化
1.使用小程序時(shí)，是否會(huì)經(jīng)常遇到如下問題？
打開是一直白屏
打開是loading態(tài)，轉(zhuǎn)好幾圈
我的頁面點(diǎn)了怎么跳轉(zhuǎn)這么慢？
我的列表怎么越滑越卡？
2.我們優(yōu)化的方向有哪些？
啟動(dòng)加載性能
渲染性能
3.啟動(dòng)加載性能
1.首次加載
你是否見過小程序首次加載時(shí)是這樣的圖？
這張圖中的三種狀態(tài)對應(yīng)的都是什么呢？
小程序啟動(dòng)時(shí)，微信會(huì)為小程序展示一個(gè)固定的啟動(dòng)界面，界面內(nèi)包含小程序的圖標(biāo)、名稱和加載提示圖標(biāo)。此時(shí)，微信會(huì)在背后完成幾項(xiàng)工作：下載小程序代碼包、加載小程序代碼包、初始化小程序首頁。下載到的小程序代碼包不是小程序的源代碼，而是編譯、壓縮、打包之后的代碼包。
2.加載順序
小程序加載的順序是如何？
微信會(huì)在小程序啟動(dòng)前為小程序準(zhǔn)備好通用的運(yùn)行環(huán)境。這個(gè)運(yùn)行環(huán)境包括幾個(gè)供小程序使用的線程，并在其中完成小程序基礎(chǔ)庫的初始化，預(yù)先執(zhí)行通用邏輯，盡可能做好小程序的啟動(dòng)準(zhǔn)備。這樣可以顯著減少小程序的啟動(dòng)時(shí)間。
通過2，我們知道了，問題1中第一張圖是資源準(zhǔn)備（代碼包下載）；第二張圖是業(yè)務(wù)代碼的注入以及落地頁首次渲染；第三張圖是落地頁數(shù)據(jù)請求時(shí)的loading態(tài)（部分小程序存在）
3.控制包大小
提升體驗(yàn)最直接的方法是控制小程序包的大小，這是最顯而易見的
勾選開發(fā)者工具中“上傳代碼時(shí)，壓縮代碼”選項(xiàng)；
及時(shí)清理無用的代碼和資源文件（包括無用的日志代碼）
減少資源包中的圖片等資源的數(shù)量和大?。ɡ碚撋铣诵con，其他圖片資源從網(wǎng)絡(luò)下載），圖片資源壓縮率有限
從開發(fā)者的角度看，控制代碼包大小有助于減少小程序的啟動(dòng)時(shí)間。對低于1MB的代碼包，其下載時(shí)間可以控制在929ms（iOS）、1500ms（Android）內(nèi)。
4.采用分包加載機(jī)制
根據(jù)業(yè)務(wù)場景，將用戶訪問率高的頁面放在主包里，將訪問率低的頁面放入子包里，按需加載；
使用分包時(shí)需要注意代碼和資源文件目錄的劃分。啟動(dòng)時(shí)需要訪問的頁面及其依賴的資源文件應(yīng)放在主包中。
5采用分包預(yù)加載技術(shù)
在4的基礎(chǔ)上，當(dāng)用戶點(diǎn)擊到子包的目錄時(shí)，還是有一個(gè)代碼包下載的過程，這會(huì)感覺到明顯的卡頓，所以子包也不建議拆的太大，當(dāng)然我們可以采用子包預(yù)加載技術(shù)，并不需要等到用戶點(diǎn)擊到子包頁面后在下載子包，而是可以根據(jù)后期數(shù)據(jù)，做子包預(yù)加載，將用戶在當(dāng)先頁可能點(diǎn)擊的子包頁面先加載，當(dāng)用戶點(diǎn)擊后直接跳轉(zhuǎn)；
這種基于配置的子包預(yù)加載技術(shù)，是可以根據(jù)用戶網(wǎng)絡(luò)類型來判斷的，當(dāng)用戶處于網(wǎng)絡(luò)條件好時(shí)才預(yù)加載；是靈活可控的
6.采用獨(dú)立分包技術(shù)
目前很多小程序主包+子包（2M+6M）的方式，但是在做很多運(yùn)營活動(dòng)時(shí)，我們會(huì)發(fā)現(xiàn)活動(dòng)（紅包）是在子包里，但是運(yùn)營、產(chǎn)品投放的落地頁鏈接是子包鏈接，這是的用戶在直達(dá)落地時(shí)，必須先下載主包內(nèi)容（一般比較大），在下載子包內(nèi)容（相對主包，較小），這使得在用戶停留時(shí)間比較短的小程序場景中，用戶體驗(yàn)不是很好，而且浪費(fèi)了很大部分流量；
可以采用獨(dú)立分包技術(shù)，區(qū)別于子包，和主包之間是無關(guān)的，在功能比較獨(dú)立的子包里，使用戶只需下載分包資源；
7.首屏加載的優(yōu)化建議
7.1提前請求
異步請求可以在頁面onLoad就加載，不需要等頁面ready后在異步請求數(shù)據(jù)；當(dāng)然，如果能在前置頁面點(diǎn)擊跳轉(zhuǎn)時(shí)預(yù)請求當(dāng)前頁的核心異步請求，效果會(huì)更好；
7.2利用緩存
利用storageAPI,對變動(dòng)頻率比較低的異步數(shù)據(jù)進(jìn)行緩存，二次啟動(dòng)時(shí)，先利用緩存數(shù)據(jù)進(jìn)行初始化渲染，然后后臺(tái)進(jìn)行異步數(shù)據(jù)的更新，這不僅優(yōu)化了性能，在無網(wǎng)環(huán)境下，用戶也能很順暢的使用到關(guān)鍵服務(wù)；
7.3避免白屏
可以在前置頁面將一些有用的字段帶到當(dāng)前頁，進(jìn)行首次渲染（列表頁的某些數(shù)據(jù)–>詳情頁），沒有數(shù)據(jù)的模塊可以進(jìn)行骨架屏的占位，使用戶不會(huì)等待的很焦慮，甚至走了；
7.4及時(shí)反饋
及時(shí)的對需要用戶等待的交互操作進(jìn)行反饋，避免用戶以為小程序卡了，無響應(yīng)
渲染性能優(yōu)化
1.小程序渲染原理
雙線程下的界面渲染，小程序的邏輯層和渲染層是分開的兩個(gè)線程。在渲染層，宿主環(huán)境會(huì)把WXML轉(zhuǎn)化成對應(yīng)的JS對象，在邏輯層發(fā)生數(shù)據(jù)變更的時(shí)候，我們需要通過宿主環(huán)境提供的setData方法把數(shù)據(jù)從邏輯層傳遞到渲染層，再經(jīng)過對比前后差異，把差異應(yīng)用在原來的Dom樹上，渲染出正確的UI界面。
分析這個(gè)流程不難得知：頁面初始化的時(shí)間大致由頁面初始數(shù)據(jù)通信時(shí)間和初始渲染時(shí)間兩部分構(gòu)成。其中，數(shù)據(jù)通信的時(shí)間指數(shù)據(jù)從邏輯層開始組織數(shù)據(jù)到視圖層完全接收完畢的時(shí)間，數(shù)據(jù)量小于64KB時(shí)總時(shí)長可以控制在30ms內(nèi)。傳輸時(shí)間與數(shù)據(jù)量大體上呈現(xiàn)正相關(guān)關(guān)系，傳輸過大的數(shù)據(jù)將使這一時(shí)間顯著增加。因而減少傳輸數(shù)據(jù)量是降低數(shù)據(jù)傳輸時(shí)間的有效方式。
2.避免使用不當(dāng)setData
在數(shù)據(jù)傳輸時(shí)，邏輯層會(huì)執(zhí)行一次JSON.stringify來去除掉setData數(shù)據(jù)中不可傳輸?shù)牟糠?，之后將?shù)據(jù)發(fā)送給視圖層。同時(shí)，邏輯層還會(huì)將setData所設(shè)置的數(shù)據(jù)字段與data合并，使開發(fā)者可以用this.data讀取到變更后的數(shù)據(jù)。因此，為了提升數(shù)據(jù)更新的性能，開發(fā)者在執(zhí)行setData調(diào)用時(shí)，最好遵循以下原則：
2.1不要過于頻繁調(diào)用setData，應(yīng)考慮將多次setData合并成一次setData調(diào)用；
2.2數(shù)據(jù)通信的性能與數(shù)據(jù)量正相關(guān)，因而如果有一些數(shù)據(jù)字段不在界面中展示且數(shù)據(jù)結(jié)構(gòu)比較復(fù)雜或包含長字符串，則不應(yīng)使用setData來設(shè)置這些數(shù)據(jù)；
2.3與界面渲染無關(guān)的數(shù)據(jù)最好不要設(shè)置在data中，可以考慮設(shè)置在page對象的其他字段下
提升數(shù)據(jù)更新性能方式的代碼示例
Page({
onShow:function(){
//不要頻繁調(diào)用setData
this.setData({a:1})
this.setData({b:2})
//絕大多數(shù)時(shí)候可優(yōu)化為
this.setData({a:1,b:2})
//不要設(shè)置不在界面渲染時(shí)使用的數(shù)據(jù)，并將界面無關(guān)的數(shù)據(jù)放在data外
this.setData({
myData:{
a:'這個(gè)字符串在WXML中用到了',
b:'這個(gè)字符串未在WXML中用到，而且它很長…………………………'
}
})
//可以優(yōu)化為
this.setData({
'myData.a':'這個(gè)字符串在WXML中用到了'
})
this._myData={
b:'這個(gè)字符串未在WXML中用到，而且它很長…………………………'
}
}
})
利用setData進(jìn)行列表局部刷新
在一個(gè)列表中，有n條數(shù)據(jù)，采用上拉加載更多的方式，假如這個(gè)時(shí)候想對其中某一個(gè)數(shù)據(jù)進(jìn)行點(diǎn)贊操作，還能及時(shí)看到點(diǎn)贊的效果
解決方法
1、可以采用setData全局刷新，點(diǎn)贊完成之后，重新獲取數(shù)據(jù)，再次進(jìn)行全局重新渲染，這樣做的優(yōu)點(diǎn)是：方便，快捷！缺點(diǎn)是：用戶體驗(yàn)極其不好，當(dāng)用戶刷量100多條數(shù)據(jù)后，重新渲染量大會(huì)出現(xiàn)空白期（沒有渲染過來）
2、說到重點(diǎn)了，就是利用setData局部刷新
>a.將點(diǎn)贊的`id`傳過去，知道點(diǎn)的是那一條數(shù)據(jù),將點(diǎn)贊的`id`傳過去，知道點(diǎn)的是那一條數(shù)據(jù)
<viewwx:if="{{!item.status}}"class="btn"data-id="{{index}}"bindtap="couponTap">立即領(lǐng)取</view>
>b.重新獲取數(shù)據(jù)，查找相對應(yīng)id的那條數(shù)據(jù)的下標(biāo)（`index`是不會(huì)改變的）
>c.用setData進(jìn)行局部刷新
this.setData({
list[index]=newList[index]
})
其實(shí)這個(gè)小操作對剛剛接觸到微信小程序的人來說應(yīng)該是不容易發(fā)現(xiàn)的，不理解setData還有這樣的寫法。
2.4切勿在后臺(tái)頁面進(jìn)行setData
在一些頁面會(huì)進(jìn)行一些操作，而到頁面跳轉(zhuǎn)后，代碼邏輯還在執(zhí)行，此時(shí)多個(gè)webview是共享一個(gè)js進(jìn)程；后臺(tái)的setData操作會(huì)搶占前臺(tái)頁面的渲染資源；
3.用戶事件使用不當(dāng)
視圖層將事件反饋給邏輯層時(shí)，同樣需要一個(gè)通信過程，通信的方向是從視圖層到邏輯層。因?yàn)檫@個(gè)通信過程是異步的，會(huì)產(chǎn)生一定的延遲，延遲時(shí)間同樣與傳輸?shù)臄?shù)據(jù)量正相關(guān)，數(shù)據(jù)量小于64KB時(shí)在30ms內(nèi)。降低延遲時(shí)間的方法主要有兩個(gè)。
1.去掉不必要的事件綁定（WXML中的bind和catch），從而減少通信的數(shù)據(jù)量和次數(shù)；
2.事件綁定時(shí)需要傳輸target和currentTarget的dataset，因而不要在節(jié)點(diǎn)的data前綴屬性中放置過大的數(shù)據(jù)。
4.視圖層渲染原理
4.1首次渲染
初始渲染發(fā)生在頁面剛剛創(chuàng)建時(shí)。初始渲染時(shí)，將初始數(shù)據(jù)套用在對應(yīng)的WXML片段上生成節(jié)點(diǎn)樹。節(jié)點(diǎn)樹也就是在開發(fā)者工具WXML面板中看到的頁面樹結(jié)構(gòu)，它包含頁面內(nèi)所有組件節(jié)點(diǎn)的名稱、屬性值和事件回調(diào)函數(shù)等信息。最后根據(jù)節(jié)點(diǎn)樹包含的各個(gè)節(jié)點(diǎn)，在界面上依次創(chuàng)建出各個(gè)組件。
在這整個(gè)流程中，時(shí)間開銷大體上與節(jié)點(diǎn)樹中節(jié)點(diǎn)的總量成正比例關(guān)系。因而減少WXML中節(jié)點(diǎn)的數(shù)量可以有效降低初始渲染和重渲染的時(shí)間開銷，提升渲染性能。
簡化WXML代碼的例子
<viewdata-my-data="{{myData}}"><!--這個(gè)view和下一行的view可以合并-->
<viewclass="my-class"data-my-data="{{myData}}"bindtap="onTap">
<text><!--這個(gè)text通常是沒必要的-->
{{myText}}
</text>
</view>
</view>
<!--可以簡化為-->
<viewclass="my-class"data-my-data="{{myData}}"bindtap="onTap">
{{myText}}
</view>
4.2重渲染
初始渲染完畢后，視圖層可以多次應(yīng)用setData的數(shù)據(jù)。每次應(yīng)用setData數(shù)據(jù)時(shí)，都會(huì)執(zhí)行重渲染來更新界面。初始渲染中得到的data和當(dāng)前節(jié)點(diǎn)樹會(huì)保留下來用于重渲染。每次重渲染時(shí)，將data和setData數(shù)據(jù)套用在WXML片段上，得到一個(gè)新節(jié)點(diǎn)樹。然后將新節(jié)點(diǎn)樹與當(dāng)前節(jié)點(diǎn)樹進(jìn)行比較，這樣可以得到哪些節(jié)點(diǎn)的哪些屬性需要更新、哪些節(jié)點(diǎn)需要添加或移除。最后，將setData數(shù)據(jù)合并到data中，并用新節(jié)點(diǎn)樹替換舊節(jié)點(diǎn)樹，用于下一次重渲染。
在進(jìn)行當(dāng)前節(jié)點(diǎn)樹與新節(jié)點(diǎn)樹的比較時(shí)，會(huì)著重比較setData數(shù)據(jù)影響到的節(jié)點(diǎn)屬性。因而，去掉不必要設(shè)置的數(shù)據(jù)、減少setData的數(shù)據(jù)量也有助于提升這一個(gè)步驟的性能。
5.使用自定義組件
自定義組件的更新只在組件內(nèi)部進(jìn)行，不受頁面其他不能分內(nèi)容的影響；比如一些運(yùn)營活動(dòng)的定時(shí)模塊可以單獨(dú)抽出來，做成一個(gè)定時(shí)組件，定時(shí)組件的更新并不會(huì)影響頁面上其他元素的更新；各個(gè)組件也將具有各自獨(dú)立的邏輯空間。每個(gè)組件都分別擁有自己的獨(dú)立的數(shù)據(jù)、setData調(diào)用。
6.避免不當(dāng)?shù)氖褂胦nPageScroll
每一次事件監(jiān)聽都是一次視圖到邏輯的通信過程，所以只在必要的時(shí)候監(jiān)聽pageSrcoll
總結(jié)
小程序啟動(dòng)加載性能
控制代碼包的大小
分包加載
首屏體驗(yàn)（預(yù)請求，利用緩存，避免白屏，及時(shí)反饋
小程序渲染性能
避免不當(dāng)?shù)氖褂胹etData
合理利用事件通信
避免不當(dāng)?shù)氖褂胦nPageScroll
優(yōu)化視圖節(jié)點(diǎn)
使用自定義組件
本文標(biāo)簽： 微信開發(fā)
站應(yīng)該怎么做.jpg)
備類網(wǎng)站推廣方案.jpg)
類網(wǎng)站建設(shè)費(fèi)用明細(xì)表.jpg)
站內(nèi)容運(yùn)營方案.jpg)
體材料類網(wǎng)站內(nèi)容運(yùn)營方案.jpg)
站應(yīng)該怎么做.jpg)
站應(yīng)該怎么做.jpg)
浴設(shè)施類網(wǎng)站建設(shè)費(fèi)用明細(xì)表.jpg)
類網(wǎng)站建設(shè)方案書.jpg)
施類網(wǎng)站內(nèi)容運(yùn)營方案.jpg)
站SEO選哪家公司好.jpg)
站SEO選哪家公司好.jpg)
站SEO一年需要多少錢.jpg)
站SEO選哪家公司好.jpg)
站SEO一年需要多少錢.jpg)
站SEO一年需要多少錢.jpg)
站SEO一年需要多少錢.jpg)
站SEO選哪家公司好.jpg)
站SEO需要注意什么.jpg)
站SEO選哪家公司好.jpg)
.jpg)
貨.jpg)
意怎么改.jpg)
干什么的.jpg)
