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