小程式效能優化的幾點實踐技巧

skinner發表於2019-04-01
優化

小程式效能優化的幾點實踐技巧

大家好，我叫張文軒，這是我的第6篇分享

我們都知道，效能的好壞直接影響使用者的體驗。本文首先論述下如何評判一個小程式頁面的效能情況，之後通過具體的案例重點講解下幾點實踐技巧，最後再講講key值在渲染一個列表時發揮了一個怎麼樣的作用，以此來論述為啥key值對效能提升有幫助。

評判小程式頁面效能

由於小程式開發環境的特殊性，我們不能像普通網頁那樣通過chrome開發工具或者一些成熟的效能測試工具（例如Lighthouse）來了解一個頁面的效能，但微信官方提供了一個效能評分的工具，點選這裡可以檢視工具詳情。

體驗評分是一項給小程式的體驗好壞打分的功能，它會在小程式執行過程中實時檢查，分析出一些可能導致體驗不好的地方，並且定位出哪裡有問題，以及給出一些優化建議。

後面我會以一個實際的例子來展示如何通過該工具來優化頁面效能，我們先看下我們頁面優化前的一個評分情況。

小程式效能優化的幾點實踐技巧

存在setData的資料過大

小程式效能優化的幾點實踐技巧

我們的功能裡面有個滾動到底部載入的功能，優化前我們的做法是這樣的

<!--只闡述邏輯，非真實程式碼-->

// 1: 初始一個list，儲存列表資料
data = startList
// 2: 監聽滾動事件，滾動到底部獲取新資料，並追加到list尾部,最後重新setData
onReachBottom:()=>{
    const {list} = this.data
    fetchNewData().then((res)=>{
        list.push(res.list);
        this.setData({list})
    }
}
複製程式碼

我估計大部分人面對長列表滾動的時候，一開始的處理方式都是這樣的，如果資料不多，只有幾頁可能不會太暴露問題，如果頁數過多，幾十頁甚至上百頁的情況，list的資料會越來越大，每次setData的資料就會越來越多，因而每次頁面重新渲染的節點就會越來越多，從而導致滾動到後面，載入越來越慢。另外，由於小程式的檢視渲染層和資料邏輯處理層是分開的，不是在同一個執行緒上面的，從使用者觸發頁面互動，到處理資料邏輯，最後層現頁面，資料到檢視是需要傳輸的，因而小程式本身對資料大小也有限制，不能超過1M。

setData資料路徑

怎麼解決呢？小程式setData裡面的key支援資料路徑的寫法，比如

let o = obj;
this.setData({
    'o.屬性'：value
})

或者
let a = array;
this.setData({
    'array[0].text':value
})
複製程式碼

所以我們可以通過資料路徑的寫法，來將資料分批的傳輸到檢視層中，減少一次性setData的資料大小。具體寫法如下

// 1.通過一個二維陣列來儲存資料
let feedList = [[array]];

// 2.維護一個頁面變數值，載入完一次資料page++
let page = 1

// 3.頁面每次滾動到底部，通過資料路徑更新資料
onReachBottom:()=>{
    fetchNewData().then((newVal)=>{
        this.setData({
            ['feedList[' + (page - 1) + ']']: newVal,
        })
    }
}
// 4.最終我們的資料是[[array1],[array2]]這樣的格式，然後通過wx:for遍歷渲染資料
複製程式碼

存在短時間內發起太多圖片請求（圖片懶載入）

這個應該好理解，就是渲染頁面時，一次性傳送了過多的圖片請求，導致了同一時間發起了過多的http請求，http連線是非常耗時的，尤其是一次性發起這麼多，並且一次性發起的http連結也是有限制的，比如chrome瀏覽器就限制一次性最多6個。

所以在渲染頁面時，不在檢視範圍內的圖片我們不載入，只有元素出現在檢視範圍內了，再渲染。

常規的做法是，通過getBoundingClientRect()獲取元素的位置，然後與頁面滾動位置比較，如果出現在檢視內，就將img顯示。這種方式有2個問題

  • getBoundingClientRect()方法呼叫本身容易引起頁面重排
  • 監聽滾動事件本身就頻繁觸發，雖然可以通過節流的方式來減少，但還是容易增加無謂程式碼處理

IntersectionObserver

其實，微信提供了IntersectionObserver物件。

IntersectionObserver 物件，用於推斷某些節點是否可以被使用者看見、有多大比例可以被使用者看見

通過這個api我們不用再主動去監聽元素位置了，在頁面渲染一開始，通過這個api指明需要監聽的元素，系統會自動去監聽了元素位置。

let data = list;

<img class="img-{{index}}" wx:for="{{data}}"></img>

data.forEach((item,index)=>{
    this.createIntersectionObserver().relativeToViewport.observe(`.img-${index}`,res=>{
        if (res.intersectionRatio > 0){
            this.setData({
                item.imgShow:true
            })
        }
    })
})

複製程式碼

intersectionRatio值大於0，說明元素出現在檢視中了，重新setData資料，顯示圖片元件。

存在圖片太大而顯示區域過小

這個問題就是指圖片尺寸太大了，而頁面上我們顯示的尺寸又太小了，圖片尺寸大，請求圖片就越慢，導致頁面渲染速度下降。

CDN圖片處理

對於頁面裡面的圖片，最好都把圖片儲存在cdn伺服器上，一個是能充分利用cdn快取來加快請求速度，另外一個就是cdn上能夠將圖片進行一定的處理，比如裁剪。我司就是通過cdn來響應圖片處理，然後請求圖片時告訴cdn伺服器需要什麼要的尺寸圖片，由cdn伺服器響應對應尺寸圖片。

key值在列表渲染中的作用

key值在列表渲染的時候，能夠提升列表渲染效能，為什麼呢？首先得想想小程式的頁面是如何渲染的，主要分為以下幾步：

  1. 將wxml結構的文件構建成一個vdom虛擬數
  2. 頁面有新的互動，產生新的vdom數，然後與舊數進行比較，看哪裡有變化了，做對應的修改（刪除、移動、更新值）等操作
  3. 最後再將vdom渲染成真實的頁面結構

key值的作用就在第二步，當資料改變觸發渲染層重新渲染的時候，會校正帶有 key 的元件，框架會確保他們被重新排序，而不是重新建立，以確保使元件保持自身的狀態，並且提高列表渲染時的效率。

key值如果不指明，預設會按陣列的索引來處理，因而會導致一些類似input等輸入框元件的值出現混亂的問題。

小程式效能優化的幾點實踐技巧

相關測試程式碼可以檢視：wxkey

可以看到

  • 不加key,在陣列末尾追加元素，之前已渲染的元素不會重新渲染。但如果是在頭部或者中間插入元素，整個list被刪除重新渲染，且input元件的值還出現了混亂，值沒有正常被更新
  • 新增key，在陣列末尾、中間、或者頭部插入元素，其它已存在的元素都不會被重新渲染，值也能正常被更新

因而，在做list渲染時，如果list的順序發生變化時，最好增加key，且不要簡單的使用陣列索引當做key。

最後看看我們的成果：

小程式效能優化的幾點實踐技巧

體驗碼：

小程式效能優化的幾點實踐技巧

希望今天我的分享能對您優化小程式頁面有一定的啟示，創造出效能更好更流暢的頁面。

最後如果喜歡我的文章，歡迎點選關注，我會不定期的分享自己的一些所看所想，和大家一起成長，持續學習。

相關文章