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