概述

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

實現(xiàn)原理

（一）原理說明

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

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

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

if更新機制是根據狀態(tài)判斷條件，如果分支沒有變化，不會對條件渲染語句進行更新。

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

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

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

具體操作流程如下圖：

轉場場景

由于業(yè)務需求，從當前頁面進入一個新頁面時，會有轉場動畫播放，并且在動畫首幀中加載新頁面所需要的數(shù)據。如果數(shù)據量較多，那么動畫首幀的響應時延就會變長，導致后面動畫幀延遲播放的情況。從一個頁面到新頁面轉場流程圖如下：

（一）解決思路

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

轉場場景分幀：轉場時會在動畫首幀加載新頁面的數(shù)據，采用分幀策略就是將首幀加載的數(shù)據拆分，將數(shù)據拆分到后面的幀加載，新頁面打開后List列表只展示兩個列表項，因此在首幀加載顯示兩條數(shù)據，其余緩存數(shù)據可以在第二幀加載。該方法的優(yōu)點是減少動畫首幀的響應時間，缺點是轉場動畫完成時延變長。

轉場場景效果圖如下：

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

（二）常規(guī)情況

在組件即將出現(xiàn)時回調aboutToAppear()接口，將數(shù)據放入productData中，并通過瀑布流加載。編譯運行后，可以通過Trace圖看到，轉場動畫的首幀耗時21ms左右，這是因為在點擊進入頁面時將數(shù)據全部放入瀑布流，在235970幀中需要計算每個子組件的尺寸，導致了響應時間增長。

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

在aboutToAppear()接口中添加displaySync的幀回調，并將數(shù)據拆分進行加載。此時，aboutToAppear()接口中并沒有一次性加載全部數(shù)據，而是將數(shù)據拆分，在幀回調中分成2次進行加載，編譯運行后，通過Trace圖可以看到，動畫首幀的耗時是12ms。相較于優(yōu)化前的代碼，不再是首幀占據大量的時間，而是將耗時分攤到了后面的動畫幀中。當數(shù)據量更大時，可以將數(shù)據進行更多次拆分，將不會直接出現(xiàn)在屏幕上的數(shù)據放到第二幀或者第三幀中進行加載，降低首幀的響應時延。

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

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

滑動場景

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

（一）解決思路

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

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

滑動場景效果圖如下：

分幀前后示意圖如下：

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

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

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

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

在列表數(shù)據量較少時，其實并不會引起掉幀現(xiàn)象，因為每次延長幀的時間都很短，對幀率的影響較小，但是在列表數(shù)據較多時，就會因為延長幀過多，發(fā)生掉幀現(xiàn)象。

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

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

首先，需要在ItemView中第一次使用時創(chuàng)建displaySync對象，設置期望幀率，添加幀回調的監(jiān)聽，然后進行啟動。

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

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

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

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

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

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

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

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

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

總結

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