微信小程序優化

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 客戶端內存佔用上升，從而觸發系統回收小程序頁面。

圖片對內存的影響

在 iOS 上，小程序的頁面是由多個 WKWebView 組成的，在系統內存緊張時，會回收掉一部分 WKWebView。從過去咱們分析的案例來看，大圖片和長列表圖片的使用會引發 WKWebView 的回收。

圖片對頁面切換的影響

除了內存問題外，大圖片也會形成頁面切換的卡頓。咱們分析過的案例中，有一部分小程序會在頁面中引用大圖片，在頁面後退切換中會出現掉幀卡頓的狀況。

當前咱們建議開發者儘可能減小使用大圖片資源。

代碼包大小的優化

小程序一開始時代碼包限制爲 1MB，但咱們收到了不少反饋說代碼包大小不夠用，通過評估後咱們放開了這個限制，增長到 2MB 。代碼包上限的增長對於開發者來講，可以實現更豐富的功能，但對於用戶來講，也增長了下載流量和本地空間的佔用。

開發者在實現業務邏輯同時也有必要儘可能減小代碼包的大小，由於代碼包大小直接影響到下載速度，從而影響用戶的首次打開體驗。除了代碼自身的重構優化外，還能夠從這兩方面着手優化代碼大小：

控制代碼包內圖片資源

小程序代碼包通過編譯後，會放在微信的 CDN 上供用戶下載，CDN 開啓了 GZIP 壓縮，因此用戶下載的是壓縮後的 GZIP 包，其大小比代碼包原體積會更小。 但咱們分析數據發現，不一樣小程序之間的代碼包壓縮比差別也挺大的，部分能夠達到 30%，而部分只有 80%，而形成這部分差別的一個緣由，就是圖片資源的使用。GZIP 對基於文本資源的壓縮效果最好，在壓縮較大文件時每每可高達 70%-80% 的壓縮率，而若是對已經壓縮的資源（例如大多數的圖片格式）則效果甚微。

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

在平常開發的時候，咱們可能引入了一些新的庫文件，而過了一段時間後，因爲各類緣由又再也不使用這個庫了，咱們經常會只是去掉了代碼裏的引用，而忘記刪掉這類庫文件了。目前小程序打包是會將工程下全部文件都打入代碼包內，也就是說，這些沒有被實際使用到的庫文件和資源也會被打入到代碼包裏，從而影響到總體代碼包的大小。