網(wǎng)頁(yè)的性能優(yōu)化是前端開(kāi)發(fā)老生常談的熱門話題，其中微信小程序因其頁(yè)面雙線程架構(gòu)設(shè)計(jì)，所以性能優(yōu)化的手段跟傳統(tǒng)的 H5 應(yīng)用不太一樣。今天主要介紹一下微信小程序頁(yè)面雙線程架構(gòu)的特性給頁(yè)面渲染帶來(lái)的一些影響，以及應(yīng)對(duì)的一些渲染性能調(diào)優(yōu)策略。為了敘述方便，下文會(huì)把微信小程序簡(jiǎn)稱為小程序。

小程序的雙線程架構(gòu)

與傳統(tǒng)的瀏覽器Web頁(yè)面最大區(qū)別在于，小程序的是基于 雙線程 模型的，在這種架構(gòu)中，小程序的渲染層使用 WebView 作為渲染載體，而邏輯層則由獨(dú)立的 JsCore 線程運(yùn)行 JS 腳本，雙方并不具備數(shù)據(jù)直接共享的通道，因此渲染層和邏輯層的通信要由 Native 的 JSBrigde 做中轉(zhuǎn)。

小程序更新視圖數(shù)據(jù)的通信流程

每當(dāng)小程序視圖數(shù)據(jù)需要更新時(shí)，邏輯層會(huì)調(diào)用小程序宿主環(huán)境提供的 setData 方法將數(shù)據(jù)從邏輯層傳遞到視圖層，經(jīng)過(guò)一系列渲染步驟之后完成UI視圖更新。完整的通信流程如下：

小程序邏輯層調(diào)用宿主環(huán)境的 setData 方法。 邏輯層執(zhí)行 JSON.stringify 將待傳輸數(shù)據(jù)轉(zhuǎn)換成字符串并拼接到特定的JS腳本，并通過(guò)evaluateJavascript 執(zhí)行腳本將數(shù)據(jù)傳輸?shù)戒秩緦印? 渲染層接收到后， WebView JS 線程會(huì)對(duì)腳本進(jìn)行編譯，得到待更新數(shù)據(jù)后進(jìn)入渲染隊(duì)列等待 WebView 線程空閑時(shí)進(jìn)行頁(yè)面渲染。 WebView 線程開(kāi)始執(zhí)行渲染時(shí)，待更新數(shù)據(jù)會(huì)合并到視圖層保留的原始 data 數(shù)據(jù)，并將新數(shù)據(jù)套用在WXML片段中得到新的虛擬節(jié)點(diǎn)樹。經(jīng)過(guò)新虛擬節(jié)點(diǎn)樹與當(dāng)前節(jié)點(diǎn)樹的 diff 對(duì)比，將差異部分更新到UI視圖。同時(shí)，將新的節(jié)點(diǎn)樹替換舊節(jié)點(diǎn)樹，用于下一次重渲染。

引發(fā)渲染性能問(wèn)題的一些原因

在上述通信流程中，一些不恰當(dāng)?shù)牟僮骺赡軙?huì)影響到頁(yè)面渲染的性能：

setData傳遞大量的新數(shù)據(jù)

數(shù)據(jù)的傳輸會(huì)經(jīng)歷跨線程傳輸和腳本編譯的過(guò)程，當(dāng)數(shù)據(jù)量過(guò)大，會(huì)增加腳本編譯的執(zhí)行時(shí)間，占用 WebView JS 線程。

下圖是我們做的一組測(cè)試統(tǒng)計(jì)：在相同網(wǎng)絡(luò)環(huán)境下，各個(gè)機(jī)型分別對(duì)大小為 1KB 、 2KB 、 3KB 的數(shù)據(jù)執(zhí)行 setData 操作所消耗的時(shí)間。

從圖中可以看出， setData 數(shù)據(jù)傳輸量越大，數(shù)據(jù)傳輸所消耗的時(shí)間越大。

頻繁的執(zhí)行setData操作

頻繁的執(zhí)行 setData 會(huì)讓 WebView JS 線程一直忙碌于腳本的編譯、節(jié)點(diǎn)樹的對(duì)比計(jì)算和頁(yè)面渲染。導(dǎo)致的結(jié)果是：