內(nèi)容整理于微信公開課 為什么要做性能優(yōu)化?一切性能優(yōu)化都是為了體驗(yàn)優(yōu)化 1. 使用小程序時(shí),是否會(huì)經(jīng)常遇到如下問題?
2. 我們優(yōu)化的方向有哪些?
3. 啟動(dòng)加載性能1. 首次加載你是否見過小程序首次加載時(shí)是這樣的圖?
這張圖中的三種狀態(tài)對(duì)應(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ǔ)庫(kù)的初始化,預(yù)先執(zhí)行通用邏輯,盡可能做好小程序的啟動(dòng)準(zhǔn)備。這樣可以顯著減少小程序的啟動(dòng)時(shí)間。 通過2,我們知道了,問題1中第一張圖是 資源準(zhǔn)備 (代碼包下載);第二張圖是業(yè)務(wù)代碼的注入以及落地頁(yè)首次渲染 ;第三張圖是落地頁(yè)數(shù)據(jù)請(qǐng)求時(shí)的loading態(tài) (部分小程序存在)
3. 控制包大小提升體驗(yàn)最直接的方法是控制小程序包的大小,這是最顯而易見的
從開發(fā)者的角度看,控制代碼包大小有助于減少小程序的啟動(dòng)時(shí)間。對(duì)低于1MB的代碼包,其下載時(shí)間可以控制在929ms(iOS)、1500ms(Android)內(nèi)。 4. 采用分包加載機(jī)制根據(jù)業(yè)務(wù)場(chǎng)景,將用戶訪問率高的頁(yè)面放在主包里,將訪問率低的頁(yè)面放入子包里,按需加載; 使用分包時(shí)需要注意代碼和資源文件目錄的劃分。啟動(dòng)時(shí)需要訪問的頁(yè)面及其依賴的資源文件應(yīng)放在主包中。
5 采用分包預(yù)加載技術(shù)在4的基礎(chǔ)上,當(dāng)用戶點(diǎn)擊到子包的目錄時(shí),還是有一個(gè)代碼包下載的過程,這會(huì)感覺到明顯的卡頓,所以子包也不建議拆的太大,當(dāng)然我們可以采用子包預(yù)加載技術(shù),并不需要等到用戶點(diǎn)擊到子包頁(yè)面后在下載子包,而是可以根據(jù)后期數(shù)據(jù),做子包預(yù)加載,將用戶在當(dāng)先頁(yè)可能點(diǎn)擊的子包頁(yè)面先加載,當(dāng)用戶點(diǎn)擊后直接跳轉(zhuǎn); 這種基于配置的子包預(yù)加載技術(shù),是可以根據(jù)用戶網(wǎng)絡(luò)類型來(lái)判斷的,當(dāng)用戶處于網(wǎng)絡(luò)條件好時(shí)才預(yù)加載;是靈活可控的
6. 采用獨(dú)立分包技術(shù)
目前很多小程序 可以采用獨(dú)立分包技術(shù),區(qū)別于子包,和主包之間是無(wú)關(guān)的,在功能比較獨(dú)立的子包里,使用戶只需下載分包資源;
7. 首屏加載的優(yōu)化建議7.1 提前請(qǐng)求 異步請(qǐng)求可以在頁(yè)面onLoad就加載,不需要等頁(yè)面ready后在異步請(qǐng)求數(shù)據(jù);當(dāng)然,如果能在前置頁(yè)面點(diǎn)擊跳轉(zhuǎn)時(shí)預(yù)請(qǐng)求當(dāng)前頁(yè)的核心異步請(qǐng)求,效果會(huì)更好; 7.2 利用緩存 利用storage API, 對(duì)變動(dòng)頻率比較低的異步數(shù)據(jù)進(jìn)行緩存,二次啟動(dòng)時(shí),先利用緩存數(shù)據(jù)進(jìn)行初始化渲染,然后后臺(tái)進(jìn)行異步數(shù)據(jù)的更新,這不僅優(yōu)化了性能,在無(wú)網(wǎng)環(huán)境下,用戶也能很順暢的使用到關(guān)鍵服務(wù); 7.3 避免白屏 可以在前置頁(yè)面將一些有用的字段帶到當(dāng)前頁(yè),進(jìn)行首次渲染(列表頁(yè)的某些數(shù)據(jù)--> 詳情頁(yè)),沒有數(shù)據(jù)的模塊可以進(jìn)行骨架屏的占位,使用戶不會(huì)等待的很焦慮,甚至走了; 7.4 及時(shí)反饋 及時(shí)的對(duì)需要用戶等待的交互操作進(jìn)行反饋,避免用戶以為小程序卡了,無(wú)響應(yīng) 渲染性能優(yōu)化1. 小程序渲染原理雙線程下的界面渲染,小程序的邏輯層和渲染層是分開的兩個(gè)線程。在渲染層,宿主環(huán)境會(huì)把WXML轉(zhuǎn)化成對(duì)應(yīng)的JS對(duì)象,在邏輯層發(fā)生數(shù)據(jù)變更的時(shí)候,我們需要通過宿主環(huán)境提供的setData方法把數(shù)據(jù)從邏輯層傳遞到渲染層,再經(jīng)過對(duì)比前后差異,把差異應(yīng)用在原來(lái)的Dom樹上,渲染出正確的UI界面。 分析這個(gè)流程不難得知:頁(yè)面初始化的時(shí)間大致由頁(yè)面初始數(shù)據(jù)通信時(shí)間和初始渲染時(shí)間兩部分構(gòu)成。其中,數(shù)據(jù)通信的時(shí)間指數(shù)據(jù)從邏輯層開始組織數(shù)據(jù)到視圖層完全接收完畢的時(shí)間,數(shù)據(jù)量小于64KB時(shí)總時(shí)長(zhǎng)可以控制在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í)行一次 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ù)雜或包含長(zhǎng)字符串,則不應(yīng)使用
2.3 與界面渲染無(wú)關(guān)的數(shù)據(jù)最好不要設(shè)置在data中,可以考慮設(shè)置在page對(duì)象的其他字段下
提升數(shù)據(jù)更新性能方式的代碼示例
2.4 切勿在后臺(tái)頁(yè)面進(jìn)行setData
在一些頁(yè)面會(huì)進(jìn)行一些操作,而到頁(yè)面跳轉(zhuǎn)后,代碼邏輯還在執(zhí)行,此時(shí)多個(gè)
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中的
4. 視圖層渲染原理4.1首次渲染 初始渲染發(fā)生在頁(yè)面剛剛創(chuàng)建時(shí)。初始渲染時(shí),將初始數(shù)據(jù)套用在對(duì)應(yīng)的WXML片段上生成節(jié)點(diǎn)樹。節(jié)點(diǎn)樹也就是在開發(fā)者工具WXML面板中看到的頁(yè)面樹結(jié)構(gòu),它包含頁(yè)面內(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í)間開銷,提升渲染性能。 簡(jiǎn)化WXML代碼的例子
4.2 重渲染
初始渲染完畢后,視圖層可以多次應(yīng)用
在進(jìn)行當(dāng)前節(jié)點(diǎn)樹與新節(jié)點(diǎn)樹的比較時(shí),會(huì)著重比較 5. 使用自定義組件自定義組件的更新只在組件內(nèi)部進(jìn)行,不受頁(yè)面其他不能分內(nèi)容的影響;比如一些運(yùn)營(yíng)活動(dòng)的定時(shí)模塊可以單獨(dú)抽出來(lái),做成一個(gè)定時(shí)組件,定時(shí)組件的更新并不會(huì)影響頁(yè)面上其他元素的更新;各個(gè)組件也將具有各自獨(dú)立的邏輯空間。每個(gè)組件都分別擁有自己的獨(dú)立的數(shù)據(jù)、setData調(diào)用。
6. 避免不當(dāng)?shù)氖褂胦nPageScroll每一次事件監(jiān)聽都是一次視圖到邏輯的通信過程,所以只在必要的時(shí)候監(jiān)聽pageSrcoll
總結(jié)小程序啟動(dòng)加載性能
小程序渲染性能
|
工作日 8:30-12:00 14:30-18:00
周六及部分節(jié)假日提供值班服務(wù)