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

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

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

1. 使用小程序時，是否會經(jīng)常遇到如下問題？

• 打開是一直白屏

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

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

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

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

• 啟動加載性能

• 渲染性能

3. 啟動加載性能

1. 首次加載

你是否見過小程序首次加載時是這樣的圖？

 

 

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

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

2. 加載順序

小程序加載的順序是如何？

微信會在小程序啟動前為小程序準(zhǔn)備好通用的運行環(huán)境。這個運行環(huán)境包括幾個供小程序使用的線程，并在其中完成小程序基礎(chǔ)庫的初始化，預(yù)先執(zhí)行通用邏輯，盡可能做好小程序的啟動準(zhǔn)備。這樣可以顯著減少小程序的啟動時間。

 

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

 

3. 控制包大小

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

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

• 及時清理無用的代碼和資源文件（包括無用的日志代碼）

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

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

4. 采用分包加載機制

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

 

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

 

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

在4的基礎(chǔ)上，當(dāng)用戶點擊到子包的目錄時，還是有一個代碼包下載的過程，這會感覺到明顯的卡頓，所以子包也不建議拆的太大，當(dāng)然我們可以采用子包預(yù)加載技術(shù)，并不需要等到用戶點擊到子包頁面后在下載子包，而是可以根據(jù)后期數(shù)據(jù)，做子包預(yù)加載，將用戶在當(dāng)先頁可能點擊的子包頁面先加載，當(dāng)用戶點擊后直接跳轉(zhuǎn)；

 

這種基于配置的子包預(yù)加載技術(shù)，是可以根據(jù)用戶網(wǎng)絡(luò)類型來判斷的，當(dāng)用戶處于網(wǎng)絡(luò)條件好時才預(yù)加載；是靈活可控的

 

6. 采用獨立分包技術(shù)

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

 

可以采用獨立分包技術(shù)，區(qū)別于子包，和主包之間是無關(guān)的，在功能比較獨立的子包里，使用戶只需下載分包資源；

 

7. 首屏加載的優(yōu)化建議

7.1 提前請求

異步請求可以在頁面onLoad就加載，不需要等頁面ready后在異步請求數(shù)據(jù)；當(dāng)然，如果能在前置頁面點擊跳轉(zhuǎn)時預(yù)請求當(dāng)前頁的核心異步請求，效果會更好；

7.2 利用緩存

利用storage API, 對變動頻率比較低的異步數(shù)據(jù)進(jìn)行緩存，二次啟動時，先利用緩存數(shù)據(jù)進(jìn)行初始化渲染，然后后臺進(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)行骨架屏的占位，使用戶不會等待的很焦慮，甚至走了；

7.4 及時反饋

及時的對需要用戶等待的交互操作進(jìn)行反饋，避免用戶以為小程序卡了，無響應(yīng)

---

渲染性能優(yōu)化

1. 小程序渲染原理

雙線程下的界面渲染，小程序的邏輯層和渲染層是分開的兩個線程。在渲染層，宿主環(huán)境會把WXML轉(zhuǎn)化成對應(yīng)的JS對象，在邏輯層發(fā)生數(shù)據(jù)變更的時候，我們需要通過宿主環(huán)境提供的setData方法把數(shù)據(jù)從邏輯層傳遞到渲染層，再經(jīng)過對比前后差異，把差異應(yīng)用在原來的Dom樹上，渲染出正確的UI界面。

 

分析這個流程不難得知：頁面初始化的時間大致由頁面初始數(shù)據(jù)通信時間和初始渲染時間兩部分構(gòu)成。其中，數(shù)據(jù)通信的時間指數(shù)據(jù)從邏輯層開始組織數(shù)據(jù)到視圖層完全接收完畢的時間，數(shù)據(jù)量小于64KB時總時長可以控制在30ms內(nèi)。傳輸時間與數(shù)據(jù)量大體上呈現(xiàn)正相關(guān)關(guān)系，傳輸過大的數(shù)據(jù)將使這一時間顯著增加。因而減少傳輸數(shù)據(jù)量是降低數(shù)據(jù)傳輸時間的有效方式。

 

 

 

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

在數(shù)據(jù)傳輸時，邏輯層會執(zhí)行一次JSON.stringify來去除掉setData數(shù)據(jù)中不可傳輸?shù)牟糠郑髮?shù)據(jù)發(fā)送給視圖層。同時，邏輯層還會將setData所設(shè)置的數(shù)據(jù)字段與data合并，使開發(fā)者可以用this.data讀取到變更后的數(shù)據(jù)。因此，為了提升數(shù)據(jù)更新的性能，開發(fā)者在執(zhí)行setData調(diào)用時，最好遵循以下原則：

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ù)時候可優(yōu)化為
    this.setData({ a: 1, b: 2 })

    // 不要設(shè)置不在界面渲染時使用的數(shù)據(jù)，并將界面無關(guān)的數(shù)據(jù)放在data外
    this.setData({
      myData: {
        a: '這個字符串在WXML中用到了',
        b: '這個字符串未在WXML中用到，而且它很長…………………………'
      }
    })
    // 可以優(yōu)化為
    this.setData({
      'myData.a': '這個字符串在WXML中用到了'
    })
    this._myData = {
      b: '這個字符串未在WXML中用到，而且它很長…………………………'
    }

  }
})
復(fù)制代碼

2.4 切勿在后臺頁面進(jìn)行setData

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

 

 

 

 

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

視圖層將事件反饋給邏輯層時，同樣需要一個通信過程，通信的方向是從視圖層到邏輯層。因為這個通信過程是異步的，會產(chǎn)生一定的延遲，延遲時間同樣與傳輸?shù)臄?shù)據(jù)量正相關(guān)，數(shù)據(jù)量小于64KB時在30ms內(nèi)。降低延遲時間的方法主要有兩個。

1.去掉不必要的事件綁定（WXML中的bind和catch），從而減少通信的數(shù)據(jù)量和次數(shù)； 2.事件綁定時需要傳輸target和currentTarget的dataset，因而不要在節(jié)點的data前綴屬性中放置過大的數(shù)據(jù)。

 

 

4. 視圖層渲染原理

4.1首次渲染

初始渲染發(fā)生在頁面剛剛創(chuàng)建時。初始渲染時，將初始數(shù)據(jù)套用在對應(yīng)的WXML片段上生成節(jié)點樹。節(jié)點樹也就是在開發(fā)者工具WXML面板中看到的頁面樹結(jié)構(gòu)，它包含頁面內(nèi)所有組件節(jié)點的名稱、屬性值和事件回調(diào)函數(shù)等信息。最后根據(jù)節(jié)點樹包含的各個節(jié)點，在界面上依次創(chuàng)建出各個組件。

 

 

在這整個流程中，時間開銷大體上與節(jié)點樹中節(jié)點的總量成正比例關(guān)系。因而減少WXML中節(jié)點的數(shù)量可以有效降低初始渲染和重渲染的時間開銷，提升渲染性能。

簡化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ù)時，都會執(zhí)行重渲染來更新界面。初始渲染中得到的data和當(dāng)前節(jié)點樹會保留下來用于重渲染。每次重渲染時，將data和setData數(shù)據(jù)套用在WXML片段上，得到一個新節(jié)點樹。然后將新節(jié)點樹與當(dāng)前節(jié)點樹進(jìn)行比較，這樣可以得到哪些節(jié)點的哪些屬性需要更新、哪些節(jié)點需要添加或移除。最后，將setData數(shù)據(jù)合并到data中，并用新節(jié)點樹替換舊節(jié)點樹，用于下一次重渲染。

 

 

在進(jìn)行當(dāng)前節(jié)點樹與新節(jié)點樹的比較時，會著重比較setData數(shù)據(jù)影響到的節(jié)點屬性。因而，去掉不必要設(shè)置的數(shù)據(jù)、減少setData的數(shù)據(jù)量也有助于提升這一個步驟的性能。

5. 使用自定義組件

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

 

 

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

每一次事件監(jiān)聽都是一次視圖到邏輯的通信過程，所以只在必要的時候監(jiān)聽pageSrcoll

 

 

總結(jié)

小程序啟動加載性能

• 控制代碼包的大小

• 分包加載

• 首屏體驗（預(yù)請求，利用緩存，避免白屏，及時反饋

小程序渲染性能

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

• 合理利用事件通信

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

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

• 使用自定義組件