化：useMemo緩存結(jié)果實戰(zhàn))
1. 搜索頁卡頓在鴻蒙端被放大了先還原現(xiàn)場我先把背景交代清楚。我們團隊在做資訊類App的鴻蒙適配React Native版本用的0.72通過HarmonyOS的RN適配層跑原生渲染鏈路。首頁、詳情頁遷移都算順利唯獨搜索頁在輸入關(guān)鍵詞時掉幀嚴重。測試機覆蓋了HarmonyOS 4.0的Mate 60 Pro和P40癥狀一致每次按鍵觸發(fā)列表重建滾動結(jié)果列表時卡頓明顯尤其是條目多、帶縮略圖的場景更煩人的是輸入法和列表渲染互相搶主線程打字本身都有遲滯感。這個問題在Android和iOS上不是沒有但沒那么刺眼。鴻蒙端的RN渲染鏈路比兩端多了一層中轉(zhuǎn)和橋接開銷主線程負荷一旦上來卡頓就被放大了。我一開始以為是鴻蒙適配層的性能問題查了一圈發(fā)現(xiàn)根子還是在業(yè)務代碼的渲染策略上——搜索頁在每次輸入變化時把整個結(jié)果列表的數(shù)據(jù)處理鏈路完整跑了一遍。這個場景正是React Hooks里useMemo最典型的用武之地搜索結(jié)果緩存的本質(zhì)就是把不隨輸入變化的計算擋在render之外。這篇文章不是入門教程而是實戰(zhàn)記錄。目標讀者應該是已經(jīng)在做React Native鴻蒙開發(fā)、對Hooks有基本了解、正在或即將處理列表渲染性能問題的同學。我會按問題現(xiàn)場—卡頓根因—useMemo原理—代碼改造—實測收益—鴻蒙端特有坑這條線完整梳理最后附帶我們踩過的一些額外經(jīng)驗。2. 卡頓根因render過程中的隱性計算成本2.1 React Native的render機制與列表重建先拆解一下為什么搜索頁會卡。React Native里state變化會觸發(fā)組件重新渲染所有依賴這個state的子組件也會跟著重新走一遍render流程。搜索頁的結(jié)構(gòu)大致是這樣一個SearchScreen組件持有searchText這個state輸入框每次變化都調(diào)用setSearchText底下掛著一個SearchResults組件接收搜索詞和原始結(jié)果數(shù)據(jù)SearchResults內(nèi)部把原始數(shù)據(jù)做過濾、排序、關(guān)鍵詞高亮、時間格式化、去重合并然后交給FlatList渲染問題就出在這個數(shù)據(jù)處理過程上。每次按鍵searchText一變整個SearchResults重新執(zhí)行內(nèi)部所有數(shù)據(jù)處理邏輯全部重算一遍。哪怕用戶只是從鴻字打到鴻蒙結(jié)果列表的原始數(shù)據(jù)根本沒變processResults這個純計算函數(shù)也會完完整整跑一趟。如果原始結(jié)果集有幾百條每條還要做字符串匹配和高亮片段切割這個計算耗時在低端機上就很可觀了。2.2 鴻蒙端為什么更敏感同樣的代碼在Android上可能只是輕微掉幀到鴻蒙上就變成明顯卡頓。原因有幾個層面第一鴻蒙的RN適配層目前仍在快速迭代渲染指令的批量處理和調(diào)度優(yōu)化不如Android/iOS成熟同樣的render工作量會產(chǎn)生更高的主線程占用。第二HarmonyOS的輸入法服務和應用主線程之間的調(diào)度協(xié)調(diào)和Android的InputMethod機制存在差異輸入事件處理的優(yōu)先級表現(xiàn)不同。一旦主線程被render任務占滿輸入事件的響應延遲會更明顯。第三搜索頁通常還伴隨鍵盤彈起、頁面轉(zhuǎn)場動畫、列表滾動等并發(fā)任務鴻蒙端的動畫渲染管線還在適配優(yōu)化中這些任務疊加時更容易互相擠壓。所以搜索頁在鴻蒙端對無效計算的容忍度更低。這也解釋了為什么同樣的性能問題我們是在鴻蒙適配階段才下決心徹底解決的。2.3 數(shù)據(jù)轉(zhuǎn)換操作的成本量級我專門把processResults的耗時拆開測過。一次處理300條搜索結(jié)果包含關(guān)鍵詞高亮切割每條要做字符串indexOf和slice拼接、相對時間格式化、來源去重合并在Mate 60 Pro上單次執(zhí)行大約12ms到25ms。聽起來不多但輸入一個關(guān)鍵詞通常要打4到6個字符每個字符觸發(fā)一次完整處理再加上FlatList對可見單元格的render每幀的JavaScript執(zhí)行時間輕松超過50ms。而React Native的UI更新需要和JavaScript執(zhí)行在同一幀內(nèi)完成超出16.6ms的幀預算就意味著掉幀。這些數(shù)據(jù)轉(zhuǎn)換都是純函數(shù)——輸入是原始結(jié)果集和搜索詞輸出是展示用的列表中間沒有任何副作用。純函數(shù)有個特點只要輸入不變輸出一定不變。那為什么每次都要重新算這正是useMemo能派上用場的地方。3. useMemo的原理用記憶化換掉無效計算3.1 從組件重新渲染說起useMemo是React提供的記憶化Hook。它的簽名長這樣const memoizedValue useMemo(() computeExpensiveValue(a, b), [a, b]);第一個參數(shù)是執(zhí)行計算的函數(shù)第二個參數(shù)是依賴數(shù)組。React會在首次渲染時執(zhí)行計算函數(shù)并把結(jié)果緩存起來。后續(xù)渲染時React會比較依賴數(shù)組里的每一項和上一次的值是否相同如果全部相同就直接返回上一次緩存的結(jié)果不再執(zhí)行計算函數(shù)只有某個依賴項發(fā)生變化時才會重新執(zhí)行計算。這里有個關(guān)鍵點React比較依賴用的是Object.is也就是引用相等。對于原始類型來說比較的是值對于對象和數(shù)組來說比較的是引用。所以useMemo的緩存失效條件本質(zhì)上是依賴的引用是否變化。3.2 搜索場景為什么完美契合回到搜索結(jié)果的場景。processResults(rawResults, query)這個函數(shù)有兩個輸入rawResults是請求返回的結(jié)果集query是搜索詞。用戶連續(xù)輸入鴻蒙這兩個字時發(fā)生了什么輸入鴻query從空字符串變成鴻處理一次輸入鴻蒙query從鴻變成鴻蒙再處理一次兩次之間rawResults的引用有沒有變大多數(shù)情況是沒有。搜索請求還沒有發(fā)出或者返回的數(shù)據(jù)還掛在state上沒有被替換。也就是說rawResults這個依賴始終保持同一個引用。那么問題來了query變化的時候rawResults并沒有變?yōu)槭裁疵看味家匦卤闅v幾百條數(shù)據(jù)做高亮切割如果processResults的計算邏輯能拆成不依賴query的預處理和依賴query的高亮處理兩個階段緩存的價值就更大了。不過實際項目里搜索結(jié)果的原始數(shù)據(jù)通常已經(jīng)經(jīng)過接口層的字段裁剪預處理空間不大真正值得緩存的是整個processedResults數(shù)組的生成過程。用useMemo改造之后的效果用戶從鴻打到鴻蒙第二次渲染時useMemo檢查依賴發(fā)現(xiàn)rawResults引用沒變query從鴻變成了鴻蒙依賴有變化所以還是重新執(zhí)行了。這一步看起來沒省多少。但如果用戶按退格鍵從鴻蒙刪到鴻這時候query從鴻蒙變回鴻useMemo照樣要重新算。那緩存的意義在哪關(guān)鍵在于另一個場景用戶輸入完關(guān)鍵詞結(jié)果列表渲染出來后可能因為鍵盤彈起、頁面布局變化、列表滾動等觸發(fā)父組件重新渲染。這些渲染和query、rawResults都沒關(guān)系但如果沒有useMemoSearchResults內(nèi)部的processResults會被白白重算。有了useMemo只要依賴不變這些額外渲染就完全跳過計算邏輯直接復用上次的結(jié)果數(shù)組。3.3 useMemo和useCallback、React.memo的配合實際工程里useMemo很少單獨出現(xiàn)。它經(jīng)常和React.memo、useCallback一起用useMemo緩存計算結(jié)果useCallback緩存函數(shù)引用React.memo阻止組件在props不變時重新渲染搜索列表場景里如果renderListItem是內(nèi)聯(lián)函數(shù)每次父組件render都會生成新引用FlatList的renderItem變化會觸發(fā)所有可見單元格重新渲染。這時候給ListItem組件包上React.memo再把renderListItem用useCallback包一層就能做到只有數(shù)據(jù)變化時才重渲染對應行。我在改造時一并做了收益疊加const renderListItem useCallback(({ item }) { return ListItem data{item} onPress{handlePress} /; }, [handlePress]);這里有個細節(jié)handlePress也必須用useCallback包住否則它本身引用變化renderListItem的緩存也會失效整個鏈路的記憶化就白做了。4. 代碼實戰(zhàn)搜索結(jié)果緩存的完整改造4.1 改造前的基線版本這是搜索頁最初的樣子我做了簡化但保留了核心邏輯const SearchScreen () { const [searchText, setSearchText] useState(); const [results, setResults] useState([]); const [isSearching, setIsSearching] useState(false); const handleSearch async (text) { setSearchText(text); if (text.trim().length 2) { setResults([]); return; } // 實際項目里有防抖邏輯這里省略 const res await fetchSearchResults(text); setResults(res); setIsSearching(false); }; return ( View style{styles.container} SearchInput value{searchText} onChange{handleSearch} / SearchResults query{searchText} rawResults{results} / /View ); };再看SearchResults的原始實現(xiàn)const SearchResults ({ query, rawResults }) { // 每次render都會完整執(zhí)行一遍 const processedResults processResults(rawResults, query); return ( FlatList data{processedResults} renderItem{renderListItem} keyExtractor{(item) item.id} keyboardShouldPersistTapshandled ListEmptyComponent{EmptyState /} / ); };processResults放在render函數(shù)體里直接調(diào)用這是性能隱患的源頭。React組件每次渲染都會執(zhí)行函數(shù)體不管rawResults和query是否變化。搜索頁里只要有任何state變化——比如鍵盤彈出、FlatList內(nèi)部狀態(tài)、父組件某個不相關(guān)的state——SearchResults都會重新render然后白白跑一遍完整的數(shù)據(jù)處理。4.2 processResults到底做了什么我把processResults拆出來單獨看方便說明緩存的粒度function processResults(rawResults, query) { if (!rawResults || rawResults.length 0) return []; // 1. 按時間倒序排序 const sorted [...rawResults].sort((a, b) b.timestamp - a.timestamp); // 2. 去重按內(nèi)容標題合并重復來源 const deduped []; const seen new Set(); for (const item of sorted) { const key item.title.trim().toLowerCase(); if (!seen.has(key)) { seen.add(key); deduped.push(item); } } // 3. 關(guān)鍵詞高亮切割依賴query return deduped.map((item) { const highlightParts []; if (query query.trim().length 0) { const lowerTitle item.title.toLowerCase(); const lowerQuery query.trim().toLowerCase(); let index lowerTitle.indexOf(lowerQuery); while (index ! -1 highlightParts.length 20) { highlightParts.push({ start: index, end: index query.trim().length, }); index lowerTitle.indexOf(lowerQuery, index query.trim().length); } } return { ...item, highlightParts, displayTime: formatRelativeTime(item.timestamp), }; }); }排序和去重完全不依賴query但它們隨每次render一起執(zhí)行。高亮部分依賴query但大多數(shù)時候用戶輸入過程中rawResults還沒更新高亮處理也在重復勞動。整個函數(shù)是純計算沒有副作用這給它放進useMemo提供了充分條件。4.3 用useMemo改造后的版本改動很小但語義變化很大import React, { useMemo, useCallback } from react; const SearchResults ({ query, rawResults, onItemPress }) { // 只在 rawResults 或 query 的引用/值變化時重新計算 const processedResults useMemo(() { return processResults(rawResults, query); }, [rawResults, query]); const handlePress useCallback((item) { onItemPress(item); }, [onItemPress]); const renderListItem useCallback(({ item }) { return ListItem data{item} onPress{handlePress} /; }, [handlePress]); return ( FlatList data{processedResults} renderItem{renderListItem} keyExtractor{(item) item.id} keyboardShouldPersistTapshandled ListEmptyComponent{EmptyState /} initialNumToRender{10} maxToRenderPerBatch{10} windowSize{5} / ); };幾個細節(jié)說明一下第一useMemo的依賴數(shù)組是[rawResults, query]。query是字符串React用值比較rawResults是數(shù)組React用引用比較。如果父組件每次setState都創(chuàng)建新數(shù)組哪怕內(nèi)容一模一樣useMemo也會失效。所以我在SearchScreen里刻意保持了resultsstate的引用穩(wěn)定只有接口返回新數(shù)據(jù)時才setResults(res)不做多余的set。第二onItemPress如果直接從父組件傳下來且沒有緩存handlePress的useCallback就會失效進而renderListItem失效FlatList的單元格每次都要重渲染。所以父組件的onItemPress也要用useCallback包一層。第三FlatList的initialNumToRender、maxToRenderPerBatch、windowSize這些參數(shù)在鴻蒙端也要顯式設置。后面我會單獨講鴻蒙適配的額外參數(shù)調(diào)優(yōu)。4.4 進一步拆分緩存的粒度useMemo的緩存粒度可以根據(jù)實際場景調(diào)整。如果processResults里的排序和去重計算量很大而高亮只依賴query可以拆成兩個useMemoconst sortedDeduped useMemo(() { return deduplicate(sortByTime(rawResults)); }, [rawResults]); const highlightedResults useMemo(() { return highlightKeyword(sortedDeduped, query); }, [sortedDeduped, query]);這樣當用戶快速修改關(guān)鍵詞時排序去重只依賴rawResults只要原始數(shù)據(jù)沒變就跳過高亮部分在query變化時重算。不過這個優(yōu)化要建立在排序去重確實昂貴的前提下。如果原始結(jié)果集只有幾十條拆分反而增加代碼復雜度收益可以忽略。我們的項目里搜索鏈路是輸入關(guān)鍵詞—防抖—請求—返回新結(jié)果rawResults本身更新不頻繁所以最終還是合并成一個useMemo代碼更清爽。5. 鴻蒙端實測Profiler數(shù)據(jù)與體驗對比5.1 Profiler記錄到的前后對比改造完成后我在鴻蒙真機上用React DevTools的Profiler跑了多次錄制。注意React DevTools連接鴻蒙端的RN應用方式和Android類似通過adb reverse把調(diào)試端口映射到設備上。測出來的數(shù)據(jù)很能說明問題。場景在搜索框輸入鴻蒙操作系統(tǒng)每輸入一個字符停頓片刻讓列表完成渲染。結(jié)果列表300條帶縮略圖。改造前的數(shù)據(jù)指標最低值最高值典型值單次render耗時98ms220ms140ms左右輸入響應延遲明顯遲滯卡頓感強每幀JS執(zhí)行約60-80msFlatList可見單元格render次數(shù)每次輸入全部重渲-10個左右單元格全部重渲改造后的數(shù)據(jù)指標最低值最高值典型值單次render耗時35ms75ms45ms左右輸入響應延遲基本跟手偶發(fā)輕微遲滯每幀JS執(zhí)行約20-30msFlatList可見單元格render次數(shù)僅輸入變化時重渲-10個左右單元格按需重渲為什么沒降到0因為FlatList可見區(qū)域的單元格仍然需要渲染renderListItem的執(zhí)行成本省不掉。但整個組件的JavaScript執(zhí)行時間降了一半以上原因是processResults不再被反復執(zhí)行主線程從每幀60-80ms的負荷降到20-30ms已經(jīng)低于16.6ms幀預算的2倍以內(nèi)。實際體驗就是打字跟手了列表滾動不再一卡一卡。5.2 輸入過程中原始結(jié)果集不變時的緩存命中最典型的收益場景是用戶連續(xù)輸入但還沒有新請求返回時。比如用戶快速輸入鴻蒙開發(fā)防抖時間內(nèi)其實只有一個請求被發(fā)出rawResults在整個輸入過程中可能只更新一次。沒有useMemo時每輸入一個字符都重新跑一遍幾百條數(shù)據(jù)的處理和排序有了useMemo這些中間態(tài)的渲染全部命中緩存直接返回上一次處理結(jié)果。這里有個反直覺的點即使在useMemo下query每次變化都會導致緩存失效重算。那省掉的計算到底是什么省掉的是因為鍵盤彈起、布局變化、FlatList內(nèi)部狀態(tài)變化等觸發(fā)的無關(guān)render。搜索頁在輸入過程中鍵盤高度變化、光標位置變化、甚至輸入法候選詞彈窗都可能觸發(fā)組件樹重新渲染這些渲染和數(shù)據(jù)處理沒有關(guān)系它們正是useMemo保護的對象。5.3 內(nèi)存占用的實測觀察我特意用DevTools的Memory面板觀察了useMemo改造后的內(nèi)存變化。緩存的數(shù)據(jù)是processedResults數(shù)組300條左右的結(jié)果條目每條包含原始字段和高亮切割數(shù)組占用大約幾百KB到1MB。持續(xù)輸入5分鐘后內(nèi)存曲線平穩(wěn)沒有出現(xiàn)緩存堆積的跡象。原因很簡單useMemo的依賴數(shù)組固定只有兩個緩存只會保留最近一次的計算結(jié)果不會累積歷史版本。這一點和useRef手動維護緩存完全不同后者如果忘記清理內(nèi)存會只增不減。6. 鴻蒙端適配過程中額外踩過的坑6.1 React Native版本與鴻蒙適配層的匹配問題我們的RN版本是0.72鴻蒙適配層用的對應版本。這里有個重要經(jīng)驗RN的0.72及以下版本useMemo的執(zhí)行語義和React 18是保持一致的但在鴻蒙適配層上部分做了并發(fā)特性裁剪的版本可能影響組件更新批處理效果。如果你發(fā)現(xiàn)useMemo改造后收益不明顯先確認適配層是否把React的Concurrent Mode相關(guān)邏輯完整移植了。鴻蒙適配層還在快速迭代不同版本的批處理策略有差異建議升到適配層官方推薦的RN版本不要自己停留在老版本上。6.2 白屏問題搜索頁打開鍵盤時偶發(fā)實測中發(fā)現(xiàn)一個高頻問題搜索框聚焦、鍵盤彈出時頁面出現(xiàn)白屏過一兩秒才恢復。這個和useMemo無關(guān)是KeyboardAvoidingView在鴻蒙端的適配問題。RN的KeyboardAvoidingView在Android上通常設置behavior{undefined}就能正常工作因為Android系統(tǒng)自帶adjustResize但鴻蒙端如果沿用這個配置鍵盤彈出時的窗口尺寸變化通知機制和Android不同可能導致頁面布局重算異常出現(xiàn)白屏。我們的解決方案是鴻蒙端不依賴KeyboardAvoidingView改用HarmonyOS原生的鍵盤避讓模式。在頁面配置里啟用安全區(qū)和鍵盤避讓然后移除RN層的KeyboardAvoidingView包裹。這樣鍵盤彈出時由系統(tǒng)層面處理窗口避讓RN層完全不用參與布局重算從根上避開了白屏問題。6.3 真機調(diào)試比模擬器更容易暴露問題在鴻蒙模擬器上測試輸入流暢度比真機好很多很容易得出性能沒問題的錯誤結(jié)論。原因是模擬器上CPU調(diào)度和GPU渲染都是虛擬化的主線程負荷模型和真機差異很大。我們所有性能優(yōu)化后的驗證都要求真機進行至少覆蓋一款麒麟芯片設備和一個中低端設備。最終優(yōu)化效果以真機為準模擬器只做功能驗證。6.4 HiLog定位JS層性能問題鴻蒙端的RN日志默認輸出機制和Android不完全一樣。在Android上ReactNative的JS console日志會打到Logcat里tag通常是ReactNativeJS。鴻蒙端除了Logcat兼容層還有自己的HiLog系統(tǒng)。我建議用HiLog抓取RN相關(guān)日志過濾關(guān)鍵詞如ReactNative、JS同時關(guān)注ArkTS和UI渲染相關(guān)的事件。定位性能問題的時候單看JS層耗時不夠還要對比Native側(cè)的渲染耗時因為鴻蒙端的渲染鏈路和Android端不同同樣的掉幀問題可能由不同層級的瓶頸引起。6.5 FlatList在鴻蒙端的參數(shù)調(diào)優(yōu)FlatList在鴻蒙端的表現(xiàn)和Android有細微差異主要是滾動事件分發(fā)和單元格復用的時機。我做了三個調(diào)整initialNumToRender從默認10降到8。鴻蒙端首屏渲染壓力大少渲染兩個單元格對首屏速度有幫助。maxToRenderPerBatch從默認10降到8。限制單批渲染的單元格數(shù)量避免主線程被一下子占滿。windowSize從默認21降到7?？s小渲染窗口減少離屏單元格的render和內(nèi)存占用。這三個參數(shù)配合useMemo的緩存讓列表滾動時的計算和渲染壓力都保持在低位。有一點需要注意windowSize降太低可能導致快速滾動時出現(xiàn)白屏占位我試過5滾動稍快就會出現(xiàn)空白最后定在7是性能和觀感的平衡點。7. 搜索結(jié)果緩存方案從useMemo延伸的思考7.1 什么時候不該用useMemo一定要明確一點useMemo不是免費的。它本身有內(nèi)存開銷依賴比較有計算開銷。如果processResults很短比如只是簡單filter一下幾十條數(shù)據(jù)單次執(zhí)行不到1ms那么useMemo的依賴比較成本加緩存管理成本可能比直接重新計算還高。React官方文檔也明確說過不要在沒有必要的情況下給所有計算都套上useMemo。我的判斷標準是單次計算超過1ms或者計算結(jié)果被多個子組件復用或者組件本身會頻繁因為無關(guān)state變化而重新渲染。滿足其中一個useMemo才值得用。搜索列表這個場景單次處理300條數(shù)據(jù)耗時12-25ms加上組件在鍵盤彈起、滾動時頻繁重渲染三個條件全中所以收益非常明顯。7.2 緩存的數(shù)據(jù)結(jié)構(gòu)要穩(wěn)定useMemo返回的數(shù)組引用如果被其他組件當作useEffect的依賴要特別小心。比如某個子組件接收processedResults在useEffect里根據(jù)這個數(shù)組的長度發(fā)起統(tǒng)計上報那么useMemo如果因為無關(guān)原因失效返回一個新數(shù)組即使內(nèi)容沒變子組件的useEffect也會重新觸發(fā)可能造成重復上報或重復請求。解決辦法是依賴數(shù)組的粒度要盡量準確不要因為父組件的無關(guān)state導致useMemo失效。同時如果子組件只依賴數(shù)組的某個派生值比如長度可以直接傳processedResults.length避免整個數(shù)組引用變化引發(fā)連鎖反應。7.3 和useRef手動緩存對比有人可能會問為什么不用useRef自己維護一個緩存對象寫法上確實可以const cacheRef useRef(null); const lastQueryRef useRef(); if (lastQueryRef.current ! query || cacheRef.current null) { cacheRef.current processResults(rawResults, query); lastQueryRef.current query; }這段代碼和useMemo效果接近但有個隱患手動緩存需要自己維護失效條件rawResults的引用變化很容易被忽略。useMemo把依賴聲明放在代碼里失效邏輯是聲明式的讀代碼的人一眼能看出這個緩存依賴哪些值。團隊協(xié)作時useMemo的可維護性明顯更好。手動緩存適合更復雜的場景比如需要同時維護多個歷史版本或者緩存結(jié)構(gòu)比單一數(shù)組復雜得多但這種場景在搜索列表里用不上。8. 從搜索頁到整個鴻蒙適配的性能優(yōu)化思路8.1 減少主線程負擔是統(tǒng)一方向搜索頁這個案例往大了說其實是鴻蒙適配性能優(yōu)化的一個縮影。鴻蒙端的RN適配層仍在成熟過程中很多在Android上不是問題的問題到鴻蒙上會暴露得更明顯。核心思路就一條盡可能減少主線程的無效工作。這條思路可以拆成多個落地手段useMemo減少無意義的計算任務useCallback穩(wěn)定函數(shù)引用減少子組件重渲染React.memo阻止props未變時的單元格重渲染FlatList參數(shù)調(diào)優(yōu)控制渲染窗口移除不必要的KeyboardAvoidingView讓系統(tǒng)處理鍵盤避讓這五個手段配合使用才把搜索頁的主線程負荷壓到可接受的范圍。只加一個useMemo不調(diào)整FlatList參數(shù)滾動時仍然可能卡只調(diào)FlatList參數(shù)不緩存計算結(jié)果輸入時仍然可能掉幀。性能優(yōu)化是系統(tǒng)工程不要指望單一手段解決所有問題。8.2 排查鏈路先確認瓶頸在哪一層鴻蒙端排查性能問題時我建議按這個順序來先用Profiler確認是JavaScript層計算量大還是Native層渲染耗時長。React DevTools的Profiler能明確看到每個組件的render耗時。如果JS層render耗時長看是數(shù)據(jù)處理邏輯耗時processResults這一類還是大量組件重復render。前者用useMemo后者用React.memo和useCallback。如果Native層耗時長看FlatList的渲染窗口、圖片加載策略、陰影/透明度等過度繪制。FlatList參數(shù)調(diào)優(yōu)在鴻蒙端尤其重要。最后檢查是否有隱性的全局問題比如KeyboardAvoidingView引發(fā)布局重算、導航轉(zhuǎn)場動畫阻塞主線程。我們在這個排查鏈路里走了不少彎路。一開始直接調(diào)FlatList參數(shù)效果有但不明顯后來用Profiler才發(fā)現(xiàn)數(shù)據(jù)處理邏輯才是主因補齊useMemo后才徹底解決。所以我的建議是先測量再優(yōu)化不要憑感覺下手。8.3 搜索場景可以繼續(xù)擴展的方向搜索結(jié)果緩存這個需求useMemo解決的是展示數(shù)據(jù)生成的緩存。如果再往前一步把接口返回的原始數(shù)據(jù)也緩存起來就能實現(xiàn)更完整的搜索體驗優(yōu)化用useRef或外部狀態(tài)管理庫緩存最近N次搜索詞對應的原始結(jié)果用戶重新輸入相同關(guān)鍵詞時先渲染緩存結(jié)果再靜默請求刷新輸入過程中快速切換關(guān)鍵詞配合AbortController取消過期請求這些擴展在實際項目中能進一步提升搜索頁的響應速度但復雜度也在上升。我的建議是先把useMemo緩存做好確認基礎(chǔ)體驗達標后再有針對性地做請求層緩存。如果一上來就做全套緩存方案排查問題時會多一層干擾。9. 寫在最后關(guān)于性能優(yōu)化的一些個人體會搜索頁的useMemo改造代碼改動量只有幾行但背后是整個團隊對鴻蒙端性能特性的理解沉淀。做RN鴻蒙適配這幾個月我最大的體會是鴻蒙端不是一個換殼Android它的渲染鏈路、調(diào)度策略、輸入法機制都有獨立的行為特性很多Android開發(fā)的經(jīng)驗可以平移但性能邊界需要重新摸索。如果只是把代碼跑通搜索頁能用但體驗粗糙把主線程負擔摳下來之后X頁才能真正達到可用以上的標準。useMemo是其中一個手段和它并列的還有useCallback、React.memo、FlatList參數(shù)調(diào)優(yōu)甚至鍵盤避讓策略。建議各位在鴻蒙適配過程中每遇到一個性能問題都先問自己這個耗時是計算引起的還是渲染引起的還是系統(tǒng)調(diào)度引起的答案不同解法完全不同。最后分享一個小技巧在鴻蒙真機上調(diào)試性能時把開發(fā)者選項里的動畫時長縮放全部關(guān)掉再進行Profiler錄制。這樣拿到的耗時數(shù)據(jù)是純渲染和計算時長不會被系統(tǒng)動畫干擾。我們最初在真機上測出的render耗時忽高忽低后來發(fā)現(xiàn)就是系統(tǒng)轉(zhuǎn)場動畫在搗亂。關(guān)掉之后數(shù)據(jù)穩(wěn)定多了優(yōu)化前后的對比也更有說服力。 鴻蒙React Native搜索頁卡頓優(yōu)化：useMemo緩存結(jié)果實戰(zhàn)
1. 搜索頁卡頓在鴻蒙端被放大了先還原現(xiàn)場我先把背景交代清楚。我們團隊在做資訊類App的鴻蒙適配React Native版本用的0.72通過HarmonyOS的RN適配層跑原生渲染鏈路。首頁、詳情頁遷移都算順利唯獨搜索頁在輸入關(guān)鍵詞時掉幀嚴重。測試機覆蓋了HarmonyOS 4.0的Mate 60 Pro和P40癥狀一致每次按鍵觸發(fā)列表重建滾動結(jié)果列表時卡頓明顯尤其是條目多、帶縮略圖的場景更煩人的是輸入法和列表渲染互相搶主線程打字本身都有遲滯感。這個問題在Android和iOS上不是沒有但沒那么刺眼。鴻蒙端的RN渲染鏈路比兩端多了一層中轉(zhuǎn)和橋接開銷主線程負荷一旦上來卡頓就被放大了。我一開始以為是鴻蒙適配層的性能問題查了一圈發(fā)現(xiàn)根子還是在業(yè)務代碼的渲染策略上——搜索頁在每次輸入變化時把整個結(jié)果列表的數(shù)據(jù)處理鏈路完整跑了一遍。這個場景正是React Hooks里useMemo最典型的用武之地搜索結(jié)果緩存的本質(zhì)就是把不隨輸入變化的計算擋在render之外。這篇文章不是入門教程而是實戰(zhàn)記錄。目標讀者應該是已經(jīng)在做React Native鴻蒙開發(fā)、對Hooks有基本了解、正在或即將處理列表渲染性能問題的同學。我會按問題現(xiàn)場—卡頓根因—useMemo原理—代碼改造—實測收益—鴻蒙端特有坑這條線完整梳理最后附帶我們踩過的一些額外經(jīng)驗。2. 卡頓根因render過程中的隱性計算成本2.1 React Native的render機制與列表重建先拆解一下為什么搜索頁會卡。React Native里state變化會觸發(fā)組件重新渲染所有依賴這個state的子組件也會跟著重新走一遍render流程。搜索頁的結(jié)構(gòu)大致是這樣一個SearchScreen組件持有searchText這個state輸入框每次變化都調(diào)用setSearchText底下掛著一個SearchResults組件接收搜索詞和原始結(jié)果數(shù)據(jù)SearchResults內(nèi)部把原始數(shù)據(jù)做過濾、排序、關(guān)鍵詞高亮、時間格式化、去重合并然后交給FlatList渲染問題就出在這個數(shù)據(jù)處理過程上。每次按鍵searchText一變整個SearchResults重新執(zhí)行內(nèi)部所有數(shù)據(jù)處理邏輯全部重算一遍。哪怕用戶只是從鴻字打到鴻蒙結(jié)果列表的原始數(shù)據(jù)根本沒變processResults這個純計算函數(shù)也會完完整整跑一趟。如果原始結(jié)果集有幾百條每條還要做字符串匹配和高亮片段切割這個計算耗時在低端機上就很可觀了。2.2 鴻蒙端為什么更敏感同樣的代碼在Android上可能只是輕微掉幀到鴻蒙上就變成明顯卡頓。原因有幾個層面第一鴻蒙的RN適配層目前仍在快速迭代渲染指令的批量處理和調(diào)度優(yōu)化不如Android/iOS成熟同樣的render工作量會產(chǎn)生更高的主線程占用。第二HarmonyOS的輸入法服務和應用主線程之間的調(diào)度協(xié)調(diào)和Android的InputMethod機制存在差異輸入事件處理的優(yōu)先級表現(xiàn)不同。一旦主線程被render任務占滿輸入事件的響應延遲會更明顯。第三搜索頁通常還伴隨鍵盤彈起、頁面轉(zhuǎn)場動畫、列表滾動等并發(fā)任務鴻蒙端的動畫渲染管線還在適配優(yōu)化中這些任務疊加時更容易互相擠壓。所以搜索頁在鴻蒙端對無效計算的容忍度更低。這也解釋了為什么同樣的性能問題我們是在鴻蒙適配階段才下決心徹底解決的。2.3 數(shù)據(jù)轉(zhuǎn)換操作的成本量級我專門把processResults的耗時拆開測過。一次處理300條搜索結(jié)果包含關(guān)鍵詞高亮切割每條要做字符串indexOf和slice拼接、相對時間格式化、來源去重合并在Mate 60 Pro上單次執(zhí)行大約12ms到25ms。聽起來不多但輸入一個關(guān)鍵詞通常要打4到6個字符每個字符觸發(fā)一次完整處理再加上FlatList對可見單元格的render每幀的JavaScript執(zhí)行時間輕松超過50ms。而React Native的UI更新需要和JavaScript執(zhí)行在同一幀內(nèi)完成超出16.6ms的幀預算就意味著掉幀。這些數(shù)據(jù)轉(zhuǎn)換都是純函數(shù)——輸入是原始結(jié)果集和搜索詞輸出是展示用的列表中間沒有任何副作用。純函數(shù)有個特點只要輸入不變輸出一定不變。那為什么每次都要重新算這正是useMemo能派上用場的地方。3. useMemo的原理用記憶化換掉無效計算3.1 從組件重新渲染說起useMemo是React提供的記憶化Hook。它的簽名長這樣const memoizedValue useMemo(() computeExpensiveValue(a, b), [a, b]);第一個參數(shù)是執(zhí)行計算的函數(shù)第二個參數(shù)是依賴數(shù)組。React會在首次渲染時執(zhí)行計算函數(shù)并把結(jié)果緩存起來。后續(xù)渲染時React會比較依賴數(shù)組里的每一項和上一次的值是否相同如果全部相同就直接返回上一次緩存的結(jié)果不再執(zhí)行計算函數(shù)只有某個依賴項發(fā)生變化時才會重新執(zhí)行計算。這里有個關(guān)鍵點React比較依賴用的是Object.is也就是引用相等。對于原始類型來說比較的是值對于對象和數(shù)組來說比較的是引用。所以useMemo的緩存失效條件本質(zhì)上是依賴的引用是否變化。3.2 搜索場景為什么完美契合回到搜索結(jié)果的場景。processResults(rawResults, query)這個函數(shù)有兩個輸入rawResults是請求返回的結(jié)果集query是搜索詞。用戶連續(xù)輸入鴻蒙這兩個字時發(fā)生了什么輸入鴻query從空字符串變成鴻處理一次輸入鴻蒙query從鴻變成鴻蒙再處理一次兩次之間rawResults的引用有沒有變大多數(shù)情況是沒有。搜索請求還沒有發(fā)出或者返回的數(shù)據(jù)還掛在state上沒有被替換。也就是說rawResults這個依賴始終保持同一個引用。那么問題來了query變化的時候rawResults并沒有變?yōu)槭裁疵看味家匦卤闅v幾百條數(shù)據(jù)做高亮切割如果processResults的計算邏輯能拆成不依賴query的預處理和依賴query的高亮處理兩個階段緩存的價值就更大了。不過實際項目里搜索結(jié)果的原始數(shù)據(jù)通常已經(jīng)經(jīng)過接口層的字段裁剪預處理空間不大真正值得緩存的是整個processedResults數(shù)組的生成過程。用useMemo改造之后的效果用戶從鴻打到鴻蒙第二次渲染時useMemo檢查依賴發(fā)現(xiàn)rawResults引用沒變query從鴻變成了鴻蒙依賴有變化所以還是重新執(zhí)行了。這一步看起來沒省多少。但如果用戶按退格鍵從鴻蒙刪到鴻這時候query從鴻蒙變回鴻useMemo照樣要重新算。那緩存的意義在哪關(guān)鍵在于另一個場景用戶輸入完關(guān)鍵詞結(jié)果列表渲染出來后可能因為鍵盤彈起、頁面布局變化、列表滾動等觸發(fā)父組件重新渲染。這些渲染和query、rawResults都沒關(guān)系但如果沒有useMemoSearchResults內(nèi)部的processResults會被白白重算。有了useMemo只要依賴不變這些額外渲染就完全跳過計算邏輯直接復用上次的結(jié)果數(shù)組。3.3 useMemo和useCallback、React.memo的配合實際工程里useMemo很少單獨出現(xiàn)。它經(jīng)常和React.memo、useCallback一起用useMemo緩存計算結(jié)果useCallback緩存函數(shù)引用React.memo阻止組件在props不變時重新渲染搜索列表場景里如果renderListItem是內(nèi)聯(lián)函數(shù)每次父組件render都會生成新引用FlatList的renderItem變化會觸發(fā)所有可見單元格重新渲染。這時候給ListItem組件包上React.memo再把renderListItem用useCallback包一層就能做到只有數(shù)據(jù)變化時才重渲染對應行。我在改造時一并做了收益疊加const renderListItem useCallback(({ item }) { return ListItem data{item} onPress{handlePress} /; }, [handlePress]);這里有個細節(jié)handlePress也必須用useCallback包住否則它本身引用變化renderListItem的緩存也會失效整個鏈路的記憶化就白做了。4. 代碼實戰(zhàn)搜索結(jié)果緩存的完整改造4.1 改造前的基線版本這是搜索頁最初的樣子我做了簡化但保留了核心邏輯const SearchScreen () { const [searchText, setSearchText] useState(); const [results, setResults] useState([]); const [isSearching, setIsSearching] useState(false); const handleSearch async (text) { setSearchText(text); if (text.trim().length 2) { setResults([]); return; } // 實際項目里有防抖邏輯這里省略 const res await fetchSearchResults(text); setResults(res); setIsSearching(false); }; return ( View style{styles.container} SearchInput value{searchText} onChange{handleSearch} / SearchResults query{searchText} rawResults{results} / /View ); };再看SearchResults的原始實現(xiàn)const SearchResults ({ query, rawResults }) { // 每次render都會完整執(zhí)行一遍 const processedResults processResults(rawResults, query); return ( FlatList data{processedResults} renderItem{renderListItem} keyExtractor{(item) item.id} keyboardShouldPersistTapshandled ListEmptyComponent{EmptyState /} / ); };processResults放在render函數(shù)體里直接調(diào)用這是性能隱患的源頭。React組件每次渲染都會執(zhí)行函數(shù)體不管rawResults和query是否變化。搜索頁里只要有任何state變化——比如鍵盤彈出、FlatList內(nèi)部狀態(tài)、父組件某個不相關(guān)的state——SearchResults都會重新render然后白白跑一遍完整的數(shù)據(jù)處理。4.2 processResults到底做了什么我把processResults拆出來單獨看方便說明緩存的粒度function processResults(rawResults, query) { if (!rawResults || rawResults.length 0) return []; // 1. 按時間倒序排序 const sorted [...rawResults].sort((a, b) b.timestamp - a.timestamp); // 2. 去重按內(nèi)容標題合并重復來源 const deduped []; const seen new Set(); for (const item of sorted) { const key item.title.trim().toLowerCase(); if (!seen.has(key)) { seen.add(key); deduped.push(item); } } // 3. 關(guān)鍵詞高亮切割依賴query return deduped.map((item) { const highlightParts []; if (query query.trim().length 0) { const lowerTitle item.title.toLowerCase(); const lowerQuery query.trim().toLowerCase(); let index lowerTitle.indexOf(lowerQuery); while (index ! -1 highlightParts.length 20) { highlightParts.push({ start: index, end: index query.trim().length, }); index lowerTitle.indexOf(lowerQuery, index query.trim().length); } } return { ...item, highlightParts, displayTime: formatRelativeTime(item.timestamp), }; }); }排序和去重完全不依賴query但它們隨每次render一起執(zhí)行。高亮部分依賴query但大多數(shù)時候用戶輸入過程中rawResults還沒更新高亮處理也在重復勞動。整個函數(shù)是純計算沒有副作用這給它放進useMemo提供了充分條件。4.3 用useMemo改造后的版本改動很小但語義變化很大import React, { useMemo, useCallback } from react; const SearchResults ({ query, rawResults, onItemPress }) { // 只在 rawResults 或 query 的引用/值變化時重新計算 const processedResults useMemo(() { return processResults(rawResults, query); }, [rawResults, query]); const handlePress useCallback((item) { onItemPress(item); }, [onItemPress]); const renderListItem useCallback(({ item }) { return ListItem data{item} onPress{handlePress} /; }, [handlePress]); return ( FlatList data{processedResults} renderItem{renderListItem} keyExtractor{(item) item.id} keyboardShouldPersistTapshandled ListEmptyComponent{EmptyState /} initialNumToRender{10} maxToRenderPerBatch{10} windowSize{5} / ); };幾個細節(jié)說明一下第一useMemo的依賴數(shù)組是[rawResults, query]。query是字符串React用值比較rawResults是數(shù)組React用引用比較。如果父組件每次setState都創(chuàng)建新數(shù)組哪怕內(nèi)容一模一樣useMemo也會失效。所以我在SearchScreen里刻意保持了resultsstate的引用穩(wěn)定只有接口返回新數(shù)據(jù)時才setResults(res)不做多余的set。第二onItemPress如果直接從父組件傳下來且沒有緩存handlePress的useCallback就會失效進而renderListItem失效FlatList的單元格每次都要重渲染。所以父組件的onItemPress也要用useCallback包一層。第三FlatList的initialNumToRender、maxToRenderPerBatch、windowSize這些參數(shù)在鴻蒙端也要顯式設置。后面我會單獨講鴻蒙適配的額外參數(shù)調(diào)優(yōu)。4.4 進一步拆分緩存的粒度useMemo的緩存粒度可以根據(jù)實際場景調(diào)整。如果processResults里的排序和去重計算量很大而高亮只依賴query可以拆成兩個useMemoconst sortedDeduped useMemo(() { return deduplicate(sortByTime(rawResults)); }, [rawResults]); const highlightedResults useMemo(() { return highlightKeyword(sortedDeduped, query); }, [sortedDeduped, query]);這樣當用戶快速修改關(guān)鍵詞時排序去重只依賴rawResults只要原始數(shù)據(jù)沒變就跳過高亮部分在query變化時重算。不過這個優(yōu)化要建立在排序去重確實昂貴的前提下。如果原始結(jié)果集只有幾十條拆分反而增加代碼復雜度收益可以忽略。我們的項目里搜索鏈路是輸入關(guān)鍵詞—防抖—請求—返回新結(jié)果rawResults本身更新不頻繁所以最終還是合并成一個useMemo代碼更清爽。5. 鴻蒙端實測Profiler數(shù)據(jù)與體驗對比5.1 Profiler記錄到的前后對比改造完成后我在鴻蒙真機上用React DevTools的Profiler跑了多次錄制。注意React DevTools連接鴻蒙端的RN應用方式和Android類似通過adb reverse把調(diào)試端口映射到設備上。測出來的數(shù)據(jù)很能說明問題。場景在搜索框輸入鴻蒙操作系統(tǒng)每輸入一個字符停頓片刻讓列表完成渲染。結(jié)果列表300條帶縮略圖。改造前的數(shù)據(jù)指標最低值最高值典型值單次render耗時98ms220ms140ms左右輸入響應延遲明顯遲滯卡頓感強每幀JS執(zhí)行約60-80msFlatList可見單元格render次數(shù)每次輸入全部重渲-10個左右單元格全部重渲改造后的數(shù)據(jù)指標最低值最高值典型值單次render耗時35ms75ms45ms左右輸入響應延遲基本跟手偶發(fā)輕微遲滯每幀JS執(zhí)行約20-30msFlatList可見單元格render次數(shù)僅輸入變化時重渲-10個左右單元格按需重渲為什么沒降到0因為FlatList可見區(qū)域的單元格仍然需要渲染renderListItem的執(zhí)行成本省不掉。但整個組件的JavaScript執(zhí)行時間降了一半以上原因是processResults不再被反復執(zhí)行主線程從每幀60-80ms的負荷降到20-30ms已經(jīng)低于16.6ms幀預算的2倍以內(nèi)。實際體驗就是打字跟手了列表滾動不再一卡一卡。5.2 輸入過程中原始結(jié)果集不變時的緩存命中最典型的收益場景是用戶連續(xù)輸入但還沒有新請求返回時。比如用戶快速輸入鴻蒙開發(fā)防抖時間內(nèi)其實只有一個請求被發(fā)出rawResults在整個輸入過程中可能只更新一次。沒有useMemo時每輸入一個字符都重新跑一遍幾百條數(shù)據(jù)的處理和排序有了useMemo這些中間態(tài)的渲染全部命中緩存直接返回上一次處理結(jié)果。這里有個反直覺的點即使在useMemo下query每次變化都會導致緩存失效重算。那省掉的計算到底是什么省掉的是因為鍵盤彈起、布局變化、FlatList內(nèi)部狀態(tài)變化等觸發(fā)的無關(guān)render。搜索頁在輸入過程中鍵盤高度變化、光標位置變化、甚至輸入法候選詞彈窗都可能觸發(fā)組件樹重新渲染這些渲染和數(shù)據(jù)處理沒有關(guān)系它們正是useMemo保護的對象。5.3 內(nèi)存占用的實測觀察我特意用DevTools的Memory面板觀察了useMemo改造后的內(nèi)存變化。緩存的數(shù)據(jù)是processedResults數(shù)組300條左右的結(jié)果條目每條包含原始字段和高亮切割數(shù)組占用大約幾百KB到1MB。持續(xù)輸入5分鐘后內(nèi)存曲線平穩(wěn)沒有出現(xiàn)緩存堆積的跡象。原因很簡單useMemo的依賴數(shù)組固定只有兩個緩存只會保留最近一次的計算結(jié)果不會累積歷史版本。這一點和useRef手動維護緩存完全不同后者如果忘記清理內(nèi)存會只增不減。6. 鴻蒙端適配過程中額外踩過的坑6.1 React Native版本與鴻蒙適配層的匹配問題我們的RN版本是0.72鴻蒙適配層用的對應版本。這里有個重要經(jīng)驗RN的0.72及以下版本useMemo的執(zhí)行語義和React 18是保持一致的但在鴻蒙適配層上部分做了并發(fā)特性裁剪的版本可能影響組件更新批處理效果。如果你發(fā)現(xiàn)useMemo改造后收益不明顯先確認適配層是否把React的Concurrent Mode相關(guān)邏輯完整移植了。鴻蒙適配層還在快速迭代不同版本的批處理策略有差異建議升到適配層官方推薦的RN版本不要自己停留在老版本上。6.2 白屏問題搜索頁打開鍵盤時偶發(fā)實測中發(fā)現(xiàn)一個高頻問題搜索框聚焦、鍵盤彈出時頁面出現(xiàn)白屏過一兩秒才恢復。這個和useMemo無關(guān)是KeyboardAvoidingView在鴻蒙端的適配問題。RN的KeyboardAvoidingView在Android上通常設置behavior{undefined}就能正常工作因為Android系統(tǒng)自帶adjustResize但鴻蒙端如果沿用這個配置鍵盤彈出時的窗口尺寸變化通知機制和Android不同可能導致頁面布局重算異常出現(xiàn)白屏。我們的解決方案是鴻蒙端不依賴KeyboardAvoidingView改用HarmonyOS原生的鍵盤避讓模式。在頁面配置里啟用安全區(qū)和鍵盤避讓然后移除RN層的KeyboardAvoidingView包裹。這樣鍵盤彈出時由系統(tǒng)層面處理窗口避讓RN層完全不用參與布局重算從根上避開了白屏問題。6.3 真機調(diào)試比模擬器更容易暴露問題在鴻蒙模擬器上測試輸入流暢度比真機好很多很容易得出性能沒問題的錯誤結(jié)論。原因是模擬器上CPU調(diào)度和GPU渲染都是虛擬化的主線程負荷模型和真機差異很大。我們所有性能優(yōu)化后的驗證都要求真機進行至少覆蓋一款麒麟芯片設備和一個中低端設備。最終優(yōu)化效果以真機為準模擬器只做功能驗證。6.4 HiLog定位JS層性能問題鴻蒙端的RN日志默認輸出機制和Android不完全一樣。在Android上ReactNative的JS console日志會打到Logcat里tag通常是ReactNativeJS。鴻蒙端除了Logcat兼容層還有自己的HiLog系統(tǒng)。我建議用HiLog抓取RN相關(guān)日志過濾關(guān)鍵詞如ReactNative、JS同時關(guān)注ArkTS和UI渲染相關(guān)的事件。定位性能問題的時候單看JS層耗時不夠還要對比Native側(cè)的渲染耗時因為鴻蒙端的渲染鏈路和Android端不同同樣的掉幀問題可能由不同層級的瓶頸引起。6.5 FlatList在鴻蒙端的參數(shù)調(diào)優(yōu)FlatList在鴻蒙端的表現(xiàn)和Android有細微差異主要是滾動事件分發(fā)和單元格復用的時機。我做了三個調(diào)整initialNumToRender從默認10降到8。鴻蒙端首屏渲染壓力大少渲染兩個單元格對首屏速度有幫助。maxToRenderPerBatch從默認10降到8。限制單批渲染的單元格數(shù)量避免主線程被一下子占滿。windowSize從默認21降到7?？s小渲染窗口減少離屏單元格的render和內(nèi)存占用。這三個參數(shù)配合useMemo的緩存讓列表滾動時的計算和渲染壓力都保持在低位。有一點需要注意windowSize降太低可能導致快速滾動時出現(xiàn)白屏占位我試過5滾動稍快就會出現(xiàn)空白最后定在7是性能和觀感的平衡點。7. 搜索結(jié)果緩存方案從useMemo延伸的思考7.1 什么時候不該用useMemo一定要明確一點useMemo不是免費的。它本身有內(nèi)存開銷依賴比較有計算開銷。如果processResults很短比如只是簡單filter一下幾十條數(shù)據(jù)單次執(zhí)行不到1ms那么useMemo的依賴比較成本加緩存管理成本可能比直接重新計算還高。React官方文檔也明確說過不要在沒有必要的情況下給所有計算都套上useMemo。我的判斷標準是單次計算超過1ms或者計算結(jié)果被多個子組件復用或者組件本身會頻繁因為無關(guān)state變化而重新渲染。滿足其中一個useMemo才值得用。搜索列表這個場景單次處理300條數(shù)據(jù)耗時12-25ms加上組件在鍵盤彈起、滾動時頻繁重渲染三個條件全中所以收益非常明顯。7.2 緩存的數(shù)據(jù)結(jié)構(gòu)要穩(wěn)定useMemo返回的數(shù)組引用如果被其他組件當作useEffect的依賴要特別小心。比如某個子組件接收processedResults在useEffect里根據(jù)這個數(shù)組的長度發(fā)起統(tǒng)計上報那么useMemo如果因為無關(guān)原因失效返回一個新數(shù)組即使內(nèi)容沒變子組件的useEffect也會重新觸發(fā)可能造成重復上報或重復請求。解決辦法是依賴數(shù)組的粒度要盡量準確不要因為父組件的無關(guān)state導致useMemo失效。同時如果子組件只依賴數(shù)組的某個派生值比如長度可以直接傳processedResults.length避免整個數(shù)組引用變化引發(fā)連鎖反應。7.3 和useRef手動緩存對比有人可能會問為什么不用useRef自己維護一個緩存對象寫法上確實可以const cacheRef useRef(null); const lastQueryRef useRef(); if (lastQueryRef.current ! query || cacheRef.current null) { cacheRef.current processResults(rawResults, query); lastQueryRef.current query; }這段代碼和useMemo效果接近但有個隱患手動緩存需要自己維護失效條件rawResults的引用變化很容易被忽略。useMemo把依賴聲明放在代碼里失效邏輯是聲明式的讀代碼的人一眼能看出這個緩存依賴哪些值。團隊協(xié)作時useMemo的可維護性明顯更好。手動緩存適合更復雜的場景比如需要同時維護多個歷史版本或者緩存結(jié)構(gòu)比單一數(shù)組復雜得多但這種場景在搜索列表里用不上。8. 從搜索頁到整個鴻蒙適配的性能優(yōu)化思路8.1 減少主線程負擔是統(tǒng)一方向搜索頁這個案例往大了說其實是鴻蒙適配性能優(yōu)化的一個縮影。鴻蒙端的RN適配層仍在成熟過程中很多在Android上不是問題的問題到鴻蒙上會暴露得更明顯。核心思路就一條盡可能減少主線程的無效工作。這條思路可以拆成多個落地手段useMemo減少無意義的計算任務useCallback穩(wěn)定函數(shù)引用減少子組件重渲染React.memo阻止props未變時的單元格重渲染FlatList參數(shù)調(diào)優(yōu)控制渲染窗口移除不必要的KeyboardAvoidingView讓系統(tǒng)處理鍵盤避讓這五個手段配合使用才把搜索頁的主線程負荷壓到可接受的范圍。只加一個useMemo不調(diào)整FlatList參數(shù)滾動時仍然可能卡只調(diào)FlatList參數(shù)不緩存計算結(jié)果輸入時仍然可能掉幀。性能優(yōu)化是系統(tǒng)工程不要指望單一手段解決所有問題。8.2 排查鏈路先確認瓶頸在哪一層鴻蒙端排查性能問題時我建議按這個順序來先用Profiler確認是JavaScript層計算量大還是Native層渲染耗時長。React DevTools的Profiler能明確看到每個組件的render耗時。如果JS層render耗時長看是數(shù)據(jù)處理邏輯耗時processResults這一類還是大量組件重復render。前者用useMemo后者用React.memo和useCallback。如果Native層耗時長看FlatList的渲染窗口、圖片加載策略、陰影/透明度等過度繪制。FlatList參數(shù)調(diào)優(yōu)在鴻蒙端尤其重要。最后檢查是否有隱性的全局問題比如KeyboardAvoidingView引發(fā)布局重算、導航轉(zhuǎn)場動畫阻塞主線程。我們在這個排查鏈路里走了不少彎路。一開始直接調(diào)FlatList參數(shù)效果有但不明顯后來用Profiler才發(fā)現(xiàn)數(shù)據(jù)處理邏輯才是主因補齊useMemo后才徹底解決。所以我的建議是先測量再優(yōu)化不要憑感覺下手。8.3 搜索場景可以繼續(xù)擴展的方向搜索結(jié)果緩存這個需求useMemo解決的是展示數(shù)據(jù)生成的緩存。如果再往前一步把接口返回的原始數(shù)據(jù)也緩存起來就能實現(xiàn)更完整的搜索體驗優(yōu)化用useRef或外部狀態(tài)管理庫緩存最近N次搜索詞對應的原始結(jié)果用戶重新輸入相同關(guān)鍵詞時先渲染緩存結(jié)果再靜默請求刷新輸入過程中快速切換關(guān)鍵詞配合AbortController取消過期請求這些擴展在實際項目中能進一步提升搜索頁的響應速度但復雜度也在上升。我的建議是先把useMemo緩存做好確認基礎(chǔ)體驗達標后再有針對性地做請求層緩存。如果一上來就做全套緩存方案排查問題時會多一層干擾。9. 寫在最后關(guān)于性能優(yōu)化的一些個人體會搜索頁的useMemo改造代碼改動量只有幾行但背后是整個團隊對鴻蒙端性能特性的理解沉淀。做RN鴻蒙適配這幾個月我最大的體會是鴻蒙端不是一個換殼Android它的渲染鏈路、調(diào)度策略、輸入法機制都有獨立的行為特性很多Android開發(fā)的經(jīng)驗可以平移但性能邊界需要重新摸索。如果只是把代碼跑通搜索頁能用但體驗粗糙把主線程負擔摳下來之后X頁才能真正達到可用以上的標準。useMemo是其中一個手段和它并列的還有useCallback、React.memo、FlatList參數(shù)調(diào)優(yōu)甚至鍵盤避讓策略。建議各位在鴻蒙適配過程中每遇到一個性能問題都先問自己這個耗時是計算引起的還是渲染引起的還是系統(tǒng)調(diào)度引起的答案不同解法完全不同。最后分享一個小技巧在鴻蒙真機上調(diào)試性能時把開發(fā)者選項里的動畫時長縮放全部關(guān)掉再進行Profiler錄制。這樣拿到的耗時數(shù)據(jù)是純渲染和計算時長不會被系統(tǒng)動畫干擾。我們最初在真機上測出的render耗時忽高忽低后來發(fā)現(xiàn)就是系統(tǒng)轉(zhuǎn)場動畫在搗亂。關(guān)掉之后數(shù)據(jù)穩(wěn)定多了優(yōu)化前后的對比也更有說服力。