內(nèi)容整理于微信公開課

為什么要做性能優(yōu)化？

一切性能優(yōu)化都是為了體驗(yàn)優(yōu)化

1. 使用小程序時(shí)，是否會(huì)經(jīng)常遇到如下問(wèn)題？

• 打開是一直白屏

• 打開是loading態(tài)，轉(zhuǎn)好幾圈

• 我的頁(yè)面點(diǎn)了怎么跳轉(zhuǎn)這么慢？

• 我的列表怎么越滑越卡？

2. 我們優(yōu)化的方向有哪些？

• 啟動(dòng)加載性能

• 渲染性能

3. 啟動(dòng)加載性能

1. 首次加載

你是否見過(guò)小程序首次加載時(shí)是這樣的圖？

 

 

這張圖中的三種狀態(tài)對(duì)應(yīng)的都是什么呢？

小程序啟動(dòng)時(shí)，微信會(huì)為小程序展示一個(gè)固定的啟動(dòng)界面，界面內(nèi)包含小程序的圖標(biāo)、名稱和加載提示圖標(biāo)。此時(shí)，微信會(huì)在背后完成幾項(xiàng)工作：下載小程序代碼包、加載小程序代碼包、初始化小程序首頁(yè)。下載到的小程序代碼包不是小程序的源代碼，而是編譯、壓縮、打包之后的代碼包。

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í)間。

 

通過(guò)2，我們知道了，問(wèn)題1中第一張圖是資源準(zhǔn)備（代碼包下載）；第二張圖是業(yè)務(wù)代碼的注入以及落地頁(yè)首次渲染；第三張圖是落地頁(yè)數(shù)據(jù)請(qǐng)求時(shí)的loading態(tài)（部分小程序存在）

 

3. 控制包大小

提升體驗(yàn)最直接的方法是控制小程序包的大小，這是最顯而易見的

• 勾選開發(fā)者工具中“上傳代碼時(shí)，壓縮代碼”選項(xiàng)；

• 及時(shí)清理無(wú)用的代碼和資源文件（包括無(wú)用的日志代碼）

• 減少資源包中的圖片等資源的數(shù)量和大小（理論上除了小icon，其他圖片資源從網(wǎng)絡(luò)下載），圖片資源壓縮率有限

從開發(fā)者的角度看，控制代碼包大小有助于減少小程序的啟動(dòng)時(shí)間。對(duì)低于1MB的代碼包，其下載時(shí)間可以控制在929ms（iOS）、1500ms（Android）內(nèi)。

4. 采用分包加載機(jī)制

根據(jù)業(yè)務(wù)場(chǎng)景，將用戶訪問(wèn)率高的頁(yè)面放在主包里，將訪問(wèn)率低的頁(yè)面放入子包里，按需加載；

 

使用分包時(shí)需要注意代碼和資源文件目錄的劃分。啟動(dòng)時(shí)需要訪問(wèn)的頁(yè)面及其依賴的資源文件應(yīng)放在主包中。

 

5 采用分包預(yù)加載技術(shù)

在4的基礎(chǔ)上，當(dāng)用戶點(diǎn)擊到子包的目錄時(shí)，還是有一個(gè)代碼包下載的過(guò)程，這會(huì)感覺(jué)到明顯的卡頓，所以子包也不建議拆的太大，當(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ù)

目前很多小程序主包+子包（2M+6M）的方式，但是在做很多運(yùn)營(yíng)活動(dòng)時(shí)，我們會(huì)發(fā)現(xiàn)活動(dòng)（紅包）是在子包里，但是運(yùn)營(yíng)、產(chǎn)品投放的落地頁(yè)鏈接是子包鏈接，這是的用戶在直達(dá)落地時(shí)，必須先下載主包內(nèi)容（一般比較大），在下載子包內(nèi)容（相對(duì)主包，較?。?，這使得在用戶停留時(shí)間比較短的小程序場(chǎng)景中，用戶體驗(yàn)不是很好，而且浪費(fèi)了很大部分流量；

 

可以采用獨(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è)），沒(méi)有數(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í)候，我們需要通過(guò)宿主環(huán)境提供的setData方法把數(shù)據(jù)從邏輯層傳遞到渲染層，再經(jīng)過(guò)對(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)系，傳輸過(guò)大的數(shù)據(jù)將使這一時(shí)間顯著增加。因而減少傳輸數(shù)據(jù)量是降低數(shù)據(jù)傳輸時(shí)間的有效方式。

 

 

 

2. 避免使用不當(dāng)setData

在數(shù)據(jù)傳輸時(shí)，邏輯層會(huì)執(zhí)行一次JSON.stringify來(lái)去除掉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 不要過(guò)于頻繁調(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)使用setData來(lái)設(shè)置這些數(shù)據(jù)；

 

 

2.3 與界面渲染無(wú)關(guān)的數(shù)據(jù)最好不要設(shè)置在data中，可以考慮設(shè)置在page對(duì)象的其他字段下

 

 

提升數(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ù)，并將界面無(wú)關(guān)的數(shù)據(jù)放在data外
    this.setData({
      myData: {
        a: '這個(gè)字符串在WXML中用到了',
        b: '這個(gè)字符串未在WXML中用到，而且它很長(zhǎng)…………………………'
      }
    })
    // 可以優(yōu)化為
    this.setData({
      'myData.a': '這個(gè)字符串在WXML中用到了'
    })
    this._myData = {
      b: '這個(gè)字符串未在WXML中用到，而且它很長(zhǎng)…………………………'
    }

  }
})
復(fù)制代碼

2.4 切勿在后臺(tái)頁(yè)面進(jìn)行setData

在一些頁(yè)面會(huì)進(jìn)行一些操作，而到頁(yè)面跳轉(zhuǎn)后，代碼邏輯還在執(zhí)行，此時(shí)多個(gè)webview是共享一個(gè)js進(jìn)程；后臺(tái)的setData操作會(huì)搶占前臺(tái)頁(yè)面的渲染資源；

 

 

 

 

3. 用戶事件使用不當(dāng)

視圖層將事件反饋給邏輯層時(shí)，同樣需要一個(gè)通信過(guò)程，通信的方向是從視圖層到邏輯層。因?yàn)檫@個(gè)通信過(guò)程是異步的，會(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前綴屬性中放置過(guò)大的數(shù)據(jù)。

 

 

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代碼的例子

<view data-my-data="{{myData}}"> 
  <view class="my-class" data-my-data="{{myData}}" bindtap="onTap">
    <text> 
      {{myText}}
    text>
  view>
view>



<view class="my-class" data-my-data="{{myData}}" bindtap="onTap">
  {{myText}}
view>
復(fù)制代碼

4.2 重渲染

初始渲染完畢后，視圖層可以多次應(yīng)用setData的數(shù)據(jù)。每次應(yīng)用setData數(shù)據(jù)時(shí)，都會(huì)執(zhí)行重渲染來(lái)更新界面。初始渲染中得到的data和當(dāng)前節(jié)點(diǎn)樹會(huì)保留下來(lái)用于重渲染。每次重渲染時(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)行，不受頁(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)聽都是一次視圖到邏輯的通信過(guò)程，所以只在必要的時(shí)候監(jiān)聽pageSrcoll

 

 

總結(jié)

小程序啟動(dòng)加載性能

• 控制代碼包的大小

• 分包加載

• 首屏體驗(yàn)（預(yù)請(qǐng)求，利用緩存，避免白屏，及時(shí)反饋

小程序渲染性能

• 避免不當(dāng)?shù)氖褂胹etData

• 合理利用事件通信

• 避免不當(dāng)?shù)氖褂胦nPageScroll

• 優(yōu)化視圖節(jié)點(diǎn)

• 使用自定義組件