這兩年做跨平臺開發(fā)的人應(yīng)該都有同一個(gè)感受鴻蒙生態(tài)起來之后原本一套代碼走天下的舒適區(qū)被打破了。Flutter和鴻蒙之間的關(guān)系從最初的觀望、爭議到如今真正能落地跑通我算是全程踩過來的。這篇就想結(jié)合我剛做完的一個(gè)真實(shí)項(xiàng)目——運(yùn)動(dòng)損傷防護(hù)知識APP把Flutter框架做鴻蒙跨平臺適配的完整開發(fā)流程從環(huán)境搭建、工程改造、組件通信到打包發(fā)布事無巨細(xì)地復(fù)盤一遍。這個(gè)項(xiàng)目的定位很清晰給運(yùn)動(dòng)愛好者、康復(fù)期人群、甚至基層教練提供一套結(jié)構(gòu)化的損傷防護(hù)知識庫包含風(fēng)險(xiǎn)評估問卷、急性處理RICE流程、復(fù)健動(dòng)作庫、訓(xùn)練強(qiáng)度建議等功能。用戶場景大多發(fā)生在球場邊、健身房、戶外跑步途中所以移動(dòng)端是第一優(yōu)先級而團(tuán)隊(duì)手頭又有現(xiàn)成的Flutter代碼庫主打一個(gè)跨平臺成本可控。如果你是打算入坑鴻蒙開發(fā)的Flutter工程師或者正在評估現(xiàn)有Flutter項(xiàng)目要不要適配鴻蒙、怎么適配這篇文章應(yīng)該能幫你省掉不少摸索的時(shí)間。1. 為什么選Flutter做鴻蒙運(yùn)動(dòng)防護(hù)APP選型思路與項(xiàng)目邊界首先要搞清楚一個(gè)核心問題鴻蒙應(yīng)用開發(fā)官方主推的明明是ArkTS和ArkUI為什么我還要繞一圈用Flutter1.1 跨平臺代碼復(fù)用的現(xiàn)實(shí)賬本我們團(tuán)隊(duì)之前已經(jīng)做了一版運(yùn)動(dòng)損傷防護(hù)APP跑在Android和iOS上功能覆蓋了損傷風(fēng)險(xiǎn)評估、圖文課程、視頻動(dòng)作庫、訓(xùn)練打卡記錄底層用的是Dart寫的一套領(lǐng)域模型和本地?cái)?shù)據(jù)庫。如果鴻蒙版本從零用ArkTS重寫意味著UI層、業(yè)務(wù)邏輯層、數(shù)據(jù)層三套代碼并行維護(hù)再加上后續(xù)版本迭代人力成本直接翻倍。對一個(gè)小型團(tuán)隊(duì)來說這不是技術(shù)棧好不好的問題是能不能活下來的問題。Flutter接鴻蒙的路徑本質(zhì)上是把OpenHarmony作為Flutter的一個(gè)新平臺Target來支持。社區(qū)里有專門的flutter_flutter適配分支通過Fork官方引擎并補(bǔ)充鴻蒙平臺的渲染層和平臺通道實(shí)現(xiàn)讓同一套Dart代碼可以編譯成鴻蒙的HAP包。對業(yè)務(wù)層來說幾乎不需要改動(dòng)——Model類、狀態(tài)管理器、數(shù)據(jù)庫操作這些純Dart邏輯是平臺無關(guān)的需要改動(dòng)的主要是原生插件層比如文件路徑、權(quán)限申請、設(shè)備信息獲取這類涉及平臺API的部分。1.2 鴻蒙適配的三種路線對比我把市面上能走的路子整理了一下大概有三條路線實(shí)現(xiàn)方式維護(hù)成本性能表現(xiàn)適用場景純ArkTS原生用DevEco Studio ArkTS完全重寫高最優(yōu)只做鴻蒙、追求極致體驗(yàn)Flutter OpenHarmony適配分支用Flutter引擎編譯到鴻蒙平臺中低良好已有Flutter代碼庫、需要快速覆蓋鴻蒙WebView/H5套殼網(wǎng)頁包一層原生殼低一般內(nèi)容展示為主、無復(fù)雜交互考慮到運(yùn)動(dòng)防護(hù)APP里有大量視頻播放、計(jì)時(shí)器、動(dòng)畫交互和本地?cái)?shù)據(jù)庫操作純H5套殼在流暢度上明顯不夠而純ArkTS重寫在檔期上又排不過來。Flutter適配分支就成了唯一兼顧成本與體驗(yàn)的選擇。實(shí)測下來Flutter渲染層在鴻蒙設(shè)備上確實(shí)有一定的首幀開銷但運(yùn)動(dòng)知識類頁面以列表、卡片、圖文混排為主不會(huì)觸發(fā)復(fù)雜的GPU密集型場景幀率穩(wěn)定性完全夠用。1.3 項(xiàng)目范圍的重新定義選型定了之后還需要把運(yùn)動(dòng)損傷防護(hù)知識APP這個(gè)產(chǎn)品需求翻譯成技術(shù)模塊。這一步很關(guān)鍵因?yàn)榭缙脚_項(xiàng)目的通病是什么都想干結(jié)果什么都干不深。我們的鴻蒙版本只保留了三個(gè)核心域風(fēng)險(xiǎn)評估問卷形式判斷用戶當(dāng)前的風(fēng)險(xiǎn)等級、知識庫損傷類型、處理流程、動(dòng)作庫條目、訓(xùn)練記錄打卡和進(jìn)度追蹤。砍掉了社交、直播、在線咨詢這類重運(yùn)營功能——這些功能需要大量原生平臺能力對鴻蒙適配來說會(huì)引入太多不可控變量。把邊界劃清楚后面的開發(fā)才不會(huì)被雜音干擾。2. 運(yùn)動(dòng)防護(hù)知識庫的建模思路從內(nèi)容體系到本地?cái)?shù)據(jù)庫設(shè)計(jì)這部分是整個(gè)項(xiàng)目的業(yè)務(wù)核心。運(yùn)動(dòng)損傷防護(hù)知識不是簡單的文章堆砌它有很強(qiáng)的結(jié)構(gòu)化特征損傷部位、損傷類型、處理階段、對應(yīng)動(dòng)作、風(fēng)險(xiǎn)等級之間是相互關(guān)聯(lián)的。我在建模時(shí)參考了運(yùn)動(dòng)康復(fù)教材里常用的損傷-評估-干預(yù)框架把它映射成了一套關(guān)系型數(shù)據(jù)模型。2.1 領(lǐng)域模型設(shè)計(jì)主要拆出了五張核心表injury_types損傷類型、body_parts身體部位、assessment_questions評估問卷題、training_actions復(fù)健動(dòng)作庫、treatment_stages處理階段。它們之間的關(guān)聯(lián)邏輯是這樣走的一個(gè)損傷類型比如踝關(guān)節(jié)扭傷屬于某個(gè)身體部位踝關(guān)節(jié)對應(yīng)一個(gè)評估問卷用于確認(rèn)嚴(yán)重程度關(guān)聯(lián)一組訓(xùn)練動(dòng)作按復(fù)健階段劃分每個(gè)階段又引用RICE等標(biāo)準(zhǔn)處理流程。為了在Dart側(cè)表達(dá)這種關(guān)系我用了一個(gè)非常樸素但好維護(hù)的方式——給每個(gè)實(shí)體類加上id和relatedIds然后用JSON序列化存在SQLite里。字段本身不搞復(fù)雜的對象引用嵌套查詢時(shí)用表關(guān)聯(lián)臨時(shí)組裝ViewModel。代碼如下class InjuryType { final int id; final String name; final int bodyPartId; final String description; final ListString keywords; final ListTreatmentStage stages; InjuryType({ required this.id, required this.name, required this.bodyPartId, required this.description, required this.keywords, required this.stages, }); factory InjuryType.fromJson(MapString, dynamic json) { return InjuryType( id: json[id] as int, name: json[name] as String, bodyPartId: json[bodyPartId] as int, description: json[description] as String, keywords: (json[keywords] as List).castString(), stages: (json[stages] as List) .map((e) TreatmentStage.fromJson(e as MapString, dynamic)) .toList(), ); } }2.2 離線優(yōu)先的存儲(chǔ)策略運(yùn)動(dòng)損傷防護(hù)知識的典型使用場景在健身房、戶外運(yùn)動(dòng)場網(wǎng)絡(luò)狀況很不穩(wěn)定。如果用戶在場邊扭了腳打開APP查RICE處理步驟卻發(fā)現(xiàn)轉(zhuǎn)圈加載那這個(gè)APP就廢了。所以我把內(nèi)容獲取設(shè)計(jì)成構(gòu)建期預(yù)置 運(yùn)行時(shí)更新的離線優(yōu)先策略。具體做法是APP首次安裝后從assets目錄讀取一份預(yù)置的JSON種子數(shù)據(jù)寫入本地SQLite當(dāng)網(wǎng)絡(luò)可用時(shí)后臺靜默檢查服務(wù)端版本號有新版本就把差異數(shù)據(jù)合并進(jìn)來。這套方案用sqlite3 sqflite就能實(shí)現(xiàn)不需要引入重量級同步框架。需要注意的坑是預(yù)置JSON體積控制在一兩MB以內(nèi)大體積文件會(huì)導(dǎo)致冷啟動(dòng)解析變慢內(nèi)容字段里如果包含Markdown格式解析時(shí)還要處理空行和轉(zhuǎn)義字符。2.3 知識條目狀態(tài)機(jī)設(shè)計(jì)有意思的是知識庫里的每個(gè)條目并不是靜態(tài)的。一個(gè)復(fù)健動(dòng)作在急性期是禁忌動(dòng)作在恢復(fù)期卻是關(guān)鍵訓(xùn)練。比如踝關(guān)節(jié)活動(dòng)度訓(xùn)練在扭傷后48小時(shí)內(nèi)是絕對禁止的但第4天開始就是必要的。所以我在training_actions表里加了一個(gè)phase字段表示這個(gè)動(dòng)作適用于哪個(gè)處理階段急性期、恢復(fù)期、功能訓(xùn)練期。用戶在詳情頁看到的不只是一個(gè)動(dòng)作演示而是帶時(shí)間窗的建議。這個(gè)狀態(tài)機(jī)設(shè)計(jì)在跨平臺代碼里用Dart的枚舉加工廠方法實(shí)現(xiàn)邏輯和UI完全解耦在鴻蒙和Android上表現(xiàn)完全一致。實(shí)測下來這種內(nèi)容隨傷情階段變化的設(shè)計(jì)遠(yuǎn)比單純的文章列表有辨識度也是這個(gè)APP最核心的價(jià)值點(diǎn)。3. 鴻蒙環(huán)境下的Flutter開發(fā)環(huán)境搭建從下載到真機(jī)調(diào)試的完整鏈路說句實(shí)話Flutter適配鴻蒙這事最大的技術(shù)門檻不在Dart業(yè)務(wù)代碼而在環(huán)境搭建和構(gòu)建鏈路的接通。這一節(jié)我把每一步怎么操作、哪些地方容易卡殼都寫清楚。3.1 開發(fā)工具鏈清單我用的這套工具鏈?zhǔn)墙?jīng)過實(shí)際驗(yàn)證的操作系統(tǒng)Windows 11macOS也能跑但部分步驟略有差異IDEDevEco Studio 5.0用于創(chuàng)建鴻蒙工程殼、編譯HAP包、真機(jī)調(diào)試Flutter SDK基于OpenHarmony適配分支的Flutter版本建議用穩(wěn)定版不要追betaJDK17DevEco Studio 5.0要求JDK 17低于這個(gè)版本在編譯階段會(huì)報(bào)錯(cuò)HarmonyOS SDKAPI 9以上的版本建議用API 11或12API版本太低會(huì)導(dǎo)致部分原生API缺失這里有個(gè)前置知識點(diǎn)Flutter跑鴻蒙的架構(gòu)方式是Flutter引擎編譯成native動(dòng)態(tài)庫嵌入到鴻蒙的Stage模型工程中。所以你不是在Flutter工程里選鴻蒙平臺而是先在DevEco Studio里建一個(gè)鴻蒙宿主工程再把Flutter模塊作為依賴集成進(jìn)去。理解了這個(gè)后面出任何構(gòu)建錯(cuò)誤你都不會(huì)慌。3.2 三步接入法第一步準(zhǔn)備鴻蒙宿主工程。在DevEco Studio里新建一個(gè)Empty Ability工程包名、版本號等信息要和Flutter模塊保持一致。這個(gè)工程負(fù)責(zé)承載應(yīng)用入口、權(quán)限聲明、原生能力調(diào)用。第二步拉取Flutter鴻蒙適配分支。在工程根目錄下把Flutter SDK換成適配分支的版本用命令行驗(yàn)證版本號flutter --version flutter doctor正常情況下flutter doctor會(huì)顯示Flutter版本和Dart版本但不會(huì)自動(dòng)檢測鴻蒙開發(fā)環(huán)境——這是正常的別慌。第三步把Flutter模塊作為依賴集成進(jìn)鴻蒙工程。在鴻蒙工程的entry/oh-package.json5中添加Flutter模塊依賴然后把Flutter編譯產(chǎn)物so庫和jar包放進(jìn)對應(yīng)目錄。到這里一個(gè)最小可運(yùn)行的Flutter鴻蒙工程就成立了。3.3 真機(jī)調(diào)試的兩個(gè)高頻報(bào)錯(cuò)我在真機(jī)調(diào)試階段遇到兩個(gè)報(bào)錯(cuò)幾乎每個(gè)做鴻蒙Flutter適配的人都會(huì)撞上。第一個(gè)是簽名問題真機(jī)安裝HAP時(shí)必須保證簽名證書已配置且與設(shè)備匹配否則會(huì)報(bào)install fail: sign verify failed。解決辦法是在DevEco Studio里配置自動(dòng)簽名用華為賬號登錄后讓IDE自動(dòng)生成調(diào)試證書。這一步不需要購買開發(fā)者賬號用個(gè)人賬號的調(diào)試證書就行。第二個(gè)是libflutter.so加載失敗鴻蒙版本的Flutter引擎動(dòng)態(tài)庫版本和宿主工程編譯版本不匹配會(huì)出現(xiàn)dlopen failed或cannot find symbol的報(bào)錯(cuò)。解決辦法是確認(rèn)Flutter模塊與OpenHarmony SDK版本一一對應(yīng)不要一個(gè)用API 9一個(gè)用API 12。這個(gè)坑很隱蔽我把版本對照表列出來Flutter適配分支版本對應(yīng)OpenHarmony版本推薦API級別3.7.xOpenHarmony 3.2API 93.10.xOpenHarmony 4.0API 103.22.xOpenHarmony 4.1以上API 11/123.4 DevEco Studio和Flutter命令行的分工日常開發(fā)中代碼編寫、熱重載、Dart分析交給Flutter命令行工具鏈工程配置、權(quán)限聲明、簽名、打包HAP交給DevEco Studio。我建議在IDE里配置好外部工具這樣可以直接在DevEco里調(diào)用flutter build命令不用來回切換終端。不過熱重載flutter run在鴻蒙設(shè)備上的響應(yīng)延遲比Android略高如果是頻繁改UI建議先用Android模擬器調(diào)樣式再同步到鴻蒙真機(jī)驗(yàn)證。4. 核心功能模塊拆解風(fēng)險(xiǎn)評估、急救指引與訓(xùn)練課程的實(shí)現(xiàn)接下來的幾個(gè)功能模塊是運(yùn)動(dòng)防護(hù)APP的內(nèi)容核心也是Flutter跨平臺能力的高光區(qū)。我在拆解的時(shí)候刻意將不同模塊用了不同的實(shí)現(xiàn)策略這樣既能驗(yàn)證鴻蒙適配的兼容性又能給后續(xù)復(fù)用做參照。4.1 風(fēng)險(xiǎn)評估基于癥狀組合的問卷邏輯與狀態(tài)管理風(fēng)險(xiǎn)評估模塊的邏輯是讓用戶完成一份包含12道題目的問卷題型分為三類身體部位選擇、疼痛癥狀勾選、運(yùn)動(dòng)頻率和強(qiáng)度選擇。根據(jù)回答結(jié)果系統(tǒng)會(huì)計(jì)算出一個(gè)風(fēng)險(xiǎn)等級低風(fēng)險(xiǎn)、中風(fēng)險(xiǎn)、高風(fēng)險(xiǎn)對應(yīng)不同的內(nèi)容推薦。這個(gè)模塊的技術(shù)重點(diǎn)是State Management。因?yàn)閱柧硎且粋€(gè)典型的多步驟表單用戶的實(shí)時(shí)答案、當(dāng)前步驟索引、每一題的選中狀態(tài)都需要在多個(gè)Widget間共享。我用的是Provider模式把問卷狀態(tài)放到了一個(gè)ChangeNotifier里class AssessmentState extends ChangeNotifier { int _currentStep 0; final Mapint, ListString _answers {}; int get currentStep _currentStep; Mapint, ListString get answers _answers; void selectAnswer(int questionId, ListString values) { _answers[questionId] values; notifyListeners(); } void nextStep() { _currentStep; notifyListeners(); } RiskLevel computeRiskLevel() { int score 0; _answers.values.forEach((values) score values.length); if (score 10) return RiskLevel.high; if (score 5) return RiskLevel.medium; return RiskLevel.low; } }設(shè)計(jì)得比較直白。這里我刻意沒有引入redux之類重武器原因有二一是問卷模塊的狀態(tài)邊界非常清晰用不上全局狀態(tài)管理二是Provider在鴻蒙上的狀態(tài)刷新鏈路和Android一致消息逐級往下通知不會(huì)出現(xiàn)不同平臺的狀態(tài)不同步問題。4.2 急救指引離線可用的分步流程頁急性損傷處理流程最適合做成分步卡片。我用一個(gè)全屏的PageView每一頁展示RICERest休息、Ice冰敷、Compression加壓、Elevation抬高的一個(gè)步驟。用戶右滑進(jìn)入下一步同時(shí)頂部用進(jìn)度條表示當(dāng)前位置。這里有個(gè)容易被忽視的細(xì)節(jié)用戶在球場邊看急救指引時(shí)很多人是單手操作甚至滿手是汗所以每一步的按鈕逐級放大頁面切換也用了手指滑動(dòng)的物理手勢不用精確點(diǎn)擊下一步按鈕。實(shí)測在鴻蒙設(shè)備上這個(gè)滑動(dòng)流暢感和Android完全一致因?yàn)镕lutter的手勢識別是引擎自繪的不依賴系統(tǒng)組件。離線能力上我把這四步的文字和圖示全部內(nèi)嵌在APP資源里服務(wù)端只負(fù)責(zé)更新版本。這樣即使完全斷網(wǎng)核心急救流程也不會(huì)失效。這是運(yùn)動(dòng)類APP的基本素養(yǎng)排查了好幾個(gè)競品后我發(fā)現(xiàn)能做到這點(diǎn)的其實(shí)不多。4.3 復(fù)健課程定時(shí)器與動(dòng)作庫聯(lián)動(dòng)復(fù)健課程的設(shè)計(jì)思路是動(dòng)作計(jì)時(shí)打卡。用戶選擇一個(gè)復(fù)健動(dòng)作后進(jìn)入訓(xùn)練頁頁面上方播放動(dòng)作拆解動(dòng)畫下方是一個(gè)倒計(jì)時(shí)器結(jié)束后自動(dòng)進(jìn)行下一個(gè)動(dòng)作所有完成記錄存入本地?cái)?shù)據(jù)庫。計(jì)時(shí)器這塊我用的是Flutter的Timer.periodic按秒遞減。這里必須處理兩個(gè)跨平臺問題一是頁面切到后臺時(shí)計(jì)時(shí)器穩(wěn)定性不一樣Android的進(jìn)程可能在后臺被壓縮而鴻蒙的后臺管理策略又不同二是頁面銷毀時(shí)如果不取消Timer會(huì)造成內(nèi)存泄漏。我的做法是在dispose里強(qiáng)制取消Timer同時(shí)記錄訓(xùn)練開始時(shí)間戳頁面恢復(fù)時(shí)用時(shí)間差重新計(jì)算剩余時(shí)間int remainingSeconds totalSeconds - (DateTime.now().difference(_startTime).inSeconds);這樣即使用戶中途切走再回來剩余時(shí)間也是準(zhǔn)的。鴻蒙上的后臺資源限制比Android要嚴(yán)格一些但這種基于時(shí)間戳的補(bǔ)償方案能規(guī)避大多數(shù)問題推薦所有計(jì)時(shí)類跨平臺需求都照這個(gè)思路處理。5. 組件通信與狀態(tài)管理Provider在鴻蒙多頁面場景下的實(shí)戰(zhàn)前面提到風(fēng)險(xiǎn)評估模塊用了Provider實(shí)際上組件通信是整個(gè)APP最值得深入聊的部分。鴻蒙平臺和Android最大的差異在于頁面棧的返回機(jī)制、異步任務(wù)的調(diào)度方式不同這對Flutter的跨頁面通信策略會(huì)產(chǎn)生微妙影響。我基于這次項(xiàng)目總結(jié)了一套可復(fù)用的通信模式。5.1 三層通信架構(gòu)我在項(xiàng)目里把通信鏈路分成三層頁面內(nèi)部Widget間通信用Provider的Consumer或Selector做局部刷新跨頁面通信用一個(gè)全局的AppState作為共享數(shù)據(jù)樞紐頁面銷毀不丟數(shù)據(jù)Flutter與鴻蒙原生層通信用MethodChannel調(diào)用平臺API如獲取設(shè)備信息、震動(dòng)提醒、通知欄推送第一層最簡單不展開。第二層是本次項(xiàng)目的精髓我單獨(dú)詳細(xì)說。5.2 全局AppState的設(shè)計(jì)運(yùn)動(dòng)防護(hù)APP有一個(gè)跨頁面強(qiáng)關(guān)聯(lián)的場景用戶在訓(xùn)練記錄頁打卡了一個(gè)動(dòng)作后回到知識庫首頁時(shí)該動(dòng)作對應(yīng)的已訓(xùn)練天數(shù)角標(biāo)需要實(shí)時(shí)更新。如果用普通的Navigator路由傳參這個(gè)更新邏輯會(huì)非常繁瑣如果用EventBus消息滿天飛后期維護(hù)會(huì)瘋掉。最終我用了全局AppState配合Provider的MultiProviderclass AppState extends ChangeNotifier { int _completedSessions 0; MapString, int _actionFrequency {}; int get completedSessions _completedSessions; void recordSession(String actionId) { _completedSessions; _actionFrequency[actionId] (_actionFrequency[actionId] ?? 0) 1; notifyListeners(); } } void main() { runApp( MultiProvider( providers: [ ChangeNotifierProvider(create: (_) AppState()), ChangeNotifierProvider(create: (_) AssessmentState()), ], child: const SportsInjuryApp(), ), ); }這個(gè)AppState注冊在應(yīng)用根部任何頁面都可以通過context.readAppState()觸發(fā)方法、通過context.watchAppState()訂閱變化。鴻蒙頁面棧退出時(shí)Flutter引擎實(shí)例并不會(huì)銷毀所以全局狀態(tài)天然保留和Android側(cè)的表現(xiàn)完全一致。這一點(diǎn)反而是鴻蒙的一個(gè)優(yōu)勢Activity可以銷毀重建但Flutter引擎是獨(dú)立于UIAbility存在的狀態(tài)更容易保持。5.3 Provider和ArkTS狀態(tài)管理的聯(lián)動(dòng)還有一個(gè)比較進(jìn)階的場景鴻蒙宿主原生側(cè)也會(huì)偶發(fā)需要觸發(fā)Flutter頁面更新的事件——比如系統(tǒng)權(quán)限彈窗返回結(jié)果、外部DeepLink拉起指定頁面。這個(gè)場景沒法純靠Provider解決需要走M(jìn)ethodChannel從原生側(cè)把事件傳到Flutter側(cè)再由Flutter側(cè)的EventBus或回調(diào)分發(fā)到Provider。我在項(xiàng)目里封裝了一個(gè)PlatformEventBridge的Dart類class PlatformEventBridge { static const MethodChannel _channel MethodChannel(sports_injury/events); static void init() { _channel.setMethodCallHandler((call) async { if (call.method refreshData) { AppState.instance.recordSession(call.arguments as String); } }); } }在鴻蒙原生側(cè)的寫法是用windowStage的loadContent接口拿到FlutterEngine后調(diào)用withModuleName獲取MethodChannel然后通過sendMethodCall把事件傳過去。這套鏈路打通后三個(gè)平臺的事件處理邏輯就統(tǒng)一了。我在鴻蒙上實(shí)測過原生側(cè)發(fā)送的消息延遲在毫秒級幾乎感知不到跨層通信的開銷。5.4 Provider的Hot Reload坑最后提醒一個(gè)實(shí)際開發(fā)中很容易踩的坑Provider在Hot Reload后偶爾會(huì)出現(xiàn)Duplicate provider found的報(bào)錯(cuò)。原因通常是全局MultiProvider和局部Provider重復(fù)創(chuàng)建了同一個(gè)實(shí)例。鴻蒙上的Hot Reload鏈路比Android更慢遇到這個(gè)報(bào)錯(cuò)時(shí)不要反復(fù)熱重載直接冷重啟最穩(wěn)妥。6. 打包發(fā)布與真機(jī)表現(xiàn)鴻蒙應(yīng)用市場的適配要求與性能觀測開發(fā)完功能之后還有一整個(gè)鏈路要打通打包HAP、上架鴻蒙應(yīng)用市場、真機(jī)性能調(diào)優(yōu)。我把這塊單獨(dú)拉出來講因?yàn)檫@是很多Flutter開發(fā)者初次接觸鴻蒙時(shí)最容易兩眼一抹黑的地方。6.1 HAP包的構(gòu)建流程及常見配置錯(cuò)誤HAP包是鴻蒙應(yīng)用的分發(fā)單元類似Android的APK。Flutter模塊集成到鴻蒙工程后構(gòu)建路徑是先構(gòu)建Flutter產(chǎn)物再構(gòu)建鴻蒙工程最后打包生成HAP。在DevEco Studio的構(gòu)建配置里有幾個(gè)容易踩的坑CPU架構(gòu)鴻蒙設(shè)備主要支持ARM64打包時(shí)建議只勾選arm64-v8a不用帶x86_64可以減小包體動(dòng)態(tài)庫依賴Flutter引擎的so文件必須隨包發(fā)布檢查entry/libs目錄下是否有l(wèi)ibflutter.so和libapp.so混淆配置鴻蒙支持代碼混淆但Flutter產(chǎn)物的so庫不要加混淆否則運(yùn)行時(shí)會(huì)崩潰我的構(gòu)建命令大致是這樣flutter build --release --target-platform ohos構(gòu)建結(jié)束后在entry/build/default/outputs/default/目錄下生成entry-default-signed.hap簽名完成后即可安裝到真機(jī)或上傳應(yīng)用市場。6.2 應(yīng)用市場上架材料清單上架鴻蒙應(yīng)用市場需要準(zhǔn)備的材料比Android略少但有幾點(diǎn)很嚴(yán)格隱私政策URL是必需的且必須能正常打開運(yùn)動(dòng)健康類應(yīng)用需要確認(rèn)是否存在醫(yī)療建議的敏感權(quán)限如果被判定為醫(yī)療健康類目需要補(bǔ)充資質(zhì)材料風(fēng)險(xiǎn)等級標(biāo)簽需要如實(shí)選擇不建議隱瞞聯(lián)網(wǎng)權(quán)限或位置信息我們的APP因?yàn)樯婕斑\(yùn)動(dòng)損傷風(fēng)險(xiǎn)評估被歸入了健康類目所以額外提交了一份軟件功能說明和免責(zé)聲明。這個(gè)環(huán)節(jié)建議提前規(guī)劃和準(zhǔn)備因?yàn)閷徍酥芷诒華ndroid應(yīng)用市場上架要長一些。6.3 真機(jī)下的性能觀測及參數(shù)調(diào)整性能這塊我整理了幾組實(shí)測對比數(shù)據(jù)都是同一臺鴻蒙設(shè)備開半屏亮度測的是知識庫列表頁和視頻動(dòng)作播放頁場景冷啟動(dòng)首次幀滾動(dòng)列表幀率視頻播放幀率內(nèi)存占用純Flutter頁面640ms58~60fps55~60fps142MB含圖片加載的詳情頁780ms55~58fps53~58fps168MB首幀時(shí)間比Android略高主要原因就是Flutter引擎在鴻蒙環(huán)境下的初始化加載so庫耗時(shí)要多一點(diǎn)。如果比較在意冷啟動(dòng)速度可以這樣優(yōu)化精簡首頁加載數(shù)據(jù)量把圖片資源改成WebP格式延遲初始化非首屏組件。我把首頁改成了優(yōu)先展示用戶本地緩存的概覽卡片跳過網(wǎng)絡(luò)請求后再加載詳情冷啟動(dòng)體感從還能接受進(jìn)步到基本無感。另外要特別留意一個(gè)鴻蒙特性系統(tǒng)的內(nèi)存回收策略比Android更激進(jìn)后臺運(yùn)行幾分鐘后大量圖片緩存可能被系統(tǒng)回收。在Flutter側(cè)不要在內(nèi)存里緩存太多的圖片位圖改用Image.network加寬高約束的懶加載方式或者使用cached_network_image插件時(shí)注意設(shè)置緩存上限。我在視頻動(dòng)作頁里就把縮略圖緩存數(shù)量控制在30張以內(nèi)頻繁切換動(dòng)作時(shí)回收效果穩(wěn)定。6.4 權(quán)限聲明和隱私合規(guī)最后提一嘴權(quán)限。鴻蒙生態(tài)對權(quán)限的管控比Android還要細(xì)尤其是運(yùn)動(dòng)健康類數(shù)據(jù)。我們的APP只申請了兩個(gè)高風(fēng)險(xiǎn)權(quán)限本地存儲(chǔ)用于保存訓(xùn)練記錄和網(wǎng)絡(luò)用于內(nèi)容更新。攝像頭和定位權(quán)限完全不需要一律不申請減少審核風(fēng)險(xiǎn)。務(wù)必在module.json5里把權(quán)限用途說明寫得清晰審核人員最反感籠統(tǒng)的用于用戶完善個(gè)人資料。我寫過的最敷衍版本是讀取存儲(chǔ)權(quán)限以提升用戶體驗(yàn)結(jié)果被駁回過一次。把權(quán)限說明改成具體場景后一次通過。做完這個(gè)項(xiàng)目我的最大感受是Flutter適配鴻蒙這條路早就不是嘴上談兵的狀態(tài)了。只要把環(huán)境鏈路的版本對應(yīng)關(guān)系摸透、把原生通信的橋接機(jī)制理清純Dart側(cè)的代碼幾乎可以無縫跑起來。運(yùn)動(dòng)防護(hù)APP這個(gè)項(xiàng)目不大但恰好覆蓋了表單狀態(tài)、離線知識庫、視頻播放、計(jì)時(shí)器、跨頁面通信這幾個(gè)跨平臺開發(fā)的典型難點(diǎn)。如果你正在做類似的知識科普類或工具類APP這套流程完全可以平移過去。真要再往前一步的話下一步我會(huì)把折疊屏適配和表盤端同步做進(jìn)去鴻蒙在這兩塊的生態(tài)讓利比Android大得多值得提前占坑。