setData

setData 是小程序開發(fā)中使用最頻繁的接口，也是最容易引發(fā)性能問題的接口。在介紹常見的錯誤用法前，先簡單介紹一下 setData 背后的工作原理。

工作原理

小程序的視圖層目前使用 WebView 作為渲染載體，而邏輯層是由獨立的 JavascriptCore 作為運行環(huán)境。在架構上，WebView 和 JavascriptCore 都是獨立的模塊，并不具備數(shù)據(jù)直接共享的通道。當前，視圖層和邏輯層的數(shù)據(jù)傳輸，實際上通過兩邊提供的evaluateJavascript 所實現(xiàn)。即用戶傳輸?shù)臄?shù)據(jù)，需要將其轉換為字符串形式傳遞，同時把轉換后的數(shù)據(jù)內容拼接成一份 JS 腳本，再通過執(zhí)行 JS 腳本的形式傳遞到兩邊獨立環(huán)境。

而 evaluateJavascript 的執(zhí)行會受很多方面的影響，數(shù)據(jù)到達視圖層并不是實時的。

常見的 setData 操作錯誤

1. 頻繁的去 setData

在我們分析過的一些案例里，部分小程序會非常頻繁（毫秒級）的去setData，其導致了兩個后果：

· Android 下用戶在滑動時會感覺到卡頓，操作反饋延遲嚴重，因為 JS 線程一直在編譯執(zhí)行渲染，未能及時將用戶操作事件傳遞到邏輯層，邏輯層亦無法及時將操作處理結果及時傳遞到視圖層；

· 渲染有出現(xiàn)延時，由于 WebView 的 JS 線程一直處于忙碌狀態(tài)，邏輯層到頁面層的通信耗時上升，視圖層收到的數(shù)據(jù)消息時距離發(fā)出時間已經過去了幾百毫秒，渲染的結果并不實時；

2. 每次 setData 都傳遞大量新數(shù)據(jù)

由setData的底層實現(xiàn)可知，我們的數(shù)據(jù)傳輸實際是一次 evaluateJavascript 腳本過程，當數(shù)據(jù)量過大時會增加腳本的編譯執(zhí)行時間，占用 WebView JS 線程，

3. 后臺態(tài)頁面進行 setData

當頁面進入后臺態(tài)（用戶不可見），不應該繼續(xù)去進行setData，后臺態(tài)頁面的渲染用戶是無法感受的，另外后臺態(tài)頁面去setData也會搶占前臺頁面的執(zhí)行。

圖片資源

目前圖片資源的主要性能問題在于大圖片和長列表圖片上，這兩種情況都有可能導致 iOS 客戶端內存占用上升，從而觸發(fā)系統(tǒng)回收小程序頁面。

圖片對內存的影響

圖片對頁面切換的影響

除了內存問題外，大圖片也會造成頁面切換的卡頓。我們分析過的案例中，有一部分小程序會在頁面中引用大圖片，在頁面后退切換中會出現(xiàn)掉幀卡頓的情況。

當前我們建議開發(fā)者盡量減少使用大圖片資源。

代碼包大小的優(yōu)化

小程序一開始時代碼包限制為 1MB，但我們收到了很多反饋說代碼包大小不夠用，經過評估后我們放開了這個限制，增加到 2MB 。代碼包上限的增加對于開發(fā)者來說，能夠實現(xiàn)更豐富的功能，但對于用戶來說，也增加了下載流量和本地空間的占用。

開發(fā)者在實現(xiàn)業(yè)務邏輯同時也有必要盡量減少代碼包的大小，因為代碼包大小直接影響到下載速度，從而影響用戶的首次打開體驗。除了代碼自身的重構優(yōu)化外，還可以從這兩方面著手優(yōu)化代碼大小：

控制代碼包內圖片資源

小程序代碼包經過編譯后，會放在微信的 CDN 上供用戶下載，CDN 開啟了 GZIP 壓縮，所以用戶下載的是壓縮后的 GZIP 包，其大小比代碼包原體積會更小。 但我們分析數(shù)據(jù)發(fā)現(xiàn)，不同小程序之間的代碼包壓縮比差異也挺大的，部分可以達到 30%，而部分只有 80%，而造成這部分差異的一個原因，就是圖片資源的使用。GZIP 對基于文本資源的壓縮效果最好，在壓縮較大文件時往往可高達 70%-80% 的壓縮率，而如果對已經壓縮的資源（例如大多數(shù)的圖片格式）則效果甚微。

及時清理沒有使用到的代碼和資源

在日常開發(fā)的時候，我們可能引入了一些新的庫文件，而過了一段時間后，由于各種原因又不再使用這個庫了，我們常常會只是去掉了代碼里的引用，而忘記刪掉這類庫文件了。目前小程序打包是會將工程下所有文件都打入代碼包內，也就是說，這些沒有被實際使用到的庫文件和資源也會被打入到代碼包里，從而影響到整體代碼包的大小。

WXS 模塊

每個 wxs 模塊均有一個內置的 module 對象。
直接在wxml中引入，可以將寫需要轉化數(shù)據(jù)的寫進去，防止給setData加負擔

使用了過大的 WXML 節(jié)點數(shù)目

一個太大的WXML節(jié)點樹會增加內存的使用，樣式重排時間也會更長，建議一個頁面使用少于1000個WXML的節(jié)點，節(jié)點樹深度少于30層，子節(jié)點數(shù)不大于60

小程序有并發(fā)限制

wx.request、wx.uploadFile、wx.downloadFile 的最大并發(fā)限制是 10 個。

所有為了保險起見，采用公共方法和組件

編寫公共方法和組件，可以避免重復造輪子。
1.公共埋點方法
2.各種處理js的方法（轉https，throttle，formatTime等）
3.公共組件（iphonex兼容組件，倒計時組件等）

需要寫個請求隊列，如果并發(fā)量大于10，則等待請求。

埋點的坑

埋點用公共方法，頁面曝光pv埋點放入onshow生命周期中更加準確。

setData注意點

1. 頻繁的去 setData
存在將未綁定在 WXML 的變量都不需要傳入 setData。
2. 每次 setData 都傳遞大量新數(shù)據(jù)，可局部更新

this.setData({

list[index] = newList[index]

})

3. 后臺態(tài)頁面進行 setData

當頁面進入后臺態(tài)（用戶不可見），不應該繼續(xù)去進行setData，后臺態(tài)頁面的渲染用戶是無法感受的，另外后臺態(tài)頁面去setData也會搶占前臺頁面的執(zhí)行。也就是上文提到的不要忘了clearTimeout、clearInterval。