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