概述

在應(yīng)用開(kāi)發(fā)中，當(dāng)頁(yè)面內(nèi)的列表結(jié)構(gòu)較為復(fù)雜且每個(gè)列表項(xiàng)包含的組件較多時(shí)，容易導(dǎo)致嵌套層級(jí)過(guò)深，進(jìn)而增加組件的負(fù)載，延長(zhǎng)繪制時(shí)間。在轉(zhuǎn)場(chǎng)或列表滑動(dòng)時(shí)，列表項(xiàng)可能會(huì)一次性加載大量數(shù)據(jù)，導(dǎo)致性能問(wèn)題。此時(shí)，可以采用分幀渲染技術(shù)，將原本在一幀內(nèi)加載的數(shù)據(jù)分散到多幀中逐步加載，從而減輕單幀的渲染壓力。不過(guò)，分幀渲染需要開(kāi)發(fā)者精確計(jì)算每幀加載的數(shù)據(jù)量，操作較為復(fù)雜，因此建議僅在性能瓶頸明顯且必要時(shí)使用。

實(shí)現(xiàn)原理

（一）原理說(shuō)明

在單幀內(nèi)繪制多個(gè)特性各不相同的組件時(shí)，會(huì)同時(shí)創(chuàng)建大量的GraphicsPipelines，導(dǎo)致后續(xù)整個(gè)Flush階段的耗時(shí)增加，從而使得單幀渲染時(shí)間過(guò)長(zhǎng)。針對(duì)這種單幀內(nèi)組件負(fù)載重、數(shù)據(jù)量大、繪制耗時(shí)長(zhǎng)的問(wèn)題，開(kāi)發(fā)者可以根據(jù)實(shí)際的業(yè)務(wù)邏輯、頁(yè)面布局和數(shù)據(jù)量，提前規(guī)劃需要通過(guò)多少幀完成加載，通過(guò)幀回調(diào)監(jiān)聽(tīng)來(lái)動(dòng)態(tài)修改狀態(tài)變量或向數(shù)據(jù)結(jié)構(gòu)中補(bǔ)充數(shù)據(jù)，計(jì)算和設(shè)置每一幀需要處理的渲染數(shù)據(jù)，確保每一幀只處理預(yù)設(shè)的數(shù)據(jù)量。由于已經(jīng)設(shè)置了幀回調(diào)監(jiān)聽(tīng)，頁(yè)面組件在加載數(shù)據(jù)時(shí)，只需通過(guò)狀態(tài)變量或數(shù)據(jù)結(jié)構(gòu)即可實(shí)現(xiàn)按幀分批加載數(shù)據(jù)。這種方式將原本需要在一幀內(nèi)加載的數(shù)據(jù)分散到多幀中處理，有效減少了首幀的渲染壓力，避免了首幀卡頓現(xiàn)象的發(fā)生。如下圖所示，將一幀數(shù)據(jù)拆分到三幀示例：

（二）具體實(shí)現(xiàn)

在高負(fù)載場(chǎng)景下使用分幀渲染的關(guān)鍵操作是把數(shù)據(jù)拆分到每一幀中加載，但這個(gè)過(guò)程中加載新的數(shù)據(jù)時(shí)可能會(huì)將已有數(shù)據(jù)再次繪制，因此需要搭配合理的頁(yè)面布局來(lái)避免重繪?？梢酝ㄟ^(guò)if或ForEach兩種方法來(lái)實(shí)現(xiàn)布局，兩種方法的更新機(jī)制如下：

if更新機(jī)制是根據(jù)狀態(tài)判斷條件，如果分支沒(méi)有變化，不會(huì)對(duì)條件渲染語(yǔ)句進(jìn)行更新。

ForEach非首次渲染會(huì)檢查新生成的鍵值是否在上次渲染中已經(jīng)存在。如果鍵值不存在，則會(huì)創(chuàng)建一個(gè)新的組件；如果鍵值存在，則不會(huì)創(chuàng)建新的組件，而是直接渲染該鍵值所對(duì)應(yīng)的組件。

因此在分幀逐步加載數(shù)據(jù)時(shí)使用上述兩種方法不會(huì)引起重繪。并且在頁(yè)面布局時(shí)可以給分幀渲染的外部容器組件設(shè)置寬高，這樣組件本身不會(huì)觸發(fā)重新進(jìn)行Measure的過(guò)程，對(duì)組件的寬高不會(huì)重新測(cè)算，避免因外部容器大小改變引起重繪，詳情可參考合理使用布局。

保證頁(yè)面不會(huì)重繪后，在實(shí)際開(kāi)發(fā)過(guò)程中為了逐步增加頁(yè)面數(shù)據(jù)，可以使用ArkTS中提供的displaySync（可變幀率）API接口，通過(guò)Vsync信號(hào)控制數(shù)據(jù)刷新的時(shí)機(jī)，來(lái)實(shí)現(xiàn)繪制內(nèi)容幀率的控制。先通過(guò)頁(yè)面UI中aboutToAppear()添加幀回調(diào)監(jiān)聽(tīng)并開(kāi)啟監(jiān)聽(tīng)，Vsync信號(hào)變化時(shí)觸發(fā)幀回調(diào)執(zhí)行應(yīng)用邏輯，計(jì)算每幀加載的數(shù)據(jù)，改變ViewModel數(shù)據(jù)。ViewModel數(shù)據(jù)改變后驅(qū)動(dòng)頁(yè)面或組件執(zhí)行build()，使用if或ForEach分幀迭代渲染繪制UI并控制刷新范圍。最后可以在aboutToDisappear()里停止幀回調(diào)監(jiān)聽(tīng)。

具體操作流程如下圖：

轉(zhuǎn)場(chǎng)場(chǎng)景

由于業(yè)務(wù)需求，從當(dāng)前頁(yè)面進(jìn)入一個(gè)新頁(yè)面時(shí)，會(huì)有轉(zhuǎn)場(chǎng)動(dòng)畫(huà)播放，并且在動(dòng)畫(huà)首幀中加載新頁(yè)面所需要的數(shù)據(jù)。如果數(shù)據(jù)量較多，那么動(dòng)畫(huà)首幀的響應(yīng)時(shí)延就會(huì)變長(zhǎng)，導(dǎo)致后面動(dòng)畫(huà)幀延遲播放的情況。從一個(gè)頁(yè)面到新頁(yè)面轉(zhuǎn)場(chǎng)流程圖如下：

（一）解決思路

既然轉(zhuǎn)場(chǎng)時(shí)一次性加載大量的數(shù)據(jù)會(huì)導(dǎo)致卡頓情況，那么采用分幀渲染將數(shù)據(jù)拆分成多份并分批次進(jìn)行加載就是一種解決思路。

轉(zhuǎn)場(chǎng)場(chǎng)景分幀：轉(zhuǎn)場(chǎng)時(shí)會(huì)在動(dòng)畫(huà)首幀加載新頁(yè)面的數(shù)據(jù)，采用分幀策略就是將首幀加載的數(shù)據(jù)拆分，將數(shù)據(jù)拆分到后面的幀加載，新頁(yè)面打開(kāi)后List列表只展示兩個(gè)列表項(xiàng)，因此在首幀加載顯示兩條數(shù)據(jù)，其余緩存數(shù)據(jù)可以在第二幀加載。該方法的優(yōu)點(diǎn)是減少動(dòng)畫(huà)首幀的響應(yīng)時(shí)間，缺點(diǎn)是轉(zhuǎn)場(chǎng)動(dòng)畫(huà)完成時(shí)延變長(zhǎng)。

轉(zhuǎn)場(chǎng)場(chǎng)景效果圖如下：

在分幀前會(huì)在轉(zhuǎn)場(chǎng)動(dòng)畫(huà)的首幀將層疊組件和列表可見(jiàn)區(qū)域與緩存區(qū)域的數(shù)據(jù)全部加載，而分幀后在首幀加載層疊組件和列表前兩項(xiàng)的數(shù)據(jù)，在第二幀加載緩存區(qū)域的列表數(shù)據(jù)。分幀前后示意圖如下：

（二）常規(guī)情況

在組件即將出現(xiàn)時(shí)回調(diào)aboutToAppear()接口，將數(shù)據(jù)放入productData中，并通過(guò)瀑布流加載。編譯運(yùn)行后，可以通過(guò)Trace圖看到，轉(zhuǎn)場(chǎng)動(dòng)畫(huà)的首幀耗時(shí)21ms左右，這是因?yàn)樵邳c(diǎn)擊進(jìn)入頁(yè)面時(shí)將數(shù)據(jù)全部放入瀑布流，在235970幀中需要計(jì)算每個(gè)子組件的尺寸，導(dǎo)致了響應(yīng)時(shí)間增長(zhǎng)。

（三）優(yōu)化方案

在aboutToAppear()接口中添加displaySync的幀回調(diào)，并將數(shù)據(jù)拆分進(jìn)行加載。此時(shí)，aboutToAppear()接口中并沒(méi)有一次性加載全部數(shù)據(jù)，而是將數(shù)據(jù)拆分，在幀回調(diào)中分成2次進(jìn)行加載，編譯運(yùn)行后，通過(guò)Trace圖可以看到，動(dòng)畫(huà)首幀的耗時(shí)是12ms。相較于優(yōu)化前的代碼，不再是首幀占據(jù)大量的時(shí)間，而是將耗時(shí)分?jǐn)偟搅撕竺娴膭?dòng)畫(huà)幀中。當(dāng)數(shù)據(jù)量更大時(shí)，可以將數(shù)據(jù)進(jìn)行更多次拆分，將不會(huì)直接出現(xiàn)在屏幕上的數(shù)據(jù)放到第二幀或者第三幀中進(jìn)行加載，降低首幀的響應(yīng)時(shí)延。

對(duì)使用分幀前后進(jìn)行分析，得到的數(shù)據(jù)如下表所示：

在使用分幀后動(dòng)畫(huà)首幀與第二幀分別是12ms和13ms，如果依然沒(méi)有達(dá)到期望的幀率，可以繼續(xù)將數(shù)據(jù)拆分。

滑動(dòng)場(chǎng)景

在日歷應(yīng)用中，需要在一個(gè)List里面加載每個(gè)月的全部天數(shù)，包括公歷和農(nóng)歷日期，這樣在一個(gè)ItemView復(fù)用組件中就會(huì)有很多數(shù)據(jù)加載，當(dāng)列表滑動(dòng)的時(shí)候，通過(guò)組件復(fù)用的aboutToReuse()接口設(shè)置新的數(shù)據(jù)，就會(huì)導(dǎo)致ItemView內(nèi)所有組件一起刷新，可能會(huì)引起掉幀卡頓現(xiàn)象。

（一）解決思路

由于一次性加載大量數(shù)據(jù)、刷新大量組件會(huì)導(dǎo)致卡頓丟幀，那么減少一次性加載的數(shù)據(jù)量就是一種解決方法。但是由于業(yè)務(wù)需求，需要加載的數(shù)據(jù)總量和繪制的組件數(shù)量是不能減少的，那么就可以考慮采用分幀渲染。

滑動(dòng)場(chǎng)景分幀：滑動(dòng)日歷列表，復(fù)用ItemView組件，更新每月天數(shù)包含陰歷和陽(yáng)歷，一次更新所有天數(shù)，數(shù)據(jù)量大，可以使用分幀策略，將每月日期數(shù)據(jù)進(jìn)行拆分，一幀只更新5天數(shù)據(jù)，在使用ForEach循環(huán)每月的天數(shù)時(shí)，因?yàn)橐淮沃桓?天數(shù)據(jù)，F(xiàn)orEach會(huì)根據(jù)key值更新對(duì)應(yīng)的天數(shù)，從而避免在一幀中更新所有數(shù)據(jù)。該方法優(yōu)點(diǎn)是可以將數(shù)據(jù)拆分在多幀中加載，缺點(diǎn)是操作比較麻煩，需要開(kāi)發(fā)者根據(jù)實(shí)際情況計(jì)算一幀中加載的數(shù)據(jù)量，維護(hù)較為復(fù)雜。

滑動(dòng)場(chǎng)景效果圖如下：

分幀前后示意圖如下：

（二）?常規(guī)情況

通常情況下，會(huì)在aboutToReuse()中設(shè)置新的數(shù)據(jù)，并一次性繪制所有的組件。通過(guò)組件復(fù)用，在ItemView的aboutToReuse()接口中，將一個(gè)月的數(shù)據(jù)直接設(shè)置到狀態(tài)變量monthItem中，這樣下面的Flex就會(huì)收到狀態(tài)變量變更的消息通知，從而刷新組件中的數(shù)據(jù)。編譯運(yùn)行后，進(jìn)入日歷頁(yè)面，然后滑動(dòng)列表到最底端，分析下圖。

選中Actual Timeline（render_service）標(biāo)簽中的146272后，可以通過(guò)箭頭看到它所關(guān)聯(lián)到的位置是Actual Timeline（example.display）標(biāo)簽中的209136和209137，即RenderService層出現(xiàn)的異常情況是由應(yīng)用層中前面兩幀里面的操作引起的。

通過(guò)箭頭2的標(biāo)簽可以看到，在209135中調(diào)用了aboutToReuse接口，此時(shí)系統(tǒng)開(kāi)始了組件復(fù)用的繪制操作，在aboutToReuse接口將一個(gè)月的所有數(shù)據(jù)全部放入了當(dāng)前被復(fù)用的組件中，并更新了所有用于顯示日期的Text組件中的數(shù)據(jù)（箭頭3，diffIndexArray.lenght：35，表示有35個(gè)不同的元素），這就導(dǎo)致209136需要計(jì)算35個(gè)子組件的尺寸（箭頭1），從而引起146272的繪制時(shí)間延長(zhǎng)。

在列表數(shù)據(jù)量較少時(shí)，其實(shí)并不會(huì)引起掉幀現(xiàn)象，因?yàn)槊看窝娱L(zhǎng)幀的時(shí)間都很短，對(duì)幀率的影響較小，但是在列表數(shù)據(jù)較多時(shí)，就會(huì)因?yàn)檠娱L(zhǎng)幀過(guò)多，發(fā)生掉幀現(xiàn)象。

（三）優(yōu)化方案

通過(guò)displaySync中的幀回調(diào)方法，將數(shù)據(jù)拆分到每一幀中進(jìn)行加載和繪制，只需要在幀回調(diào)中修改自定義子組件ItemView中加載數(shù)據(jù)的方式。

首先，需要在ItemView中第一次使用時(shí)創(chuàng)建displaySync對(duì)象，設(shè)置期望幀率，添加幀回調(diào)的監(jiān)聽(tīng)，然后進(jìn)行啟動(dòng)。

然后，在監(jiān)聽(tīng)中添加更新數(shù)據(jù)的代碼。這里將每個(gè)月的數(shù)據(jù)更新拆分開(kāi)來(lái)，第一步用來(lái)更新月份數(shù)據(jù)和計(jì)算總的執(zhí)行步驟，最后一步將計(jì)數(shù)數(shù)據(jù)清空， 方便下一次數(shù)據(jù)的寫(xiě)入，其余需要執(zhí)行步驟的多少根據(jù)每次加載數(shù)據(jù)量會(huì)有所改變。

最后，在aboutToReuse接口中將數(shù)據(jù)放入數(shù)組中，用于幀回調(diào)中開(kāi)始執(zhí)行數(shù)據(jù)更新。

分析下面trace圖，在211618中，開(kāi)始調(diào)用aboutToReuse接口，由于只是將數(shù)據(jù)放入一個(gè)temp數(shù)組中，并沒(méi)有更新復(fù)用組件中的數(shù)據(jù)，所以這一幀并沒(méi)有發(fā)生延長(zhǎng)現(xiàn)象。

在211619中開(kāi)始逐步更新復(fù)用組件中的數(shù)據(jù)，在第一幀中更新月份和周的數(shù)據(jù)，但是由于前一幀（211618）中并沒(méi)有更新當(dāng)前復(fù)用組件中的數(shù)據(jù)，所以在211619中并不需要繪制組件，所以此幀耗時(shí)依舊很短。

結(jié)合代碼可以看到，在211620中放入了5天的日期數(shù)據(jù)，由于前一幀（211619）只是設(shè)置了2條數(shù)據(jù)，并且只有1條會(huì)更新，所以這一幀的繪制時(shí)間也不會(huì)超時(shí)。

和前一幀（211620）一樣，此幀（211621）中更新了5天的日期數(shù)據(jù)，并且會(huì)重新測(cè)量上一幀中更新數(shù)據(jù)的5個(gè)Text組件尺寸（箭頭1），而其余的組件由于數(shù)據(jù)并沒(méi)有變動(dòng)，所以測(cè)量被略過(guò)了（箭頭2）。

后面的幀是類(lèi)似的，每次只會(huì)放入5天的數(shù)據(jù)，并且更新上一幀中設(shè)置的數(shù)據(jù)所關(guān)聯(lián)的Text組件。由于每次更新的組件數(shù)量較少，每幀基本上都能在規(guī)定的時(shí)間內(nèi)（1秒120幀，即8ms一幀）繪制完成，所以延長(zhǎng)幀就會(huì)較少。這樣不論列表中數(shù)據(jù)多還是少，都不會(huì)引起掉幀現(xiàn)象的發(fā)生。

對(duì)使用分幀前后進(jìn)行分析，得到的數(shù)據(jù)如下表所示：

在使用displaySync時(shí)不建議將ExpectedFrameRateRange中的expected、min、max都設(shè)置為120，否則會(huì)干擾系統(tǒng)的可變幀率機(jī)制運(yùn)行，產(chǎn)生不必要的負(fù)載，進(jìn)而影響到整機(jī)的性能和功耗，詳情請(qǐng)參考場(chǎng)景策略建議。

總結(jié)

通過(guò)上述示例代碼和優(yōu)化過(guò)程可以看出，在列表中使用組件復(fù)用時(shí)，如果一次性加載所有數(shù)據(jù)，可能會(huì)導(dǎo)致掉幀問(wèn)題。雖然在數(shù)據(jù)量較少時(shí)，單幀繪制時(shí)間的延長(zhǎng)不會(huì)明顯影響性能，但隨著數(shù)據(jù)量增加，這種單幀耗時(shí)的增加會(huì)變得顯著，進(jìn)而引發(fā)掉幀。因此，開(kāi)發(fā)者可以根據(jù)實(shí)際業(yè)務(wù)需求，合理采用分幀策略對(duì)數(shù)據(jù)進(jìn)行拆分，將原本集中在一幀內(nèi)處理的任務(wù)分散到多幀中執(zhí)行。這種方式可以有效減少單幀的渲染壓力，降低延長(zhǎng)幀的發(fā)生概率，從而避免因掉幀導(dǎo)致的性能問(wèn)題。