做 Flutter on OpenHarmony 開(kāi)發(fā)有一段時(shí)間了踩過(guò)不少坑也淌出幾條能走的路。今天把生活助手 App 里的“收入分析統(tǒng)計(jì)”模塊拆開(kāi)講從選型、工程接入、核心邏輯到平臺(tái)通道適配完整過(guò)一遍。如果你正好想把 Flutter 項(xiàng)目跑在 OpenHarmony 設(shè)備上或者只是想把收入統(tǒng)計(jì)這類(lèi)功能做得像樣一點(diǎn)這篇內(nèi)容應(yīng)該能幫你省下不少排查時(shí)間。這年頭做跨端 App已經(jīng)不是“Android 一套、iOS 一套”就夠了OpenHarmony 設(shè)備的覆蓋面越來(lái)越廣生態(tài)里又有大量現(xiàn)存 Flutter 組件和邏輯可以直接復(fù)用。收入分析統(tǒng)計(jì)這個(gè)功能看起來(lái)只是“加幾個(gè)餅圖、折線圖”但真正落地上手會(huì)發(fā)現(xiàn)數(shù)據(jù)模型怎么設(shè)計(jì)、月度環(huán)比怎么算、分類(lèi)占比怎么聚合、圖表在 OpenHarmony 上字體不亂、頁(yè)面切換后狀態(tài)不丟這些都是實(shí)打?qū)嵉募?xì)節(jié)。我用的技術(shù)組合是 Flutter UI Dart 業(yè)務(wù)邏輯 OpenHarmony 原生能力通道下面把我實(shí)際跑通過(guò)的方案分享出來(lái)。1. 為什么是 Flutter 加 OpenHarmony項(xiàng)目背景與選型思路1.1 我為什么把一個(gè)生活助手App的統(tǒng)計(jì)模塊放在這套組合上先說(shuō)背景。我做的是一個(gè)生活助手方向的 App早期版本只在 Android 上跑后面產(chǎn)品要覆蓋更多設(shè)備形態(tài)包括帶屏幕的辦公終端、智能家居中控屏、學(xué)習(xí)平板這類(lèi) OpenHarmony 設(shè)備。重新用原生語(yǔ)言寫(xiě)一套顯然不現(xiàn)實(shí)團(tuán)隊(duì)里 Flutter 的積累又最多所以最終定了 Flutter for OpenHarmony 這條路。選擇 Flutter 的原因很直白收入分析統(tǒng)計(jì)頁(yè)面里有大量圖表、日歷、彈窗、表單交互跨端復(fù)用成本最低。Flutter 的渲染層是自繪的不依賴(lài)系統(tǒng) WebView 或原生控件在 OpenHarmony 上只要能把 Flutter 引擎跑起來(lái)頁(yè)面顯示效果就基本是所見(jiàn)即所得不會(huì)出現(xiàn)同一套代碼在 Android 上正常、到鴻蒙設(shè)備上控件全變樣的問(wèn)題。OpenHarmony 對(duì) Flutter 的支持現(xiàn)在也不再是“實(shí)驗(yàn)品”狀態(tài)。官方倉(cāng)庫(kù)持續(xù)在推同步版本插件機(jī)制方面也有完整的方法通道和事件通道可以做原生能力橋接。收入統(tǒng)計(jì)功能本身不重但要讀取本地賬單、把 CSV 導(dǎo)出到系統(tǒng)下載目錄、以后可能還要監(jiān)聽(tīng)文件變化自動(dòng)導(dǎo)入這種跨端能力必須靠原生側(cè)配合Flutter 加 OpenHarmony 的組合反而成了剛需。1.2 收入統(tǒng)計(jì)模塊的需求切分與功能清單動(dòng)手寫(xiě)代碼前我把需求拆成了四層數(shù)據(jù)層、計(jì)算層、展示層、平臺(tái)能力層。很多開(kāi)發(fā)者在做統(tǒng)計(jì)功能時(shí)一上來(lái)就畫(huà)圖表結(jié)果數(shù)據(jù)模型亂掉后面算環(huán)比、算占比全得返工。數(shù)據(jù)層管理收入記錄的增刪改查字段包括金額、分類(lèi)、發(fā)生日期、備注、所屬賬戶(hù)。計(jì)算層按月/按周匯總計(jì)算環(huán)比增長(zhǎng)、日均收入、分類(lèi)占比、最高單筆。展示層首頁(yè)統(tǒng)計(jì)卡片、收入趨勢(shì)折線圖、分類(lèi)占比餅圖、明細(xì)列表。平臺(tái)能力層通過(guò) MethodChannel 導(dǎo)出 CSV通過(guò) EventChannel 監(jiān)聽(tīng)外部賬單文件的導(dǎo)入事件。這四個(gè)層分開(kāi)做的好處是后面即使把 UI 從“統(tǒng)計(jì)卡片式”改成“日歷熱力圖式”計(jì)算層和平臺(tái)能力層完全不用動(dòng)。我實(shí)際寫(xiě)下來(lái)收入分析統(tǒng)計(jì)模塊的核心工作量其實(shí)不在圖表組件上而在數(shù)據(jù)聚合和時(shí)間范圍處理上這個(gè)后面會(huì)詳細(xì)講。2. 工程搭建與OpenHarmony接入指南2.1 用哪條Flutter分支OpenHarmony版本不能隨便選OpenHarmony 上的 Flutter 開(kāi)發(fā)最勸退新手的一步是環(huán)境版本匹配。直接flutter create一個(gè)普通工程再硬塞進(jìn) DevEco Studio 里大概率是構(gòu)建失敗錯(cuò)誤信息五花八門(mén)有的報(bào)Unsupported有的報(bào)Could not resolve all task dependencies。我的建議是用 OpenHarmony 官方適配過(guò)的 Flutter SDK 分支不要用谷歌原版 Flutter 直接上。原因很簡(jiǎn)單原版 Flutter 的 Android/iOS 工具鏈里沒(méi)有 ohos 平臺(tái)模板也沒(méi)內(nèi)置 OpenHarmony 的構(gòu)建產(chǎn)物邏輯跑起來(lái)必然缺東西。工程里幾個(gè)關(guān)鍵版本要鎖死Flutter SDK 版本、OpenHarmony SDK 版本、DevEco Studio 版本。我第一次就是 Flutter 用新版本、DevEco 用舊版本結(jié)果編譯時(shí)原生側(cè)接口對(duì)不上。后來(lái)統(tǒng)一換成同一個(gè)發(fā)布周期內(nèi)的版本組合問(wèn)題立刻消失。建議按官方發(fā)布說(shuō)明里給出的搭配表走更新版本前先查兼容矩陣省得返工。2.2 創(chuàng)建工程并生成ohos入口的完整步驟初始化工程時(shí)我用的是帶ohos平臺(tái)標(biāo)識(shí)的方式。命令大致是flutter create --platforms ohos,android,ios -t app income_report_app如果你的 Flutter 分支還不認(rèn)識(shí)ohos這個(gè)平臺(tái)名就手動(dòng)創(chuàng)建一個(gè)普通的 Flutter 工程然后在工程根目錄補(bǔ)一個(gè)ohos目錄。OpenHarmony 應(yīng)用的標(biāo)準(zhǔn)入口是ohos/entry/src/main里面會(huì)有一個(gè)module.json5控制應(yīng)用模塊配置這個(gè)文件相當(dāng)于 OpenHarmony 側(cè)的 AndroidManifest。把工程導(dǎo)入 DevEco Studio 時(shí)要注意DevEco 打開(kāi)的是整個(gè)工程根目錄不是只打開(kāi)ohos子目錄。導(dǎo)入后先同步一下依賴(lài)讓 hvigor 把原生構(gòu)建腳本跑通再回到終端執(zhí)行flutter build ohos --debug第一次構(gòu)建會(huì)下載不少依賴(lài)耗時(shí)較長(zhǎng)。我遇到過(guò)一次構(gòu)建到一半報(bào)網(wǎng)絡(luò)超時(shí)重試后通過(guò)屬于正常情況。2.3 第三方插件在ohos側(cè)的取舍插件是跨端開(kāi)發(fā)里最容易翻車(chē)的環(huán)節(jié)。我在收入統(tǒng)計(jì)模塊里用到的插件主要有三類(lèi)圖表繪制、本地存儲(chǔ)、文件路徑獲取。選型時(shí)要有一個(gè)原則優(yōu)先純 Dart 實(shí)現(xiàn)其次選已經(jīng)適配 ohos 的插件最后才是自己去補(bǔ) ohos 平臺(tái)實(shí)現(xiàn)。圖表庫(kù)這個(gè)選擇很關(guān)鍵。收入趨勢(shì)圖和餅圖我可以選fl_chart它是純 Dart 繪制不依賴(lài)原生控件OpenHarmony 上直接跑沒(méi)問(wèn)題。數(shù)據(jù)緩存我用的是shared_preferences它官方適配了 ohos 平臺(tái)取值和寫(xiě)入行為跟 Android 一致用來(lái)存“最后一次同步時(shí)間”這類(lèi)輕量標(biāo)記夠用。至于數(shù)據(jù)庫(kù)收入記錄如果量不大我建議先別急著上 SQLite。用path_provider獲取文檔目錄把記錄序列化成 JSON 存文件即可。等數(shù)據(jù)量過(guò)萬(wàn)再考慮接適配好的 SQLite 插件。這樣能少踩一半插件兼容性的坑。3. 收入分析統(tǒng)計(jì)的核心實(shí)現(xiàn)從數(shù)據(jù)采集到可視化3.1 收入數(shù)據(jù)模型金額、分類(lèi)、時(shí)間的字段設(shè)計(jì)收入記錄的數(shù)據(jù)模型看著簡(jiǎn)單但字段設(shè)計(jì)直接決定后面統(tǒng)計(jì)好不好寫(xiě)。我前后改過(guò)兩版第一版只有金額、分類(lèi)、日期三個(gè)字段后來(lái)加上了“所屬賬戶(hù)”和“外部單號(hào)”因?yàn)橐С侄噘~戶(hù)對(duì)賬和 CSV 導(dǎo)入去重。最終版本是這樣的class IncomeRecord { final int id; final String category; final double amount; final DateTime date; final String account; final String note; final String? externalNo; const IncomeRecord({ this.id 0, required this.category, required this.amount, required this.date, this.account 默認(rèn)賬戶(hù), this.note , this.externalNo, }); }一個(gè)容易被忽略的點(diǎn)是DateTime的時(shí)區(qū)處理。OpenHarmony 設(shè)備上的系統(tǒng)時(shí)區(qū)會(huì)變化如果直接存本地時(shí)間用戶(hù)在 A 時(shí)區(qū)錄入、到 B 時(shí)區(qū)打開(kāi)統(tǒng)計(jì)月份分組可能有偏差。我的做法是統(tǒng)一在數(shù)據(jù)層把日期轉(zhuǎn)成 UTC 存儲(chǔ)展示時(shí)再轉(zhuǎn)換到當(dāng)前時(shí)區(qū)。統(tǒng)計(jì)按“用戶(hù)當(dāng)前時(shí)區(qū)的自然月”來(lái)分組這個(gè)邏輯寫(xiě)在計(jì)算服務(wù)里UI 層只關(guān)心結(jié)果。3.2 按月、按品類(lèi)做統(tǒng)計(jì)聚合的邏輯實(shí)現(xiàn)統(tǒng)計(jì)聚合是整個(gè)模塊的“心臟”。我要算幾個(gè)指標(biāo)本月總收入、上月總收入、環(huán)比增長(zhǎng)率、本月日均收入、分類(lèi)占比、最高單筆、收入走勢(shì)序列。先定義一個(gè)結(jié)果對(duì)象class IncomeStats { final double monthTotal; final double previousTotal; final double growthRate; final double dailyAverage; final double maxSingle; final MapString, double categoryMap; final Listdouble dailyTrend; }聚合函數(shù)的核心思路是先把記錄按時(shí)間過(guò)濾到目標(biāo)月份再按分類(lèi)分組累加最后生成從當(dāng)月 1 號(hào)到今天為止的每日累計(jì)序列。環(huán)比不能只比“當(dāng)月至今”和“上月至今”應(yīng)該把上月同時(shí)長(zhǎng)區(qū)間拿出來(lái)對(duì)比否則月初看環(huán)比一定是暴跌因?yàn)檫@個(gè)月才過(guò) 3 天。IncomeStats computeStats(ListIncomeRecord records, DateTime month) { final firstDay DateTime(month.year, month.month); final lastDay DateTime(month.year, month.month 1, 0); final monthRecords records.where((r) !r.date.isBefore(firstDay) !r.date.isAfter(lastDay)).toList(); final previousMonth DateTime(month.year, month.month - 1); final previousFirst DateTime(previousMonth.year, previousMonth.month); final previousLast DateTime(previousMonth.year, previousMonth.month 1, 0); final previousRecords records.where((r) !r.date.isBefore(previousFirst) !r.date.isAfter(previousLast)).toList(); var total 0.0; var maxSingle 0.0; final categoryMap String, double{}; for (final r in monthRecords) { total r.amount; if (r.amount maxSingle) maxSingle r.amount; categoryMap.update(r.category, (v) v r.amount, ifAbsent: () r.amount); } final previousTotal previousRecords.fold(0.0, (sum, r) sum r.amount); final growthRate previousTotal 0 ? 0.0 : (total - previousTotal) / previousTotal * 100; final dayCount DateTime(month.year, month.month 1, 0).day; final today DateTime.now(); final effectiveDay month.year today.year month.month today.month ? today.day : dayCount; final dailyTrend Listdouble.generate(effectiveDay, (i) { final day firstDay.add(Duration(days: i)); return monthRecords .where((r) r.date.year day.year r.date.month day.month r.date.day day.day) .fold(0.0, (sum, r) sum r.amount); }); return IncomeStats( monthTotal: total, previousTotal: previousTotal, growthRate: growthRate, dailyAverage: effectiveDay 0 ? 0 : total / effectiveDay, maxSingle: maxSingle, categoryMap: categoryMap, dailyTrend: dailyTrend, ); }這里要特別提醒環(huán)比增長(zhǎng)率分母不能直接用previousTotal如果上月是 0 或者本月是 0直接除會(huì)得到 Infinity 或 NaN。我這里的處理是上月為 0 時(shí)增長(zhǎng)率按 0 算你可以根據(jù)產(chǎn)品需求調(diào)整為“顯示新增”或“顯示 --”。3.3 用fl_chart畫(huà)收入趨勢(shì)與占比圖圖表部分我選fl_chart因?yàn)樗?OpenHarmony 的 Flutter 環(huán)境下工作穩(wěn)定而且 API 方便做動(dòng)態(tài)數(shù)據(jù)刷新。折線圖展示每日收入趨勢(shì)餅圖展示分類(lèi)占比。折線圖核心配置LineChart( LineChartData( minY: 0, maxY: maxValue * 1.2, lineBarsData: [ LineChartBarData( spots: dailyTrend.asMap().entries.map((e) { return FlSpot(e.key.toDouble(), e.value); }).toList(), isCurved: true, color: const Color(0xFF3B82F6), barWidth: 3, dotData: const FlDotData(show: false), ), ], titlesData: const FlTitlesData(show: false), ), )一個(gè)實(shí)際經(jīng)驗(yàn)折線圖的 Y 軸最大值不要寫(xiě)死成 100 或 1000而要根據(jù)當(dāng)月數(shù)據(jù)最大值動(dòng)態(tài)計(jì)算并留出 20% 的上邊距否則最大一筆收入會(huì)把折線頂?shù)綀D表頂部顯得很擠。餅圖統(tǒng)計(jì)分類(lèi)占比時(shí)如果某個(gè)分類(lèi)金額特別小占比可能只有 1%扇區(qū)標(biāo)簽會(huì)擠在一起。我的處理方案是在繪制前先過(guò)濾掉占比小于 3% 的分類(lèi)把它們的金額匯總成“其他”保證圖表可讀性。3.4 數(shù)據(jù)持久化與刷新策略收入記錄的存儲(chǔ)策略我前面提過(guò)輕量階段用 JSON 文件。每次保存記錄后我會(huì)重新讀取整個(gè)列表再觸發(fā)一次統(tǒng)計(jì)計(jì)算。這個(gè)方案在記錄量幾千條以?xún)?nèi)完全夠用實(shí)測(cè)在平板設(shè)備上重建統(tǒng)計(jì)結(jié)果耗時(shí)幾十毫秒用戶(hù)無(wú)感知。刷新策略上要避免“每次進(jìn)入頁(yè)面都全量重算”。我的做法是在 Cubit 里維護(hù)一個(gè)IncomeState里面包含當(dāng)前月份、原始記錄列表、統(tǒng)計(jì)結(jié)果。用戶(hù)新增一條記錄后先更新記錄文件再對(duì)新月份范圍重新computeStats最后emit新的 state。月份切換則只改month字段重新走一遍計(jì)算邏輯。用 Cubit 而不是 Bloc是因?yàn)槭杖虢y(tǒng)計(jì)頁(yè)這種中小型模塊用不到復(fù)雜事件流Cubit 的代碼量更少、心智負(fù)擔(dān)更小。組件通信方面統(tǒng)計(jì)卡片、圖表、明細(xì)列表都在同一個(gè)頁(yè)面下我只用BlocBuilder監(jiān)聽(tīng) state不需要跨頁(yè)面?zhèn)鲄?。這就避免了 Flutter 里常見(jiàn)的“父子組件層層回調(diào)”地獄。4. 平臺(tái)通道適配Flutter與OpenHarmony原生能力打通4.1 MethodChannel 與 EventChannel 的使用邊界Flutter 和 OpenHarmony 原生側(cè)通信最常用的是 MethodChannel 和 EventChannel。收入統(tǒng)計(jì)模塊里有兩個(gè)典型場(chǎng)景導(dǎo)出 CSV 賬單文件用 MethodChannel監(jiān)聽(tīng)外部文件導(dǎo)入事件用 EventChannel。MethodChannel 適合“一次調(diào)用、同步或異步返回結(jié)果”的場(chǎng)景。比如 Flutter 側(cè)組裝好 CSV 字符串調(diào)用原生側(cè)寫(xiě)入系統(tǒng)下載目錄返回是否成功。EventChannel 適合“原生側(cè)主動(dòng)向 Flutter 推數(shù)據(jù)”的場(chǎng)景比如監(jiān)聽(tīng)某個(gè)目錄下新增文件一旦發(fā)現(xiàn)新賬單文件就推給 Flutter 觸發(fā)導(dǎo)入確認(rèn)。剛開(kāi)始我很容易把這兩個(gè)通道用混。記住一個(gè)判斷標(biāo)準(zhǔn)如果啟動(dòng)方是 Flutter要求原生干一件事并返回結(jié)果用 MethodChannel如果原生側(cè)要持續(xù)把變化往 Flutter 送用 EventChannel。4.2 一個(gè)導(dǎo)出CSV賬單的原生交互實(shí)例Flutter 側(cè)封裝如下static const MethodChannel _channel MethodChannel( com.example.income/export, ); Futurebool exportCsv({ required String fileName, required String content, }) async { try { final result await _channel.invokeMethodbool( exportCsv, { fileName: fileName, content: content, }, ); return result ?? false; } on PlatformException catch (e) { debugPrint(導(dǎo)出失敗: ${e.message}); return false; } }OpenHarmony 原生側(cè)對(duì)應(yīng)實(shí)現(xiàn)核心是文件寫(xiě)入。我這邊是在entry/src/main/ets下注冊(cè)了一個(gè)自定義模塊通過(guò)fileio創(chuàng)建文件并寫(xiě)入內(nèi)容。注冊(cè)時(shí)通道名稱(chēng)必須和 Flutter 側(cè)完全一致我最初就因?yàn)?Flutter 側(cè)寫(xiě)的是com.example.income/export原生側(cè)漏了個(gè)/export后綴導(dǎo)致調(diào)用一直報(bào)找不到實(shí)現(xiàn)。這個(gè)經(jīng)驗(yàn)可以放大到所有插件適配OpenHarmony 平臺(tái)插件適配流程本質(zhì)上是“在原生側(cè)實(shí)現(xiàn) Dart 側(cè)聲明的 MethodChannel 方法”你可以參考其他平臺(tái)已有插件的實(shí)現(xiàn)思路把 Android 里用 Java 寫(xiě)的邏輯改寫(xiě)成 ArkTS 或者 C 接口但通道名和參數(shù)鍵盡量保持不變這樣 Flutter 業(yè)務(wù)代碼可以原封不動(dòng)復(fù)用。4.3 常用數(shù)據(jù)類(lèi)型的轉(zhuǎn)換與踩坑通道傳參的類(lèi)型轉(zhuǎn)換是我踩坑重災(zāi)區(qū)這里單獨(dú)列一下常見(jiàn)對(duì)應(yīng)關(guān)系Flutter 側(cè)類(lèi)型OpenHarmony 原生側(cè)類(lèi)型注意事項(xiàng)boolboolean無(wú)intnumber大整數(shù)容易溢出建議金額用 double 傳doublenumber金額場(chǎng)景統(tǒng)一用 double不要混用 intStringstring無(wú)ListObject?ArrayObject?空數(shù)組要判斷長(zhǎng)度部分原生 API 不接受空引用Uint8ListArrayBuffer / Arraynumber傳輸二進(jìn)制文件內(nèi)容時(shí)使用我在導(dǎo)出 CSV 時(shí)一開(kāi)始把金額用 int 傳結(jié)果遇到小數(shù)金額被截?cái)嘟y(tǒng)計(jì)對(duì)不上賬。后來(lái)定下規(guī)矩涉及貨幣的字段在通道里一律用 double 或字符串絕不傳 int。整型只用于記錄 id、排序序號(hào)這類(lèi)非金額字段。另外MethodChannel 的 invokeMethod 默認(rèn)有超時(shí)機(jī)制如果原生側(cè)執(zhí)行時(shí)間太久Flutter 會(huì)拋出超時(shí)異常。大型 CSV 導(dǎo)出時(shí)文件內(nèi)容可能幾百 KB原生寫(xiě)入一般很快但如果內(nèi)容特別大建議先壓縮再傳或者通過(guò)文件路徑共享而不是直接傳字符串內(nèi)容。5. 完整實(shí)操?gòu)目枕?xiàng)目到收入分析頁(yè)面5.1 第1步搭建基礎(chǔ)頁(yè)面骨架頁(yè)面骨架我用的是Scaffold 頂部統(tǒng)計(jì)卡片區(qū) 中間圖表 Tab 底部明細(xì)列表。這里有一個(gè)結(jié)構(gòu)上的選擇圖表和明細(xì)列表不是“上下滾動(dòng)一個(gè) ListView”而是把圖表固定在頁(yè)面上半部分明細(xì)列表獨(dú)立滾動(dòng)。這樣用戶(hù)切換月份時(shí)圖表始終可見(jiàn)不會(huì)滾到一半就看不到趨勢(shì)。class IncomeAnalysisPage extends StatelessWidget { const IncomeAnalysisPage({super.key}); override Widget build(BuildContext context) { return BlocProvider( create: (_) IncomeCubit()..loadInitialData(), child: const _IncomeView(), ); } }5.2 第2步接入統(tǒng)計(jì)服務(wù)收入模塊我用了BlocProvider和BlocBuilder組合。Cubit 初始化時(shí)從本地 JSON 讀取記錄列表然后調(diào)用computeStats生成第一版統(tǒng)計(jì)結(jié)果。切換月份的方法如下class IncomeCubit extends CubitIncomeState { IncomeCubit() : super(const IncomeState()); void loadInitialData() { final records _loadFromLocal(); final stats computeStats(records, DateTime.now()); emit(state.copyWith( records: records, currentMonth: DateTime.now(), stats: stats, loading: false, )); } void switchMonth(DateTime month) { final stats computeStats(state.records, month); emit(state.copyWith(currentMonth: month, stats: stats)); } }這種寫(xiě)法把“用戶(hù)操作”和“數(shù)據(jù)重算”徹底分開(kāi)。每次 emit 新的 state 是一個(gè)全新的不可變對(duì)象BlocBuilder只在 stats 或者 currentMonth 發(fā)生變化時(shí)刷新圖表不會(huì)因?yàn)槠渌麩o(wú)關(guān)狀態(tài)改動(dòng)導(dǎo)致頁(yè)面整體重建。頁(yè)面狀態(tài)保留這塊我要多說(shuō)一句。如果你的收入分析頁(yè)是在 Tab 里切換 Tab 再切回來(lái)默認(rèn)情況下 Flutter 可能會(huì)重建頁(yè)面導(dǎo)致記錄重新加載、圖表重新進(jìn)入加載動(dòng)畫(huà)。我用了IndexedStack包裹整個(gè)頁(yè)面容器讓所有 Tab 的頁(yè)面狀態(tài)常駐內(nèi)存。實(shí)測(cè)下來(lái)收入分析頁(yè)的滾動(dòng)位置、選中月份、圖表縮放狀態(tài)都能完整保留體驗(yàn)要順滑很多。5.3 第3步動(dòng)態(tài)圖表渲染與空態(tài)處理空數(shù)據(jù)和真實(shí)數(shù)據(jù)的處理差異很大。收入統(tǒng)計(jì)模塊在剛部署時(shí)用戶(hù)很可能一個(gè)月的收入記錄都是空的。繪制折線圖時(shí)如果dailyTrend全是 0直接把數(shù)據(jù)丟給LineChart圖表會(huì)畫(huà)出一條貼在底部的橫線視覺(jué)上很奇怪?？諔B(tài)處理我分兩種情況如果整月沒(méi)有任何記錄顯示“本月還沒(méi)有收入記錄”的占位組件不渲染圖表如果月中有記錄但不是每天都有缺失的日期補(bǔ) 0折線圖才能連貫。圖表組件刷新還有個(gè)細(xì)節(jié)fl_chart在數(shù)據(jù)更新時(shí)建議給圖表加一個(gè)與數(shù)據(jù)內(nèi)容相關(guān)的key比如LineChart( key: ValueKey(line_${state.currentMonth.year}_${state.currentMonth.month}), LineChartData(...), )這樣切換月份后圖表會(huì)主動(dòng)重繪而不是因?yàn)閮?nèi)部狀態(tài)未重置繼續(xù)沿用舊數(shù)據(jù)動(dòng)畫(huà)。這個(gè)小問(wèn)題我排查了很久數(shù)據(jù)明明變了圖表卻顯示上個(gè)月的圖原因就是圖表實(shí)例沒(méi)有感知到月份變化。5.4 真機(jī)運(yùn)行效果與性能表現(xiàn)在 OpenHarmony 真機(jī)上跑起來(lái)后收入分析頁(yè)的性能數(shù)據(jù)如下冷啟動(dòng)進(jìn)入頁(yè)面約 500 毫秒完成首幀統(tǒng)計(jì)計(jì)算在 2000 條記錄下約 80 毫秒圖表動(dòng)畫(huà)流暢無(wú)明顯掉幀。內(nèi)存占用主要來(lái)自圖表庫(kù)的緩存和記錄列表整體可控。如果后續(xù)記錄量膨脹到幾萬(wàn)條有兩個(gè)優(yōu)化方向一是把聚合計(jì)算的頻率降下來(lái)只在記錄變更時(shí)算一次并用緩存二是把明細(xì)列表從ListView升級(jí)為懶加載分頁(yè)避免一次性渲染所有記錄。目前幾千條量級(jí)完全不需要上這些方案過(guò)度優(yōu)化反而增加維護(hù)成本。6. 常見(jiàn)問(wèn)題排查與避坑速查6.1 OpenHarmony環(huán)境下Flutter構(gòu)建失敗典型場(chǎng)景是執(zhí)行flutter build ohos時(shí)報(bào)一堆 Gradle 或 hvigor 依賴(lài)錯(cuò)誤。這種問(wèn)題九成以上是版本不匹配不是代碼問(wèn)題。癥狀可能原因處理方式報(bào)Unsupported或找不到 ohos 任務(wù)Flutter SDK 不含 ohos 平臺(tái)模板換成 OpenHarmony 官方適配的 Flutter 分支構(gòu)建時(shí)下載依賴(lài)超時(shí)網(wǎng)絡(luò)問(wèn)題配置鏡像倉(cāng)庫(kù)后重試原生側(cè)編譯報(bào)找不到符號(hào)DevEco Studio 版本太舊升級(jí)到與 SDK 匹配的版本Could not resolve all task dependencies插件缺少 ohos 依賴(lài)檢查 pub 插件是否聲明了 ohos 平臺(tái)實(shí)現(xiàn)我建議把環(huán)境版本寫(xiě)進(jìn)團(tuán)隊(duì)的 README不要靠口頭傳。新版 Flutter 發(fā)布后OpenHarmony 適配會(huì)滯后一段時(shí)間別急著升級(jí)先在 SDK 目錄下跑flutter doctor -v確認(rèn)所有工具鏈檢查通過(guò)再動(dòng)手。6.2 圖表不更新/數(shù)據(jù)丟失圖表不更新主要有兩個(gè)原因。第一個(gè)是狀態(tài)管理寫(xiě)錯(cuò)了修改了舊的 state 對(duì)象沒(méi)有 emit 新對(duì)象。Cubit 里所有狀態(tài)變更都必須走emit(state.copyWith(...))直接改state.xxx value不會(huì)觸發(fā) UI 刷新。第二個(gè)是圖表 key 沒(méi)變化導(dǎo)致的緩存問(wèn)題。切換月份后即使數(shù)據(jù)變了fl_chart內(nèi)部可能保留上一幀的繪制狀態(tài)所以要在構(gòu)造圖表時(shí)把月份信息放進(jìn)ValueKey。數(shù)據(jù)丟失問(wèn)題常見(jiàn)于退出 App 后重新進(jìn)入發(fā)現(xiàn)收入記錄變空。檢查一下是否在寫(xiě)入 JSON 文件前忘了先讀取舊數(shù)據(jù)導(dǎo)致每次新增記錄都覆蓋了整個(gè)文件。正確做法是讀取、追加、寫(xiě)回三個(gè)動(dòng)作嚴(yán)格按順序執(zhí)行。6.3 字體、中文水印、時(shí)區(qū)問(wèn)題OpenHarmony 上 Flutter 的中文顯示一般沒(méi)問(wèn)題但如果你的圖表里用了自定義字體或者設(shè)置的字體文件路徑不支持中文可能變成方塊。我建議圖表里的中文標(biāo)簽直接用系統(tǒng)默認(rèn)字體不要為了美觀引入外部字體文件。如果要支持用戶(hù)自定義字體最好做成可選配置而不是全局默認(rèn)。時(shí)區(qū)問(wèn)題容易被忽略。記錄數(shù)據(jù)時(shí)我用DateTime.now()取得的是設(shè)備本地時(shí)間但存儲(chǔ)時(shí)統(tǒng)一轉(zhuǎn)成 UTC。統(tǒng)計(jì)時(shí)先把 UTC 轉(zhuǎn)換回本地時(shí)間再做月份分組。過(guò)了午夜、跨時(shí)區(qū)飛行后重新打開(kāi) App統(tǒng)計(jì)結(jié)果也必須跟著本地時(shí)間走不能因?yàn)槟銚Q了時(shí)區(qū)就看到上個(gè)月的數(shù)據(jù)。6.4 速查表問(wèn)題原因解決方案MethodChannel 報(bào)找不到實(shí)現(xiàn)通道名不一致核對(duì) Flutter 和原生側(cè)通道名完全一致EventChannel 收不到事件原生側(cè)沒(méi)有在生命周期里注冊(cè)在頁(yè)面 onResume/onShow 重新監(jiān)聽(tīng)金額在通道里精度丟失int 傳小數(shù)被截?cái)嘟痤~一律用 double 或 String 傳輸頁(yè)面切回后數(shù)據(jù)重新加載頁(yè)面狀態(tài)丟失用 IndexedStack 或 AutomaticKeepAliveClientMixin ?；罱y(tǒng)計(jì)結(jié)果出現(xiàn) NaN上月收入為 0聚合函數(shù)里顯式處理除零場(chǎng)景導(dǎo)出 CSV 文件內(nèi)容亂碼編碼格式不符寫(xiě)入文件時(shí)顯式指定 UTF-8 編碼最后再分享一個(gè)小技巧收入分析統(tǒng)計(jì)這種功能建議先手工構(gòu)造一批固定測(cè)試數(shù)據(jù)把聚合函數(shù)的結(jié)果和 Excel 核對(duì)通過(guò)后再接 UI。我在開(kāi)發(fā)時(shí)就因?yàn)橐粋€(gè)期初日期算錯(cuò)導(dǎo)致所有月份的收入都比實(shí)際少了 1 天這個(gè)問(wèn)題如果不是提前核對(duì)數(shù)據(jù)表光看界面根本發(fā)現(xiàn)不了。開(kāi)發(fā) OpenHarmony 側(cè)的能力時(shí)也一樣不要急著寫(xiě)復(fù)雜圖表先把最小閉環(huán)跑通再膨脹功能路徑會(huì)順很多。