關於小程式優化的一些建議(小結)
setData
setData 是小程式開發中使用最頻繁的介面，也是最容易引發效能問題的介面。在介紹常見的錯誤用法前，先簡單介紹一下 setData 背後的工作原理。
工作原理
小程式的檢視層目前使用 WebView 作為渲染載體，而邏輯層是由獨立的 JavascriptCore 作為執行環境。在架構上，WebView 和 JavascriptCore 都是獨立的模組，並不具備資料直接共享的通道。當前，檢視層和邏輯層的資料傳輸，實際上通過兩邊提供的evaluateJavascript 所實現。即使用者傳輸的資料，需要將其轉換為字串形式傳遞，同時把轉換後的資料內容拼接成一份 JS 指令碼，再通過執行 JS 指令碼的形式傳遞到兩邊獨立環境。
而 evaluateJavascript 的執行會受很多方面的影響，資料到達檢視層並不是實時的。
常見的 setData 操作錯誤
1. 頻繁的去 setData
在我們分析過的一些案例裡，部分小程式會非常頻繁（毫秒級）的去setData，其導致了兩個後果：
- Android 下使用者在滑動時會感覺到卡頓，操作反饋延遲嚴重，因為 JS 執行緒一直在編譯執行渲染，未能及時將使用者操作事件傳遞到邏輯層，邏輯層亦無法及時將操作處理結果及時傳遞到檢視層；
- 渲染有出現延時，由於 WebView 的 JS 執行緒一直處於忙碌狀態，邏輯層到頁面層的通訊耗時上升，檢視層收到的資料訊息時距離發出時間已經過去了幾百毫秒，渲染的結果並不實時；
2. 每次 setData 都傳遞大量新資料
由setData的底層實現可知，我們的資料傳輸實際是一次 evaluateJavascript 指令碼過程，當資料量過大時會增加指令碼的編譯執行時間，佔用 WebView JS 執行緒，
3. 後臺態頁面進行 setData
當頁面進入後臺態（使用者不可見），不應該繼續去進行setData，後臺態頁面的渲染使用者是無法感受的，另外後臺態頁面去setData也會搶佔前臺頁面的執行。
圖片資源
目前圖片資源的主要效能問題在於大圖片和長列表圖片上，這兩種情況都有可能導致 iOS 客戶端記憶體佔用上升，從而觸發系統回收小程式頁面。
圖片對記憶體的影響
圖片對頁面切換的影響
除了記憶體問題外，大圖片也會造成頁面切換的卡頓。我們分析過的案例中，有一部分小程式會在頁面中引用大圖片，在頁面後退切換中會出現掉幀卡頓的情況。
當前我們建議開發者儘量減少使用大圖片資源。
程式碼包大小的優化
小程式一開始時程式碼包限制為 1MB，但我們收到了很多反饋說程式碼包大小不夠用，經過評估後我們放開了這個限制，增加到 2MB 。程式碼包上限的增加對於開發者來說，能夠實現更豐富的功能，但對於使用者來說，也增加了下載流量和本地空間的佔用。
開發者在實現業務邏輯同時也有必要儘量減少程式碼包的大小，因為程式碼包大小直接影響到下載速度，從而影響使用者的首次開啟體驗。除了程式碼自身的重構優化外，還可以從這兩方面著手優化程式碼大小：
控制程式碼包內圖片資源
小程式程式碼包經過編譯後，會放在微信的 CDN 上供使用者下載，CDN 開啟了 GZIP 壓縮，所以使用者下載的是壓縮後的 GZIP 包，其大小比程式碼包原體積會更小。 但我們分析資料發現，不同小程式之間的程式碼包壓縮比差異也挺大的，部分可以達到 30%，而部分只有 80%，而造成這部分差異的一個原因，就是圖片資源的使用。GZIP 對基於文字資源的壓縮效果最好，在壓縮較大檔案時往往可高達 70%-80% 的壓縮率，而如果對已經壓縮的資源（例如大多數的圖片格式）則效果甚微。
及時清理沒有使用到的程式碼和資源
在日常開發的時候，我們可能引入了一些新的庫檔案，而過了一段時間後，由於各種原因又不再使用這個庫了，我們常常會只是去掉了程式碼裡的引用，而忘記刪掉這類庫檔案了。目前小程式打包是會將工程下所有檔案都打入程式碼包內，也就是說，這些沒有被實際使用到的庫檔案和資源也會被打入到程式碼包裡，從而影響到整體程式碼包的大小。
WXS 模組
每個 wxs 模組均有一個內建的 module 物件。
直接在wxml中引入，可以將寫需要轉化資料的寫進去，防止給setData加負擔
使用了過大的 WXML 節點數目
一個太大的WXML節點樹會增加記憶體的使用，樣式重排時間也會更長，建議一個頁面使用少於1000個WXML的節點，節點樹深度少於30層，子節點數不大於60
小程式有併發限制
wx.request、wx.uploadFile、wx.downloadFile 的最大併發限制是 10 個。
所有為了保險起見，採用公共方法和元件
編寫公共方法和元件，可以避免重複造輪子。
1.公共埋點方法
2.各種處理js的方法（轉https，throttle，formatTime等）
3.公共元件（iphonex相容元件，倒計時元件等）
需要寫個請求佇列，如果併發量大於10，則等待請求。
埋點的坑
埋點用公共方法，頁面曝光pv埋點放入onshow生命週期中更加準確。
setData注意點
1. 頻繁的去 setData
存在將未繫結在 WXML 的變數都不需要傳入 setData。
2. 每次 setData 都傳遞大量新資料，可區域性更新
this.setData({
list[index] = newList[index]
})
3. 後臺態頁面進行 setData
當頁面進入後臺態（使用者不可見），不應該繼續去進行setData，後臺態頁面的渲染使用者是無法感受的，另外後臺態頁面去setData也會搶佔前臺頁面的執行。也就是上文提到的不要忘了clearTimeout、clearInterval。
到此這篇關於關於小程式優化的一些建議(小結)的文章就介紹到這了,更多相關小程式優化內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！