把 Flutter 搬上 OpenHarmony我第一個完整練手的項(xiàng)目選了數(shù)獨(dú)游戲 App。選它不是圖簡單而是這個題材能把跨端 UI、自繪布局、狀態(tài)管理、邏輯純 Dart 化這幾條關(guān)鍵鏈路全部串起來又不需要任何平臺獨(dú)有能力特別適合做適配驗(yàn)證。真正讓我意外的是整個項(xiàng)目里占調(diào)試時間最久的不是數(shù)獨(dú)生成也不是界面布局而是那個看起來人畜無害的“撤銷”按鈕。這篇就把這個數(shù)獨(dú) App 從架構(gòu)設(shè)計到撤銷功能落地的完整過程拆開講包括快照方案選型、UndoManager 實(shí)現(xiàn)、OpenHarmony 環(huán)境適配、真機(jī)調(diào)試踩坑以及一組可以直接抄的核心代碼。正在研究 Flutter 多端適配、或者想在 OpenHarmony 上做工具類小 App 的開發(fā)者應(yīng)該能從里面拿走不少實(shí)際可用的東西。1. 項(xiàng)目起點(diǎn)與整體架構(gòu)設(shè)計1.1 為什么是“Flutter OpenHarmony 數(shù)獨(dú)”這個組合OpenHarmony 的應(yīng)用開發(fā)主流是它自己的 ArkUI 聲明式范式但 Flutter 在 OpenHarmony 上已經(jīng)有一條非?；钴S的適配分支Flutter 的 Skia 自繪引擎天然不依賴系統(tǒng)控件所以 UI 層搬到 OpenHarmony 時行為一致性比傳統(tǒng) WebView 方案要好得多。我當(dāng)初選這個組合就是為了驗(yàn)證“一套 Flutter 代碼能不能在 OpenHarmony 上跑得干凈”數(shù)獨(dú)正好是壓力最小的驗(yàn)證載體。數(shù)獨(dú)這個游戲邏輯不復(fù)雜但狀態(tài)不少81 個格子、數(shù)字面板、錯誤標(biāo)記、候選數(shù)、當(dāng)前選中格、撤銷歷史。它足以暴露狀態(tài)管理上的問題又不會把問題復(fù)雜到失控。比起做一個列表頁 Demo數(shù)獨(dú)能逼著我把“數(shù)據(jù)層、邏輯層、UI 層”的邊界先厘清否則撤銷功能寫到一半就會變成一團(tuán)亂麻。這個選擇也對“能不能跑”這個問題給出了更真實(shí)的答案如果連帶交互狀態(tài)的小游戲都能在 OpenHarmony 上流暢跑那么普通的工具類和內(nèi)容類 App 基本不用擔(dān)心。1.2 功能范圍界定與版本規(guī)劃我把這個項(xiàng)目的功能范圍卡得很小第一版只做了這幾件事生成一局有唯一解的數(shù)獨(dú)棋盤、點(diǎn)擊格子后從數(shù)字面板選擇數(shù)字、自動檢測同行的沖突并標(biāo)紅、旁邊放一個清除按鈕、右上角放一個撤銷按鈕、左上角放一個“新一局”。候選數(shù)輔助、難度分級、計時器、錯誤次數(shù)統(tǒng)計全部推后。這樣做的原因是撤銷功能的質(zhì)量取決于整個狀態(tài)模型是否干凈而不取決于功能數(shù)量。過早把錯誤提示、計時器、幫助功能疊進(jìn)來會讓“撤銷時到底要回滾哪些狀態(tài)”這個問題變得模糊。我見過不少項(xiàng)目功能很多但撤銷只回滾了棋盤數(shù)字高亮、候選數(shù)、提示狀態(tài)全部殘留玩家只好一遍遍手動清理體驗(yàn)非常奇怪。所以第一版寧缺毋濫把撤銷做成“閉環(huán)”比做出一堆半成品功能更重要。1.3 分層UI、狀態(tài)、邏輯的邊界整個工程目錄我是這樣組織的先有個宏觀印象lib/ main.dart models/ cell_state.dart board_snapshot.dart logic/ sudoku_engine.dart state/ undo_manager.dart sudoku_controller.dart ui/ game_screen.dart number_panel.dart sudoku_grid.dart關(guān)鍵原則只有一條UI 層永遠(yuǎn)不直接寫棋盤數(shù)組。所有修改必須經(jīng)過 SudokuController控制器再決定要不要生成新快照、要不要通知 UI 刷新。這樣做之后“撤銷”就變成了一個純粹的控制器行為把當(dāng)前快照換成歷史快照UI 自然跟著變。為了達(dá)到這個效果我在動手寫 Flutter Widget 之前先花了一天時間把 CellState、BoardSnapshot、UndoManager 三個類全部寫完并用純 Dart 測試腳本跑了一遍模擬操作。事實(shí)證明這個前置投入非常值后面在 OpenHarmony 真機(jī)上出現(xiàn)的幾乎所有疑難問題都跟 UI 本身無關(guān)而是狀態(tài)邊界沒處理好。2. 撤銷功能的前置思考先想清楚要撤銷“什么”2.1 “一步”到底指什么做撤銷功能第一件要想清楚的事是“一次撤銷到底撤回哪一個動作”。這個定義如果含糊后面所有邏輯都是糊涂賬。我當(dāng)時列了三個候選定義按“手指點(diǎn)擊”算一步玩家連續(xù)點(diǎn)了兩次“刪除候選數(shù)”撤銷也要一步一步回退體驗(yàn)很碎。按“格子的有效數(shù)值變化”算一步選手在同一個格里改三次數(shù)字那三次修改就是三個獨(dú)立歷史節(jié)點(diǎn)。按“一次完整編輯會話”算一步一個格子沒定下來之前所有修改算一步提交后合并。我最后選了第二種也就是按“格子數(shù)值或候選數(shù)狀態(tài)的一次有效變化”來記錄。理由是它最符合玩家直覺玩家每一步操作都有一個明確結(jié)果撤銷時能一步到位中間不會出現(xiàn)“刪除了一下卻沒變化”的空歷史。這個決策直接影響 UndoManager 的 push 時機(jī)。不是每次按鍵都 push而是只有當(dāng)格子里的實(shí)際狀態(tài)發(fā)生變化時才 push。比如玩家先填了 5又填了 5第二次操作由于沒有產(chǎn)生任何新狀態(tài)就不應(yīng)該記入歷史。2.2 快照方案還是命令模式做過編輯器類應(yīng)用的人一聽到撤銷第一反應(yīng)往往是“命令模式”。命令模式把所有操作抽象成一個個 Command每個 Command 記錄執(zhí)行和反向執(zhí)行邏輯然后維護(hù) undo 棧和 redo 棧。這個思路在大型文檔編輯器、繪圖軟件里是標(biāo)準(zhǔn)解因?yàn)橐粡垐D片或一篇文檔的內(nèi)存快照大到不可接受。但數(shù)獨(dú)棋盤有 81 個格子每個格子的狀態(tài)也就是“數(shù)字 候選數(shù)位掩碼 是否給定的標(biāo)志”滿打滿算幾十個字節(jié)。一個快照撐死 1KB存 200 步歷史也就 200KB 左右放在今天任何移動設(shè)備上都不值一提。所以我直接選了“不可變快照 歷史棧”的方案每次格子狀態(tài)發(fā)生變化就把整張棋盤當(dāng)前狀態(tài)復(fù)制一份存進(jìn)歷史棧撤銷時直接切回上一份快照。這看起來“笨”但它是這個場景下最穩(wěn)定、最簡單、最少 bug 的方案。命令模式雖然優(yōu)雅但需要為每一個操作類型實(shí)現(xiàn) execute 和 undo還要處理“撤銷后重新計算聯(lián)動狀態(tài)”的問題。數(shù)獨(dú)這種小棋盤用快照換邏輯簡單非常劃算。2.3 快照里到底要放哪些字段快照內(nèi)容我最初只放了 81 個數(shù)字真機(jī)一跑就發(fā)現(xiàn)問題玩家撤銷之后數(shù)字倒是回退了但之前填錯數(shù)字時產(chǎn)生的紅色沖突標(biāo)記還留在屏幕上。原因很簡單沖突狀態(tài)不是獨(dú)立數(shù)據(jù)而是從棋盤數(shù)字推導(dǎo)出來的我在第一次實(shí)現(xiàn)時卻沒有在撤銷后重新推導(dǎo)。所以我在 BoardSnapshot 里最終放了兩個東西每個格子的數(shù)字以及每個格子的候選數(shù)位掩碼。格子是否選中、是否標(biāo)紅都屬于“派生狀態(tài)”撤銷后由 SudokuController 根據(jù)當(dāng)前棋盤重新計算一遍而不是直接塞進(jìn)快照。這個取舍很重要。如果什么狀態(tài)都往快照里塞快照之間互相牽制很容易出現(xiàn)“數(shù)字恢復(fù)了但 UI 狀態(tài)沒恢復(fù)”的詭異現(xiàn)象。把派生狀態(tài)排除在快照之外撤銷邏輯就只負(fù)責(zé)一件事讓真實(shí)數(shù)據(jù)回到過去然后讓所有 UI 重新從真實(shí)數(shù)據(jù)算一遍。3. 工程落地Flutter for OpenHarmony 環(huán)境準(zhǔn)備3.1 OpenHarmony SDK 與 Flutter 適配分支OpenHarmony 上跑 Flutter首先要準(zhǔn)備好一套適配分支的 Flutter SDK因?yàn)?Flutter 官方主干還沒有把 OpenHarmony 作為一等平臺支持。具體步驟大概是這樣# 1. 安裝 OpenHarmony SDK并記錄 SDK 路徑 export OPENHARMONY_SDK_HOME/path/to/ohos-sdk # 2. 拉取支持 OpenHarmony 的 Flutter SDK 分支 # 這里用一個穩(wěn)定的 release 分支 # 3. 把 SDK 相關(guān)路徑加入 PATH export PATH/path/to/flutter-for-ohos/bin:$PATH # 4. 檢查環(huán)境 flutter doctorflutter doctor 之后如果一切正常再用flutter devices能看到通過調(diào)試橋連接的真機(jī)或模擬器說明工程鏈路已經(jīng)通了一半。這里有個比較容易踩的坑Flutter 工程默認(rèn)從官方源拉依賴包但在 OpenHarmony 適配環(huán)境里很多包沒有兼容的二進(jìn)制產(chǎn)物所以我直接把依賴源切到了對應(yīng)的兼容倉庫純 Dart 包則不受影響。3.2 依賴管理注意點(diǎn)數(shù)獨(dú) App 全程沒有加任何帶原生代碼的第三方插件。這確實(shí)是刻意為之。在 OpenHarmony 適配早期Flutter 插件生態(tài)還沒有完全遷移凡是走 MethodChannel 的插件都需要對應(yīng) OpenHarmony 原生側(cè)的實(shí)現(xiàn)否則編譯到原生部分就會斷。數(shù)獨(dú)邏輯純 Dart 實(shí)現(xiàn)UI 由 Flutter 自繪完成所以從一開始就規(guī)避了整個插件兼容性問題。最終依賴極簡只有 flutter 本身和一個小狀態(tài)管理庫。之所以沒用更重的狀態(tài)管理框架是因?yàn)檫@個項(xiàng)目狀態(tài)足夠集中ChangeNotifier 配合一個控制器類已經(jīng)夠用。多加一層框架反而會讓“撤銷時重新計算派生狀態(tài)”這件事變繞。給同樣入手的開發(fā)者一個建議先別急著引一堆狀態(tài)管理包把“誰擁有狀態(tài)、誰負(fù)責(zé)改狀態(tài)”想清楚比選哪個框架重要得多。3.3 工程目錄與模塊劃分代碼層的目錄我在前面已經(jīng)給了這里補(bǔ)充說明每層職責(zé)。models 層只描述數(shù)據(jù)不含任何業(yè)務(wù)邏輯。logic 層是純函數(shù)集合負(fù)責(zé)數(shù)獨(dú)生成、合法性判斷、沖突檢測。state 層是控制器和撤銷管理器是整個 App 的“大腦”。ui 層只負(fù)責(zé)把 state 渲染出來不存儲任何游戲狀態(tài)。這樣的分層雖然一開始寫起來多幾個文件但調(diào)試撤銷相關(guān) bug 時非常幸福問題要么在 state 層要么在 ui 層定位范圍瞬間縮小一半。我在真機(jī)上遇到“撤銷后數(shù)字面板高亮錯位”排查時直接跳過 logic 層只查 controller 里的派生狀態(tài)計算幾分鐘就找到原因。4. 核心實(shí)現(xiàn)數(shù)據(jù)模型與撤銷管理器4.1 CellState 與 BoardSnapshot數(shù)據(jù)模型的不可變是快照撤銷的命根子。如果同一個 CellState 對象被外部修改了那么排進(jìn)歷史棧的所有快照都會跟著變撤銷就會徹底失效。所以我所有的數(shù)據(jù)類都只提供 copyWith沒有提供 setter。class CellState { final int number; // 0 表示未填 final int candidates; // 9 位二進(jìn)制每一位代表一個候選數(shù) final bool isGiven; // 是否為題目初始給定 const CellState({ this.number 0, this.candidates 0, this.isGiven false, }); CellState copyWith({ int? number, int? candidates, bool? isGiven, }) { return CellState( number: number ?? this.number, candidates: candidates ?? this.candidates, isGiven: isGiven ?? this.isGiven, ); } CellState clone() copyWith(number: number, candidates: candidates, isGiven: isGiven); }候選數(shù)用 int 的位掩碼而不是 Set因?yàn)樵?Dart 里每個 Set 對象都是堆分配復(fù)制 81 個格子時會產(chǎn)生大量垃圾對象。位掩碼只是一個 int復(fù)制成本幾乎為零后面真機(jī)跑起來 GC 壓力也小很多。BoardSnapshot 就更直接了持有一個不可變列表。class BoardSnapshot { final ListCellState cells; BoardSnapshot(ListCellState cells) : cells List.unmodifiable(cells); BoardSnapshot clone() { return BoardSnapshot(cells.map((c) c.clone()).toList()); } }我在構(gòu)造函數(shù)里強(qiáng)制 List.unmodifiable就是為了防止外部拿到列表后往里塞東西?？煺障到y(tǒng)的第一原則一旦進(jìn)入歷史棧任何代碼都不能改動它。4.2 UndoManager 的設(shè)計UndoManager 是所有撤銷邏輯的收口我把它設(shè)計得很小只維護(hù)一個歷史列表和一個當(dāng)前游標(biāo)class UndoManager { final ListBoardSnapshot _history []; int _currentIndex -1; bool get canUndo _currentIndex 0; void push(BoardSnapshot snapshot) { // 先把當(dāng)前游標(biāo)之后的歷史丟棄再追加新快照 if (_currentIndex _history.length - 1) { _history.removeRange(_currentIndex 1, _history.length); } _history.add(snapshot); _currentIndex; } BoardSnapshot? undo() { if (!canUndo) return null; _currentIndex--; return _history[_currentIndex]; } BoardSnapshot? redo() { if (_currentIndex _history.length - 1) return null; _currentIndex; return _history[_currentIndex]; } }注意 push 里先截斷后半段歷史這是為了實(shí)現(xiàn)“新操作會清掉未來的 redo 分支”。比如玩家撤銷三次改了一個數(shù)字那么原來的 redo 歷史就應(yīng)該全部作廢不然就會出現(xiàn)“時間線分叉”。整個 UndoManager 不關(guān)心數(shù)獨(dú)規(guī)則它只處理“快照進(jìn)?！焙汀坝螛?biāo)回退”兩件事。這讓我可以在不碰數(shù)獨(dú)功能的情況下單獨(dú)給 UndoManager 寫單元測試覆蓋連續(xù) undo、undo 之后 push、空棧調(diào)用 undo 等邊界情況。4.3 數(shù)獨(dú)引擎與沖突檢測數(shù)獨(dú)引擎我只寫了兩部分生成題目、檢測沖突。生成題目的簡單做法是先用回溯填滿一個完整終盤再按隨機(jī)順序挖去一些數(shù)字。完整回溯代碼比較長核心思路就是逐格嘗試 1 到 9并跳過同行同列同宮已經(jīng)出現(xiàn)過的數(shù)字。挖洞環(huán)節(jié)我做了個輕量約束保證每個被挖掉的格子都還有唯一答案。嚴(yán)格生成唯一解數(shù)獨(dú)需要額外做“是否有且僅有一個解”的判斷我在這版里用的是隨機(jī)挖洞加基礎(chǔ)校驗(yàn)先把第一版跑起來難度均衡可以放到后面優(yōu)化。沖突檢測是撤銷后派生狀態(tài)重算的關(guān)鍵。它不修改任何數(shù)據(jù)只返回一個布爾列表供 UI 標(biāo)紅使用Listbool computeConflicts(BoardSnapshot snapshot) { final cells snapshot.cells; final conflict Listbool.filled(81, false); bool checkConflict(int a, int b) { if (cells[a].number 0 || cells[b].number 0) return false; return cells[a].number cells[b].number; } // 檢查行、列、宮有沖突就把兩個格子都標(biāo)紅 for (int row 0; row 9; row) { final map int, Listint{}; for (int col 0; col 9; col) { final index row * 9 col; final v cells[index].number; if (v 0) continue; map.putIfAbsent(v, () []).add(index); } for (final list in map.values) { if (list.length 1) { for (final index in list) { conflict[index] true; } } } } // 列和宮同理省略按同思路處理 return conflict; }這個函數(shù)不依賴歷史每次調(diào)用都從當(dāng)前快照重新計算因此撤銷后 UI 拿到的沖突標(biāo)記天然就是正確的。4.4 SudokuController把編輯動作變成狀態(tài)變化SudokuController 繼承 ChangeNotifier是整個狀態(tài)流轉(zhuǎn)的樞紐。它內(nèi)部持有一個當(dāng)前快照、一個 UndoManager、以及一份沖突列表。UI 上每次點(diǎn)擊數(shù)字最終都調(diào)用同一個方法。class SudokuController extends ChangeNotifier { SudokuController() : _undoManager UndoManager(); final UndoManager _undoManager; BoardSnapshot? _currentSnapshot; Listbool _conflicts List.filled(81, false); BoardSnapshot? get currentSnapshot _currentSnapshot; Listbool get conflicts _conflicts; bool get canUndo _undoManager.canUndo; void loadPuzzle(BoardSnapshot puzzle) { _currentSnapshot puzzle; _undoManager.clear(); _refresh(); } void fillCell(int index, int number) { if (_currentSnapshot null) return; final cells _currentSnapshot!.cells; final cell cells[index]; if (cell.isGiven) return; if (cell.number number) return; final nextCells ListCellState.of(cells); nextCells[index] cell.copyWith(number: number, candidates: 0); final nextSnapshot BoardSnapshot(nextCells); _undoManager.push(nextSnapshot); _currentSnapshot nextSnapshot; _refresh(); } void undo() { if (_currentSnapshot null) return; final snapshot _undoManager.undo(); if (snapshot ! null) { _currentSnapshot snapshot; _refresh(); } } void _refresh() { _conflicts computeConflicts(_currentSnapshot!); notifyListeners(); } }這里有幾個細(xì)節(jié)值得單獨(dú)說。第一fillCell 里先判斷格子是不是給定格題目給定的格子不能被玩家修改。第二如果格子數(shù)字沒變不 push 歷史避免記錄無意義操作。第三每次狀態(tài)變化后調(diào)用 _refresh重新計算沖突并通知 UI這樣撤銷時沖突標(biāo)記也會自動重算。5. 撤銷按鈕的 UI 接入與交互細(xì)節(jié)5.1 AppBar 按鈕與禁用態(tài)UI 側(cè)接入撤銷非常直白頂部工具欄放一個 IconButton監(jiān)聽 controller.canUndo 的值來決定它是否置灰。用 AnimatedBuilder 包住按鈕這樣每次 undo 或 push 后canUndo 變化會立刻反映到界面上。實(shí)際操作中我還做了一個小優(yōu)化當(dāng)可以撤銷時按鈕用實(shí)色圖標(biāo)不可撤銷時用半透明圖標(biāo)視覺上給玩家一個明確反饋。這個細(xì)節(jié)成本極低但能讓玩家第一時間確認(rèn)“剛才那一步有沒有被記錄”。5.2 完整交互鏈路一次完整操作的事件流是玩家點(diǎn)擊棋盤某個格子UI 記錄當(dāng)前選中格玩家在底部數(shù)字面板點(diǎn)一個數(shù)字?jǐn)?shù)字面板把請求發(fā)給 SudokuController.fillCell控制器生成新快照、push 進(jìn) UndoManager、重算沖突、notifyListeners整個棋盤 Widget 重建數(shù)字更新沖突標(biāo)紅刷新。撤銷按鈕的事件流是玩家點(diǎn)撤銷控制器從 UndoManager 取出上一份快照把當(dāng)前快照替換成歷史快照重算沖突并通知 UI棋盤 Widget 重建數(shù)字和沖突標(biāo)記一并恢復(fù)。兩條鏈路最終都匯聚到“刷新”這一步所以 UI 層完全不需要區(qū)分“這是正常填寫”還是“這是撤銷回退”它每次都是全量重算天然不會出現(xiàn)殘留狀態(tài)。5.3 連點(diǎn)防抖與撤銷時的選中狀態(tài)真機(jī)調(diào)試時我發(fā)現(xiàn)一個體驗(yàn)問題快速連點(diǎn)撤銷按鈕會在極短時間內(nèi)連續(xù) pop 多份歷史玩家本來只想回退一步結(jié)果連退了四五步。解決辦法是加一個最簡單的防抖標(biāo)志用 runAsync 或 async 方法保證上一次撤銷的 UI 刷新完成之前不接受下一次撤銷請求。bool _isUndoing false; Futurevoid undo() async { if (_isUndoing) return; _isUndoing true; final snapshot _undoManager.undo(); if (snapshot ! null) { _currentSnapshot snapshot; _refresh(); await WidgetsBinding.instance.endOfFrame; } _isUndoing false; }另外還有個容易忽略的小點(diǎn)撤銷之后棋盤上應(yīng)該選中哪個格子我的選擇是保留當(dāng)前選中格不變。因?yàn)榭煺绽餂]有保存“選中格”所以撤銷不會打斷玩家的操作節(jié)奏玩家可以立刻繼續(xù)在同一個格子里試下一個數(shù)字這是體驗(yàn)上比較順的做法。6. 真機(jī)調(diào)試中的常見問題實(shí)錄6.1 首次構(gòu)建非常慢且構(gòu)建產(chǎn)物路徑有坑在 OpenHarmony 上第一次構(gòu)建 Flutter 工程速度會比普通 Flutter 項(xiàng)目慢不少原因是除了 Dart 層編譯還要經(jīng)歷 OpenHarmony 原生工程的編譯和資源打包。這個階段最容易出現(xiàn)的問題是找不到 SDK 路徑、簽名配置缺失、目標(biāo)設(shè)備不識別。我的排查順序是先flutter doctor看環(huán)境項(xiàng)再用flutter devices看設(shè)備連接最后檢查工程的簽名配置。把這三個環(huán)節(jié)單獨(dú)打通再執(zhí)行完整構(gòu)建基本能避免“編譯一小時最后報錯發(fā)現(xiàn)是設(shè)備沒連上”的尷尬。另外建議構(gòu)建設(shè)備只留一臺不要同時接模擬器和多臺真機(jī)否則 OpenHarmony 調(diào)試橋的默認(rèn)選擇和 Flutter devices 的展示可能不一致。6.2 撤銷后紅色沖突標(biāo)記殘留這個問題我在前面提過一次但值得再展開說。第一版快照只保存了格子數(shù)字沖突是進(jìn)入歷史前就算好的一份列表撤銷時直接恢復(fù)那份舊列表?？此茮]問題但下一步操作一旦改變了這個格子沖突列表就和新棋盤對不上了。正確的做法就是把沖突當(dāng)派生狀態(tài)每次快照切換之后強(qiáng)制重算。我后來把 computeConflicts 的調(diào)用放進(jìn)了 _refresh并把所有進(jìn)入 _refresh 的路徑統(tǒng)一成一條問題就消失了。這個坑的核心教訓(xùn)是哪種狀態(tài)屬于“源數(shù)據(jù)”哪種狀態(tài)屬于“可推導(dǎo)數(shù)據(jù)”這個分類必須在項(xiàng)目開始時想明白。6.3 快照復(fù)制導(dǎo)致的偶發(fā)掉幀理論上 81 個格子復(fù)制不該有性能問題但在 OpenHarmony 模擬器上我確實(shí)觀察到偶發(fā)掉幀。查了性能分析器才發(fā)現(xiàn)問題出在候選數(shù)用 Set 的那一版實(shí)現(xiàn)上。每復(fù)制一個格子就要 new 一個 Set一次復(fù)制 81 個 Set歷史棧里又累積幾十份GC 壓力被放大。把 Set 改成 int 位掩碼后GC 壓力立刻降下來。這個優(yōu)化不是提前做性能設(shè)計而是在實(shí)際設(shè)備上看到問題才動手改的但好在數(shù)據(jù)模型封裝得干凈UI 層根本沒有感知到內(nèi)部表示變化。這也再次說明面向?qū)ο蠓庋b在狀態(tài)管理里的價值。6.4 后臺切換回來之后 UI 和狀態(tài)不一致OpenHarmony 上調(diào)試時發(fā)現(xiàn)App 切到后臺再切回來如果中間發(fā)生過多次操作界面偶爾會顯示舊狀態(tài)。根因是 Flutter 層面的生命周期事件與 OpenHarmony 側(cè)的事件傳遞時機(jī)不完全同步有些繪制發(fā)生在狀態(tài)已經(jīng)更新之前。我加的兜底處理是在 App 回到前臺時調(diào)用一次強(qiáng)制刷新用依賴注入的方式讓 SudokuController 收到生命周期回調(diào)任何 view 重建都不再走“緩存狀態(tài)”而是從 controller 當(dāng)前快照重新讀取。// 回到前臺時 controller.forceRefresh();forceRefresh 內(nèi)部只做一件事重新計算沖突列表再 notifyListeners。實(shí)踐證明這個辦法簡單可靠也不影響正常流程。如果你在做類似跨端項(xiàng)目遇到“界面偶爾停在舊樣子”的玄學(xué)問題可以先往生命周期事件上想。7. 收獲、優(yōu)化方向與給后來者的建議7.1 撤銷功能帶來的狀態(tài)管理啟示做完這個項(xiàng)目我對撤銷功能最大的感悟是撤銷不是一個“按鈕功能”而是一套狀態(tài)模型設(shè)計。如果你把棋盤數(shù)據(jù)、候選數(shù)、沖突狀態(tài)、歷史列表、當(dāng)前游標(biāo)這些概念分清楚撤銷只是“把當(dāng)前指針往前移一格”。反過來如果狀態(tài)東一塊西一塊散落在各個 Widget 里那撤銷無論怎么做都是災(zāi)難。現(xiàn)在再看網(wǎng)上很多“撤銷功能實(shí)現(xiàn)教程”大多數(shù)只是給玩家按鈕上加了個“保存上一份二維數(shù)組”的邏輯。棋盤數(shù)字能恢復(fù)但高亮、候選數(shù)、禁用態(tài)全部遺漏。這類實(shí)現(xiàn)看著能用一遇到稍微復(fù)雜一點(diǎn)的狀態(tài)聯(lián)動就崩。數(shù)獨(dú)這個項(xiàng)目恰好把這種復(fù)雜的聯(lián)動放大值得每個做狀態(tài)管理的開發(fā)者親手寫一遍。7.2 后續(xù)想補(bǔ)的方向第一版跑通之后我已經(jīng)列好了幾個擴(kuò)展方向。首先是 redoUndoManager 里其實(shí)已經(jīng)預(yù)留了 redo 方法只需要在 UI 上加一個按鈕其次是自動候選數(shù)模式玩家填入數(shù)字后自動移除同行、同列、同宮的候選數(shù)這個功能的數(shù)據(jù)結(jié)構(gòu)已經(jīng)支持只是需要把候選數(shù)聯(lián)動邏輯從空實(shí)現(xiàn)變成真正的推導(dǎo)算法再往后是難度分級和題目庫目前生成算法是純隨機(jī)挖洞后續(xù)可以改成按難度模板生成。還有一個我自己很有興趣的方向是“回放模式”利用現(xiàn)在保存的歷史快照把玩家整局操作完整回放出來用來做錯題分析。這種能力在快照方案下幾乎白送只要遍歷歷史棧就行放到命令模式方案里反而要額外實(shí)現(xiàn)查詢接口。可見選擇快照方案雖然看起來“笨”卻能省下很多隱形成本。7.3 給后來者的具體建議如果讓我重新做一遍我會把流程壓縮成三步。第一步絕不寫 UI先在純 Dart 環(huán)境里把 CellState、BoardSnapshot、UndoManager、SudokuController 寫完并用測試腳本模擬一百步隨機(jī)操作。第二步再接入 Flutter UI先只做棋盤的拉伸和數(shù)據(jù)顯示確認(rèn)狀態(tài)能正確驅(qū)動 UI。第三步最后加撤銷按鈕和數(shù)字面板專門針對 undo 連續(xù)調(diào)用和混合操作做排查。另外一個小建議給 UndoManager 寫測試時不只是測試功能“能用”而是主動寫出這些場景——空棧 undo、連續(xù) undo 到底、push 后舊 redo 分支是否清空、同一格子連續(xù)填相同數(shù)字是否產(chǎn)生多余歷史。這幾個場景幾乎覆蓋了撤銷功能 80% 的 bug 來源測試通過之后UI 層的接入工作會變得異常輕松。這次實(shí)戰(zhàn)的最大體會是在 OpenHarmony 上跑 Flutter工程鏈路和工具鏈確實(shí)還有一些“毛刺”但純 Dart 層的代碼幾乎感覺不到跨平臺差異。撤銷功能之所以能順利落地靠的并不是什么高級技巧而是把狀態(tài)邊界劃清楚把不可變快照這條底線守住。數(shù)獨(dú)這個項(xiàng)目后續(xù)還能繼續(xù)擴(kuò)展出不少玩法但基礎(chǔ)的狀態(tài)模型一旦打牢再加什么功能都不會動搖它。