去年做設(shè)備端業(yè)務(wù)和技術(shù)調(diào)研時(shí)我把團(tuán)隊(duì)里已有的 Flutter 代碼庫嘗試往 OpenHarmony 生態(tài)遷移第一個(gè)拿來練手的就是生活助手類 App 里的喝水提醒模塊每天到了設(shè)定時(shí)間彈一條通知用戶點(diǎn)一下記錄喝了多少水。聽起來就是一個(gè) Timer 加一個(gè)通知真開始做才發(fā)現(xiàn)這個(gè)功能橫跨了 Dart 層的狀態(tài)管理、鴻蒙原生通知與提醒代理、本地存儲(chǔ)、混合棧頁面生命周期而且每一步都跟 Android/iOS 上的習(xí)慣不太一樣。這篇文章就把我的完整實(shí)現(xiàn)思路和踩坑記錄整理出來適合想在 OpenHarmony 上復(fù)用 Flutter 代碼、或者準(zhǔn)備做鴻蒙端生活助手類應(yīng)用的開發(fā)者參考。1. 為什么在 OpenHarmony 上用 Flutter 做喝水提醒1.1 功能需求拆解喝水提醒聽上去簡(jiǎn)單實(shí)際拆開看有四個(gè)獨(dú)立的能力點(diǎn):定時(shí)調(diào)度、系統(tǒng)通知、數(shù)據(jù)記錄、狀態(tài)展示。定時(shí)調(diào)度決定什么時(shí)候觸發(fā)提醒通知決定提醒怎么觸達(dá)用戶數(shù)據(jù)記錄負(fù)責(zé)把每次喝水的時(shí)間、杯數(shù)存下來狀態(tài)展示則是首頁上的今日進(jìn)度、下次喝水倒計(jì)時(shí)這些 UI。任何一個(gè)環(huán)節(jié)都不能省而且它們之間的依賴關(guān)系是串行的:調(diào)度觸發(fā)通知通知被點(diǎn)擊后寫記錄記錄最終驅(qū)動(dòng) UI 刷新。還有一個(gè)隱性需求:提醒要盡量可靠。很多同類 App 只在應(yīng)用開著的時(shí)候用 Timer 彈對(duì)話框App 一旦被殺就徹底失聲了。對(duì)于喝水這種高頻剛需場(chǎng)景用戶要的是系統(tǒng)級(jí)的、App 不在前臺(tái)也能收到的提醒這就必須借助鴻蒙原生的提醒代理能力而不能只靠 Flutter 側(cè)的前臺(tái)計(jì)時(shí)器。1.2 為什么選擇 Flutter 而不是純 ArkTS 開發(fā)我在技術(shù)選型時(shí)反復(fù)權(quán)衡過純 ArkTS 開發(fā)方案。OpenHarmony 的聲明式 UI 框架這幾年迭代很快寫一個(gè)簡(jiǎn)單頁面完全不虛但如果團(tuán)隊(duì)已有成熟的 Flutter 業(yè)務(wù)代碼純 ArkTS 意味著所有業(yè)務(wù)邏輯、UI 組件、狀態(tài)管理方案全部重寫這個(gè)成本在項(xiàng)目啟動(dòng)階段幾乎不可接受。Flutter 的優(yōu)勢(shì)在于 UI 層完全自繪不依賴系統(tǒng)組件樹。這意味著頁面渲染邏輯在 OpenHarmony 上的行為和 Android 上幾乎一致遷移時(shí)主要改的是平臺(tái)通道和原生插件層而不是 Dart 業(yè)務(wù)代碼。對(duì)喝水提醒這個(gè)模塊來說真正涉及鴻蒙原生的地方只有通知調(diào)度和提醒代理其他全部是純 Dart 邏輯所以用 Flutter 做業(yè)務(wù)層、ArkTS 做宿主殼是最短路徑。1.3 混合棧架構(gòu)的整體設(shè)計(jì)OpenHarmony 的 HAP 應(yīng)用必須有一個(gè)原生殼入口Flutter 在里面只是頁面渲染引擎這跟安卓原生項(xiàng)目嵌入 Flutter 頁面的模式本質(zhì)上是一樣的只是宿主從 Android 工程換成了鴻蒙工程。我的架構(gòu)分成三層:宿主層:鴻蒙側(cè)的 MainAbility 負(fù)責(zé)應(yīng)用生命周期同時(shí)持有 Flutter 容器用于渲染首頁、統(tǒng)計(jì)頁等 Flutter 頁面。橋接層:MethodChannel 負(fù)責(zé) Flutter 調(diào)用鴻蒙原生能力比如發(fā)布通知、注冊(cè)提醒EventChannel 負(fù)責(zé)鴻蒙原生把通知點(diǎn)擊事件、提醒觸發(fā)結(jié)果回傳 Flutter。業(yè)務(wù)層:純 Dart 實(shí)現(xiàn)配置管理、記錄存儲(chǔ)、倒計(jì)時(shí)狀態(tài)、UI 刷新。選擇 MethodChannel EventChannel 組合的原因很直接:通知的發(fā)布是典型的單向調(diào)用適合 MethodChannel提醒被點(diǎn)擊、提醒觸發(fā)回調(diào)是持續(xù)產(chǎn)生的事件流EventChannel 更合適。如果只用一個(gè) MethodChannel 做輪詢不僅費(fèi)電而且很難做到實(shí)時(shí)性。2. 環(huán)境準(zhǔn)備與工程接入2.1 版本選型是第一個(gè)坑Flutter 官方主線目前并不直接支持 OpenHarmony需要拉取 OpenHarmony SIG 維護(hù)的 Flutter 分支。這個(gè)分支從官方 Flutter 倉庫 fork 出來持續(xù)跟進(jìn)上游版本同時(shí)維護(hù)了鴻蒙側(cè)的引擎適配和插件適配。我當(dāng)時(shí)沒有太在意版本匹配直接拉了一個(gè)較新的 Flutter 分支結(jié)果運(yùn)行flutter doctor時(shí)立刻觸發(fā)了一直被提到的警告:The current configured Flutter SDK is not known to be fully supported. Please ...這個(gè)警告的本質(zhì)是:本地 Flutter SDK 版本比當(dāng)前工程模板期望支持的版本要新工具鏈認(rèn)為存在未知的兼容性風(fēng)險(xiǎn)。網(wǎng)上很多人遇到這個(gè)提示就直接忽略了但我在實(shí)際調(diào)試中發(fā)現(xiàn)版本跨度大的時(shí)候真的會(huì)出現(xiàn)一些詭異的編譯報(bào)錯(cuò)問題往往很難查。我的建議是查看 SIG 分支的倉庫說明確認(rèn)它當(dāng)前跟蹤的是官方 Flutter 哪個(gè)穩(wěn)定版本然后讓本地分支跟工程模板保持同一基準(zhǔn)。2.2 創(chuàng)建鴻蒙工程并接入 Flutter 模塊創(chuàng)建工程的流程不算復(fù)雜但順序很重要。先在 DevEco Studio 里新建一個(gè) Empty Ability 工程作為宿主殼拿到包名和工程結(jié)構(gòu)之后再在這個(gè)工程里集成 Flutter 模塊。這里要注意不要在鴻蒙工程里直接flutter create因?yàn)?OpenHarmony 分支生成的模塊結(jié)構(gòu)跟普通 Flutter 工程不完全一樣最好按 SIG 倉庫的指引操作。接入的核心邏輯是:Flutter 代碼構(gòu)建出鴻蒙側(cè)可加載的產(chǎn)物宿主殼啟動(dòng)時(shí)把 Flutter 頁面掛載到指定的 Ability 上。你可以理解為鴻蒙的 HAP 是一個(gè)瀏覽器殼Flutter 是里面的頁面引擎兩者通過 build 階段生成的中間產(chǎn)物完成綁定。由于不同分支的產(chǎn)物格式有差異這一步我強(qiáng)烈建議直接照抄 SIG 倉庫 README 里的配置不要自己發(fā)揮。我當(dāng)時(shí)就是因?yàn)樯倥淞艘粋€(gè)依賴項(xiàng)導(dǎo)致運(yùn)行時(shí)一直報(bào)找不到 So 庫排查了兩天才意識(shí)到是產(chǎn)物沒打進(jìn) HAP。2.3 構(gòu)建配置中的兩個(gè)高頻報(bào)錯(cuò)構(gòu)建階段最常見的 Gralde 報(bào)錯(cuò)是:You are applying Flutters main Gradle plugin imperatively using the apply script method, which is not supported. Remove this apply statement ...這個(gè)報(bào)錯(cuò)出現(xiàn)在使用新版 Flutter Gradle 插件的工程里。舊版 Flutter 工程習(xí)慣在android/settings.gradle里用apply from的方式加載 Flutter 工具腳本新版插件要求改用pluginsDSL 聲明式加載兩者機(jī)制完全不同。我當(dāng)時(shí)的解決方式是把settings.gradle里的apply from拿掉改成:plugins { id com.android.application id dev.flutter.flutter-gradle-plugin }改完記得執(zhí)行一次 Gradle Sync并且讓本地的 Flutter SDK 路徑通過local.properties里的flutter.sdk明確指定。這個(gè)報(bào)錯(cuò)在鴻蒙分支上同樣會(huì)出現(xiàn)因?yàn)轼櫭?Flutter 分支沿用同一套構(gòu)建體系排查思路完全一致。3. 喝水提醒核心功能實(shí)現(xiàn)3.1 數(shù)據(jù)模型與本地存儲(chǔ)設(shè)計(jì)先把數(shù)據(jù)層定下來。喝水提醒要存兩類數(shù)據(jù):一類是用戶配置包括每日目標(biāo)杯數(shù)、每杯容量、提醒間隔另一類是每天的飲水記錄包含喝水時(shí)間戳和杯數(shù)。配置我用 SharedPreferences 存記錄我選擇以 JSON 文件方式存在應(yīng)用私有目錄這樣后續(xù)做歷史統(tǒng)計(jì)時(shí)更容易擴(kuò)展也不會(huì)被輕量存儲(chǔ)的 key-value 限制束縛。Dart 側(cè)的記錄模型很簡(jiǎn)單:class WaterRecord { final DateTime time; final int cupVolumeMl; WaterRecord({required this.time, required this.cupVolumeMl}); MapString, dynamic toJson() { time: time.toIso8601String(), cupVolumeMl: cupVolumeMl, }; factory WaterRecord.fromJson(MapString, dynamic json) WaterRecord( time: DateTime.parse(json[time] as String), cupVolumeMl: json[cupVolumeMl] as int, ); }配置類同樣用簡(jiǎn)單模型承載。這里有個(gè)小技巧:把目標(biāo)的dailyGoal用杯數(shù)而不是毫升數(shù)存儲(chǔ)避免用戶修改杯容量時(shí)歷史目標(biāo)跟著漂移。例如目標(biāo) 8 杯、每杯 200ml今天喝到 1200ml如果改成 250ml 每杯按毫升算就變成 4.8 杯了按杯數(shù)算則始終穩(wěn)定。這類細(xì)節(jié)點(diǎn)在生活類 App 里很影響用戶體驗(yàn)。3.2 雙重提醒調(diào)度策略提醒調(diào)度是整個(gè)模塊的核心我最終采用了前臺(tái)計(jì)時(shí)器和系統(tǒng)級(jí)提醒代理并行的方案。前臺(tái)計(jì)時(shí)器負(fù)責(zé)應(yīng)用存活期間的即時(shí)反饋。我用Timer.periodic每 30 秒檢查一次當(dāng)前時(shí)間是否命中提醒窗口命中就彈應(yīng)用內(nèi)對(duì)話框同時(shí)刷新首頁倒計(jì)時(shí)。不用固定時(shí)間的Timer是因?yàn)橛脩艨赡茈S時(shí)修改提醒間隔或關(guān)閉某段時(shí)間的提醒輪詢方式對(duì)配置變更的響應(yīng)最及時(shí)。Timer? _timer; void startReminderLoop() { _timer?.cancel(); _timer Timer.periodic(const Duration(seconds: 30), (timer) { final now DateTime.now(); if (_shouldNotifyNow(now) _checkCooldown(now)) { _triggerReminder(); } }); }_shouldNotifyNow里判斷當(dāng)前時(shí)間距上次喝水是否超過設(shè)定的間隔_checkCooldown保證同一時(shí)段不會(huì)重復(fù)轟炸用戶。這兩個(gè)判斷很關(guān)鍵不然用戶午休睡個(gè)覺起來手機(jī)上可能堆了十幾條提醒。系統(tǒng)級(jí)提醒用的是鴻蒙的提醒代理服務(wù)。這部分必須走原生側(cè)編碼因?yàn)閼?yīng)用進(jìn)程被清理后 Dart 代碼就停了只有系統(tǒng)級(jí)的提醒代理能保證觸達(dá)。我在鴻蒙側(cè)通過reminderAgentManager注冊(cè)一個(gè)定時(shí)提醒設(shè)置觸發(fā)時(shí)間和點(diǎn)擊后要跳轉(zhuǎn)的 Ability。這里要注意把提醒的wantAgent指向自己的應(yīng)用否則點(diǎn)擊通知后無法正確喚起頁面。3.3 MethodChannel 與 EventChannel 橋接原生能力Flutter 側(cè)通過 MethodChannel 調(diào)起鴻蒙原生提醒代理。通道名我用ohos_water_app/reminder方法名scheduleReminder參數(shù)帶上標(biāo)題、內(nèi)容和觸發(fā)時(shí)間戳:static const _reminderChannel MethodChannel(ohos_water_app/reminder); Futurevoid scheduleSystemReminder({ required String title, required String content, required DateTime triggerTime, }) async { await _reminderChannel.invokeMethod(scheduleReminder, { title: title, content: content, triggerTimestamp: triggerTime.millisecondsSinceEpoch, }); }鴻蒙側(cè)對(duì)應(yīng)實(shí)現(xiàn)時(shí)我用了ohos.reminderAgentManager:import reminderAgentManager from ohos.reminderAgentManager; export function scheduleReminder(title: string, content: string, triggerTime: number): void { const reminder { reminderType: reminderAgentManager.ReminderType.REMINDER_TYPE_TIMER, triggerTimeInSeconds: Math.floor((triggerTime - Date.now()) / 1000), actionItems: [ { title: 喝水, type: 0 } ], wantAgent: { pkgName: com.example.waterapp, abilityName: MainAbility } }; reminderAgentManager.publishReminder(reminder) .then((id: number) { console.info(reminder published: ${id}); }) .catch((err: Error) { console.error(publish reminder failed: ${err.message}); }); }triggerTimeInSeconds是按秒計(jì)算的相對(duì)時(shí)間不是絕對(duì)時(shí)間戳我一開始傳了絕對(duì)時(shí)間戳導(dǎo)致提醒提前了不知多少倍觸發(fā)調(diào)試時(shí)差點(diǎn)以為是鴻蒙系統(tǒng) bug。這個(gè)轉(zhuǎn)換關(guān)系在文檔里其實(shí)有寫但很容易被忽略。通知點(diǎn)擊事件的回傳我用了 EventChannel。鴻蒙側(cè)在用戶點(diǎn)擊通知的wantAgent回調(diào)里把信息通過 eventSink 發(fā)給 FlutterDart 側(cè)用receiveBroadcastStream監(jiān)聽:static const _clickChannel EventChannel(ohos_water_app/notification_click); void listenNotificationClick() { _clickChannel.receiveBroadcastStream().listen((event) { // event 里帶通知 id、點(diǎn)擊時(shí)間等 _onNotificationClicked(event); }, onError: (error) { // 通道斷開時(shí)處理 }); }這個(gè)設(shè)計(jì)讓日志記錄和統(tǒng)計(jì)變得非常順暢。用戶點(diǎn)了提醒通知原生側(cè)把事件推回 DartDart 側(cè)直接寫一條喝水記錄并刷新首頁整個(gè)過程沒有額外的輪詢成本。3.4 首頁交互與頁面狀態(tài)保持首頁 UI 我分了三塊:今日進(jìn)度環(huán)形圖、下次喝水倒計(jì)時(shí)、歷史記錄入口。狀態(tài)管理用的是 ValueNotifier 加自定義組合沒有引重量級(jí)狀態(tài)管理框架因?yàn)楹人嵝训墓蚕頎顟B(tài)并不多ValueNotifier 足夠且直觀。有一個(gè)坑必須重點(diǎn)說:底部Tab切換到統(tǒng)計(jì)頁再切回來首頁的倒計(jì)時(shí)不走了。這個(gè)問題正是熱詞里討論的flutter navigator切換頁面后會(huì)丟失狀態(tài)嗎。默認(rèn)情況下 Navigator 的 push/pop 會(huì)銷毀下層路由狀態(tài)不走常規(guī)保存邏輯倒計(jì)時(shí) Timer 自然就停了。解決辦法是給首頁加AutomaticKeepAliveClientMixin并且把底部 Tab 切換改成IndexedStack而不是反復(fù) push 新路由。IndexedStack 會(huì)同時(shí)保持所有子頁面的狀態(tài)配合 keepAlive 才能真正做到切換不丟計(jì)時(shí)器:class HomePage extends StatefulWidget { override StateHomePage createState() _HomePageState(); } class _HomePageState extends StateHomePage with AutomaticKeepAliveClientMixin { override bool get wantKeepAlive true; // build 方法中不要忘記 super.build(context) }這個(gè)操作雖然只是加一個(gè) Mixin但它直接決定了提醒功能在真實(shí)使用中可不可靠。如果用戶切一下頁面就把計(jì)時(shí)器丟了這個(gè)功能等于殘廢。3.5 記錄統(tǒng)計(jì)與連續(xù)天數(shù)歷史記錄我做了兩個(gè)維度:按天聚合的總杯數(shù)和一周趨勢(shì)。每天的數(shù)據(jù)從 JSON 文件里讀取按日期分組后渲染。連續(xù)喝水天數(shù)這個(gè)指標(biāo)稍微處理了一下:用戶可能凌晨喝完就直接跨天了所以我在判斷連續(xù)天數(shù)時(shí)允許當(dāng)天還沒結(jié)束時(shí)就算作連續(xù)中否則用戶會(huì)看到連續(xù)天數(shù)偶爾倒退。統(tǒng)計(jì)頁還順手處理了 TabBar 的默認(rèn)點(diǎn)擊動(dòng)畫。熱詞里有人在找flutter tabbar點(diǎn)擊取消動(dòng)畫效果我個(gè)人偏好切換更干脆的手感所以把 TabBar 的animationDuration設(shè)成了零同時(shí)監(jiān)聽了 TabController 的 index 變化來同步頁面內(nèi)容而不是依賴默認(rèn)的動(dòng)畫感知。這種細(xì)節(jié)在生活類工具里很影響主觀手感實(shí)際調(diào)試時(shí)值得花點(diǎn)時(shí)間。4. 常見問題與排查技巧實(shí)錄4.1 Flutter SDK 兼容性警告問題現(xiàn)象是開頭提到的The current configured Flutter SDK is not known to be fully supported警告。它本身不影響編譯但會(huì)讓人心慌而且確實(shí)可能在后續(xù)構(gòu)建中暴露 API 差異。處理思路是三步走:第一步查看項(xiàng)目模板要求的具體 Flutter 版本一般在pubspec.yaml或工程配置里能發(fā)現(xiàn)痕跡。第二步檢查當(dāng)前flutter --version輸出如果兩者差距過大把 Flutter 分支切換到與模板配套的版本。第三步跑一次flutter doctor -v確認(rèn) OpenHarmony 工具鏈識(shí)別正常再看警告是否消失。我最后發(fā)現(xiàn)是工程模板太舊升級(jí)模板依賴后就干凈了。4.2 構(gòu)建時(shí)的 AssertionError 與緩存問題熱詞里有人遇到過flutter打包 java.lang.assertionerror: java.lang.exception: could not close i...這類錯(cuò)誤。這個(gè)報(bào)錯(cuò)經(jīng)常讓人誤以為是代碼問題其實(shí)絕大多數(shù)時(shí)候是 Gradle 緩存或文件句柄異常。我的排查順序是:先執(zhí)行flutter clean和flutter pub get清除 Dart 側(cè)的緩存。再刪除鴻蒙工程下的build目錄和 Gradle 緩存目錄注意別刪錯(cuò)了。執(zhí)行./gradlew --stop干掉后臺(tái) Gradle 守護(hù)進(jìn)程釋放占用的文件鎖。重新構(gòu)建。如果重建還是失敗重點(diǎn)檢查工程路徑是否包含中文或空格以及資源文件里有沒有文件名帶特殊字符的圖片。這類問題在 Windows 和部分 CI 環(huán)境特別常見項(xiàng)目路徑稍微復(fù)雜一點(diǎn)就會(huì)引發(fā)資源讀取異常。4.3 Navigator 狀態(tài)丟失問題深入排查前面說的AutomaticKeepAliveClientMixin是主解法但實(shí)際還有更隱秘的場(chǎng)景:用戶在統(tǒng)計(jì)頁停留很久系統(tǒng)因?yàn)閮?nèi)存壓力回收了底層頁面結(jié)果切回首頁發(fā)現(xiàn)狀態(tài)還是丟了。這時(shí)只靠 keepAlive 不夠還需要在頁面initState里判斷是否有緩存的數(shù)據(jù)并重建狀態(tài)。我的做法是在首頁 State 里把倒計(jì)時(shí)目標(biāo)和下次提醒時(shí)間持久化到內(nèi)存緩存didChangeAppLifecycleState里監(jiān)聽?wèi)?yīng)用回到前臺(tái)事件如果發(fā)現(xiàn)計(jì)時(shí)器已經(jīng)停止就主動(dòng)重新啟動(dòng)。同時(shí)把喝水量、目標(biāo)等關(guān)鍵數(shù)據(jù)在dispose前寫入本地配置這樣即使頁面真的被銷毀恢復(fù)到前臺(tái)時(shí)也能無縫還原。4.4 第三方 Flutter 插件鴻蒙適配流程喝水提醒本身沒有用太多第三方插件但我在這個(gè)項(xiàng)目里順帶摸清了給平臺(tái)插件補(bǔ)鴻蒙適配的完整流程這個(gè)經(jīng)驗(yàn)對(duì)后續(xù)接入登錄、推送、地圖等插件非常有用。以某個(gè)提供原生能力的平臺(tái)插件為例適配鴻蒙的步驟是先在插件工程中新增鴻蒙原生實(shí)現(xiàn)新建繼承自平臺(tái)通道接口的類把 Android/iOS 原生方法重寫為鴻蒙 API 調(diào)用然后在插件的注冊(cè)入口把實(shí)現(xiàn)類掛上去最后在pubspec.yaml里聲明鴻蒙側(cè)的支持。流程本身不復(fù)雜難點(diǎn)在于大部分第三方插件的鴻蒙原生實(shí)現(xiàn)需要自己寫工作量和插件的復(fù)雜度成正比。所以在選型階段就要考察插件的社區(qū)維護(hù)情況盡量選那些已經(jīng)在公開倉庫里提供ohos目錄或harmonyos適配的版本而不是自己從零補(bǔ)全。4.5 常見問題速查表現(xiàn)象根因解決方案Flutter SDK 版本警告本地 SDK 與模板要求版本不一致對(duì)齊分支版本升級(jí)模板依賴Gradle 提示 apply 方式不支持新版插件要求 plugins DSL改用 plugins 塊聲明打包 AssertionErrorGradle 緩存損壞或文件句柄異常clean、刪 build、停 Gradle 守護(hù)進(jìn)程切 Tab 后計(jì)時(shí)器停路由狀態(tài)被銷毀IndexedStack KeepAlive提醒時(shí)間提前triggerTimeInSeconds 誤傳絕對(duì)時(shí)間戳改成相對(duì)秒數(shù)后臺(tái)無法提醒僅靠前臺(tái) TimerApp 被殺后失效使用 reminderAgentManager 系統(tǒng)提醒4.6 關(guān)于通知權(quán)限和用戶可見性最后提一個(gè)容易被忽略的細(xì)節(jié):鴻蒙系統(tǒng)的通知權(quán)限。用戶在系統(tǒng)設(shè)置里關(guān)掉通知后無論 Flutter 側(cè)還是提醒代理側(cè)都無法觸達(dá)用戶所以 App 首次啟動(dòng)時(shí)要主動(dòng)引導(dǎo)用戶開啟通知權(quán)限。我的做法是進(jìn)入設(shè)置頁時(shí)檢查通知權(quán)限狀態(tài)如果未授權(quán)彈一個(gè)引導(dǎo)對(duì)話框說明喝水提醒的場(chǎng)景然后調(diào)用鴻蒙側(cè)打開設(shè)置授權(quán)頁面。這個(gè)引導(dǎo)文案不能寫得太單薄要說明提醒用于記錄每日飲水目標(biāo)不會(huì)產(chǎn)生廣告類打擾授權(quán)率會(huì)明顯高一些。寫在最后就我個(gè)人而言在 OpenHarmony 上做 Flutter 開發(fā)最大的感受是功能本身不難難在版本組合和工具鏈的匹配。只要 Flutter 分支、鴻蒙 SDK、Gradle 插件三者版本對(duì)不上各種莫名其妙的問題就會(huì)接踵而至。如果你準(zhǔn)備走這條路我的建議是先照著 SIG 倉庫的 Release 分支配好一套可用組合鎖定版本后不要再隨意升級(jí)等業(yè)務(wù)跑通后再考慮版本滾動(dòng)。喝水提醒雖小但把 Flutter 與 OpenHarmony 之間的橋接路徑完整走通了:MethodChannel 調(diào)用原生能力EventChannel 回傳實(shí)時(shí)事件本地存儲(chǔ)管理業(yè)務(wù)數(shù)據(jù)混合棧頁面處理好生命周期。這個(gè)能力組合可以直接復(fù)用到番茄鐘、吃藥提醒、久坐提醒等一整套生活助手功能上后續(xù)要做的只是把調(diào)度層和通知層抽成公共模塊讓不同業(yè)務(wù)各自注冊(cè)提醒。希望這篇文章能幫你少踩幾個(gè)坑尤其在版本對(duì)齊和狀態(tài)保持上真的值得多花一點(diǎn)心思。