運(yùn)行時性能

setData

setData 是小程序開發(fā)中使用最頻繁的接口，也是最容易引發(fā)性能問題的接口。在介紹常見的錯誤用法前，先簡單介紹一下 setData 背后的工作原理。

創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比昔陽網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式昔陽網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋昔陽地區(qū)。費(fèi)用合理售后完善，十多年實(shí)體公司更值得信賴。

工作原理

小程序的視圖層目前使用 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 操作錯誤

1. 頻繁的去 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í)時；

2. 每次 setData 都傳遞大量新數(shù)據(jù)

由setData的底層實(shí)現(xiàn)可知，我們的數(shù)據(jù)傳輸實(shí)際是一次 evaluateJavascript 腳本過程，當(dāng)數(shù)據(jù)量過大時會增加腳本的編譯執(zhí)行時間，占用 WebView JS 線程，

3. 后臺態(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ā)者盡量減少使用大圖片資源。

本文標(biāo)題：創(chuàng)新互聯(lián)小程序教程：微信小程序運(yùn)行時性能
鏈接分享：http://uogjgqi.cn/article/dpiieip.html