頻繁setData（毫秒級）后果

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

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

每次 setData 都傳遞大量新數據

數據傳輸實際是一次 evaluateJavascript 腳本過程，當數據量過大時會增加腳本的編譯執行時間，占用 WebView JS 線程

后臺態頁面進行 setData

當頁面進入后臺態（用戶不可見），不應該繼續去進行setData，后臺態頁面的渲染用戶是無法感受的，另外后臺態頁面去setData也會搶占前臺頁面的執行

建議

不要頻繁調用setData, 盡量合并到一次setData調用

傳輸數據量跟通信性能有關，盡量少于64k，避免一些不需要在頁面展示的復雜數據結構或者長字符串

與界面無關的數據最好不要設置在data中

去掉不必要的事件綁定，減少通信的數據量以及次數

不要在節點data前綴放置過大數據（需要傳輸target的currentTarget和dataset）

圖片優化
圖片資源

主要性能問題在于大圖片和長列表圖片上，這兩種情況都有可能導致 iOS 客戶端內存占用上升，從而觸發系統回收小程序頁面

圖片對內存的影響

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

圖片對頁面切換的影響

大圖片也會造成頁面切換的卡頓。我們分析過的案例中，有一部分小程序會在頁面中引用大圖片，在頁面后退切換中會出現掉幀卡頓的情況.建議開發者盡量減少使用大圖片資源

代碼包大小的優化
有必要盡量減少代碼包的大小，因為代碼包大小直接影響到下載速度，從而影響用戶的首次打開體驗。除了代碼自身的重構優化外，還可以從這兩方面著手優化代碼大小：

控制代碼包內圖片資源

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

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

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