買家具的時(shí)候拍胸脯記賬的時(shí)候拍腦袋。我自己的情況是餐桌、柜子、幾把椅子分散在三個(gè)電商平臺(tái)保修卡可能夾在抽屜或者早被扔掉。真到了“這把椅子什么時(shí)候買的、還能不能保修”的時(shí)候我翻聊天記錄和相冊翻了二十分鐘。后來逼自己做了個(gè)家具購買記錄App用Flutter跑在OpenHarmony設(shè)備上核心需求除了錄入、分類、到期提醒就剩一個(gè)“想找什么直接搜”。本來以為搜索功能是最簡單的寫個(gè)輸入框再加個(gè)List遍歷兩晚上能完事。結(jié)果真上手之后發(fā)現(xiàn)搜索這個(gè)功能做得好不好跟數(shù)據(jù)模型、交互細(xì)節(jié)、跨端適配、性能取舍全都掛鉤光是“怎么搜、搜什么、排序怎么排、中文分詞要不要做”這四個(gè)問題就夠喝一壺的。這篇就把我實(shí)現(xiàn)搜索功能的完整過程寫出來包括踩過的坑和最后改了三版才定下來的搜索策略。適合打算用Flutter給OpenHarmony做應(yīng)用、或者想把自己的工具類App搜索體驗(yàn)做扎實(shí)的開發(fā)者參考。1. 為什么“搜索”值得單獨(dú)設(shè)計(jì)需求拆解與技術(shù)選型1.1 用戶到底會(huì)怎么搜先搞清楚搜索詞長什么樣做搜索功能之前最忌諱的就是一上來寫代碼。我把自己關(guān)在房間里模擬了一個(gè)真實(shí)的“找記錄”場景半年前買過一張升降桌想查保修期我腦子里浮現(xiàn)出的第一個(gè)詞是“桌子”還是“升降桌”是品牌名“樂歌”還是“升降桌”都可能。更麻煩的是我可能根本不記得品牌名只記得“那是家京東買的”“花了大概兩千三”。你看用戶搜索的入口是極度模糊的不是數(shù)據(jù)庫查詢那種“輸入完整字段名再匹配”的邏輯。同理搜索還得考慮中英文混合的情況。比如我買過一把“Herman Miller”椅子記錄里的名稱是英文但我可能輸入“赫曼米勒”或者“人體工學(xué)椅”甚至還可能輸入“HM”——這就是多語言、多維度匹配的問題。我當(dāng)時(shí)把搜索場景拆成了幾類按物品名稱搜索、按品牌搜索、按購買渠道搜索、按金額范圍搜索、按日期范圍搜索以及“不知道字段只知道大概語義”的模糊搜索。前幾個(gè)是硬條件過濾最后一個(gè)是真正的“搜索”。這些需求直接決定了后面的數(shù)據(jù)模型怎么設(shè)計(jì)。1.2 技術(shù)方案選型內(nèi)存過濾還是數(shù)據(jù)庫全文檢索這個(gè)項(xiàng)目的數(shù)據(jù)量不會(huì)特別大撐死幾千條購買記錄所以我首先排除了上重量級(jí)全文檢索引擎的方案。很多技術(shù)團(tuán)隊(duì)一提到搜索就想到 Elasticsearch、SQLite FTS5、分詞器其實(shí)在小規(guī)模個(gè)人數(shù)據(jù)場景下屬于過度設(shè)計(jì)。但我也沒打算用最無腦的for循環(huán)遍歷匹配因?yàn)樗阉黧w驗(yàn)不只是“找得到”還要“找得快、排得準(zhǔn)”。我對(duì)比了三種方案方案A每次搜索實(shí)時(shí)遍歷內(nèi)存中的ListPurchaseRecord對(duì)每個(gè)字段做contains判斷。優(yōu)點(diǎn)是實(shí)現(xiàn)簡單缺點(diǎn)是字段一多、每次搜索都重復(fù)掃描數(shù)據(jù)到上萬條后幀率會(huì)明顯掉。方案B在啟動(dòng)時(shí)預(yù)計(jì)算一個(gè)“可搜索字段緩存”把名稱、品牌、備注等字段拼成一個(gè)長字符串搜索時(shí)統(tǒng)一匹配這一個(gè)字段。優(yōu)點(diǎn)是快缺點(diǎn)是丟失了“哪個(gè)字段命中了”的信息不好做高亮和排序。方案C數(shù)據(jù)量再大一點(diǎn)時(shí)直接上 SQLite FTS5用數(shù)據(jù)庫索引來做。最終我選了方案B的改進(jìn)版預(yù)計(jì)算緩存的同時(shí)保留每個(gè)字段獨(dú)立的可搜索項(xiàng)和命中權(quán)重。這個(gè)決定在后面排序打分章節(jié)會(huì)詳細(xì)講。搜索本身在內(nèi)存里完成但排序、高亮、狀態(tài)恢復(fù)這些體驗(yàn)細(xì)節(jié)可以做得非常精致。1.3 為什么選Flutter而不是原生開發(fā)項(xiàng)目跑在OpenHarmony上很多人會(huì)問為什么不直接用ArkTS開發(fā)原生應(yīng)用這其實(shí)是個(gè)務(wù)實(shí)的選擇Flutter生態(tài)我已經(jīng)積累了很多組件和經(jīng)驗(yàn)而且跨平臺(tái)意味著后續(xù)如果我想把App搬到Android、iOS上UI邏輯能復(fù)用八成以上。OpenHarmony目前對(duì)Flutter的官方適配已經(jīng)比較成熟常見的基礎(chǔ)Widget、列表、動(dòng)畫、事件通道都有對(duì)應(yīng)的實(shí)現(xiàn)項(xiàng)目跑通沒問題。不過也得說清楚Flutter跑在OpenHarmony上跟跑在Android上并不是百分之百一致尤其是底層系統(tǒng)能力調(diào)用、輸入法行為、文件路徑這些地方坑不少。后面我會(huì)專門用一整章來講我在OpenHarmony真機(jī)上踩到的適配問題。這也是為什么我把這個(gè)項(xiàng)目定位成“實(shí)戰(zhàn)”——不是官方Demo跑通了就算完是要真正去解決業(yè)務(wù)需求里的各種邊界情況。2. 數(shù)據(jù)模型與可搜索字段設(shè)計(jì)先把地基打結(jié)實(shí)2.1 核心字段設(shè)計(jì)不能只存“名字和價(jià)格”家具購買記錄如果只是存?zhèn)€名稱、價(jià)格、日期那搜索功能做上天也搜不出花來。我設(shè)計(jì)數(shù)據(jù)模型時(shí)參考了電商訂單和資產(chǎn)管理系統(tǒng)的做法每個(gè)購買記錄包含以下字段class PurchaseRecord { final String id; // 唯一ID用于編輯和狀態(tài)恢復(fù) final String name; // 物品名稱比如“升降桌”“人體工學(xué)椅” final String brand; // 品牌可能為空 final String category; // 分類桌、椅、柜、床、燈…… final String channel; // 購買渠道京東、淘寶、線下門店 final double price; // 成交價(jià)格 final DateTime purchaseDate; final DateTime? warrantyEnd; // 保修截止日期可能為空 final String notes; // 備注顏色、尺寸、訂單號(hào)等自由文本 final String imagePath; // 本地憑證截圖路徑 }這個(gè)模型最核心的點(diǎn)是notes字段不能小看。很多時(shí)候用戶真正能搜到東西的關(guān)鍵詞就在備注里比如“那款在宜家試過后來網(wǎng)購的白色桌面”。把這些自由文本納入搜索范圍召回率會(huì)顯著提升。圖像路徑我單獨(dú)放了一個(gè)字段是為了搜索結(jié)果顯示縮略圖時(shí)不必再去查文件系統(tǒng)。2.2 搜索索引緩存空間換時(shí)間的經(jīng)典用法每次搜索時(shí)實(shí)時(shí)遍歷所有記錄的每個(gè)字段不是不能跑但體驗(yàn)不夠干凈。我的解決思路是啟動(dòng)時(shí)構(gòu)建一份“搜索專用緩存”只做一次全量拼接之后所有搜索都在這份緩存上操作。class SearchIndex { final String recordId; final String allText; // 所有可搜索字段的小寫拼接 final String nameLower; final String brandLower; final String channelLower; final String notesLower; final num price; final DateTime date; }構(gòu)建這份索引后搜索時(shí)先快速用allText.contains(keyword)篩掉完全無關(guān)的記錄然后再對(duì)命中者逐字段計(jì)算權(quán)重和得分。這比直接遍歷原始對(duì)象快也方便排序。索引構(gòu)建有個(gè)細(xì)節(jié)toLowerCase()必須預(yù)先做避免搜索時(shí)對(duì)每個(gè)字符串反復(fù)調(diào)用這個(gè)操作在大量數(shù)據(jù)時(shí)相當(dāng)浪費(fèi)。中文不受大小寫影響但品牌、渠道、備注里都可能混著英文所以統(tǒng)一歸一化處理準(zhǔn)沒錯(cuò)。2.3 模擬數(shù)據(jù)與真實(shí)數(shù)據(jù)的一致性問題開發(fā)搜索功能時(shí)我一開始用模擬數(shù)據(jù)測試生成的家具名稱集中在“沙發(fā)”“桌子”“椅子”幾個(gè)詞結(jié)果搜索一切正常。上了真機(jī)錄入真實(shí)數(shù)據(jù)后出現(xiàn)了兩個(gè)問題一是備注里出現(xiàn)了我沒準(zhǔn)備的分詞比如“西昊 M18 人體工學(xué)椅 黑色”用戶可能搜“西昊”“M18”甚至“工學(xué)椅”二是同一個(gè)物品我在兩個(gè)平臺(tái)都買過名稱記錄方式不一樣一個(gè)叫“書柜”一個(gè)叫“收納柜”。這兩個(gè)問題的教訓(xùn)是測試搜索功能時(shí)模擬數(shù)據(jù)一定要包含“臟數(shù)據(jù)”——拼寫混寫、中英混排、字段缺失、分類口徑不一致。后來我把真實(shí)數(shù)據(jù)的脫敏版本導(dǎo)進(jìn)了開發(fā)機(jī)搜索邏輯才算經(jīng)得起考驗(yàn)。所以數(shù)據(jù)模型設(shè)計(jì)好后第一件事不是寫搜索代碼而是整理一批足夠“亂”的樣本數(shù)據(jù)。3. 搜索交互層搜索框、防抖與候選詞3.1 搜索框基礎(chǔ)搭建與清除按鈕搜索頁我用的是一個(gè)獨(dú)立的Flutter界面頂部是TextField下面是結(jié)果列表。看起來簡單但交互細(xì)節(jié)非常多。首先是清楚按鈕輸入后右側(cè)必須有一個(gè)“×”用來一鍵清空這個(gè)不能用TextField自帶的suffixIcon條件渲染來湊合而是要結(jié)合 focus 狀態(tài)和文本長度共同判斷。我見過很多App清除按鈕時(shí)隱時(shí)現(xiàn)點(diǎn)起來偶發(fā)失靈就是因?yàn)橹慌袛辔谋鹃L度沒判斷焦點(diǎn)。其次是輸入框的textInputAction設(shè)置成TextInputAction.search這樣鍵盤右下角會(huì)變成“搜索”按鈕。點(diǎn)擊搜索按鈕時(shí)收回鍵盤、觸發(fā)一次強(qiáng)制搜索繞過已有防抖這個(gè)細(xì)節(jié)后面解釋。最后建議給TextField包一層Autofocus: false不要把鍵盤自動(dòng)彈起來用戶體驗(yàn)上搜索頁自動(dòng)彈鍵盤太油膩了。3.2 輸入防抖的取舍300ms還是500ms實(shí)時(shí)搜索必須加防抖不加的話每個(gè)字符都會(huì)觸發(fā)一次全量搜索卡頓不卡頓先不說狀態(tài)和候選詞會(huì)瘋狂跳動(dòng)。我用的防抖工具是Timer包裝的Timer? _debounce; void _onSearchChanged(String keyword) { _debounce?.cancel(); _debounce Timer(const Duration(milliseconds: 300), () { _performSearch(keyword.trim()); }); }300ms是我對(duì)比后選擇的中間值中文輸入法在聯(lián)想階段不會(huì)瞬間上屏300ms足夠等用戶敲完一段短語“搜索”按鈕點(diǎn)擊時(shí)則強(qiáng)制取消防抖立即執(zhí)行。500ms聽起來更穩(wěn)但實(shí)際體驗(yàn)里“按一下鍵盤字已經(jīng)出來但結(jié)果還沒動(dòng)”的延遲感很明顯不適合工具類App。還有一個(gè)細(xì)節(jié)搜索關(guān)鍵詞要先trim()否則空格會(huì)導(dǎo)致結(jié)果列表神秘性全部為空尤其是用戶從其他App復(fù)制文本粘貼過來的時(shí)候。3.3 搜索歷史與候選詞別小看這兩個(gè)小功能搜索歷史是搜索頁體驗(yàn)的杠桿功能尤其對(duì)“保修期查詢”這種高頻重復(fù)場景。用戶可以輸入過一次“水龍頭”第二個(gè)月又壞了還想查沒有歷史就得重新輸入。我的實(shí)現(xiàn)是把搜索詞存到OpenHarmony的輕量級(jí)偏好數(shù)據(jù)庫里最多存10條去重后按時(shí)間倒序顯示成歷史標(biāo)簽。候選詞我做得比較克制。本來想實(shí)現(xiàn)“輸入拼音首字母就出候選詞”但中文拼音首字母匹配需要構(gòu)建詞庫成本高、收益有限我最終做的是“輸入部分詞匹配已錄入家具分類和常用品牌”把分類表里的“桌/椅/柜/床/燈/收納”和品牌表里的常見詞預(yù)加載輸入前兩個(gè)字符就給出下拉建議。這個(gè)功能在OpenHarmony上要注意列表彈出不要蓋住輸入法候選欄否則視覺上會(huì)閃跳。4. 核心搜索邏輯多字段匹配、打分與高亮4.1 多字段模糊匹配搜索邏輯的核心是“到底匹不匹配”。我針對(duì)不同字段采用不同策略名稱、品牌、備注、渠道子串匹配contains金額支持范圍查詢比如輸入“2000-3000”或“2000”觸發(fā)價(jià)格過濾日期支持“2024-05”這樣的月份匹配核心的函數(shù)長這樣bool _matches(SearchIndex idx, String query) { if (query.startsWith() || query.startsWith() || query.contains(-)) { return _matchPriceOrDate(idx, query); } return idx.allText.contains(query); }不過這個(gè)寫法是初始版跑起來后發(fā)現(xiàn)問題很多。比如allText.contains會(huì)把“桌”這種單字詞匹配到“書桌”但也會(huì)把“飯桌”這種本來不想召回的結(jié)果撈出來。這就引出了排序打分的問題——匹配要寬松排序要嚴(yán)格。4.2 排序打分為什么不能用“包含就行”這是我改版最明顯的一處。第一版只是“包含即返回”結(jié)果搜“桌”的時(shí)候數(shù)據(jù)庫里所有帶“桌”字的記錄全出來了排在第一位的不一定是我今天想找的那張升降桌體驗(yàn)非?；靵y。我參考了通常搜索引擎的思維方式針對(duì)這個(gè)業(yè)務(wù)場景設(shè)計(jì)了一套輕量打分規(guī)則double _score(SearchIndex idx, String query) { double score 0; if (idx.nameLower query) score 100; // 名稱完全相等 else if (idx.nameLower.startsWith(query)) score 80; // 名稱前綴 else if (idx.nameLower.contains(query)) score 60; // 名稱包含 if (idx.brandLower.contains(query)) score 30; if (idx.notesLower.contains(query)) score 10; if (idx.channelLower.contains(query)) score 5; return score; }權(quán)重設(shè)計(jì)的邏輯是名稱命中是最強(qiáng)的信號(hào)品牌命中次之備注和渠道只是弱信號(hào)。一條記錄可能在四個(gè)字段里都命中同一個(gè)詞那就累加得分比如名稱里有“桌”、備注里也有“桌”得分就會(huì)明顯高于僅在名稱里出現(xiàn)的記錄。排序時(shí)得分高的在前同分再按購買日期倒序。這個(gè)規(guī)則樸素但對(duì)幾百條記錄來說搜索結(jié)果準(zhǔn)確率已經(jīng)非常接近我想要的體驗(yàn)。把排序和打分放一起還有個(gè)好處是能對(duì)“完全沒匹配”做兜底。有些搜索詞確實(shí)不合理一個(gè)有“全家桶”精神的搜索功能這時(shí)候應(yīng)該給出的是“沒有找到相關(guān)記錄”而不是空白的白屏。4.3 關(guān)鍵詞高亮與Dart正則處理結(jié)果列表里高亮關(guān)鍵詞是搜索體驗(yàn)的標(biāo)配。高亮實(shí)現(xiàn)的基本思路是把你輸入的關(guān)鍵詞在展示文本中標(biāo)記出來我用RichText或者TextSpan來包。Dart里可以用RegExp.escape處理特殊字符避免用戶輸入[、(、*之類符號(hào)時(shí)正則爆炸。final escaped RegExp.escape(query); final pattern RegExp(escaped, caseSensitive: false);高亮?xí)r有個(gè)小坑如果同一個(gè)詞在一個(gè)字段里連續(xù)出現(xiàn)多次比如“桌子桌子”正則默認(rèn)只匹配第一個(gè)。要全局匹配需要給RegExp加上multiLine或者使用allMatches而不是firstMatch。另外高亮不應(yīng)該打斷原文本的大小寫信息要用文本片段的前后索引去定位高亮區(qū)間而不是簡單替換成大寫來顯示。Flutter的TextSpan拼接時(shí)還要注意overflow: TextOverflow.ellipsis的優(yōu)先級(jí)高亮后文本如果變長要保證省略號(hào)顯示在末尾。5. OpenHarmony適配記錄鍵盤、路徑與EventChannel5.1 輸入法上屏與鍵盤遮擋問題這個(gè)是我在OpenHarmony真機(jī)調(diào)試時(shí)遇到的第一塊硬骨頭。Android上常見的Scaffold(resizeToAvoidBottomInset: true)在OpenHarmony的Flutter適配版本里表現(xiàn)不完全一致?，F(xiàn)象是輸入法彈出來時(shí)搜索框被頂上去一點(diǎn)但結(jié)果列表底部還有一截被鍵盤蓋住滾動(dòng)到最后的記錄永遠(yuǎn)看不全。解決辦法有兩層。第一層是布局層面把搜索頁的根布局改成ScaffoldSafeArea并在輸入框聚焦時(shí)通過MediaQuery.of(context).viewInsets.bottom獲取鍵盤高度給結(jié)果列表底部加一個(gè)等高padding。第二層是要注意OpenHarmony輸入法的預(yù)編輯文本問題中文輸入法在聯(lián)想階段選字前TextEditingController的值可能包含未上屏的拼音字符。我在做防抖搜索前特意判斷了輸入法狀態(tài)在拼音拼寫階段不觸發(fā)搜索等真正上屏再執(zhí)行。這個(gè)判斷在Flutter層沒有直接的API我的做法是監(jiān)聽textInputConnection的setEditingState回調(diào)同時(shí)配合一個(gè)“連續(xù)輸入后300ms無變化才搜索”的防抖基本能規(guī)避誤搜。5.2 EventChannel與系統(tǒng)能力調(diào)用的跨端適配搜索功能本身不需要調(diào)用太深的系統(tǒng)能力但搜索歷史要持久化搜索結(jié)果里的憑證圖片要用本地文件路徑這就要跟原生層打交道。Flutter與OpenHarmony原生之間的雙向通信我用的是EventChannel因?yàn)橄啾萂ethodChannel它在實(shí)時(shí)事件回調(diào)上更順手。比如我需要在圖片文件發(fā)生變化時(shí)刷新搜索結(jié)果原生側(cè)可以主動(dòng)通過EventChannel把“文件更新了”的事件推給Flutter層Flutter收到后自動(dòng)重建搜索索引。這里有個(gè)適配上的細(xì)節(jié)OpenHarmony上獲取文件路徑的API跟Android不一樣。Android可以用getApplicationDocumentsDirectory()但OpenHarmony的目錄權(quán)限策略有自己的默認(rèn)路徑和沙箱規(guī)則。我的做法是在原生側(cè)寫一個(gè)小的橋接方法返回一個(gè)Dart側(cè)便于操作的路徑字符串。整個(gè)過程提醒我Flutter插件在OpenHarmony上并不都能直接跑用第三方插件前先查一下它是否已經(jīng)適配鴻蒙的API否則你在Android上跑得好好的換到OpenHarmony上就直接崩。5.3 真機(jī)vs模擬器架構(gòu)與性能差異搜索功能在模擬器上測試時(shí)一切流暢得讓我以為大功告成。上真機(jī)后直接被上了一課Flutter跑在OpenHarmony真機(jī)上尤其是在帶屏幕刷新率不太高的中低端設(shè)備上輸入法彈起和列表滾動(dòng)時(shí)的掉幀感很明顯。原因是模擬器走的是x86架構(gòu)指令集和渲染都在宿主機(jī)的GPU上而真機(jī)是arm架構(gòu)搜索時(shí)大量allText.contains的字符串匹配沒有經(jīng)過任何優(yōu)化全部跑在UI線程。這個(gè)問題的解法其實(shí)不該等到上真機(jī)才做。后來我把“索引構(gòu)建”這種重活放到了compute或Isolate.run里異步執(zhí)行輸入防抖搜索時(shí)不阻塞UI線程。索引構(gòu)建在啟動(dòng)時(shí)執(zhí)行一次全量拼接上千條記錄幾百毫秒完成但不開新線程會(huì)卡啟動(dòng)幀。我加了個(gè)遮罩層“正在準(zhǔn)備索引”后臺(tái)跑完再出結(jié)果頁面這個(gè)等待用戶幾乎無感。6. 性能調(diào)優(yōu)與實(shí)測對(duì)比6.1 三種搜索策略的實(shí)測數(shù)據(jù)開發(fā)過程中我記錄了三種搜索策略在真機(jī)上的性能表現(xiàn)數(shù)據(jù)量是模擬的兩萬條購買記錄策略平均單次搜索耗時(shí)兩萬條索引構(gòu)建耗時(shí)缺點(diǎn)實(shí)時(shí)遍歷原始對(duì)象約42ms0ms字段多時(shí)重復(fù)掃描幀率隱患預(yù)計(jì)算allText緩存約6ms約320ms丟失字段命中信息排序不精確預(yù)計(jì)算緩存字段權(quán)重打分約9ms約380ms需要額外設(shè)計(jì)打分邏輯我對(duì)這個(gè)結(jié)果很滿意。第三方案雖然比第二方案慢3毫秒但換來的是排序質(zhì)量和高亮信息的完整兩萬條數(shù)據(jù)下完全感覺不到差別。搜索這個(gè)功能性能目標(biāo)不是“最快”而是在“不被感知”的前提下做最準(zhǔn)的排序。同時(shí)索引構(gòu)建的380毫秒被放到了啟動(dòng)階段實(shí)際上用戶無感。6.2 大數(shù)據(jù)量下的卡頓排查與Isolate化有兩萬條數(shù)據(jù)之前我一度天真地認(rèn)為“搜索不需要優(yōu)化”。直到我導(dǎo)入了大約八千條真實(shí)歷史數(shù)據(jù)在真機(jī)上連續(xù)輸入“桌”字鍵盤每一鍵拖出來的延遲感非常明顯。排查過程有三個(gè)懷疑對(duì)象第一個(gè)是列表重建。結(jié)果列表用的ListView沒有加itemExtent關(guān)鍵詞高亮又導(dǎo)致構(gòu)建成本高我換成ListView.builder并給每項(xiàng)固定高度后滾動(dòng)明顯順滑。第二個(gè)是搜索本身。八千條記錄單次全量匹配大約要6毫秒不算致命但每輸入一個(gè)字符都觸發(fā)一次就會(huì)出現(xiàn)打字不跟手。第三個(gè)才是重點(diǎn)——搜索歷史寫入和讀取全是同步操作OpenHarmony的輕量偏好數(shù)據(jù)庫寫入一次可能就有幾十毫秒我還在建索引的隔離區(qū)之外直接進(jìn)行了偏好讀寫導(dǎo)致IO阻塞UI。修復(fù)方案就是我前面提到的把索引構(gòu)建和搜索這兩個(gè)計(jì)算密集型操作完全扔進(jìn)Isolate。Dart的Isolate.run在OpenHarmony的Flutter適配版里運(yùn)行穩(wěn)定返回值用普通的Future接收代碼上也不用改太多。注意隔離區(qū)里不能直接訪問數(shù)據(jù)庫需要把數(shù)據(jù)拷貝進(jìn)去所以我在調(diào)用前做了一個(gè)jsonEncode把記錄列表序列化后傳入。這個(gè)操作也有成本但只有啟動(dòng)時(shí)一次。6.3 滑動(dòng)、輸入、搜索三者的幀率權(quán)衡性能調(diào)優(yōu)有個(gè)不太容易被量化的維度交互場景的幀率平衡。搜索頁上同時(shí)存在鍵盤動(dòng)畫、列表滑動(dòng)動(dòng)畫、結(jié)果更新動(dòng)畫三者的GPU和CPU資源是共享的。我經(jīng)驗(yàn)是兩個(gè)原則一是結(jié)果列表僅在防抖結(jié)束后更新而不是輸入過程每幀都重建二是不要在高頻滾動(dòng)時(shí)執(zhí)行任何數(shù)據(jù)庫寫入操作比如“搜索歷史”要延遲到用戶點(diǎn)擊結(jié)果或者離開頁面時(shí)再寫避免和滾動(dòng)搶線程。還有一個(gè)細(xì)節(jié)是OpenHarmony上動(dòng)畫插值器的表現(xiàn)Flutter默認(rèn)的Curves.easeInOut在部分設(shè)備上會(huì)顯得“頓”搜索時(shí)的結(jié)果過渡動(dòng)畫我干脆用了200ms的淡入淡出減少持續(xù)的高頻計(jì)算。如果你在真機(jī)測試時(shí)感覺搜索頁“不算卡但說不出的別扭”先檢查這個(gè)動(dòng)畫時(shí)長往往不是性能問題是動(dòng)畫節(jié)奏跟系統(tǒng)不搭。收尾幾個(gè)我事后覺得值得記下來的選擇回看整個(gè)搜索功能的實(shí)現(xiàn)我最想提醒自己的是三件事。第一搜索不是“輸入框 plus 遍歷數(shù)組”它需要數(shù)據(jù)模型提前為搜索設(shè)計(jì)好可檢索字段需要索引、打分、高亮、歷史、候選詞這些細(xì)節(jié)共同支撐體驗(yàn)。第二Flutter在OpenHarmony上的適配問題遠(yuǎn)比我想象的多不要拿Android的開發(fā)習(xí)慣直接套用尤其是在鍵盤行為和文件路徑上一定留出真機(jī)調(diào)試時(shí)間。第三性能優(yōu)化要基于真實(shí)數(shù)據(jù)的數(shù)量級(jí)來判斷我做這功能之前覺得兩萬條購買記錄算非常多了真導(dǎo)完數(shù)據(jù)發(fā)現(xiàn)交給正確索引和打分邏輯后這點(diǎn)量完全不是負(fù)擔(dān)反過來如果一開始就按“大數(shù)據(jù)架構(gòu)”去設(shè)計(jì)反而會(huì)把簡單功能做復(fù)雜。按這個(gè)方案搜索功能的代碼核心邏輯差不多兩百行剩下的都是界面和適配工作。對(duì)于只在本地記錄幾百件家具的人來說穩(wěn)定、快、好找已經(jīng)足夠了。后續(xù)如果這個(gè)App真的被更多人用起來我再考慮把搜索歷史同步到云端或者引入拼音首字母匹配那就是另一個(gè)故事了。