這是我參加創(chuàng)作者計劃的第一篇文章。

前言

長列表是前端和客戶端應(yīng)用中最常見的業(yè)務(wù)場景，比如商品瀑布流等，有成千上萬條數(shù)據(jù)，因此長列表的渲染性能在iOS，Android，Harmony，Web等各大平臺都非常重要。HarmonyOS和iOS類似也提供了自己的解決方案。Roma(羅碼)作為跨端平臺，在此基礎(chǔ)上進行了具體的實踐。在實踐過程中，遇到了各種問題和挑戰(zhàn)，經(jīng)歷了ArkTS+C++架構(gòu)向純C++架構(gòu)的轉(zhuǎn)變，本文將圍繞實踐中的各種問題和挑戰(zhàn)，探討Roma的具體解決方案和優(yōu)化思路。

一、鴻蒙長列表解決方案及原理

鴻蒙系統(tǒng)為List，WaterFlow，Grid等容器組件的數(shù)據(jù)加載和渲染提供了一次性加載方案（ForEach）和按需加載方案（LazyForEach）兩種方式。

1. 一次性加載方案（ForEach）

?ForEach：一次性加載全量數(shù)據(jù)并循環(huán)渲染。原理如下：

（圖片來自鴻蒙官網(wǎng)）

缺點：

1) 因為要一次性加載所有的列表數(shù)據(jù)，創(chuàng)建所有組件節(jié)點并完成組件樹的構(gòu)建，在數(shù)據(jù)量大時會非常耗時，從而導(dǎo)致頁面加載渲染時間過長

2) 屏幕可視區(qū)外的組件雖然不會顯示在屏幕上，但是仍然會占用內(nèi)存。在系統(tǒng)處于高負載的情況下，更容易出現(xiàn)性能問題，極限情況下甚至?xí)?dǎo)致應(yīng)用異常退出。

實際業(yè)務(wù)中數(shù)據(jù)條數(shù)非常多，該方案存在很嚴重的性能問題。為了解決這個性能問題，HarmonyOS提供了性能更好的解決方案

2. 按需加載方案（LazyForEach）

?LazyForEach： 實現(xiàn)延遲加載數(shù)據(jù)并按需渲染。原理如下：

1) 根據(jù)屏幕可視區(qū)能夠容納顯示的組件數(shù)量按需加載數(shù)據(jù)。

2) 根據(jù)加載的數(shù)據(jù)量創(chuàng)建組件，掛載在組件樹上，屏幕可以展示多少列表項組件，就按需創(chuàng)建多少個ListItem組件節(jié)點掛載在List組件樹根節(jié)點上。

3) 當(dāng)組件滑出可視區(qū)域外時，框架會進行組件銷毀以降低內(nèi)存占用；當(dāng)組件滑入可視區(qū)域時，需要從頭完成數(shù)據(jù)加載、組件創(chuàng)建、掛載組件樹這一過程，直至渲染到屏幕上。

（圖片來自鴻蒙官網(wǎng)）

LazyForEach實現(xiàn)了按需加載，針對列表數(shù)據(jù)量大、列表組件復(fù)雜的場景，減少了頁面首次啟動時一次性加載數(shù)據(jù)的時間消耗，減少了內(nèi)存峰值。可以顯著提升頁面的能效比和用戶體驗。提升性能，HarmonyOS又給出了兩種優(yōu)化手段：緩存列表項（CacheCount）+組件復(fù)用（@Reusable）。

2.1 緩存列表項CacheCount

如果只有懶加載，滑動速度過快時，則會導(dǎo)致數(shù)據(jù)來不及加載而出現(xiàn)“白塊現(xiàn)象”。為了解決這一問題，LazyForEach懶加載可以通過設(shè)置cachedCount屬性來指定緩存數(shù)量。在設(shè)置cachedCount后，除屏幕內(nèi)顯示的ListItem組件外，還會預(yù)先將屏幕可視區(qū)外指定數(shù)量的列表項數(shù)據(jù)緩存起來。這樣當(dāng)緩存列表項需要從屏幕可視區(qū)外進入可視區(qū)內(nèi)時，只用創(chuàng)建、渲染組件即可，相比不設(shè)置cachedCount提升了顯示效率。（cacheCount具體設(shè)置多少，這里依然不詳細展開，詳見后續(xù)文章。）

原理如下：

（圖片來自鴻蒙官網(wǎng)）

2.2 組件復(fù)用@Reusable

由上文可知LazyForEach+cacheCount方案中，當(dāng)組件滑出可視區(qū)域外時，框架會進行組件銷毀以降低內(nèi)存占用；當(dāng)組件滑入可視區(qū)域時，需要從頭完成組件創(chuàng)建、掛載組件樹這一過程，直至渲染到屏幕上。而且列表頁面很多列表項的UI樣式完全相同，只有數(shù)據(jù)上的差異，如果能組件復(fù)用，就能節(jié)省組件創(chuàng)建的時間，因此就可以進一步提高列表頁面的加載速度和響應(yīng)速度。

框架為我們提供了組件復(fù)用的能力，機制如下：

1）標(biāo)記為@Reusable的組件從組件樹上被移除時，組件和其對應(yīng)的JSView對象都會被放入復(fù)用緩存中，復(fù)用緩存可以通過reuseId標(biāo)記為不同的緩存池。

2）當(dāng)列表滑動新的ListItem將要被顯示，List組件樹上需要新建節(jié)點時，將會從相應(yīng)的復(fù)用緩存池中查找可復(fù)用的組件節(jié)點。

3）找到可復(fù)用節(jié)點并對其進行更新后添加到組件樹中。從而節(jié)省了組件節(jié)點和JSView對象的創(chuàng)建時間。

（圖片來自鴻蒙官網(wǎng)）

二、動態(tài)化的長列表解決方案

結(jié)合上文HarmonyOS提供的解決方案，開始考慮動態(tài)化的長列表方案。通過前面鴻蒙跨端方案介紹文章，我們知道，跨平臺框架的核心原理是通過JavaScript在JS引擎上執(zhí)行時，對虛擬DOM進行操作，通過橋接或JSI與原生端進行通信，同時通過組件抽象，這些組件在不同平臺上映射到相應(yīng)的原生組件。運行時我們會有相應(yīng)的節(jié)點樹：JS虛擬DOM節(jié)點樹->原生端組件節(jié)點樹->原生端渲染節(jié)點樹。長列表的渲染同樣會涉及這三棵樹，并且過程比較復(fù)雜。

1. 移植iOS、Android方案到鴻蒙

1.1 其他兩端的方案原理

?緩存池大小設(shè)置為最大N頁，每個方向N/2頁（這里的N和摩擦系數(shù)等因素有關(guān)，這里暫時不詳細展開，后面有機會專門寫文章分享）

?當(dāng)組件滑出緩存區(qū)域外時，操作虛擬DOM樹刪除列表項節(jié)點，同時通過bridge在原生端進行相應(yīng)列表項組件的銷毀以降低內(nèi)存占用；當(dāng)組件滑入緩存區(qū)域時，操作虛擬DOM樹添加列表項節(jié)點，同時通過bridge在原生端進行相應(yīng)列表項組件的添加，這里從虛擬DOM節(jié)點到原生端的組件，都需要從頭完成組件創(chuàng)建、掛載組件樹這一過程，直至渲染到屏幕上。

?原生端列表的reuseId是一個不會重復(fù)的唯一值

該方案已經(jīng)被京東金融業(yè)務(wù)100+頁面使用，在復(fù)雜的列表頁面性能表現(xiàn)也非常好。優(yōu)點也是顯而易見，由于跨端的核心原理決定了我們必須操作VDOM節(jié)點樹和組件樹，過程中涉及JS線程和UI線程的頻繁通信，最終行為是否一致，是否能達到我們想要的結(jié)果，這個過程涉及的細節(jié)非常多，因此一個簡單的邏輯是保證正確性的比較好的手段。這當(dāng)然也得益于iOS和Android系統(tǒng)本身性能的優(yōu)越。從上文可知我們其實無論在VDOM節(jié)點樹中，還是原生端組件樹中，新的VDOM節(jié)點/列表項組件創(chuàng)建或刪除的時候，都沒有復(fù)用節(jié)點或者利用系統(tǒng)本身的組件復(fù)用的能力，只有新創(chuàng)建和真刪除，這種邏輯就非常簡單明了，不容易產(chǎn)生bug。但是從頭創(chuàng)建的過程會依賴系統(tǒng)本身的性能。

1.2 移植后存在的問題

然而，當(dāng)我們把同樣的方案移植到HarmonyOS上之后，使用ArkUI框架開發(fā)，發(fā)現(xiàn)肉眼可見的卡頓，抖動等掉幀現(xiàn)象非常嚴重，因此我們開始排查原因。并與iOS和Android系統(tǒng)進行對比分析，經(jīng)過分析我們發(fā)現(xiàn)主要存在以下3個問題：

?UI層級過多。在ArkUI框架實現(xiàn)下，自定義組件本身必須增加一個包裹的容器，比如一個類似RomaDiv這樣的業(yè)務(wù)里最常使用的，數(shù)量最多的自定義容器組件，里面必須有個類似Stack/Flex這樣的容器組件才合法，因此這個組件本身就已經(jīng)是兩層了，比其他系統(tǒng)就多了一層。另外有些容器組件還有系統(tǒng)本身生成的類似__common__ 這種層級，也會導(dǎo)致層級變多。層級過多，每次創(chuàng)建，渲染過程中的計算就更多，耗時自然就更長。

?跨語言通信鏈路長。原生組件的UI是基于ArkUI實現(xiàn)的，運行在方舟虛擬機中。JS代碼運行在系統(tǒng)的JSVM中，在C++端，兩種語言通過系統(tǒng)提供的NAPI通信，其中涉及各種數(shù)據(jù)類型轉(zhuǎn)換，成本自然比其他系統(tǒng)要高。尤其在UI層級多的情況下，成本就更高了。

?系統(tǒng)二次布局的問題。動態(tài)化系統(tǒng)架構(gòu)中有三個核心線程：UI主線程，JS線程和布局計算的線程。布局方案采用的是yoga布局，可以高效地進行組件的大小，位置的計算。但是系統(tǒng)在此布局之后還會重新進行布局一次，這個開銷就完全沒有必要，但是卻增加了耗時，影響了性能。

針對這幾個問題，經(jīng)過和華為專家溝通以后，建議我們直接使用C-API開發(fā)，但是經(jīng)過深入開發(fā)和溝通之后，發(fā)現(xiàn)C-API目前尚有功能欠缺，而且文檔不完善，不能滿足我們當(dāng)下的所有需求，因此我們決定支持ArkTS版本和C-API版本兩個版本，Q3先上線ArkTS版本，同時開發(fā)完CAPI版本，待華為進一步完善C-API后，Q4上線。

2. ArkTS版本解決方案

在已經(jīng)存在以上問題的前提下，我們需要盡可能的提高列表性能，創(chuàng)建慢的問題，首先考慮到的就是reuse的思路。

2.1 ArkTS方案原理

?原生端UI完全依賴系統(tǒng)提供的懶加載LazyForEach+緩存列表項CacheCount+組件復(fù)用@Reusable，其中復(fù)用的reuseId設(shè)置為具體緩存池的類別。

?虛擬DOM節(jié)點的創(chuàng)建，復(fù)用，回收和銷毀的時機完全與原生端UI相對應(yīng)的時機同步。由于ArkUI是聲明式語法，因此整個過程是先由原生端觸發(fā)UI占位，然后在對應(yīng)的生命周期上相應(yīng)的操作VDOM，再通過JSI&NAPI與原生端通信，更新原生端組件。

這個方案是真正做到了reuse/recycle的長列表，做到了比較絲滑的體驗。但是由于有了recycle/reuse的過程，也增加了更多的復(fù)雜性，有很多細節(jié)需要處理。

2.2 重點優(yōu)化點

1）更新數(shù)據(jù)后UI“閃”的問題 - 不要改變鍵值key + @ObjectLink + @Observed

這個問題的根本原因是lazyForEach的迭代器key generator的鍵值key發(fā)生了變化。如果鍵值key發(fā)生了變化，框架會將這個變化的組件整體先回收，然后再重新創(chuàng)建。經(jīng)歷這一個過程就會出現(xiàn)“閃”的問題。

而且，改變鍵值key去刷新UI的方式代價很大，同一類別的列表項的結(jié)構(gòu)非常類似，只是顯示的文本和圖片等不一樣，不變化的組件不需要重新創(chuàng)建，只需要更新變化的部分即可。這種情況框架提供了裝飾器@Observed和@ObjectLink，可以監(jiān)聽變化的部進行局部更新。同時，復(fù)雜列表情況下，數(shù)據(jù)源大多都是多層嵌套的對象結(jié)構(gòu)，建議使用@ObjectLink而不要用@Prop，因為@Prop會進行深拷貝，會增加創(chuàng)建時間及內(nèi)存的消耗，開銷較大，而@ObjectLink指向數(shù)據(jù)源的指針，雙向同步數(shù)據(jù)，因此這種情況下性能更優(yōu)。

2）刷新/更新數(shù)據(jù)后，數(shù)據(jù)先展示其他的數(shù)據(jù)然后快速再刷成最終結(jié)果

?不要更新（可見+cacheCount）范圍內(nèi)的組件的鍵值key，此范圍外的部分改變鍵值key

?手動調(diào)用列表組件的方法只更新（可見+cacheCount）范圍內(nèi)的組件和對應(yīng)的VDOM節(jié)點

首先產(chǎn)生這個問題的原因還是由于key發(fā)生了變化，每次重新創(chuàng)建的時候，如果當(dāng)前類型的緩存池有數(shù)據(jù)，就從緩存池取出復(fù)用，然后再更新變化的部分。這個從緩存池取出的組件仍然帶有原來的數(shù)據(jù)信息，因此我們會看到先展示其他數(shù)據(jù)然后再被刷成最終結(jié)果。為了避免這個現(xiàn)象，首先還是不要改變key。在UI上就是已經(jīng)渲染了的那些組件，也即可視加上cacheCount范圍內(nèi)的組件。同時對此范圍內(nèi)的組件手動調(diào)用組件的更新方法，更新組件，這時JS引擎會對這個節(jié)點進行diff，把變化的部分通過JSI與原生端通信，原生端完成最終UI的更新。范圍外的部分就按需更新key和數(shù)據(jù)源。

3）有些列表滑動過程中仍有卡頓現(xiàn)象

?沒有正確使用組件復(fù)用 - 使用了組件復(fù)用，實際上是無效的復(fù)用，reuseId設(shè)置一定要正確，且必須為字符串類型

標(biāo)準(zhǔn)型

有限變化型

組合型

全局型

嵌套型

此外，如果使用if/else條件語句來控制布局的結(jié)構(gòu)，會導(dǎo)致在不同邏輯創(chuàng)建不同布局結(jié)構(gòu)嵌套的組件，此時我們應(yīng)該使用reuseId將if/else條件語句拆分為不同結(jié)構(gòu)的組件

?優(yōu)先使用@Builder替代自定義組件@Component，減少嵌套層級

ArkUI中使用自定義組件時，在build階段將在在后端FrameNode樹創(chuàng)建一個相應(yīng)的CustomNode節(jié)點，在渲染階段時也會創(chuàng)建對應(yīng)的RenderNode節(jié)點。會造成組件復(fù)用下，CustomNode創(chuàng)建和和RenderNod渲染的耗時，因此應(yīng)該優(yōu)先使用@Builder。同時減少一個自定義組件，也就是減少一次aboutToReuse的回調(diào)，也會節(jié)省耗時。

?避免不必要的狀態(tài)變量刷新，使用AttributeUpdater更新組件屬性

?避免對@Link/@ObjectLink/@Prop等自動更新的狀態(tài)變量，在aboutToReuse方法中再進行更新

?避免使用函數(shù)/方法作為復(fù)用組件創(chuàng)建時的入?yún)?/p>

?避免在列表滑動過程中做大量計算或者耗時長的操作

?可以結(jié)合列表預(yù)加載，布局優(yōu)化等其他常規(guī)手段進一步優(yōu)化體驗

3. C-API版本解決方案

上文中我們已經(jīng)提到CAPI的方案能解決UI層級過多，跨語言通信鏈路長兩個核心問題，同時也減少了狀態(tài)變量維護相應(yīng)的耗時，是我們最終的解決方案。C++端我們還是采用了recycle/reuse的方案，C-API實現(xiàn)上我們需要自己實現(xiàn)類似lazyForEach的能力。

3.1 C-API方案原理

?系統(tǒng)提供了一個ArkUI_NodeAdapter對象來管理容器的子組件，這個對象類似事件的機制，通過相關(guān)事件通知按需生成組件。

（圖片來自鴻蒙官網(wǎng)）

?在監(jiān)聽事件的回調(diào)中處理創(chuàng)建，回收，復(fù)用，刪除等邏輯。

3.2 部分核心代碼

有興趣的同學(xué)可以私下聯(lián)系我。

4. 性能對比分析

使用JR APP購物車頁面（頁面結(jié)構(gòu)較復(fù)雜），400條數(shù)據(jù)，分別用三種方案以及優(yōu)化后測試，測試結(jié)果如下：

測試結(jié)果表明，lazyForEach，組件復(fù)用，cacheCount，預(yù)加載等等這些方法的確提高了性能，尤其是滑動過程中出現(xiàn)的明顯卡頓現(xiàn)象，同時減少UI層級，不跨語言通信能進一步提高性能，帶來更好的體驗。

三、總結(jié)

本文通過圖文的方式介紹了HarmonyOS的長列表ArkTS解決方案以及原理，同時結(jié)合實際的實現(xiàn)過程介紹了ROMA動態(tài)化長列表的ArkTS和C++解決方案，相應(yīng)的重點優(yōu)化細節(jié)以及部分核心源碼，最后對兩者進行了性能對比分析。

如果大家覺得有幫助，千萬別忘了點贊+收藏，方便以后隨時閱讀！

動態(tài)化是一個涉及JavaScript、C++、iOS、Android、Java、Harmony、Vue、Node、Webpack、Shell等眾多領(lǐng)域的綜合解決方案，我們有各個領(lǐng)域優(yōu)秀的小伙伴共同前行，大家如果想深入了解某個領(lǐng)域的具體實現(xiàn)或者提出寶貴意見，可以在評論中給我留言，隨時交流~！

審核編輯 黃宇