1. 一臺(tái)手機(jī)裝不下所有需求為什么“畫(huà)棧”要用Flutter去適配鴻蒙6.01.1 畫(huà)師接稿場(chǎng)景下頂部橫幅和快速入口到底承擔(dān)什么功能接稿平臺(tái)最怕什么我最怕畫(huà)師想找單子的時(shí)候頁(yè)面卡住或者委托人想進(jìn)約稿頁(yè)卻找不到入口。我在做“畫(huà)?！边@個(gè)畫(huà)師接稿平臺(tái)時(shí)把首頁(yè)兩個(gè)模塊看得特別重一個(gè)是頂部橫幅一個(gè)是快速入口。頂部橫幅承載的是運(yùn)營(yíng)位平臺(tái)活動(dòng)、熱門(mén)畫(huà)師推薦、約稿規(guī)則變更這些都要在用戶打開(kāi)App的第一屏展示出來(lái)快速入口則是功能分流器發(fā)布約稿、找畫(huà)師、作品管理、錢(qián)包提現(xiàn)這類高頻操作必須讓用戶一進(jìn)首頁(yè)就能點(diǎn)絕對(duì)不允許藏在層層菜單后面。這兩個(gè)模塊看起來(lái)簡(jiǎn)單但真放到“畫(huà)?！崩镒鼍蜁?huì)發(fā)現(xiàn)它們不是普通的輪播圖和宮格菜單。因?yàn)槟繕?biāo)用戶是畫(huà)師和約稿委托人訪問(wèn)時(shí)段跨度很大圖片素材又多橫幅如果加載慢或者輪播卡頓用戶直接劃走快速入口如果跳轉(zhuǎn)邏輯不夠清晰畫(huà)師會(huì)在約稿和作品之間反復(fù)橫跳體驗(yàn)會(huì)很糟。所以我從立項(xiàng)開(kāi)始就把這兩個(gè)模塊當(dāng)成獨(dú)立的小項(xiàng)目來(lái)設(shè)計(jì)而不只是寫(xiě)一個(gè)Widget糊上去。1.2 跨平臺(tái)選型評(píng)估原生雙端與Flutter的成本對(duì)比“畫(huà)?！鄙暇€時(shí)團(tuán)隊(duì)手里的資源很有限安卓、iOS都要覆蓋而目標(biāo)設(shè)備里又有相當(dāng)一部分是鴻蒙系統(tǒng)。市面上的跨端方案不少但我的選擇是Flutter加HarmonyOS 6.0這個(gè)組合。理由很簡(jiǎn)單Flutter的渲染引擎足夠統(tǒng)一能讓我用同一套Dart代碼去控制所有端的UI表現(xiàn)而HarmonyOS 6.0對(duì)Flutter應(yīng)用提供了完整兼容運(yùn)行環(huán)境只要我在原生工程里做好橋接業(yè)務(wù)層代碼基本不用為不同系統(tǒng)專門(mén)維護(hù)。對(duì)比原生雙端開(kāi)發(fā)成本差異很直觀。安卓iOS各寫(xiě)一套需要兩個(gè)人分別維護(hù)橫幅輪播和宮格布局UI細(xì)節(jié)還容易對(duì)不齊。用Flutter之后UI描述只有一份平臺(tái)適配集中在插件和路由層。當(dāng)時(shí)團(tuán)隊(duì)里有一個(gè)A同學(xué)他專門(mén)負(fù)責(zé)原生殼我負(fù)責(zé)Flutter業(yè)務(wù)層整個(gè)首頁(yè)模塊從設(shè)計(jì)到驗(yàn)收用了不到兩周。這個(gè)速度在原生雙端方案里幾乎不可能。當(dāng)然Flutter在鴻蒙上也不是零成本。鴻蒙的返回手勢(shì)、安全區(qū)特性和某些系統(tǒng)彈窗仍然需要單獨(dú)適配。這部分我在后面會(huì)詳細(xì)展開(kāi)。如果你也在做類似平臺(tái)我建議先不要被“一套代碼走天下”這句話迷惑而是要在選型階段就明確哪些層可以共享哪些層必須開(kāi)放原生通道。2. 頂部橫幅模塊數(shù)據(jù)協(xié)議、輪播機(jī)制和手勢(shì)調(diào)優(yōu)2.1 從后端接口到UI模型橫幅數(shù)據(jù)的協(xié)議設(shè)計(jì)頂部橫幅不能只是單純的一個(gè)圖片列表。在“畫(huà)?！表?xiàng)目里橫幅還承擔(dān)了跳轉(zhuǎn)動(dòng)作比如點(diǎn)擊橫幅要跳轉(zhuǎn)到某位畫(huà)師的主頁(yè)或者打開(kāi)一篇約稿規(guī)則說(shuō)明。如果接口只返回圖片URL前端就得硬編碼跳轉(zhuǎn)邏輯運(yùn)營(yíng)換一個(gè)運(yùn)營(yíng)位就得發(fā)版這是絕對(duì)不能接受的。所以我給后端提的協(xié)議里每條橫幅必須有四個(gè)字段橫幅ID、圖片地址、跳轉(zhuǎn)類型、跳轉(zhuǎn)參數(shù)。跳轉(zhuǎn)類型我用字符串枚舉表示比如artist_home表示畫(huà)師主頁(yè)article_detail表示文章詳情webview表示內(nèi)置網(wǎng)頁(yè)。跳轉(zhuǎn)參數(shù)是一個(gè)Map結(jié)構(gòu)可以放畫(huà)師ID、文章ID或網(wǎng)頁(yè)鏈接。這樣運(yùn)營(yíng)在后臺(tái)配置一條新橫幅時(shí)不需要改任何Flutter代碼。在Flutter端我建了一個(gè)很薄的模型類做JSON解析時(shí)放在fromJson里做兜底。圖片地址如果為空就顯示占位圖避免白屏。跳轉(zhuǎn)類型如果未知就只記錄日志不彈提示防止線上出現(xiàn)無(wú)法理解的行為。class BannerItem { final String id; final String imageUrl; final String title; final String linkType; final MapString, dynamic linkParams; const BannerItem({ required this.id, required this.imageUrl, required this.title, this.linkType , this.linkParams const {}, }); factory BannerItem.fromJson(MapString, dynamic json) { return BannerItem( id: json[id] as String? ?? , imageUrl: json[imageUrl] as String? ?? , title: json[title] as String? ?? , linkType: json[linkType] as String? ?? , linkParams: json[linkParams] as MapString, dynamic? ?? const {}, ); } }這段代碼是給團(tuán)隊(duì)協(xié)同用的后端同學(xué)只要按這個(gè)結(jié)構(gòu)返回前端就不會(huì)解析出錯(cuò)。我會(huì)在接口聯(lián)調(diào)前就把這個(gè)模型發(fā)到項(xiàng)目群里等后端接口一好直接跑通數(shù)據(jù)流。2.2 輪播實(shí)現(xiàn)PageView、定時(shí)器與手勢(shì)沖突的處理頂部橫幅輪播很多人第一反應(yīng)是用PageView.builder加一個(gè)Timer.periodic。這個(gè)方向沒(méi)錯(cuò)但直接這么干會(huì)踩到兩個(gè)坑。第一個(gè)坑是自動(dòng)輪播和手動(dòng)滑動(dòng)沖突用戶正準(zhǔn)備左滑時(shí)定時(shí)器又切到下一頁(yè)視覺(jué)上很打架第二個(gè)坑是無(wú)限循環(huán)的實(shí)現(xiàn)方式如果用PageView官方示例那種“首尾拼接”的方式在快速滑動(dòng)時(shí)會(huì)看到首尾直接跳變不夠順滑。我在“畫(huà)?！崩锊捎玫姆桨甘亲孭ageView有一個(gè)足夠大的itemCount比如10000并把初始頁(yè)設(shè)為5000。這樣做的好處是用戶無(wú)論怎么滑動(dòng)都不會(huì)觸達(dá)邊界視覺(jué)上就是無(wú)限循環(huán)。定時(shí)器在用戶按住屏幕時(shí)會(huì)暫停松開(kāi)后重啟。具體判斷手勢(shì)用NotificationListener監(jiān)聽(tīng)ScrollStartNotification和ScrollEndNotification在滾動(dòng)結(jié)束時(shí)重置定時(shí)器。自動(dòng)輪播有一個(gè)很關(guān)鍵的經(jīng)驗(yàn)不要在PageView的onPageChanged里直接setState去更新指示器那樣會(huì)把整棵Widget樹(shù)重建一遍導(dǎo)致圖片閃爍。正確做法是把當(dāng)前頁(yè)索引存到ValueNotifier里指示器用ValueListenableBuilder單獨(dú)監(jiān)聽(tīng)這樣只有指示器那一小塊會(huì)更新輪播主體不會(huì)被無(wú)謂重建。Timer? _autoPlayTimer; int _currentPage 5000; final ValueNotifierint _pageIndexNotifier ValueNotifier(5000); void _startAutoPlay() { _autoPlayTimer?.cancel(); _autoPlayTimer Timer.periodic(const Duration(seconds: 4), (timer) { if (_pageController.hasClients !_userInteracting) { final next _pageController.page!.round() 1; _pageController.animateToPage( next, duration: const Duration(milliseconds: 350), curve: Curves.easeOutCubic, ); } }); }關(guān)于時(shí)長(zhǎng)我試過(guò)3秒和5秒最后在4秒上定了稿。對(duì)畫(huà)師作品來(lái)說(shuō)太短看不清圖太長(zhǎng)又讓人等得不耐煩。還有一個(gè)小技巧如果當(dāng)前頁(yè)面的圖片還沒(méi)加載完定時(shí)器輪播過(guò)去了用戶會(huì)看到半張圖。我會(huì)在圖片加載完成前先顯示背景色避免白屏閃爍。2.3 圖片加載與緩存策略避免重復(fù)刷新和卡頓橫幅圖片是重災(zāi)區(qū)一張圖動(dòng)輒幾百K如果每次切頁(yè)都重新加載用戶流量和內(nèi)存都會(huì)爆。我在項(xiàng)目中直接使用cached_network_image包做圖片緩存緩存算法用默認(rèn)的LRU即可但有一點(diǎn)必須自定義內(nèi)存緩存的大小。鴻蒙設(shè)備上內(nèi)存管理比安卓更嚴(yán)格我把內(nèi)存緩存最大值限制在50MB磁盤(pán)緩存放在應(yīng)用私有目錄下。除了緩存容量還要考慮預(yù)加載。使用PageView時(shí)我設(shè)置了allowImplicitScrolling: true并且把cacheExtent調(diào)大。這樣相鄰兩頁(yè)的圖片會(huì)提前加載用戶滑動(dòng)時(shí)幾乎感覺(jué)不到等待。實(shí)測(cè)在早期版本里如果不做預(yù)加載每次切頁(yè)都會(huì)出現(xiàn)一個(gè)短暫的灰色占位加載完成后圖片突兀地跳出來(lái)非常影響觀感。還有一個(gè)容易忽略的點(diǎn)橫幅圖片不應(yīng)該直接用普通Image.network。因?yàn)镮mage.network不會(huì)在Widget銷毀時(shí)主動(dòng)釋放內(nèi)存還容易出現(xiàn)緩存策略不一致。統(tǒng)一走CachedNetworkImage之后內(nèi)存壓力明顯下降。我也給運(yùn)營(yíng)提了一個(gè)建議圖片不要超過(guò)1MB最好是WebP格式這樣居家網(wǎng)絡(luò)環(huán)境下也能較快加載。3. 快速入口模塊宮格布局、配置化路由和防誤觸設(shè)計(jì)3.1 入口配置化圖標(biāo)、文案、路由與權(quán)限的映射快速入口的難點(diǎn)不在UI排版而在于它背后的配置關(guān)系。在“畫(huà)?！崩锊煌脩艚巧吹降娜肟诓灰粯?。畫(huà)師身份需要“作品管理”“接單記錄”“錢(qián)包提現(xiàn)”委托人身份需要“發(fā)布約稿”“找畫(huà)師”“我的委托”。如果寫(xiě)死在代碼里每次權(quán)限調(diào)整都要發(fā)版。我采用的做法是把入口列表也做成接口下發(fā)前端拿到配置后渲染。每個(gè)入口在協(xié)議層就是一個(gè)QuickEntryItem包含入口ID、顯示名稱、圖標(biāo)URL、跳轉(zhuǎn)類型和權(quán)限標(biāo)識(shí)。權(quán)限標(biāo)識(shí)用來(lái)控制某個(gè)角色是否顯示該入口比如role: artist的入口對(duì)委托人角色就自動(dòng)隱藏。這個(gè)邏輯放在首頁(yè)加載時(shí)做不依賴后端過(guò)濾因?yàn)楹蠖瞬磺宄蛻舳说臓顟B(tài)細(xì)節(jié)。渲染時(shí)我建議不要用GridView.count寫(xiě)死列數(shù)而是根據(jù)最長(zhǎng)文案和屏幕寬度動(dòng)態(tài)算列數(shù)。入口圖標(biāo)我用Icon或Image都可以但需要注意如果入口圖標(biāo)是運(yùn)營(yíng)在后臺(tái)上傳的圖片那必須給Image設(shè)置加載狀態(tài)否則圖標(biāo)加載慢時(shí)會(huì)顯示空白用戶會(huì)以為入口壞了。所以在實(shí)現(xiàn)里每個(gè)入口都有一個(gè)imageUrl和兜底icon字段圖片加載失敗時(shí)自動(dòng)切換到內(nèi)置圖標(biāo)。class QuickEntryItem { final String id; final String title; final String iconUrl; final String linkType; final String linkValue; final String role; const QuickEntryItem({ required this.id, required this.title, this.iconUrl , this.linkType , this.linkValue , this.role , }); factory QuickEntryItem.fromJson(MapString, dynamic json) { ... } }這樣設(shè)計(jì)之后新增一個(gè)入口只需要改后臺(tái)配置前端無(wú)需發(fā)版。對(duì)“畫(huà)?！边@種快速迭代的平臺(tái)來(lái)說(shuō)這種靈活度很重要。3.2 布局細(xì)節(jié)從屏幕寬度到system文字縮放的約束快速入口的布局其實(shí)比想象中容易出問(wèn)題。常見(jiàn)做法是四個(gè)入口一行一屏顯示兩行。但鴻蒙和安卓都有系統(tǒng)字體縮放功能如果用戶把字體調(diào)成超大入口文字就會(huì)溢出到圖標(biāo)上布局直接崩掉。我在項(xiàng)目里做的處理是入口區(qū)域不直接使用TextScaleFactor跟隨系統(tǒng)而是手動(dòng)限制最大字號(hào)。每個(gè)入口卡片的寬度使用固定比例比如屏幕寬度的25%文字最多顯示一行超出部分省略號(hào)截?cái)??？ㄆ叨炔还潭ǘ歉鶕?jù)內(nèi)容自適應(yīng)最小高度設(shè)為64邏輯像素避免某些高度下圖標(biāo)和文字重疊。另一個(gè)細(xì)節(jié)是點(diǎn)擊區(qū)域。快速入口的圖標(biāo)和文字之間點(diǎn)擊熱區(qū)要盡量大但又不允許誤觸。如果整個(gè)卡片都用GestureDetector用戶在圖標(biāo)的邊緣點(diǎn)時(shí)可能觸發(fā)相鄰入口。我改用InkWell包裹并通過(guò)Behavior: HitTestBehavior.opaque來(lái)確保點(diǎn)擊命中的是當(dāng)前卡片區(qū)域。同時(shí)每個(gè)入口卡片之間留出12個(gè)邏輯像素的間距避免手指寬的用戶一次按到兩個(gè)入口。3.3 防誤觸和重復(fù)跳轉(zhuǎn)事件吸收與路由去重快速入口有一個(gè)讓我抓狂的Bug連續(xù)點(diǎn)擊同一入口會(huì)打開(kāi)兩個(gè)相同的頁(yè)面。尤其“發(fā)布約稿”這種頁(yè)面如果用戶手抖雙擊就會(huì)出現(xiàn)兩個(gè)編輯頁(yè)堆疊保存時(shí)還可能覆蓋數(shù)據(jù)。我在分析后發(fā)現(xiàn)問(wèn)題不在路由本身而在于Flutter的InkWell在快速點(diǎn)擊時(shí)會(huì)觸發(fā)多次onTap事件而路由跳轉(zhuǎn)又是異步的導(dǎo)致第一次跳轉(zhuǎn)還沒(méi)完成第二次就開(kāi)始了。解決辦法是加一個(gè)全局的導(dǎo)航守衛(wèi)。我在路由跳轉(zhuǎn)前維護(hù)一個(gè)_lastTapTime如果兩次點(diǎn)擊間隔小于500毫秒直接忽略。另外在頁(yè)面級(jí)維護(hù)一個(gè)“是否已經(jīng)打開(kāi)”的標(biāo)志比如利用RouteAware當(dāng)前頁(yè)面已經(jīng)在前臺(tái)時(shí)不允許再跳轉(zhuǎn)。這套防抖邏輯寫(xiě)完后重復(fù)跳轉(zhuǎn)的問(wèn)題徹底消失。防誤觸還不止重復(fù)跳轉(zhuǎn)一種情況。入口之間點(diǎn)擊區(qū)域相鄰有時(shí)候用戶想點(diǎn)“找畫(huà)師”結(jié)果點(diǎn)到了旁邊的“作品管理”。我用的是“點(diǎn)擊反饋延遲”方案按下時(shí)先顯示按壓效果等松手后如果手指還在當(dāng)前卡片內(nèi)才觸發(fā)跳轉(zhuǎn)。這樣即使手指滑動(dòng)了一點(diǎn)點(diǎn)也不會(huì)誤觸發(fā)。4. 鴻蒙6.0適配防坑安全區(qū)、圖片緩存與啟動(dòng)速度的實(shí)測(cè)處理4.1 狀態(tài)欄、劉海屏和底部手勢(shì)區(qū)的安全區(qū)問(wèn)題把Flutter應(yīng)用跑到HarmonyOS 6.0上第一個(gè)要認(rèn)真處理的就是安全區(qū)。鴻蒙手機(jī)頂部有狀態(tài)欄部分機(jī)型還有挖孔或劉海底部有手勢(shì)條。如果直接使用SafeArea包裹整個(gè)頁(yè)面頂部和底部雖然安全了但會(huì)出現(xiàn)難看的白邊背景色無(wú)法延伸到狀態(tài)欄特別不協(xié)調(diào)。我在“畫(huà)棧”的首頁(yè)采用了半沉浸式設(shè)計(jì)背景是品牌色內(nèi)容區(qū)從安全區(qū)邊緣開(kāi)始布局。具體做法是先獲取MediaQuery.of(context).padding.top再把橫幅和快速入口的容器設(shè)為從屏幕頂部開(kāi)始并給其內(nèi)部增加對(duì)應(yīng)的頂部?jī)?nèi)邊距。底部也類似給快速入口區(qū)域留出比系統(tǒng)手勢(shì)條略高的邊距保證手勢(shì)條滑動(dòng)時(shí)不會(huì)碰到按鈕。這里有一個(gè)經(jīng)驗(yàn)HarmonyOS 6.0的底部手勢(shì)條檢測(cè)并不完全等同于安卓的View.SYSTEM_UI_FLAG_LIGHT_NAVIGATION_BAR。Flutter層的MediaQuery在某些系統(tǒng)版本上返回的padding.bottom會(huì)偏小導(dǎo)致頁(yè)面內(nèi)容和手勢(shì)條重疊。我后來(lái)在原生殼工程里拿到真實(shí)的手勢(shì)條高度通過(guò)MethodChannel傳給Flutter側(cè)從而修正偏移。如果你的團(tuán)隊(duì)有原生開(kāi)發(fā)同學(xué)這個(gè)建議可以直接落地。4.2 路由跳轉(zhuǎn)和頁(yè)面生命周期與原生側(cè)手勢(shì)返回的約定Flutter應(yīng)用在鴻蒙上的路由架構(gòu)和純安卓有些區(qū)別。鴻蒙系統(tǒng)的返回手勢(shì)有兩種處理如果頁(yè)面是用Flutter自己的Navigator管理那么從屏幕邊緣右滑時(shí)Flutter能感知到并觸發(fā)返回但如果頁(yè)面里嵌入了原生View或者有原生插件手勢(shì)沖突就會(huì)出現(xiàn)。我在“畫(huà)?！钡目焖偃肟诶锓彩翘D(zhuǎn)到原生頁(yè)面比如打開(kāi)系統(tǒng)分享的場(chǎng)景都會(huì)先通過(guò)RouteAware把當(dāng)前路由的生命周期記錄下來(lái)。原生頁(yè)面返回時(shí)Flutter側(cè)會(huì)收到resume事件并刷新入口狀態(tài)。如果這一步不做用戶從原生頁(yè)返回后快速入口的上報(bào)埋點(diǎn)會(huì)丟失點(diǎn)擊統(tǒng)計(jì)不準(zhǔn)確運(yùn)營(yíng)就不知道哪個(gè)入口最受歡迎。另外導(dǎo)航守衛(wèi)不能只做防抖還要處理頁(yè)面壓棧關(guān)系。我用的是命名路由onGenerateRoute統(tǒng)一處理每個(gè)入口的跳轉(zhuǎn)目標(biāo)都聲明在路由表里避免直接傳遞Widget對(duì)象。這樣在鴻蒙上做頁(yè)面級(jí)內(nèi)存回收時(shí)路由棧能被系統(tǒng)正確管理減少頁(yè)面泄漏。4.3 啟動(dòng)速度與滾動(dòng)性能幀率分析和削減首幀工作量頂部橫幅和快速入口雖然只是幾個(gè)小組件但它們出現(xiàn)在首頁(yè)第一屏直接影響首幀渲染時(shí)間。如果等待這兩個(gè)模塊的網(wǎng)絡(luò)接口都返回后才渲染啟動(dòng)會(huì)明顯變慢。我在項(xiàng)目中做了一個(gè)分層加載策略先渲染頁(yè)面骨架再加載快速入口最后加載橫幅。頁(yè)面骨架是一個(gè)輕量級(jí)的占位視圖用FutureBuilder控制在獲取到配置前顯示。這樣用戶打開(kāi)App后第一時(shí)間看到的是品牌色背景和入口輪廓雖然圖片還沒(méi)加載但至少頁(yè)面不白屏。等到接口響應(yīng)后再填充橫幅和入口。通過(guò)這種方式首幀時(shí)間從原來(lái)的1.8秒降到了1.1秒左右。滾動(dòng)性能方面我監(jiān)控了橫幅的FPS。早期版本里每張橫幅都是全屏寬的高清圖滾動(dòng)時(shí)會(huì)掉到30幀。后來(lái)我限制了圖片尺寸不再使用原圖而是讓后端返回按設(shè)備寬度切割的縮略圖并設(shè)置gaplessPlayback: true滾動(dòng)終于穩(wěn)定在60幀。這里我強(qiáng)烈建議橫幅圖片一定要用服務(wù)端裁剪而不是客戶端等比縮放。5. 兩個(gè)讓我印象深刻的Bug排查鏈路輪播閃爍與快速入口重復(fù)跳轉(zhuǎn)5.1 輪播圖片閃爍問(wèn)題從現(xiàn)象反推到Widget重建根因輪播閃爍這個(gè)問(wèn)題我排查了一個(gè)下午?，F(xiàn)象是自動(dòng)輪播到下一張時(shí)圖片會(huì)閃一下白色接著才顯示完整圖片。一開(kāi)始以為是網(wǎng)絡(luò)圖沒(méi)緩存但后來(lái)發(fā)現(xiàn)即使圖片已經(jīng)在緩存里切換時(shí)依然會(huì)閃。于是我懷疑是PageView在重建頁(yè)面導(dǎo)致Image重新加載。后來(lái)我打印了BannerItem的hashCode發(fā)現(xiàn)每次輪播時(shí)頁(yè)面里的橫幅列表對(duì)象都會(huì)重新創(chuàng)建一次。原因出在FutureBuilder上因?yàn)楦讣?jí)每次setState時(shí)都會(huì)重建Future然后FutureBuilder進(jìn)入waiting狀態(tài)導(dǎo)致子頁(yè)面全部重建。解決辦法是把拿到的橫幅列表緩存到狀態(tài)管理對(duì)象里而不是每次都從Future獲取。這樣PageView的itemBuilder傳入的模型引用保持穩(wěn)定圖片ImageCache也能命中。這個(gè)坑也讓我意識(shí)到在寫(xiě)輪播時(shí)一定要區(qū)分“頁(yè)面重建”和“數(shù)據(jù)刷新”。輪播的數(shù)據(jù)只在接口返回后更新日常的自動(dòng)翻頁(yè)絕不能觸發(fā)數(shù)據(jù)層刷新。如果你的輪播也有類似閃爍先檢查父級(jí)Widget是否有不穩(wěn)定的狀態(tài)。5.2 快速入口連續(xù)點(diǎn)擊重復(fù)跳轉(zhuǎn)命中InkWell的事件風(fēng)暴重復(fù)跳轉(zhuǎn)的問(wèn)題前面提到了但排查鏈路值得展開(kāi)。最開(kāi)始我懷疑是Navigator.push反復(fù)執(zhí)行于是試著在onTap里加print結(jié)果發(fā)現(xiàn)一次手指點(diǎn)擊就觸發(fā)了三次onTap這很不正常。進(jìn)一步檢查原來(lái)問(wèn)題出在我用了Semantics相關(guān)配置某個(gè)無(wú)障礙手勢(shì)被同時(shí)解釋為兩次正常點(diǎn)擊加上InkWell和父級(jí)GestureDetector同時(shí)響應(yīng)導(dǎo)致事件風(fēng)暴。處理方法是給QuickEntryItem卡片只保留一個(gè)手勢(shì)識(shí)別者去掉外層無(wú)必要的GestureDetector。同時(shí)配合導(dǎo)航守衛(wèi)的500毫秒防抖問(wèn)題就穩(wěn)定了。我還把這個(gè)邏輯抽成了通用工具類DebouncedNavigator不只用于快速入口橫幅點(diǎn)擊跳轉(zhuǎn)也復(fù)用了它。這個(gè)教訓(xùn)總結(jié)下來(lái)就是事件處理要遵循“一個(gè)視圖只認(rèn)一種手勢(shì)”的原則。尤其是在鴻蒙系統(tǒng)上不同版本對(duì)手勢(shì)事件的分發(fā)策略有細(xì)微差異過(guò)度堆疊手勢(shì)判斷很容易出現(xiàn)奇怪的重復(fù)觸發(fā)。6. 我最后想分享的幾個(gè)細(xì)節(jié)做完這兩個(gè)模塊我最大的體會(huì)是頂部橫幅和快速入口雖然只是首頁(yè)的兩個(gè)“插件”但它們把產(chǎn)品運(yùn)營(yíng)、數(shù)據(jù)上報(bào)、圖片性能、路由管理全部串在了一起。如果你也在做跨端應(yīng)用我建議把這兩個(gè)模塊當(dāng)成獨(dú)立的“微前端”來(lái)設(shè)計(jì)每個(gè)模塊有自己的數(shù)據(jù)模型、狀態(tài)管理和路由配置這樣后面無(wú)論換系統(tǒng)還是加功能都能快速調(diào)整。另外HarmonyOS 6.0的適配不能靠猜。我建議在拿到真機(jī)之前先在Android和模擬器上把UI邏輯跑通然后再用鴻蒙真機(jī)驗(yàn)證安全區(qū)和手勢(shì)條。對(duì)于圖片緩存一定要在低端機(jī)上測(cè)試因?yàn)榈投藱C(jī)的內(nèi)存更容易爆掉。每個(gè)應(yīng)用的性能瓶頸不同但輪播閃爍和點(diǎn)擊重復(fù)跳轉(zhuǎn)這兩個(gè)問(wèn)題大概率會(huì)出現(xiàn)在Flutter開(kāi)發(fā)的首頁(yè)上先自查總比用戶反饋好。