小程式列表效能優化

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

//1: 初始乙個list，儲存列表資料
data =startlist
//2: 監聽滾動事件，滾動到底部獲取新資料，並追加到list尾部,最後重新setdata
onreachbottom:()=> = this
.data
fetchnewdata().then((res)=>)}}

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

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

let o =obj;
this
.setdata()
或者let a =array;
this
.setdata()

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

//
1.通過乙個二維陣列來儲存資料
let feedlist =[[array]];
//2.維護乙個頁面變數值，載入完一次資料page++
let page = 1
//3.頁面每次滾動到底部，通過資料路徑更新資料
onreachbottom:()=>)
}}//
4.最終我們的資料是[[array1],[array2]]這樣的格式，然後通過wx:for遍歷渲染資料

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

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

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

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

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

let data =list;
img-}
" wx:for="
}">
data.foreach((item,index)=>`,res=>)}})
})

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

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

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

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

將wxml結構的文件構建成乙個vdom虛擬數

頁面有新的互動，產生新的vdom數，然後與舊數進行比較，看**有變化了，做對應的修改（刪除、移動、更新值）等操作

最後再將vdom渲染成真實的頁面結構

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

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

相關測試**可以檢視：wxkey

可以看到

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

最後看看我們的成果：

小程式列表效能優化

小程式列表倒計時

微信小程式列表渲染wx for

5 微信小程式列表渲染 wx for

小程式列表效能優化

小程式列表倒計時

微信小程式 列表渲染wx for

5 微信小程式 列表渲染 wx for

相關推薦

微信小程式列表渲染wx for

5 微信小程式列表渲染 wx for