1. 為什么要在OpenHarmony上重新造List這個輪子先說結(jié)論React Native在OpenHarmony上跑通Hello World只是第一步真正決定能不能上生產(chǎn)的是列表頁。FlatList在Android和iOS上表現(xiàn)穩(wěn)定但換到OpenHarmony環(huán)境后問題不是“性能差一點(diǎn)”這么簡單而是底層渲染鏈路完全不同直接照搬會踩出一連串的兼容性坑。我當(dāng)時接手這個項(xiàng)目時團(tuán)隊(duì)的目標(biāo)很明確現(xiàn)有RN代碼庫要盡量復(fù)用但OpenHarmony端的體驗(yàn)不能打折。嘗試直接跑原生FlatList后首屏白屏?xí)r間從Android的1.2秒飆到接近4秒滑動時還能明顯感覺到cell的創(chuàng)建和回收節(jié)奏不對幀率掉到40左右。這就在告訴我們一個道理OpenHarmony的列表必須針對鴻蒙的ArkUI渲染機(jī)制單獨(dú)做封裝不能再指望RN自帶的VirtualizedList去適配一切。為什么必須封一層而不是直接用ArkUI的List組件因?yàn)闃I(yè)務(wù)層寫的是React組件拿到的數(shù)據(jù)是JS側(cè)的數(shù)組直接讓ArkUI去渲染原始JS對象是不現(xiàn)實(shí)的。我們需要做一套橋接層把RN側(cè)的列表數(shù)據(jù)模型映射到OpenHarmony的List能力上同時把下拉刷新、上拉加載、分頁占位這些業(yè)務(wù)邏輯沉淀成通用組件。這篇文章我會把整套封裝方案拆開來講包括橋接層的設(shè)計思路、JS側(cè)組件的API設(shè)計、ArkUI原生側(cè)的渲染實(shí)現(xiàn)、以及我在實(shí)際聯(lián)調(diào)中遇到的性能問題和修復(fù)手段。無論你是準(zhǔn)備把現(xiàn)有RN應(yīng)用遷到OpenHarmony還是純粹想了解這套跨端方案的技術(shù)細(xì)節(jié)這篇文章應(yīng)該都能給你一些參考。在動手之前先看一張整體的技術(shù)路線圖層級技術(shù)棧職責(zé)JS業(yè)務(wù)層React組件ListContainer數(shù)據(jù)請求、狀態(tài)管理、下拉刷新/上拉加載邏輯橋接層TurboModule C-APIJS與ArkUI的數(shù)據(jù)交換、事件回調(diào)原生渲染層ArkUI List / WaterFlow實(shí)際列表渲染、cell復(fù)用、滾動調(diào)度平臺適配層OpenHarmony SDK RN SDK生命周期管理、設(shè)備能力適配、異常兜底這個分層是我反復(fù)調(diào)整后的最終形態(tài)。最開始我不打算碰ArkUI原生層想純靠RN的View嵌套去模擬列表結(jié)果500條數(shù)據(jù)就把JS線程卡死了。后來換成了原生List RN組件動態(tài)掛載的方案才算把性能拉回正常范圍。后面會詳細(xì)說為什么這條路走得通。1.1 核心痛點(diǎn)RN的VirtualizedList為什么在OpenHarmony上會“水土不服”RN的FlatList本質(zhì)上是VirtualizedList的封裝核心思路是只渲染視口附近的cell滾動時動態(tài)回收和創(chuàng)建。這套機(jī)制在Android和iOS上依賴的是各自平臺的ScrollView原生實(shí)現(xiàn)每個cell對應(yīng)一個原生View。問題在于OpenHarmony上的RN SDK還沒有把VirtualizedList的底層能力完全對接。我實(shí)測下來列表滾動時cell的onLayout回調(diào)頻繁觸發(fā)但ArkUI側(cè)的回收節(jié)奏和RN側(cè)的計算邏輯對不上導(dǎo)致兩種結(jié)果一種是JS側(cè)以為cell還在可視區(qū)但原生側(cè)已經(jīng)回收了畫面出現(xiàn)空白另一種是原生側(cè)保留了大量JS創(chuàng)建的View內(nèi)存持續(xù)增長最終應(yīng)用被殺。還有一個更隱蔽的問題OpenHarmony的ArkUI框架對組件樹的深度和節(jié)點(diǎn)數(shù)有自己的優(yōu)化策略RN的View在ArkUI上映射時一屏幾十個節(jié)點(diǎn)還好但列表滾起來后節(jié)點(diǎn)頻繁創(chuàng)建銷毀ArkUI的diff算法反而成了瓶頸。這個不做針對性優(yōu)化體驗(yàn)基本沒法接受。所以我才決定徹底接管列表渲染RN側(cè)只負(fù)責(zé)提供數(shù)據(jù)和業(yè)務(wù)視圖渲染交給ArkUI原生的List組件cell的創(chuàng)建和復(fù)用完全在ArkUI側(cè)完成繞過VirtualizedList那套JS層面的計算。這是一個“讓專業(yè)的人做專業(yè)的事”的思路。2. 橋接層設(shè)計讓JS數(shù)據(jù)和ArkUI原生List互相理解橋接層是整個方案的骨架。它要解決兩件核心的事一是把RN側(cè)傳入的列表數(shù)據(jù)可靠地轉(zhuǎn)成ArkUI能消費(fèi)的數(shù)據(jù)結(jié)構(gòu)二是把ArkUI側(cè)的滾動事件、cell點(diǎn)擊事件、生命周期事件準(zhǔn)確地回傳給JS側(cè)。OpenHarmony的RN SDK目前有兩種橋接方式舊版的C-API直接橋接和新版的TurboModule。我建議直接用TurboModule雖然初期配置麻煩一點(diǎn)但后續(xù)的數(shù)據(jù)傳輸效率和類型安全要好很多。舊版的callback回調(diào)在頻繁觸發(fā)時會抖動而TurboModule支持Promise和同步調(diào)用對列表這種高頻事件場景更友好。2.1 數(shù)據(jù)模型定義與類型映射先看數(shù)據(jù)從JS到ArkUI的流轉(zhuǎn)過程。JS側(cè)業(yè)務(wù)層拿到的原始數(shù)據(jù)通常是后端返回的JSON數(shù)組每一項(xiàng)可能是用戶信息、商品信息、動態(tài)內(nèi)容等任意結(jié)構(gòu)。我們不能要求業(yè)務(wù)層把數(shù)據(jù)分割好再傳那樣就失去了封裝的意義。我的方案是JS側(cè)把整個數(shù)組一次性傳給原生側(cè)原生側(cè)按索引訪問。為此我在JS側(cè)定義了一個統(tǒng)一的ListData類型// ListData.ts export interface ListDataT { data: T[]; total: number; page: number; pageSize: number; hasMore: boolean; refreshTime: number; }這里面的total和hasMore是用來控制上拉加載狀態(tài)的。原生側(cè)不關(guān)心業(yè)務(wù)字段它只需要知道數(shù)組長度、當(dāng)前頁碼和是否還有更多來決定什么時候觸發(fā)加載更多事件。TurboModule的接口定義我放在一個叫NativeListModule的模塊里關(guān)鍵方法如下// NativeListModule.ts import { TurboModule, TurboModuleRegistry } from react-native; export interface Spec extends TurboModule { // 初始化列表傳入數(shù)據(jù)數(shù)組和列表配置 initList(tag: number, data: ArrayObject, config: Object): Promiseboolean; // 追加數(shù)據(jù)上拉加載更多時調(diào)用 appendData(tag: number, data: ArrayObject): Promiseboolean; // 更新某一條數(shù)據(jù)局部刷新 updateItem(tag: number, index: number, data: Object): Promiseboolean; // 滾動到指定位置 scrollToIndex(tag: number, index: number, animated: boolean): void; // 觸發(fā)列表刷新完成告訴原生側(cè)下拉刷新的數(shù)據(jù)已就緒 finishRefresh(tag: number): void; // 觸發(fā)加載更多完成 finishLoadMore(tag: number): void; } export default TurboModuleRegistry.getSpec(NativeListModule);這里我用tag來區(qū)分不同的列表實(shí)例。一個頁面可能有多個列表比如首頁的推薦流和個人中心的訂單列表同時存在每個列表實(shí)例有自己的數(shù)據(jù)和狀態(tài)原生側(cè)通過tag查找對應(yīng)的ArkUI組件實(shí)例。2.2 ArkUI側(cè)的橋接實(shí)現(xiàn)細(xì)節(jié)ArkUI側(cè)接收J(rèn)S數(shù)據(jù)后不能直接用對象去驅(qū)動UI渲染。ArkUI是聲明式UI框架如果直接拿JS對象當(dāng)狀態(tài)用ArkUI的狀態(tài)管理V1/V2版本會有差異V1需要State裝飾器來包裝V2用ObservedV2/Trace會更靈活一些。但不管哪種直接塞一個巨大的數(shù)組都會觸發(fā)全量diff性能堪憂。我的做法是在ArkUI側(cè)維護(hù)一個輕量的數(shù)據(jù)管理器把JS傳過來的數(shù)組做一個索引化處理渲染時只是按需取數(shù)據(jù)。代碼層面我定義了一個ListDataSource類// ListDataSource.ets export class ListDataSource { private dataMap: Mapnumber, Object new Map(); private count: number 0; public setData(data: Object[]) { this.dataMap.clear(); this.count data.length; data.forEach((item, index) { this.dataMap.set(index, item); }); } public getItem(index: number): Object | undefined { return this.dataMap.get(index); } public getCount(): number { return this.count; } public appendItems(data: Object[]) { data.forEach((item, index) { this.dataMap.set(this.count index, item); }); this.count data.length; } public updateItem(index: number, data: Object) { this.dataMap.set(index, data); } }這樣做的核心目的是讓ArkUI的List組件在滾動時能按索引快速拿到數(shù)據(jù)而不需要遍歷整個數(shù)組。ArkUI的LazyForEach要求數(shù)據(jù)源實(shí)現(xiàn)IDataSource接口它內(nèi)部會維護(hù)一個key到index的映射滾動時按需調(diào)用getData方法。我們的ListDataSource把它包裝一下就能直接對接LazyForEach。有一個細(xì)節(jié)需要特別注意LazyForEach的id生成規(guī)則必須穩(wěn)定。我遇到過滾動時cell內(nèi)容錯亂的問題排查到最后是id生成規(guī)則用了index一旦數(shù)據(jù)新增或刪除index變化就會導(dǎo)致LazyForEach復(fù)用錯亂。正確的做法是根據(jù)業(yè)務(wù)數(shù)據(jù)的唯一標(biāo)識來生成key如果業(yè)務(wù)數(shù)據(jù)沒有唯一ID可以在JS側(cè)先做一次數(shù)據(jù)清洗給每條數(shù)據(jù)加一個clientId字段。3. 組件API設(shè)計既要有原生List的性能又要保留RN的開發(fā)者體驗(yàn)光有橋接層還不夠業(yè)務(wù)側(cè)拿到的應(yīng)該是一個開箱即用的React組件而不是一堆需要手動調(diào)用的原生方法。所以我在RN側(cè)封裝了一個ListContainer組件API設(shè)計盡量對齊FlatList的常用屬性讓業(yè)務(wù)方遷移成本盡量低。3.1 組件Props的取舍對齊FlatList還是另起爐灶先看ListContainer的props設(shè)計// ListContainer.tsx export interface ListContainerPropsT { // 數(shù)據(jù)源 data: T[]; // 渲染單個item的函數(shù) renderItem: (item: T, index: number) React.ReactElement; // 下拉刷新配置 onRefresh?: () Promisevoid; refreshing?: boolean; // 上拉加載更多配置 onLoadMore?: () void; hasMore?: boolean; loadingMore?: boolean; // 列表配置 keyExtractor?: (item: T, index: number) string; initialNumToRender?: number; // 空態(tài)和錯誤態(tài) ListEmptyComponent?: React.ComponentType | React.ReactElement; ListFooterComponent?: React.ComponentType | React.ReactElement; // 滾動事件 onEndReached?: () void; onEndReachedThreshold?: number; // 間距配置 ItemSeparatorComponent?: React.ComponentType | React.ReactElement; contentContainerStyle?: StylePropViewStyle; }對比FlatList我保留了下拉刷新、上拉加載、renderItem這些核心能力但砍掉了幾個在OpenHarmony上暫時沒有合理映射的屬性比如horizontal橫向列表、numColumns多列布局和getItemLayout固定高度優(yōu)化。橫向列表和多列布局在ArkUI里分別是List的水平和網(wǎng)格模式底層邏輯完全不同強(qiáng)行用一個組件兼容會把架構(gòu)搞得很擰巴。我的建議是ListContainer先專注垂直單列列表橫向和瀑布流后續(xù)單獨(dú)封裝成獨(dú)立組件不污染主組件。3.2 renderItem的跨端渲染機(jī)制renderItem是RN組件里最關(guān)鍵的部分。它的返回值是一個React元素最終需要轉(zhuǎn)成ArkUI的UI組件來渲染。這里有兩種實(shí)現(xiàn)路線路線一通過View嵌套。renderItem返回的React組件最終渲染成RN的View再通過橋接層掛到ArkUI的cell里。優(yōu)點(diǎn)是業(yè)務(wù)組件不用改缺點(diǎn)是每個cell都要創(chuàng)建一個RN原生Viewcell復(fù)用效率低而且RN和ArkUI之間多了一層消息傳遞。路線二ArkUI側(cè)用自定義組件容器。cell的根節(jié)點(diǎn)是ArkUI的組件renderItem返回的React元素通過特殊的方式“注入”到這個容器里。這樣cell的創(chuàng)建和銷毀完全由ArkUI控制RN側(cè)只負(fù)責(zé)生成業(yè)務(wù)內(nèi)容。我最終選的是第二條路但做了一個折中設(shè)計cell的骨架背景、間距、分割線全部用ArkUI原生組件繪制只有真正的業(yè)務(wù)內(nèi)容區(qū)域使用RN的View。這樣視覺上的一致性更好而且大部分列表項(xiàng)的背景和間距是重復(fù)的用原生組件繪制可以顯著減少RN側(cè)的節(jié)點(diǎn)數(shù)。具體的實(shí)現(xiàn)方案是在ArkUI側(cè)定義一個ListItemWrapper組件它接收一個RN組件的tag在aboutToAppear時向RN側(cè)發(fā)起創(chuàng)建子視圖的請求然后把這個子視圖掛載到自己內(nèi)部。這個過程在ArkUI里叫NodeContainer有很多細(xì)節(jié)要處理比如生命周期對齊、觸摸事件透傳后面會專門講。3.3 常用的附加能力下拉刷新、上拉加載、空態(tài)和錯誤態(tài)這四項(xiàng)能力是列表組件的標(biāo)配但它們各自的實(shí)現(xiàn)方案在OpenHarmony上有不同的坑拆開來說。下拉刷新我直接用了ArkUI的SwipeRefresh組件包裹List。這里要特別注意的是刷新狀態(tài)的生命周期管理。JS側(cè)的refreshing狀態(tài)和ArkUI側(cè)的刷新動畫要同步不能出現(xiàn)JS側(cè)已經(jīng)setState了但ArkUI側(cè)的刷新動畫還沒有停止的情況。我的做法是JS側(cè)onRefresh回調(diào)觸發(fā)后先把refreshing置為true等接口返回后API調(diào)用finishRefresh(tag)通知原生側(cè)停止動畫然后再把refreshing置為false。順序不能反否則會出現(xiàn)刷新動畫和列表狀態(tài)不一致的問題。上拉加載這里有個很深的坑。以前在Android上我們習(xí)慣用onEndReached來判斷是否加載更多但在OpenHarmony上List的onReachEnd事件在快速滑動時會觸發(fā)得很激進(jìn)經(jīng)常滑動一次就觸發(fā)三四次。如果不做節(jié)流分頁接口會被連續(xù)調(diào)用數(shù)據(jù)就會重復(fù)。我加的方案是onReachEnd觸發(fā)后立即把loadingMore置為true在接口返回前不響應(yīng)任何后續(xù)事件同時利用props.hasMore做二次攔截從根上避免無效請求?？諔B(tài)和錯誤態(tài)這兩種狀態(tài)實(shí)際上是同一種處理邏輯——判斷數(shù)據(jù)長度為0或異常時顯示一個全屏占位。難點(diǎn)在于ArkUI原生List的header和footer機(jī)制。如果要讓空態(tài)占位在List內(nèi)部實(shí)現(xiàn)吸頂或者居中直接放在ListFooterComponent里會有布局問題。我的處理辦法是當(dāng)data.length為0時不讓ArkUI渲染List而是在JS層渲染一個獨(dú)立的空態(tài)視圖這樣布局邏輯完全由JS控制不依賴ArkUI的列表布局。4. 性能優(yōu)化從啟動白屏到絲滑滾動的完整調(diào)優(yōu)過程這一章節(jié)講的是我在真機(jī)調(diào)試中踩過的性能坑和最終的解決方案。列表組件的性能優(yōu)化不是一個點(diǎn)而是一條鏈路每一個環(huán)節(jié)不處理好最終的體驗(yàn)都會大打折扣。4.1 啟動白屏的三個根因與針對性修復(fù)React Native在OpenHarmony上啟動白屏問題是社區(qū)里抱怨最多的問題之一。我調(diào)優(yōu)后總結(jié)出三個根因。根因一JSBundle加載慢。OpenHarmony的RN SDK加載JSBundle的方式和Android不完全一樣它對本地文件讀取的優(yōu)化不到位一個幾兆的Bundle文件加載耗時可能翻倍。這個問題在列表頁首屏尤為明顯因?yàn)榱斜眄撏ǔＳ写罅康臉I(yè)務(wù)邏輯注入。我的修復(fù)方案把JSBundle提前拆包首屏需要的核心代碼打成一個體積較小的包列表相關(guān)的業(yè)務(wù)代碼走異步加載。等到列表頁真正打開時核心代碼已經(jīng)激活再異步補(bǔ)齊業(yè)務(wù)代碼。這樣做啟動時間能優(yōu)化30%以上。根因二ArkUI側(cè)的List初始化時一次性渲染了過多cell。我在配置initialNumToRender時最初設(shè)成了20想著首屏顯示10條加上預(yù)渲染10條體驗(yàn)會更平滑。但實(shí)際上OpenHarmony的List渲染性能和Android差距很大一次性渲染20個cell會導(dǎo)致首屏卡頓。后來我把initialNumToRender調(diào)成5預(yù)渲染數(shù)量調(diào)成3首屏?xí)r間縮減了一半以上。這個參數(shù)不能照搬Android經(jīng)驗(yàn)OpenHarmony的渲染引擎對節(jié)點(diǎn)數(shù)和組件樹的敏感度更高寧可少預(yù)渲染一點(diǎn)先讓首屏出來后續(xù)滾動的時候再動態(tài)補(bǔ)。根因三圖片加載阻塞了列表渲染。列表項(xiàng)里只要有網(wǎng)絡(luò)圖片圖片解碼的耗時就會阻塞整個cell的渲染。Android上Glide有異步解碼的能力但OpenHarmony的Image組件在網(wǎng)絡(luò)圖片加載上還需要適配。我的方案是所有列表項(xiàng)中的圖片在JS側(cè)先做一個預(yù)解碼標(biāo)記非首屏的圖片延遲加載等cell真正進(jìn)入視口前100ms再發(fā)起圖片請求。這三招組合起來我的列表頁首屏白屏?xí)r間從4秒降到了1.5秒以內(nèi)。雖然離Android的1.2秒還有一點(diǎn)差距但已經(jīng)處于可接受的范圍內(nèi)。4.2 cell復(fù)用機(jī)制的二次優(yōu)化ArkUI的LazyForEach自帶cell復(fù)用能力但默認(rèn)復(fù)用策略比較保守。它在滾動時會保留離屏的cell一段時間方便快速回滾。但如果列表項(xiàng)高度不固定復(fù)用時的布局計算會消耗大量時間。我做了兩件事來優(yōu)化第一如果業(yè)務(wù)列表的高度是可以預(yù)估的我建議在JS側(cè)給每個item一個預(yù)估高度字段傳給ArkUI后ArkUI在布局時可以跳過一部分高度測量直接按預(yù)估高度排布。等真正的布局?jǐn)?shù)據(jù)出來后再矯正。// ListContainer.tsx 內(nèi)部處理邏輯 const estimatedHeight item.estimatedHeight || DEFAULT_ITEM_HEIGHT; // 通過橋接層傳給ArkUI NativeListModule.setEstimatedHeight(tag, index, estimatedHeight);第二cell的根布局盡量減少嵌套層級。有些組件為了視覺效果包了三四層View這在列表場景里是致命的。ArkUI對組件樹的深度有很明顯的性能拐點(diǎn)深度超過5層后渲染耗時指數(shù)級上升。我在代碼審查時專門要求列表項(xiàng)的renderItem返回的組件層級不能超過3層嵌套太深的磨平之后再提交。4.3 滾動幀率調(diào)優(yōu)事件節(jié)流與渲染優(yōu)先級列表滾動時的幀率問題通常在真機(jī)上比模擬器更容易暴露。我測試時發(fā)現(xiàn)快速滑動時幀率會掉到40幀以下而且伴隨著掉幀往往還會出現(xiàn)內(nèi)容閃爍。這個問題的根子在于RN側(cè)接收到ArkUI的滾動事件后會觸發(fā)JS層的onScroll回調(diào)如果業(yè)務(wù)代碼在onScroll里做了setStateReact會重新渲染整個列表組件而React重新渲染又會驅(qū)動新的ArkUI布局形成了一個惡性循環(huán)。我的調(diào)優(yōu)方案是RN側(cè)用一個訂閱者模式來管理滾動事件。ArkUI的滾動事件先經(jīng)過一個節(jié)流器throttle最小間隔16ms再分發(fā)給實(shí)際的業(yè)務(wù)回調(diào)。同時所有OnScroll觸發(fā)的JS操作禁止setState如果業(yè)務(wù)確實(shí)需要根據(jù)滾動位置更新UI比如導(dǎo)航欄變色就用ref直接修改原生組件的屬性繞開React渲染。幀率問題還跟cell的繪制優(yōu)先級有關(guān)。ArkUI的List支持通過cachedCount設(shè)置緩存數(shù)量但cachedCount設(shè)太大反而會拖慢首屏和內(nèi)存占用。我建議cachedCount設(shè)為視口可顯示數(shù)量的1.5倍讓離屏的cell即使被回收也不會在滾回時因?yàn)橹匦聞?chuàng)建而產(chǎn)生掉幀。這部分調(diào)優(yōu)做完后快速滑動的幀率穩(wěn)定在55~60幀雖然極端場景下還有輕微掉幀但已經(jīng)不影響正常使用了。5. 實(shí)踐中的坑從ADB調(diào)試到List接口約束的避坑清單寫代碼的過程是正常流程真正的心酸都在排坑里。這一章列幾個我認(rèn)為最有代表性的坑幫后來人跳過這些彎路。5.1 調(diào)試環(huán)境的坑adb devices識別不到OpenHarmony設(shè)備做OpenHarmony開發(fā)第一道坎就是設(shè)備調(diào)試。我最初用adb devices總是識別不到設(shè)備查了一圈原因發(fā)現(xiàn)OpenHarmony的調(diào)試工具鏈和Android不完全一樣。OpenHarmony設(shè)備默認(rèn)不是通過標(biāo)準(zhǔn)ADB端口通訊的需要先使用hdc工具HarmonyOS Device Connector來連接設(shè)備。hdc的啟動方式和adb類似但端口和協(xié)議不同。所以排查思路是先用hdc list targets確認(rèn)設(shè)備狀態(tài)不要一上來就死磕adb。另外還有一個坑某些版本的OpenHarmony開發(fā)板默認(rèn)開了USB調(diào)試但ADB的調(diào)試通道沒有開。需要到開發(fā)者模式里確認(rèn)“USB調(diào)試”選項(xiàng)是打開的同時確認(rèn)hdc版本和SDK版本兼容。hdc版本不匹配時連接會顯示“device offline”這種問題重新拔插USB接口或者重啟hdc服務(wù)就能解決。5.2 List數(shù)據(jù)更新時LazyForEach的key沖突前文提到過LazyForEach的id生成規(guī)則必須穩(wěn)定。這里給一個具體的排查案例我在一個點(diǎn)贊列表里用戶點(diǎn)贊后要實(shí)時更新對應(yīng)item的點(diǎn)贊狀態(tài)。JS側(cè)更新了數(shù)組里的一個字段然后調(diào)用updateItem方法結(jié)果發(fā)現(xiàn)列表里的好幾條item都串了數(shù)據(jù)。定位后發(fā)現(xiàn)LazyForEach的id生成規(guī)則用了index幾條item在數(shù)據(jù)更新時index重新排列了一下導(dǎo)致LazyForEach認(rèn)為原來的item已經(jīng)移除了新item又出現(xiàn)了就觸發(fā)了錯誤的復(fù)用。修復(fù)方案很簡單把id生成規(guī)則改成業(yè)務(wù)數(shù)據(jù)的userId問題立刻消失。這里也提醒大家如果業(yè)務(wù)數(shù)據(jù)沒有唯一主鍵一定要在數(shù)據(jù)清洗階段補(bǔ)一個clientId。否則任何局部刷新、刪除、插入操作都可能引發(fā)不可預(yù)料的渲染錯亂。5.3 List接口約束的真坑一次最多渲染多少條ArkUI的List和LazyForEach雖然宣稱支持大數(shù)據(jù)量但并不是無限的。我在測試中發(fā)現(xiàn)一次性setData超過2000條數(shù)據(jù)時List的內(nèi)存占用會急劇上升滾動也會明顯卡頓。這個問題的根源在于LazyForEach雖然只渲染可視區(qū)附近的cell但I(xiàn)DataSource內(nèi)部會維護(hù)一個完整的key-index映射表數(shù)據(jù)越多映射表越大。更麻煩的是當(dāng)List滾動到接近底部時LazyForEach會把整個映射索引進(jìn)行一些計算2000條以上的計算量會拖慢幀率。我的方案是給ListContainer強(qiáng)制做一個分頁緩存上限列表里最多只保留3000條數(shù)據(jù)超出部分舊的頁面緩存直接丟棄不放進(jìn)ArkUI的數(shù)據(jù)源。同時配合虛擬列表的思想如果用戶從第1000條往回滑我們重新從JS數(shù)據(jù)源里補(bǔ)齊前面的數(shù)據(jù)。這個方案需要JS側(cè)維護(hù)一個完整的數(shù)據(jù)副本但能保證ArkUI側(cè)的渲染始終在一個安全的數(shù)據(jù)量范圍內(nèi)。5.4 列表項(xiàng)內(nèi)的RN組件與ArkUI原生組件的觸摸事件沖突最后一個坑是觸摸事件。cell外層是ArkUI的ListItem內(nèi)層有RN的Button組件。實(shí)際測試時RN的Button點(diǎn)擊事件能正常觸發(fā)但有時候點(diǎn)擊偶發(fā)失靈而且會帶動整個列表滾動。排查后發(fā)現(xiàn)是事件冒泡機(jī)制的問題。RN側(cè)的觸摸事件通過橋接層傳遞最終和ArkUI的滾動手勢識別器產(chǎn)生了競爭。ArkUI基于手勢的識別優(yōu)先級默認(rèn)情況下滾動手勢的優(yōu)先級更高導(dǎo)致RN的點(diǎn)擊手勢在快速滑動時被吞掉。修復(fù)方案在ArkUI的ListItem上顯式設(shè)置手勢識別優(yōu)先級讓點(diǎn)擊手勢優(yōu)先于滾動手勢。同時cell上的RN可點(diǎn)擊區(qū)域要在JS側(cè)加上一個“點(diǎn)擊攔截”邏輯在觸摸開始到結(jié)束的時間內(nèi)先暫停List的滾動響應(yīng)觸摸結(jié)束再恢復(fù)。這個坑排查起來很費(fèi)勁但修好之后對列表整體交互的穩(wěn)定性提升非常明顯強(qiáng)烈建議做RNOpenHarmony混合開發(fā)的朋友提前把這個方案落地。6. 后續(xù)演進(jìn)從List到瀑布流再到國際化封裝一個List組件只是一個起點(diǎn)。項(xiàng)目的實(shí)際需求往往會從垂直列表延伸到瀑布流、多列網(wǎng)格、吸頂分組等更多形態(tài)。我在設(shè)計之初就考慮到了這一點(diǎn)所以橋接層的接口不光是給List用也給后續(xù)的組件預(yù)留了擴(kuò)展空間。6.1 快速擴(kuò)展一個WaterFlow瀑布流組件ArkUI自帶的WaterFlow組件性能和List算是一個量級但API接口完全不同。如果你需要多列瀑布流直接復(fù)用ListContainer的數(shù)據(jù)管理邏輯把渲染層替換成WaterFlow即可。建議把數(shù)據(jù)管理、狀態(tài)控制、事件回調(diào)這些邏輯抽象成一個useListController的HooksList和瀑布流都從這個Hooks里獲取能力這樣兩個組件共用一套數(shù)據(jù)流只是UI渲染層不同。后續(xù)再加網(wǎng)格列表時也只需要再寫一個渲染層。6.2 國際化適配的提前布局列表組件的文案比如“加載更多”“沒有更多了”“下拉刷新”在最初設(shè)計時就要支持多語言。這部分做晚了后面改起來的成本很高。我的方案是這些內(nèi)置文案不寫在組件內(nèi)部而是從Bridge配置里下發(fā)或者通過props傳入業(yè)務(wù)層根據(jù)當(dāng)前語言模型選擇對應(yīng)的文案。另外一個容易被忽視的點(diǎn)是雙向布局。阿拉伯語等從右到左閱讀習(xí)慣的地區(qū)列表的滾動方向和內(nèi)容排布要和LTR語言保持鏡像。ArkUI對RTL布局有內(nèi)置支持但RN側(cè)的渲染層和樣式處理是否兼容還是未知數(shù)這部分我目前還沒有完整的實(shí)踐驗(yàn)證先不做結(jié)論但建議有出海業(yè)務(wù)規(guī)劃的項(xiàng)目在技術(shù)選型時就要考慮到這個變量。7. 一些調(diào)試技巧和最后的經(jīng)驗(yàn)總結(jié)寫到最后分享幾個我在實(shí)際開發(fā)里沉淀下來的調(diào)試技巧都是網(wǎng)上比較少提到的細(xì)節(jié)。技巧一善用hdc的日志過濾。OpenHarmony的hilog調(diào)試日志默認(rèn)輸出量很大直接看會被刷屏。我開發(fā)時常用hdc shell hilog -t rn_list來過濾RN列表相關(guān)的日志或者用hdc shell hilog | grep NativeListModule來只看橋接層的日志。這個習(xí)慣能幫你快速定位是JS邏輯出了問題還是橋接層的數(shù)據(jù)傳輸出了問題。技巧二在JS側(cè)加一個列表狀態(tài)的Debug面板。我在ListContainer組件內(nèi)部埋了一個隱藏的調(diào)試開關(guān)連續(xù)點(diǎn)擊標(biāo)題欄5次會彈出一個半透明面板顯示當(dāng)前數(shù)據(jù)總量、已經(jīng)渲染的cell數(shù)量、橋接層的調(diào)用次數(shù)、平均渲染耗時等指標(biāo)。這個面板在生產(chǎn)包默認(rèn)關(guān)閉但debug包開啟后對性能調(diào)優(yōu)的幫助是巨大的很多問題不用上工具就能直觀看到。技巧三數(shù)據(jù)變化時對比ArkUI側(cè)的日志輸出時間戳。有時候JS側(cè)的setState已經(jīng)執(zhí)行了但UI遲遲不更新。這時可以通過ArkUI側(cè)的渲染日志來定位問題。正常的流程是JS調(diào)用橋接方法的時間戳應(yīng)該和ArkUI側(cè)對應(yīng)日志的時間戳相差在幾毫秒以內(nèi)。如果差距超過100ms說明數(shù)據(jù)傳輸鏈路有阻塞可能是事件節(jié)流策略太激進(jìn)也可能是ArkUI主線程卡頓。最后打個總結(jié)。我個人的體會是React Native和OpenHarmony的跨端方案目前還處于“能跑、要調(diào)、別照搬”的階段。能把一個列表組件做到接近原生體驗(yàn)需要同時理解RN的組件生命周期、ArkUI的渲染機(jī)制、以及橋接層的數(shù)據(jù)傳輸原理。這篇文章里提到的很多問題只有真機(jī)調(diào)試時才會遇到模擬器上很難復(fù)現(xiàn)。所以如果你也在做類似的事情我的建議是盡早拿到真機(jī)盡早把列表頁跑起來越早暴露性能問題調(diào)整的空間就越大。成本最低的優(yōu)化永遠(yuǎn)是在架構(gòu)階段做的優(yōu)化等業(yè)務(wù)代碼堆上來了再重構(gòu)那才是真的痛。