概述

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

實現原理

（一）原理說明

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

（二）具體實現

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

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

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

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

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

具體操作流程如下圖：

轉場場景

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

（一）解決思路

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

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

轉場場景效果圖如下：

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

（二）常規情況

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

（三）優化方案

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

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

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

滑動場景

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

（一）解決思路

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

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

滑動場景效果圖如下：

分幀前后示意圖如下：

（二）?常規情況

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

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

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

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

（三）優化方案

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

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

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

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

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

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

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

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

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

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

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

總結

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