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