setData
setData 是小程序開發(fā)中使用最頻繁的接口让禀，也是最容易引發(fā)性能問題的接口钢拧。在介紹常見的錯誤用法前拯爽，先簡單介紹一下 setData 背后的工作原理。
工作原理
小程序的視圖層目前使用 WebView 作為渲染載體碳蛋，而邏輯層是由獨(dú)立的 JavascriptCore 作為運(yùn)行環(huán)境胚泌。在架構(gòu)上，WebView 和 JavascriptCore 都是獨(dú)立的模塊肃弟，并不具備數(shù)據(jù)直接共享的通道诸迟。當(dāng)前，視圖層和邏輯層的數(shù)據(jù)傳輸愕乎，實(shí)際上通過兩邊提供的 evaluateJavascript 所實(shí)現(xiàn)。即用戶傳輸?shù)臄?shù)據(jù)壁公，需要將其轉(zhuǎn)換為字符串形式傳遞感论，同時把轉(zhuǎn)換后的數(shù)據(jù)內(nèi)容拼接成一份 JS 腳本，再通過執(zhí)行 JS 腳本的形式傳遞到兩邊獨(dú)立環(huán)境紊册。
而 evaluateJavascript 的執(zhí)行會受很多方面的影響比肄，數(shù)據(jù)到達(dá)視圖層并不是實(shí)時的。
常見的 setData 操作錯誤
- 頻繁的去 setData
在我們分析過的一些案例里囊陡，部分小程序會非常頻繁（毫秒級）的去setData芳绩，其導(dǎo)致了兩個后果：
Android 下用戶在滑動時會感覺到卡頓，操作反饋延遲嚴(yán)重撞反，因?yàn)?JS 線程一直在編譯執(zhí)行渲染妥色，未能及時將用戶操作事件傳遞到邏輯層，邏輯層亦無法及時將操作處理結(jié)果及時傳遞到視圖層遏片；
渲染有出現(xiàn)延時嘹害，由于 WebView 的 JS 線程一直處于忙碌狀態(tài)撮竿，邏輯層到頁面層的通信耗時上升，視圖層收到的數(shù)據(jù)消息時距離發(fā)出時間已經(jīng)過去了幾百毫秒笔呀，渲染的結(jié)果并不實(shí)時幢踏；
- 每次 setData 都傳遞大量新數(shù)據(jù)
由setData的底層實(shí)現(xiàn)可知，我們的數(shù)據(jù)傳輸實(shí)際是一次 evaluateJavascript 腳本過程许师，當(dāng)數(shù)據(jù)量過大時會增加腳本的編譯執(zhí)行時間房蝉，占用 WebView JS 線程，
- 后臺態(tài)頁面進(jìn)行 setData
當(dāng)頁面進(jìn)入后臺態(tài)（用戶不可見）微渠，不應(yīng)該繼續(xù)去進(jìn)行setData搭幻，后臺態(tài)頁面的渲染用戶是無法感受的，另外后臺態(tài)頁面去setData也會搶占前臺頁面的執(zhí)行敛助。
圖片資源
目前圖片資源的主要性能問題在于大圖片和長列表圖片上粗卜，這兩種情況都有可能導(dǎo)致 iOS 客戶端內(nèi)存占用上升，從而觸發(fā)系統(tǒng)回收小程序頁面纳击。
圖片對內(nèi)存的影響
在 iOS 上续扔，小程序的頁面是由多個 WKWebView 組成的，在系統(tǒng)內(nèi)存緊張時焕数，會回收掉一部分 WKWebView纱昧。從過去我們分析的案例來看，大圖片和長列表圖片的使用會引起 WKWebView 的回收堡赔。
圖片對頁面切換的影響
除了內(nèi)存問題外识脆，大圖片也會造成頁面切換的卡頓。我們分析過的案例中善已，有一部分小程序會在頁面中引用大圖片灼捂，在頁面后退切換中會出現(xiàn)掉幀卡頓的情況。
當(dāng)前我們建議開發(fā)者盡量減少使用大圖片資源换团。
代碼包大小的優(yōu)化
小程序一開始時代碼包限制為 1MB悉稠，但我們收到了很多反饋說代碼包大小不夠用，經(jīng)過評估后我們放開了這個限制艘包，增加到 2MB 的猛。代碼包上限的增加對于開發(fā)者來說，能夠?qū)崿F(xiàn)更豐富的功能想虎，但對于用戶來說卦尊，也增加了下載流量和本地空間的占用。
開發(fā)者在實(shí)現(xiàn)業(yè)務(wù)邏輯同時也有必要盡量減少代碼包的大小舌厨，因?yàn)榇a包大小直接影響到下載速度岂却，從而影響用戶的首次打開體驗(yàn)。除了代碼自身的重構(gòu)優(yōu)化外，還可以從這兩方面著手優(yōu)化代碼大刑视选：
控制代碼包內(nèi)圖片資源
小程序代碼包經(jīng)過編譯后煌恢，會放在微信的 CDN 上供用戶下載，CDN 開啟了 GZIP 壓縮震庭，所以用戶下載的是壓縮后的 GZIP 包瑰抵，其大小比代碼包原體積會更小。 但我們分析數(shù)據(jù)發(fā)現(xiàn)器联，不同小程序之間的代碼包壓縮比差異也挺大的二汛，部分可以達(dá)到 30%，而部分只有 80%拨拓，而造成這部分差異的一個原因肴颊，就是圖片資源的使用。GZIP 對基于文本資源的壓縮效果最好渣磷，在壓縮較大文件時往往可高達(dá) 70%-80% 的壓縮率婿着，而如果對已經(jīng)壓縮的資源（例如大多數(shù)的圖片格式）則效果甚微。
及時清理沒有使用到的代碼和資源
在日常開發(fā)的時候醋界，我們可能引入了一些新的庫文件竟宋，而過了一段時間后，由于各種原因又不再使用這個庫了形纺，我們常常會只是去掉了代碼里的引用丘侠，而忘記刪掉這類庫文件了。目前小程序打包是會將工程下所有文件都打入代碼包內(nèi)逐样，也就是說蜗字，這些沒有被實(shí)際使用到的庫文件和資源也會被打入到代碼包里，從而影響到整體代碼包的大小脂新。
