微信小程序性能優(yōu)化方式,小程序代碼包大小的優(yōu)化
setData
setData 是小程序開(kāi)發(fā)中使用最頻繁的接口,也是最容易引發(fā)性能問(wèn)題的接口。在介紹常見(jiàn)的錯(cuò)誤用法前,先簡(jiǎn)單介紹一下 setData 背后的工作原理。
工作原理
小程序的視圖層目前使用 WebView 作為渲染載體,而邏輯層是由獨(dú)立的 JavascriptCore 作為運(yùn)行環(huán)境。在架構(gòu)上,WebView 和 JavascriptCore 都是獨(dú)立的模塊,并不具備數(shù)據(jù)直接共享的通道。當(dāng)前,視圖層和邏輯層的數(shù)據(jù)傳輸,實(shí)際上通過(guò)兩邊提供的 evaluateJavascript 所實(shí)現(xiàn)。即用戶(hù)傳輸?shù)臄?shù)據(jù),需要將其轉(zhuǎn)換為字符串形式傳遞,同時(shí)把轉(zhuǎn)換后的數(shù)據(jù)內(nèi)容拼接成一份 JS 腳本,再通過(guò)執(zhí)行 JS 腳本的形式傳遞到兩邊獨(dú)立環(huán)境。
而 evaluateJavascript 的執(zhí)行會(huì)受很多方面的影響,數(shù)據(jù)到達(dá)視圖層并不是實(shí)時(shí)的。同一進(jìn)程內(nèi)的 WebView 實(shí)際上會(huì)共享一個(gè) JS VM,如果 WebView 內(nèi) JS 線(xiàn)程正在執(zhí)行渲染或其他邏輯,會(huì)影響 evaluateJavascript 腳本的實(shí)際執(zhí)行時(shí)間,另外多個(gè) WebView 也會(huì)搶占 JS VM 的執(zhí)行權(quán)限;另外還有 JS 本身的編譯執(zhí)行耗時(shí),都是影響數(shù)據(jù)傳輸速度的因素。
常見(jiàn)的 setData 操作錯(cuò)誤
1. 頻繁的去 setData
在我們分析過(guò)的一些案例里,部分小程序會(huì)非常頻繁(毫秒級(jí))的去setData,其導(dǎo)致了兩個(gè)后果:
Android 下用戶(hù)在滑動(dòng)時(shí)會(huì)感覺(jué)到卡頓,操作反饋延遲嚴(yán)重,因?yàn)?JS 線(xiàn)程一直在編譯執(zhí)行渲染,未能及時(shí)將用戶(hù)操作事件傳遞到邏輯層,邏輯層亦無(wú)法及時(shí)將操作處理結(jié)果及時(shí)傳遞到視圖層;
渲染有出現(xiàn)延時(shí),由于 WebView 的 JS 線(xiàn)程一直處于忙碌狀態(tài),邏輯層到頁(yè)面層的通信耗時(shí)上升,視圖層收到的數(shù)據(jù)消息時(shí)距離發(fā)出時(shí)間已經(jīng)過(guò)去了幾百毫秒,渲染的結(jié)果并不實(shí)時(shí);
2. 每次 setData 都傳遞大量新數(shù)據(jù)
由setData的底層實(shí)現(xiàn)可知,我們的數(shù)據(jù)傳輸實(shí)際是一次 evaluateJavascript 腳本過(guò)程,當(dāng)數(shù)據(jù)量過(guò)大時(shí)會(huì)增加腳本的編譯執(zhí)行時(shí)間,占用 WebView JS 線(xiàn)程,
3. 后臺(tái)態(tài)頁(yè)面進(jìn)行 setData
當(dāng)頁(yè)面進(jìn)入后臺(tái)態(tài)(用戶(hù)不可見(jiàn)),不應(yīng)該繼續(xù)去進(jìn)行setData,后臺(tái)態(tài)頁(yè)面的渲染用戶(hù)是無(wú)法感受的,另外后臺(tái)態(tài)頁(yè)面去setData也會(huì)搶占前臺(tái)頁(yè)面的執(zhí)行。
圖片資源
目前圖片資源的主要性能問(wèn)題在于大圖片和長(zhǎng)列表圖片上,這兩種情況都有可能導(dǎo)致 iOS 客戶(hù)端內(nèi)存占用上升,從而觸發(fā)系統(tǒng)回收小程序頁(yè)面。
圖片對(duì)內(nèi)存的影響
在 iOS 上,小程序的頁(yè)面是由多個(gè) WKWebView 組成的,在系統(tǒng)內(nèi)存緊張時(shí),會(huì)回收掉一部分 WKWebView。從過(guò)去我們分析的案例來(lái)看,大圖片和長(zhǎng)列表圖片的使用會(huì)引起 WKWebView 的回收。
圖片對(duì)頁(yè)面切換的影響
除了內(nèi)存問(wèn)題外,大圖片也會(huì)造成頁(yè)面切換的卡頓。我們分析過(guò)的案例中,有一部分小程序會(huì)在頁(yè)面中引用大圖片,在頁(yè)面后退切換中會(huì)出現(xiàn)掉幀卡頓的情況。
當(dāng)前我們建議開(kāi)發(fā)者盡量減少使用大圖片資源。
代碼包大小的優(yōu)化
小程序一開(kāi)始時(shí)代碼包限制為 1MB,但我們收到了很多反饋說(shuō)代碼包大小不夠用,經(jīng)過(guò)評(píng)估后我們放開(kāi)了這個(gè)限制,增加到 2MB 。代碼包上限的增加對(duì)于開(kāi)發(fā)者來(lái)說(shuō),能夠?qū)崿F(xiàn)更豐富的功能,但對(duì)于用戶(hù)來(lái)說(shuō),也增加了下載流量和本地空間的占用。
開(kāi)發(fā)者在實(shí)現(xiàn)業(yè)務(wù)邏輯同時(shí)也有必要盡量減少代碼包的大小,因?yàn)榇a包大小直接影響到下載速度,從而影響用戶(hù)的首次打開(kāi)體驗(yàn)。除了代碼自身的重構(gòu)優(yōu)化外,還可以從這兩方面著手優(yōu)化代碼大?。?/p>
控制代碼包內(nèi)圖片資源
小程序代碼包經(jīng)過(guò)編譯后,會(huì)放在微信的 CDN 上供用戶(hù)下載,CDN 開(kāi)啟了 GZIP 壓縮,所以用戶(hù)下載的是壓縮后的 GZIP 包,其大小比代碼包原體積會(huì)更小。 但我們分析數(shù)據(jù)發(fā)現(xiàn),不同小程序之間的代碼包壓縮比差異也挺大的,部分可以達(dá)到 30%,而部分只有 80%,而造成這部分差異的一個(gè)原因,就是圖片資源的使用。GZIP 對(duì)基于文本資源的壓縮效果最好,在壓縮較大文件時(shí)往往可高達(dá) 70%-80% 的壓縮率,而如果對(duì)已經(jīng)壓縮的資源(例如大多數(shù)的圖片格式)則效果甚微。
及時(shí)清理沒(méi)有使用到的代碼和資源
在日常開(kāi)發(fā)的時(shí)候,我們可能引入了一些新的庫(kù)文件,而過(guò)了一段時(shí)間后,由于各種原因又不再使用這個(gè)庫(kù)了,我們常常會(huì)只是去掉了代碼里的引用,而忘記刪掉這類(lèi)庫(kù)文件了。目前小程序打包是會(huì)將工程下所有文件都打入代碼包內(nèi),也就是說(shuō),這些沒(méi)有被實(shí)際使用到的庫(kù)文件和資源也會(huì)被打入到代碼包里,從而影響到整體代碼包的大小。
第二部分:如何開(kāi)通一個(gè)小商店