前陣子我把一直在維護(hù)的 Flutter 家具購買記錄 App 往 OpenHarmony 上遷第一個(gè)完整做完的功能就是品牌管理。Flutter for OpenHarmony 這個(gè)話題看起來熱度很高真正落地時(shí)會(huì)發(fā)現(xiàn)很多帖子只講了“能跑起來”很少聊到“一個(gè)完整業(yè)務(wù)模塊怎么做”。品牌管理這種功能剛好是個(gè)試金石它有標(biāo)準(zhǔn) CRUD有列表和搜索還要處理本地存儲(chǔ)、狀態(tài)刷新、頁面跳轉(zhuǎn)幾乎把日常 App 開發(fā)的基礎(chǔ)環(huán)節(jié)都覆蓋了。這篇文章我按實(shí)際開發(fā)順序?qū)憦男枨蟛鸾夂图夹g(shù)選型開始接著講環(huán)境搭建、數(shù)據(jù)模型、UI 實(shí)現(xiàn)、CRUD 細(xì)節(jié)最后把 OpenHarmony 適配期間踩過的坑全部交底。適合正在評估 Flutter 跨端到 OpenHarmony 的團(tuán)隊(duì)也想給打算拿一個(gè)小項(xiàng)目驗(yàn)證技術(shù)方案的開發(fā)者做參考。1. 項(xiàng)目思路與選型為什么從品牌管理切入1.1 家具購買記錄里的品牌管理到底要做什么做這個(gè) App 的初衷很簡單家里裝修完買家具沙發(fā)、床墊、餐桌、書架這些東西買完三個(gè)月可能還記得價(jià)格等過了一年需要售后時(shí)品牌、型號(hào)、保修期往往全忘了。于是想做一個(gè)小工具把每次家具購買的信息記錄下來核心的查詢維度就是品牌。品牌管理在這個(gè)場景里其實(shí)承擔(dān)著“主數(shù)據(jù)維護(hù)”的角色。它至少要做四件事維護(hù)品牌檔案品牌名稱、產(chǎn)地、備注信息比如客服電話、保修政策。建立品牌和購買記錄的關(guān)聯(lián)一條家具購買記錄必須歸屬于某個(gè)品牌否則后續(xù)按品牌統(tǒng)計(jì)就是空談。支持按品牌瀏覽和檢索列表里能看到每個(gè)品牌名下有多少件家具、累計(jì)花了多少錢。提供常規(guī)的新增、編輯、刪除操作。這里我沒有把需求做復(fù)雜。像品牌 Logo 上傳、品牌官網(wǎng)跳轉(zhuǎn)、云端同步這些功能看起來有想象空間但對第一版落地沒有太大幫助反而會(huì)牽扯圖片存儲(chǔ)、網(wǎng)絡(luò)權(quán)限這類 OpenHarmony 適配成本更高的東西。品牌管理的 MVP 邊界就是一個(gè)干凈可靠的本地?cái)?shù)據(jù)模塊先把記錄和分類的基礎(chǔ)打牢。實(shí)際開發(fā)中我給自己限定了一個(gè)原則凡是能在 Dart 側(cè)完成的邏輯絕不在原生層碰。品牌管理恰好是一個(gè)插件弱依賴模塊非常適合用來驗(yàn)證 Flutter 在 OpenHarmony 上的基礎(chǔ)能力也方便后續(xù)排查問題時(shí)縮小范圍。1.2 用 Flutter 而不是 ArkTS 重寫一遍現(xiàn)在 OpenHarmony 應(yīng)用開發(fā)的主流方式確實(shí)是用 ArkTS 加 ArkUI官方支持度也最高。但 Flutter 團(tuán)隊(duì)里通常已經(jīng)沉淀了不少跨端業(yè)務(wù)代碼如果為了 OpenHarmony 重新用 ArkTS 寫一遍雙端維護(hù)成本直接翻倍。我的出發(fā)點(diǎn)很現(xiàn)實(shí)能不能把現(xiàn)有 Flutter 這套 App 低成本移植到 OpenHarmony先跑通業(yè)務(wù)模塊再逐步適配平臺(tái)能力。這里要說明我使用的不是 Google 官方版本而是社區(qū)適配 OpenHarmony 的 Flutter SDK 分支。這個(gè)分支在 API 對齊和引擎裁剪上會(huì)比標(biāo)準(zhǔn)分支慢一點(diǎn)但日常 UI 渲染、路由跳轉(zhuǎn)、文本輸入這些能力已經(jīng)基本可用。選型時(shí)我的判斷依據(jù)是現(xiàn)有 Flutter 業(yè)務(wù)代碼復(fù)用率能到八成以上品牌管理不依賴相機(jī)、定位、推送這類高風(fēng)險(xiǎn)原生能力同一套代碼未來可以在 Andorid、iOS、OpenHarmony 三個(gè)平臺(tái)繼續(xù)迭代。關(guān)鍵要接受一個(gè)事實(shí)Flutter 生態(tài)里大部分第三方插件在 OpenHarmony 上還沒有原生實(shí)現(xiàn)很多 GitHub 上寫著跨平臺(tái)的包跑在 OpenHarmony 上會(huì)直接拋 MissingPluginException。所以工程結(jié)構(gòu)從一開始就要把“數(shù)據(jù)存儲(chǔ)”這類能力隔離開給自己留出切換實(shí)現(xiàn)的余地。2. 環(huán)境搭建與工程骨架跑通 OpenHarmony 的 Flutter 項(xiàng)目2.1 環(huán)境準(zhǔn)備與版本匹配這個(gè)步驟沒有太多黑科技但版本匹配最容易讓人崩潰。我本地的組合是某穩(wěn)定適配版 Flutter SDK配合 DevEco Studio 里下載的 OpenHarmony SDK。先保證兩條命令能跑通flutter --version flutter doctorflutter doctor 不一定能自動(dòng)識(shí)別 OpenHarmony 環(huán)境所以還要手動(dòng)確認(rèn) ohos 相關(guān)目錄是否存在。如果 Flutter 工程還沒有生成 ohos 平臺(tái)目錄可以嘗試從已有模版工程里復(fù)制或者用適配版 SDK 提供的項(xiàng)目初始化命令創(chuàng)建flutter create --platforms ohos --template app furniture_app這個(gè)命令生成的工程會(huì)自動(dòng)帶出ohos/目錄里面有一套 OpenHarmony 工程的殼。沒有的話檢查一下 Flutter 版本是不是帶 ohos 支持的 dev 分支或者直接去社區(qū)項(xiàng)目倉庫拉一個(gè)示例工程做對比。經(jīng)驗(yàn)是不要一上來就裝最新 Flutter main 分支。調(diào)試開發(fā)沒問題但一旦遇到輸入法或者渲染異常很難判斷是業(yè)務(wù)問題還是引擎問題。建議堅(jiān)持使用與 OpenHarmony SDK 版本配套的穩(wěn)定適配版并固定版本號(hào)不要輕易升級(jí)。開發(fā)機(jī)上我用了 OpenHarmony 模擬器先跑通 Hello World然后才把項(xiàng)目代碼逐步拷貝進(jìn)去。真機(jī)調(diào)試比模擬器更重要因?yàn)?OpenHarmony 的輸入法、交互回調(diào)、屏幕適配在模擬器上往往會(huì)掩蓋問題。至少準(zhǔn)備一臺(tái)開發(fā)板或真實(shí)設(shè)備后面會(huì)替你節(jié)省大量排查時(shí)間。2.2 目錄結(jié)構(gòu)與依賴清單品牌管理模塊的目錄結(jié)構(gòu)我盡量保持清晰因?yàn)楹罄m(xù)還要加購買記錄、統(tǒng)計(jì)報(bào)表、品類管理如果從一開始就是平鋪的大文件夾后面會(huì)很難維護(hù)。這是我最終采用的骨架lib/ main.dart models/ brand.dart stores/ brand_store.dart providers/ brand_provider.dart pages/ brand_list_page.dart brand_detail_page.dart widgets/ brand_form_dialog.dart依賴我只保留了真正用到的幾個(gè)dependencies: flutter: sdk: flutter provider: ^6.1.2 path_provider: ^2.1.3 intl: ^0.18.1provider 用來管理品牌列表狀態(tài)path_provider 負(fù)責(zé)找到持久化目錄intl 用于格式化時(shí)間和金額。沒有引入重量級(jí)數(shù)據(jù)庫或者狀態(tài)管理框架原因在后面數(shù)據(jù)存儲(chǔ)和狀態(tài)管理兩節(jié)會(huì)詳細(xì)展開。main.dart里的初始化邏輯也很簡單創(chuàng)建 JsonBrandStore再創(chuàng)建 BrandProvider用 Provider 包住整個(gè) App。這樣頁面里面不需要再關(guān)心 store 如何構(gòu)造后續(xù)替換數(shù)據(jù)庫實(shí)現(xiàn)只改一行注冊代碼。3. 數(shù)據(jù)模型與存儲(chǔ)方案先想清楚再寫代碼3.1 品牌模型字段是怎么定出來的建模最忌諱一步到位我參照的是家具購買記錄的真實(shí)查詢需求。一個(gè)品牌檔案最終保留在這些字段class Brand { final String id; final String name; final String origin; final String remark; final int createdAt; int furnitureCount; double totalSpent; Brand({ required this.id, required this.name, required this.origin, required this.remark, required this.createdAt, this.furnitureCount 0, this.totalSpent 0, }); MapString, dynamic toJson() { return { id: id, name: name, origin: origin, remark: remark, createdAt: createdAt, furnitureCount: furnitureCount, totalSpent: totalSpent, }; } factory Brand.fromJson(MapString, dynamic json) { return Brand( id: json[id] as String, name: json[name] as String, origin: json[origin] as String? ?? , remark: json[remark] as String? ?? , createdAt: json[createdAt] as int, furnitureCount: json[furnitureCount] as int? ?? 0, totalSpent: (json[totalSpent] as num?)?.toDouble() ?? 0, ); } }選 id 時(shí)我沒有用整型自增因?yàn)槲募鎯?chǔ)場景下自增 id 需要額外記錄當(dāng)前序列而且刪除、合并時(shí)容易出問題。我用的是“時(shí)間戳 隨機(jī)數(shù)”的字符串主鍵格式不美觀但足夠唯一。origin 字段對應(yīng)“產(chǎn)地/品牌國別”有的品牌在全球多個(gè)國家銷售用戶不一定記得準(zhǔn)確產(chǎn)地但這個(gè)字段允許為空只是輔助篩選。remark 才是真正的寶藏用來記錄保修電話、安裝注意事項(xiàng)、購買門店等非結(jié)構(gòu)化信息。furnitureCount 和 totalSpent 其實(shí)不屬于品牌原始檔案它們是聚合字段來自家具購買記錄。放到 Brand 里主要是方便列表頁直接展示不用每次都去遍歷所有記錄。這個(gè)設(shè)計(jì)在數(shù)據(jù)量幾百條時(shí)完全夠用如果以后數(shù)據(jù)大了再拆分也不遲。3.2 存儲(chǔ)層用 JSON 文件撐起第一版再考慮數(shù)據(jù)庫第一版我開始想得很簡單按之前做 App 的經(jīng)驗(yàn)直接上 sqflite。結(jié)果在 OpenHarmony 跑起來之后發(fā)現(xiàn) sqlite 相關(guān)的原生通道并沒有完全接入這個(gè) Flutter 分支啟動(dòng)即報(bào)插件缺失。我評估了一下專門去給插件補(bǔ) OpenHarmony 實(shí)現(xiàn)工作量遠(yuǎn)大于業(yè)務(wù)模塊本身。于是換了個(gè)思路品牌數(shù)據(jù)量不大單機(jī)使用為什么不用結(jié)構(gòu)化 JSON 文件這個(gè)選擇不是退步而是尊重平臺(tái)生態(tài)現(xiàn)狀。文件方案的好處是平臺(tái)依賴少核心只需要一個(gè)“能拿到應(yīng)用持久化目錄”的能力甚至拿不到時(shí)也可以回退到相對目錄。我封裝了一個(gè) BrandStore 抽象abstract class BrandStore { FutureListBrand loadAll(); Futurevoid saveAll(ListBrand brands); } class JsonBrandStore implements BrandStore { final String _filePath; JsonBrandStore(this._filePath); override FutureListBrand loadAll() async { try { final file File(_filePath); if (!await file.exists()) return []; final content await file.readAsString(); if (content.isEmpty) return []; final data jsonDecode(content) as Listdynamic; return data.map((e) Brand.fromJson(e as MapString, dynamic)).toList(); } catch (_) { return []; } } override Futurevoid saveAll(ListBrand brands) async { final file File(_filePath); await file.create(recursive: true); await file.writeAsString(jsonEncode(brands.map((e) e.toJson()).toList())); } }實(shí)際初始化路徑直接用 path_provider 獲取文檔目錄final dir await getApplicationDocumentsDirectory(); final store JsonBrandStore(${dir.path}/brands.json);這個(gè)方案有一個(gè)明顯的劣勢并發(fā)寫入時(shí)要做好串行保護(hù)而且每次保存都會(huì)全量落盤。但目前品牌數(shù)量通常幾十個(gè)JSON 序列化后再寫入耗時(shí)可以忽略不計(jì)。在代碼注釋里我也提醒自己將來引入購買記錄表如果要按日期、金額做復(fù)雜聚合查詢再換 SQLite屆時(shí)只需實(shí)現(xiàn)同一個(gè) BrandStore 接口對上層 UI 完全透明。很多開發(fā)者會(huì)覺得第一版就上一個(gè)數(shù)據(jù)庫才是“正規(guī)做法”但我這幾年的體會(huì)是選型要貼著業(yè)務(wù)規(guī)模和平臺(tái)現(xiàn)狀走能跑、能改、能換比一味追求架構(gòu)完整更重要。品牌管理本身就是驗(yàn)證這一點(diǎn)的好場景。4. 品牌管理狀態(tài)與界面實(shí)現(xiàn)4.1 Provider 管理品牌數(shù)據(jù)狀態(tài)管理我用了 provider沒有選 bloc 和 riverpod。品牌模塊的數(shù)據(jù)流很簡單加載列表、增刪改、通知刷新ChangeNotifier 天然夠用寫起來也直白。團(tuán)隊(duì)里其他成員接手心理門檻也低。BrandProvider 核心代碼如下class BrandProvider extends ChangeNotifier { final BrandStore _store; ListBrand _brands []; bool _loading false; String _keyword ; BrandProvider(this._store); ListBrand get brands { if (_keyword.isEmpty) return _brands; return _brands.where((b) b.name.contains(_keyword)).toList(); } bool get loading _loading; Futurevoid load() async { _loading true; notifyListeners(); _brands await _store.loadAll(); _loading false; notifyListeners(); } Futurevoid addBrand(Brand brand) async { _brands.add(brand); await _store.saveAll(_brands); notifyListeners(); } Futurevoid updateBrand(Brand updated) async { final index _brands.indexWhere((b) b.id updated.id); if (index 0) return; _brands[index] updated; await _store.saveAll(_brands); notifyListeners(); } Futurevoid deleteBrand(String id) async { _brands.removeWhere((b) b.id id); await _store.saveAll(_brands); notifyListeners(); } void setKeyword(String keyword) { _keyword keyword.trim(); notifyListeners(); } }有幾個(gè)細(xì)節(jié)值得注意。load 方法進(jìn)入時(shí)先置 loading 并 notify是為了讓頁面能顯示進(jìn)度如果文件不存在也沒有數(shù)據(jù)會(huì)返回一個(gè)空列表不會(huì)拋異常。brands 的 getter 里直接做關(guān)鍵詞過濾界面層不需要再維護(hù)一套過濾列表。保存順序我也做了規(guī)定先改內(nèi)存列表再寫文件最后 notifyListeners。這樣即使文件寫入失敗UI 層還是保持用戶已經(jīng)看到的最終結(jié)果至少不會(huì)出現(xiàn)界面和狀態(tài)不一致的閃跳。4.2 列表頁、空態(tài)和搜索列表頁的整體布局是 AppBar 加右下角 FloatingActionButton中間根據(jù)狀態(tài)顯示 loading、空態(tài)或者 ListView。第一版不搞復(fù)雜但用戶體驗(yàn)不能太生硬。body: ConsumerBrandProvider( builder: (context, provider, child) { if (provider.loading) { return const Center(child: CircularProgressIndicator()); } final filtered provider.brands; if (filtered.isEmpty) { return const Center(child: Text(還沒有品牌點(diǎn)擊右下角添加)); } return ListView.separated( itemCount: filtered.length, separatorBuilder: (_, __) const Divider(height: 1), itemBuilder: (context, index) { final brand filtered[index]; return ListTile( title: Text(brand.name), subtitle: Text(${brand.origin} · ${brand.remark}), trailing: Text(${brand.furnitureCount}件), onTap: () { Navigator.of(context).push( MaterialPageRoute( builder: (_) BrandDetailPage(brandId: brand.id), ), ); }, ); }, ); }, ),搜索框我放在了 AppBar 下方的安全區(qū)域而不是 AppBar 的 actions 里主要為了方便輸入也不用擔(dān)心標(biāo)題欄寬度不夠。搜索輸入時(shí)調(diào)用 provider.setKeyword列表實(shí)時(shí)過濾?？諔B(tài)文案不是隨便寫的?！斑€沒有品牌點(diǎn)擊右下角添加”這句話同時(shí)揭示了當(dāng)前狀態(tài)和下一步操作比一句“暫無數(shù)據(jù)”有用得多。后來使用測試?yán)飵缀跛腥硕寄艿谝粫r(shí)間明白該怎么操作。至于品牌詳情頁我目前展示的是品牌基礎(chǔ)信息和一個(gè)“購買記錄列表”占位頁。因?yàn)樵诩揖哂涗浤K還沒完成前詳情頁強(qiáng)行堆功能反而顯得空洞。我先放了一個(gè)簡單的信息卡片并列出關(guān)聯(lián)的購買記錄數(shù)量后面再接列表。5. 新增、編輯、刪除品牌管理的完整 CRUD5.1 表單校驗(yàn)與保存新增和編輯共用一個(gè)彈窗表單這是最省代碼也最不容易出現(xiàn)雙份邏輯的寫法。我封裝了一個(gè) BrandFormDialog內(nèi)部用 Form 和 TextFormField 做校驗(yàn)。class BrandFormDialog extends StatefulWidget { final Brand? brand; const BrandFormDialog({super.key, this.brand}); override StateBrandFormDialog createState() _BrandFormDialogState(); } class _BrandFormDialogState extends StateBrandFormDialog { final _formKey GlobalKeyFormState(); late final TextEditingController _nameController; late final TextEditingController _originController; late final TextEditingController _remarkController; override void initState() { super.initState(); _nameController TextEditingController(text: widget.brand?.name ?? ); _originController TextEditingController(text: widget.brand?.origin ?? ); _remarkController TextEditingController(text: widget.brand?.remark ?? ); } void _submit() { if (!_formKey.currentState!.validate()) return; final brand widget.brand; if (brand null) { final newBrand Brand( id: ${DateTime.now().microsecondsSinceEpoch}_${Random().nextInt(9999)}, name: _nameController.text.trim(), origin: _originController.text.trim(), remark: _remarkController.text.trim(), createdAt: DateTime.now().millisecondsSinceEpoch, ); Navigator.of(context).pop(newBrand); } else { final updated Brand( id: brand.id, name: _nameController.text.trim(), origin: _originController.text.trim(), remark: _remarkController.text.trim(), createdAt: brand.createdAt, furnitureCount: brand.furnitureCount, totalSpent: brand.totalSpent, ); Navigator.of(context).pop(updated); } } override Widget build(BuildContext context) { return AlertDialog( title: Text(widget.brand null ? 添加品牌 : 編輯品牌), content: Form( key: _formKey, child: Column( mainAxisSize: MainAxisSize.min, children: [ TextFormField( controller: _nameController, decoration: const InputDecoration(labelText: 品牌名稱), validator: (v) { if (v null || v.trim().isEmpty) { return 品牌名稱不能為空; } return null; }, ), TextFormField( controller: _originController, decoration: const InputDecoration(labelText: 產(chǎn)地), ), TextFormField( controller: _remarkController, decoration: const InputDecoration(labelText: 備注), maxLines: 2, ), ], ), ), actions: [ TextButton( onPressed: () Navigator.of(context).pop(), child: const Text(取消), ), ElevatedButton( onPressed: _submit, child: const Text(保存), ), ], ); } }編輯時(shí)這里有個(gè)小坑。新建和編輯如果都通過同一個(gè) pop 返回 Brand 對象頁面?zhèn)刃枰袛喈?dāng)前是“新增”還是“編輯”。這個(gè)判斷我放在列表頁的_openForm方法里Futurevoid _openForm({Brand? brand}) async { final result await showDialogBrand( context: context, builder: (_) BrandFormDialog(brand: brand), ); if (result null) return; final provider context.readBrandProvider(); if (brand null) { provider.addBrand(result); } else { provider.updateBrand(result); } }表單校驗(yàn)?zāi)壳爸惶幚砹朔强张袛嗪罄m(xù)應(yīng)該增加重名判斷。品牌名稱雖然在業(yè)務(wù)上要求唯一但真正做校驗(yàn)時(shí)需要遍歷現(xiàn)有品牌列表我放在 provider 側(cè)過濾一遍比在表單組件里直接依賴全局狀態(tài)更干凈。5.2 刪除策略和關(guān)聯(lián)數(shù)據(jù)處理刪除品牌絕對不只是 removeWhere 一下那么簡單。家具購買記錄和品牌是多對一關(guān)系如果直接把品牌刪掉之前的購買記錄就會(huì)變成“無家可歸”的孤兒數(shù)據(jù)。我在第一版就吃過這個(gè)虧某條沙發(fā)購買記錄還帶著品牌名但品牌詳情頁已經(jīng)打不開了查詢統(tǒng)計(jì)時(shí)那一類數(shù)據(jù)直接消失。為了避免這個(gè)問題我定下的策略是如果品牌下已經(jīng)關(guān)聯(lián)了購買記錄就不允許直接刪除。用戶在列表頁刪除時(shí)會(huì)看到一個(gè)提示說明“該品牌下還有 N 件購買記錄請先處理關(guān)聯(lián)記錄或改為編輯”。Futurevoid _deleteBrand(Brand brand) async { if (brand.furnitureCount 0) { await showDialogvoid( context: context, builder: (_) AlertDialog( title: const Text(無法刪除), content: Text(${brand.name} 下還有 ${brand.furnitureCount} 條購買記錄建議改為編輯。), actions: [ TextButton( onPressed: () Navigator.of(context).pop(), child: const Text(知道了), ), ], ), ); return; } final ok await showDialogbool( context: context, builder: (_) AlertDialog( title: const Text(刪除品牌), content: Text(確定刪除品牌“${brand.name}”嗎), actions: [ TextButton( onPressed: () Navigator.of(context).pop(false), child: const Text(取消), ), ElevatedButton( onPressed: () Navigator.of(context).pop(true), child: const Text(刪除), ), ], ), ); if (ok true) { context.readBrandProvider().deleteBrand(brand.id); } }這個(gè)策略在產(chǎn)品層面不是唯一解比如也可以設(shè)計(jì)成“刪除品牌時(shí)把記錄遷移到未分類”給用戶一個(gè)選擇。但對我這個(gè)單機(jī)小工具來說先保護(hù)數(shù)據(jù)完整性比提供復(fù)雜的原數(shù)據(jù)遷移更重要。等購買記錄模塊完整了再在設(shè)置頁提供“合并品牌”能力也不遲。6. 常見問題和排障實(shí)錄6.1 OpenHarmony 適配期遇到的三個(gè)典型問題做品牌管理模塊期間我確實(shí)積累了一些之前做 Android 時(shí)從沒遇到過的坑這里列成速查表現(xiàn)象可能原因處理方式調(diào)用 path_provider 后拋 MissingPluginExceptionOpenHarmony 分支還沒有實(shí)現(xiàn)對應(yīng)的原生 channel改用內(nèi)置文件路徑策略或暫時(shí)在調(diào)試模式用 Directory.current 定位TextField 點(diǎn)擊后中文輸入法不彈起只能輸英文輸入法框架與 Flutter 引擎通道沖突升級(jí)適配版 SDK并在運(yùn)行時(shí)禁用 suggestions 相關(guān)配置對比驗(yàn)證頁面使用系統(tǒng)返回鍵時(shí)無法正常 pop路由監(jiān)聽在 OHOS 端只走了生命周期沒有走 WidgetsBinding在 App 入口加全局返回統(tǒng)一處理避免依賴默認(rèn) Navigation 行為HAP 安裝到設(shè)備失敗簽名證書未正確配置在 DevEco Studio 里生成調(diào)試證書或檢查項(xiàng)目簽名配置第三個(gè)問題最隱蔽表面看是返回鍵失靈實(shí)際上可能是 OpenHarmony 的窗口管理把返回事件先交給原生側(cè)處理了Flutter 引擎沒有按照 Android 的習(xí)慣自動(dòng)回調(diào)。我最后是在原生入口用一個(gè)統(tǒng)一事件橋接把系統(tǒng)返回鍵轉(zhuǎn)為 Flutter 的導(dǎo)航指令。這個(gè)做法不算優(yōu)雅但至少解決了功能問題而且對品牌列表這類帶層級(jí)導(dǎo)航的頁面非常管用。6.2 性能和狀態(tài)刷新調(diào)優(yōu)品牌列表的數(shù)據(jù)量不大性能瓶頸通常不在這里但幾個(gè)細(xì)節(jié)還是值得留意。不要在 build 方法里執(zhí)行文件讀取或任何異步操作。我的做法是在頁面 initState 里調(diào)用 provider.load然后 UI 只消費(fèi) provider 里的數(shù)據(jù)。否則每次鍵盤彈出、resize列表都會(huì)去讀一次文件很快就會(huì)發(fā)現(xiàn)卡頓。狀態(tài)刷新要克制。addBrand 時(shí)我一次性修改 _brands然后 save 到磁盤最后再調(diào)一次 notifyListeners。如果每改一個(gè)字段就 notify 一次用戶會(huì)看到列表反復(fù)重建而且彈窗關(guān)閉瞬間會(huì)有明顯閃爍。還有一點(diǎn)是列表的 key。品牌列表里我用的是品牌 id不是 list 索引。刪除一個(gè)品牌后Flutter 才能準(zhǔn)確復(fù)用那些沒變化的 item減少無謂的重繪。尤其在后面接入詳情頁返回時(shí)這個(gè)細(xì)節(jié)能讓體驗(yàn)順暢不少。列表項(xiàng)的金額顯示可以用整數(shù)“元”展示但內(nèi)部計(jì)算要用 double。真正統(tǒng)計(jì)時(shí)精度的坑更多建議用分為單位做整型運(yùn)算展示時(shí)再除以 100。這個(gè)我在品牌模型里先預(yù)留了 totalSpent 字段等購買記錄模塊開發(fā)時(shí)就不會(huì)因?yàn)轭愋蛦栴}返工。這次品牌管理做下來我最大的感受是Flutter for OpenHarmony 的成熟度還沒有到可以無腦平推的程度但它也沒有傳言中那么不可用。關(guān)鍵是選對場景品牌管理這種不依賴攝像頭、定位等復(fù)雜原生能力的業(yè)務(wù)模塊恰恰是最適合做驗(yàn)證的。如果你們團(tuán)隊(duì)也在評估要不要把 Flutter 應(yīng)用遷到 OpenHarmony我建議第一件事不是搭建宏偉架構(gòu)而是把業(yè)務(wù)模塊按插件依賴程度排個(gè)序從品牌管理這種弱依賴模塊開始跑通一個(gè)完整閉環(huán)后再逐步擴(kuò)大范圍。別把 OpenHarmony 當(dāng)作另一個(gè) Android 來看文件路徑、輸入法、返回鍵這些細(xì)節(jié)都要在真實(shí)設(shè)備上反復(fù)測。這套品牌管理的實(shí)現(xiàn)雖然簡單但分層、狀態(tài)管理、存儲(chǔ)隔離的思路后續(xù)做任何模塊都能直接復(fù)用。