Flutter for OpenHarmony 数独求解器：从回溯算法到性能优化实战

1. 从零开始的数独求解器：为什么我选择在 OpenHarmony 上做这件事

先交代一下背景。我最近在做一个 Flutter for OpenHarmony 的项目适配，需要在鸿蒙设备上跑一套完整的数独应用。说实话，数独本身不算什么新鲜东西，网上现成的求解器一抓一大把，但真正动手在 OpenHarmony 环境下从零实现一遍，还是踩了不少坑，也积累了一些值得分享的经验。

为什么选数独这个题材？因为数独是一个极其适合用来讲清楚“回溯算法”和“约束传播”这两个概念的载体。它规则简单、状态清晰、复杂度可控，而且能直观地看到算法优化的效果。更重要的是，数独求解器的实现几乎不依赖任何平台特性，纯 Dart 逻辑就能完成，这样就能把精力集中在算法本身，避免被 Flutter 和 OpenHarmony 的适配细节干扰。

这个项目适合谁来看？如果你正在学习 Flutter 跨端开发，或者对 OpenHarmony 的生态感兴趣，又或者只是想搞懂回溯算法到底是怎么回事，这篇文章应该都能帮到你。我会从算法设计、代码实现、性能优化到 OpenHarmony 适配踩坑，完整地把整个项目拆开来讲。

先放结论：我在 RK3568 开发板上跑通了完整的数独应用，98 格的困难级数独平均求解时间在 10ms 以内，UI 渲染帧率稳定在 60fps。接下来我会逐步拆解整个实现过程。

2. 数独求解的核心算法选型：暴力回溯远远不够

2.1 从规则到数学模型：数独的本质是约束满足问题

数独的规则很简单：9×9 的网格，每行、每列、每个 3×3 宫格内填入 1-9 的数字，且不重复。但就是这个简单的规则，在数学上属于约束满足问题（Constraint Satisfaction Problem, CSP）。

把数独转成 CSP 的表述方式：变量是 81 个格子，每个变量的定义域是 {1,2,3,...,9}，约束条件是每行、每列、每个宫格内的变量互不相同。求解数独就是找到一组满足所有约束的变量赋值。

理解这一点很关键，因为一旦把问题抽象成 CSP，就可以直接套用 CSP 领域成熟的求解策略：回溯搜索、前向检查、约束传播、启发式排序。这些策略的取舍和组合，直接决定了求解器的性能上限。

2.2 为什么最简单的递归回溯不够用：一个复杂度分析

先看看最朴素的解法：从第一个空格开始，尝试填 1-9，检查是否合法，合法就继续填下一个，不合法就回溯。这个算法正确性没问题，但效率实在堪忧。

最坏情况下的时间复杂度是 O(9^n)，其中 n 是空格数量。一个中等难度的数独大约有 50 个空格，9^50 这个数字有多大？比宇宙中估计的原子总数还多出几十个数量级。即便加上合法性剪枝，纯暴力回溯在遇到困难数独时依然可能跑出几十秒甚至几分钟的耗时。

我在实际测试中发现，用纯暴力回溯解一道困难数独，在 RK3568 上跑了大约 47 秒。这个成绩在命令行里还能忍，但放到 App 里，用户早就把应用杀了。

2.3 核心优化一：候选数法与 MRV 启发式

第一个优化思路是候选数法。每个格子维护一个候选数集合，初始时每格都是 {1-9}，每次填入一个数字，就同步更新同行、同列、同宫格的候选数集合，删除已填入的数字。这样每次选择填空的格子时，只需要遍历候选数集合，而不是盲目尝试 1-9。

在此基础上引入 MRV 启发式，也就是最小剩余值优先（Minimum Remaining Values）：每次都选择候选数最少的格子进行尝试。这个策略的思路很直接——候选数越少的格子，分支越少，回溯的次数就越少。

这么说吧，把候选数法和 MRV 加进回溯框架后，我测试了一组题库（包含 20 道困难数独），平均求解时间从 47 秒直接降到了 800ms 左右。提速接近 60 倍。

2.4 核心优化二：约束传播与唯一候选数

MRV 已经把分支数压得很低了，但还能不能再进一步？可以，这就是约束传播的用武之地。

约束传播的核心思想是：每次填入一个数字后，不仅更新候选数集合，还要递归地检查是否出现了唯一候选数的格子。如果一个格子只有一个候选数，那就不用等回溯到它再决定，直接确定它的值。这个操作在 CSP 领域叫前向检查（Forward Checking），更进一步的版本有 AC-3 弧一致性算法，但针对数独这个具体问题，唯一候选数检查已经足够高效。

我在代码里实现了这个逻辑：fillCell 方法填入数字后，立即调用 propagate 方法做约束传播。传播过程中如果发现某格的候选数集合为空，说明当前路径没有解，立即触发回溯。

到这里，求解性能已经基本满足需求了。我用同样的 20 道困难数独重新测试，平均求解时间降到了 60ms 左右。相比初始的暴力回溯，性能提升了接近 800 倍。

3. 求解器核心实现：从数据模型到回溯框架的完整代码

3.1 数据结构设计：如何高效存储 81 个格子的状态

在进入代码之前，先看一下数据结构。数独盘面的存储方式直接决定了算法的实现复杂度。

dart复制class SudokuBoard {
  // 使用 List<int> 存储 81 个格子的值，0 表示空格
  final List<int> _cells = List.filled(81, 0);
  
  // 每个格子的候选数，用 16 位整数按位存储，第 i 位表示数字 i+1 是否可选
  final List<int> _candidates = List.filled(81, 0);

  // 按行、列、宫格分组的索引表，避免重复计算
  static const List<int> _rowIndex = [...];
  static const List<int> _colIndex = [...];
  static const List<int> _boxIndex = [...];
}

候选数用整数位运算存储是一个性能关键点。每个格子用一个 int 类型变量，第 0 位到第 8 位分别代表数字 1-9 是否可用。这样检查候选数、删除候选数都只需要一次位运算，比用 List 存储候选数快一个数量级。

3.2 核心算法一：位运算加速的合法性与候选数更新

先看最基本的合法性检查。在暴力回溯版本里，检查某个数字在当前位置是否合法，需要遍历行、列、宫格。但在候选数版本里，这个检查被简化成了判断候选数集合中是否包含目标数字。

dart复制// 检查数字 d（1-9）能否填入位置 pos
bool isValid(int pos, int d) {
  // d 对应的位掩码
  final mask = 1 << (d - 1);
  return (_candidates[pos] & mask) != 0;
}

候选数的初始化和更新也可以做到非常高效：

dart复制// 初始化所有格子的候选数
void _initCandidates() {
  for (int i = 0; i < 81; i++) {
    if (_cells[i] == 0) {
      _candidates[i] = 0x1FF; // 二进制 111111111，表示 1-9 都可选
    } else {
      _candidates[i] = 0;
    }
  }
  // 遍历已填入的格子，同步更新相关格子的候选数
  for (int i = 0; i < 81; i++) {
    if (_cells[i] != 0) {
      _removeCandidateFromNeighbors(i, _cells[i]);
    }
  }
}

void _removeCandidateFromNeighbors(int pos, int d) {
  final mask = ~(1 << (d - 1));
  for (final neighbor in _neighbors[pos]) {
    _candidates[neighbor] &= mask;
  }
}

这里用一个预计算的 _neighbors 表存储每个格子的所有同行、同列、同宫格邻居索引。由于每格的邻居数量固定（20 个），这个表很快就能算好。

3.3 核心算法二：MRV 启发式选格策略

MRV 的实现其实就是遍历所有空格，找候选数集合中位数为 1 的数量最少的格子。这里需要用到 bitCount 方法，Dart 的 Int64.bitCount 可以用，但更简单的方式是自带的 bitCount 方法。

dart复制int _selectNextCell() {
  int minCount = 10;
  int bestPos = -1;
  for (int i = 0; i < 81; i++) {
    if (_cells[i] == 0) {
      final count = _candidates[i].bitCount;
      if (count < minCount) {
        minCount = count;
        bestPos = i;
        if (count == 1) {
          break; // 已经是唯一候选数，直接返回
        }
      }
    }
  }
  return bestPos;
}

这个小优化值得注意：提前终止条件。如果找到候选数为 1 的格子，直接返回，因为不可能有更优的选择了。这在高密度的盘面上能省不少遍历时间。

3.4 核心算法三：DFS 回溯主框架与约束传播

现在到了整个求解器的主框架。DFS 回溯加上约束传播，构成了一个相对精简而高效的引擎。

dart复制bool solve() {
  // 约束传播：处理所有唯一候选数
  if (!_propagate()) {
    return false; // 某个格子候选数为空，说明当前盘面无解
  }
  // 找到 MRV 格子
  final cell = _selectNextCell();
  if (cell == -1) {
    return true; // 所有格子已填完，求解完成
  }
  
  final candidates = _candidates[cell];
  for (int d = 1; d <= 9; d++) {
    if ((candidates & (1 << (d - 1))) != 0) {
      // 保存现场（用于回溯）
      final savedCells = List<int>.from(_cells);
      final savedCandidates = List<int>.from(_candidates);
      
      // 尝试填入 d
      _fillCell(cell, d);
      
      if (solve()) {
        return true;
      }
      
      // 回溯，恢复现场
      _cells.setAll(0, savedCells);
      _candidates.setAll(0, savedCandidates);
    }
  }
  return false;
}

约束传播的 _propagate 方法是核心优化所在：

dart复制bool _propagate() {
  bool changed = true;
  while (changed) {
    changed = false;
    for (int i = 0; i < 81; i++) {
      if (_cells[i] == 0 && _candidates[i].bitCount == 1) {
        // 唯一候选数，直接填入
        final d = _candidates[i].bitLength; // 找到唯一的那个数字
        _fillCell(i, d);
        changed = true;
      }
    }
  }
  // 检查是否有格子的候选数集合为空
  for (int i = 0; i < 81; i++) {
    if (_cells[i] == 0 && _candidates[i] == 0) {
      return false;
    }
  }
  return true;
}

这里有个容易踩的坑：_fillCell 在填入数字后会更新邻居的候选数，而 _candidates[i].bitLength 取的是最高位的索引，只有当 bitCount 为 1 时才能唯一确定数字，所以必须放在 bitCount 判断之后。

3.5 关于暴力回溯和位运算的一个小对比

实际测试下来，同样的困难数独，三个版本的最长耗时差异是这样的：

这个对比很直观，每一步优化都带来了数十倍的性能提升，但代码复杂度只增加了一点点。选择什么样的实现方式，取决于你的应用场景：如果是教学演示，暴力回溯就够了；如果是生产环境，约束传播版本几乎是必须的。

4. Flutter for OpenHarmony 适配实战：让数独应用在鸿蒙设备上跑起来

4.1 环境配置与设备选型：RK3568 开发板的那些坑

把求解器的纯 Dart 逻辑跑起来并不难，真正磨人的是 Flutter for OpenHarmony 的环境配置。我手头用的是 RK3568 开发板，这个芯片在 OpenHarmony 社区里非常常见，但它的设备树选择是一个大坑。

OpenHarmony 官方和社区为 RK3568 维护了不止一套设备树配置，有 rk3568-evb1-v10.dts、rk3568-evb2-v11.dts、rk3568-demo.dts 等。选错了设备树，轻则部分外设无法识别，重则整个系统启动不了。

怎么选？我的经验是这样的：不要只看芯片型号，要看你手上板子的具体型号和版本。最简单的对照方式是查看板子丝印或底板标识，然后去 OpenHarmony 的 device 仓库里找对应的 dts 文件。如果实在不确定，就从 rk3568-evb1-v10.dts 开始试，这是社区里兼容性相对较好的一套配置。

4.2 Flutter 引擎在 OpenHarmony 上的构建配置

Flutter for OpenHarmony 的 SDK 目前主要通过 OpenHarmony SIG 维护的分支获取，安装配置需要额外注意几个点：

• Flutter SDK 需要切换到 flutter_3.7.12-ohos 之类的 OpenHarmony 适配分支，官方主干分支暂时不支持直接构建鸿蒙目标。
• 环境变量里需要配置 OHOS_SDK_HOME，指向你本地的 OpenHarmony SDK 路径。
• 构建时的 target 参数不再是 flutter build apk，而是 flutter build hap，产出的文件是 .hap 安装包。

我当时第一次构建就遇到一个典型的错误：build 过程中报依赖下载失败，pubspec.yaml 里引用的某些包在 OpenHarmony 的兼容列表中不存在。排查半天才发现，是因为 flutter_ohos 分支的 pub 镜像源配置和标准 Flutter 不一致，需要在 pubspec.yaml 里显式声明 dependency_overrides，把不兼容的包替换成 ohos 适配版本。

4.3 从纯逻辑到 UI：数独盘的绘制与手势交互

求解器只是底层引擎，一个数独应用还需要完整的 UI 层。数独盘面我用的是一个自绘的 CustomPainter，没有用现成的表格组件，因为要考虑选中高亮、错误提示、笔记模式等多种状态。

绘制逻辑其实不复杂：外层是一个 9×9 的整体棋盘，每 3×3 的宫格之间有粗线分隔；每个格子内部用细线绘制；选中的格子用半透明色块高亮；数字统一居中绘制。

dart复制class SudokuPainter extends CustomPainter {
  final SudokuBoard board;
  final int selectedIndex;
  final Set<int> hintCells;
  final Set<int> errorCells;
  
  @override
  void paint(Canvas canvas, Size size) {
    final cellWidth = size.width / 9;
    // 网格线
    final gridPaint = Paint()
      ..color = const Color(0xFF333333)
      ..strokeWidth = size.width / 180;
    for (int i = 0; i <= 9; i++) {
      // 3 的倍数行粗线，普通行细线
      final isThick = i % 3 == 0;
      gridPaint.strokeWidth = isThick ? size.width / 120 : size.width / 180;
      canvas.drawLine(
        Offset(i * cellWidth, 0),
        Offset(i * cellWidth, size.height),
        gridPaint,
      );
      canvas.drawLine(
        Offset(0, i * cellWidth),
        Offset(size.width, i * cellWidth),
        gridPaint,
      );
    }
    // ... 数字绘制和状态高亮，这里省略细节
  }
}

手势交互相对简单，用 GestureDetector 的 onTapDown 就能精确计算用户点击的是哪个格子。但我实际开发中遇到一个 OpenHarmony 特有的问题：触摸事件的采样频率比 Android 低，快速滑动选择格子时偶尔会漏掉几个坐标点。解决方案是改用 Listener 监听原始指针事件，并且在 onPointerDown 和 onPointerMove 中分别做命中测试。

4.4 让 Flutter 应用接入鸿蒙能力：一次 IAP 和相册调用的折腾

在适配过程中，我还尝试接入了一些鸿蒙系统能力，比如 IAP 支付和相册选择。这里必须提醒一句：Flutter 的标准插件生态在 OpenHarmony 上不通用。

以相册选择为例，image_picker 这个 Flutter 插件在 OpenHarmony 上不能直接用。Flutter for OpenHarmony 社区有对应的适配方案，但需要手动配置：在 ohos/ 目录下添加插件依赖，在 module.json5 里声明对应的权限，然后通过 MethodChannel 调用鸿蒙的 PhotoViewPicker API。

这里我踩的坑是：权限声明的位置搞错了。在 OpenHarmony 中，相册读取权限需要在 module.json5 的 requestPermissions 里声明 ohos.permission.READ_IMAGEVIDEO，而不是像 Android 那样在 AndroidManifest.xml 里声明。如果只配 Android 不配鸿蒙，应用在鸿蒙设备上会静默失败，不给你任何错误提示。

IAP 支付更折腾。鸿蒙的 IAP 走的是 @ohos.pay 模块，与 Android 的 billing 接口完全不同。我在社区找到了一个第三方的 flutter_ohos_pay 插件，但它需要配合鸿蒙侧的 IAP 服务回调才能完成，联调过程中还遇到了证书签名不匹配的问题——鸿蒙应用使用的签名证书必须与 IAP 服务绑定的证书一致，否则支付成功后回调收不到通知。

5. 性能优化与异常场景处理：让求解器在真实设备上稳定运行

5.1 为什么明明算法很快，UI 还是卡了一下

求解器在后台跑 60ms 已经很理想了，但实际放到 Flutter 应用里，你可能会发现一个尴尬的问题：填入数字、触发求解、刷新 UI，这一串操作下来 Frame 还是掉了几帧。原因在于 Dart 单线程模型下，完全计算密集型的求解逻辑会阻塞 UI 线程的事件循环。

解决方案是给求解器加一个独立的 Isolate，把计算任务扔到后台隔离区执行，完成后通过 SendPort 把结果传回主 Isolate 刷新 UI。

dart复制Future<SudokuResult> solveInBackground(SudokuBoard board) async {
  final receivePort = ReceivePort();
  await Isolate.spawn(_solveIsolateEntry, receivePort.sendPort);
  final sendPort = await receivePort.first as SendPort;
  
  // 发送盘面数据到子 Isolate
  final resultReceivePort = ReceivePort();
  sendPort.send([board.cells, resultReceivePort.sendPort]);
  
  final result = await resultReceivePort.first as List<int>;
  return SudokuResult(result);
}

void _solveIsolateEntry(SendPort mainSendPort) {
  final receivePort = ReceivePort();
  mainSendPort.send(receivePort.sendPort);
  
  receivePort.listen((message) {
    final cells = message[0] as List<int>;
    final resultSendPort = message[1] as SendPort;
    
    final board = SudokuBoard.fromCells(cells);
    final solved = board.solve();
    resultSendPort.send(solved ? board.cells : []);
  });
}

这个改动看似简单，但有三个注意点：

• Isolate 之间的通信需要类型声明。Dart 里 SendPort 支持发送 List<int> 这类基本类型，但如果是自定义对象，需要手动做消息转码。
• 每次创建 Isolate 有大约 100ms 的启动开销。频繁求解的场景不要反复创建，建议创建一次、长时间复用。
• 从 OpenHarmony 的进程模型看，Isolate 在鸿蒙上被映射为线程，这部分行为和标准 Flutter 保持一致，没有额外的适配成本。

5.2 无解数独与多解数独：不要让你的求解器卡死

真实世界的数独题目来源复杂，可能是用户手动输入的，也可能是某个不靠谱的生成器产生的。如果给求解器丢一道无解的题目，回溯算法会怎么表现？

答案是：它会穷举完所有可能的路径，然后返回 false。这个过程在最坏情况下依然是指数级的耗时，前面讲的约束传播不能从根本上解决这个问题。

实际测试中，一道精心构造的无解数独，求解器跑了大约 30 秒才返回。作为一个交互应用来说，这个等待是毁灭性的。所以我在求解器外层做了一层超时保护：

dart复制class SudokuSolver {
  int nodeCount = 0;
  static const int maxNodes = 100000;
  
  bool solveWithTimeout() {
    nodeCount = 0;
    return _solveWithLimit();
  }
  
  bool _solveWithLimit() {
    nodeCount++;
    if (nodeCount > maxNodes) {
      throw SudokuTimeoutException();
    }
    // ... 正常的递归逻辑
  }
}

当节点数超过阈值时直接抛出异常，UI 层捕获后提示用户“此题目可能无解或过于复杂”。这里的阈值设置需要根据设备的 CPU 性能做调整——RK3568 相比手机 CPU 弱不少，同样的算法在手机上 10ms 跑完的题目，在这块板子上可能要 60ms，所以超时阈值最好留出 3-5 倍的余量。

5.3 数独生成：如何生成一个有唯一解的题目

既然已经实现了求解器，顺手做一个数独生成器就顺理成章了。数独生成的基本流程是：

1. 从空盘开始，使用类似求解的 DFS 随机填入合法数字，直到填满整个盘面。
2. 根据指定的难度等级，挖掉一定数量的格子。
3. 每次挖掉一个格子后，用求解器验证当前盘面是否有唯一解。如果有多个解，就放弃这次挖空。

第 3 步的复解检测是整个生成器最耗时的部分。判断唯一解，最简单的方案是：在求解的过程中，如果找到了一个解，不立即返回，而是继续搜索第二个解。如果第二个解存在，说明题目不唯一。

这个方案可以直观抽象成一个参数：answerCount。找到解时先递增计数，然后继续搜索。只要计数大于等于 2，就可以提前终止搜索，因为已经能判定不唯一了。

dart复制int countSolutions(SudokuBoard board, {int limit = 2}) {
  int count = 0;
  
  void dfs() {
    if (count >= limit) return;
    
    final cell = _selectNextCell();
    if (cell == -1) {
      count++;
      return;
    }
    
    final candidates = _candidates[cell];
    for (int d = 1; d <= 9; d++) {
      if ((candidates & (1 << (d - 1))) != 0) {
        final savedCells = List<int>.from(_cells);
        final savedCandidates = List<int>.from(_candidates);
        _fillCell(cell, d);
        dfs();
        _cells.setAll(0, savedCells);
        _candidates.setAll(0, savedCandidates);
      }
    }
  }
  
  dfs();
  return count;
}

在 RK3568 上，生成一个中等难度的数独题目大约需要 300ms，其中 90% 以上的时间都花在复解检测上。如果你只是需要一个演示应用，这个性能足够；如果是做在线题库服务，建议把生成逻辑放到服务端。

5.4 Flutter 打包与调试：hap 包在鸿蒙设备上的离线安装

最后聊一下部署。OpenHarmony 应用最终打包成 .hap 文件，安装方式和 Android 的 APK 类似，但工具链不同。

最常用的方式是通过 hdc 工具安装，它相当于 Android 的 adb：

bash复制hdc install com.example.sudoku.hap

我在第一次安装时遇到签名校验失败。原因是 OpenHarmony 应用默认要求签名，而 Flutter for OpenHarmony 模板工程生成的 .hap 包如果直接用 hdc install 安装，需要先配置签名信息。开发和调试阶段，在 DevEco Studio 里创建一个本地调试证书，配置到工程里就能解决。但注意，本地调试证书和设备绑定，换设备就需要重新生成。

热重载在鸿蒙上的体验略有不同。flutter run 走的是 hdc 通道，热重载的生效时间和 Android 差不多，但如果涉及原生鸿蒙代码（ohos/ 目录下的改动），热重载不会生效，需要完整重新构建。

6. 踩坑记录与性能对比：那些文档里没写的细节

6.1 Flutter 热重载失灵和数据流不同步

开发过程中最让我头疼的问题之一是热重载在 OpenHarmony 上的表现不稳定。有时改了 Dart 代码，flutter run 显示热重载成功，但 UI 没有任何变化。排查后发现是 Flutter 引擎的 Debug 模式在鸿蒙上对 ScheduleFrame 的处理有延迟，解决办法是手动触发一次 hot restart（按 R 键），而不是只做热重载。

另一个和热重载无关、但同样棘手的问题是数据流不同步。由于 Isolate 分离了求解逻辑，求解完成后回传的数据需要通过 StreamBuilder 或 setState 手动触发 UI 更新。我一开始用 then 回调更新状态，结果在快速连续点击“求解按钮”时出现竞态条件——第一次求解的结果覆盖了第二次求解的结果。后来用了一个简单的递增请求 ID 来丢弃过期响应：

dart复制int _requestId = 0;

Future<void> _onSolvePressed() async {
  final currentId = ++_requestId;
  final result = await solveInBackground(board);
  if (currentId == _requestId) {
    setState(() {
      board.setCells(result.cells);
    });
  }
}

6.2 候选数位运算的一个隐蔽 Bug

位运算虽然高效，但调试起来也非常磨人。我在实现候选数更新时，一开始把掩码写成了 mask = ~(1 << (d - 1))，但在 Dart 中 ~ 是对 64 位整数取反，而候选数只用了低 9 位。这样取反后高位全是 1，和候选数做 & 运算虽然当前逻辑没毛病，但如果某个格子意外写入了高位数据，就会干扰后续的判断。

现在的写法是显式限定掩码范围：

dart复制final mask = 0x1FF & ~(1 << (d - 1));

这个细节不处理好，在特定盘面下会偶发出现“明明合法却显示候选数为空”的问题，排查起来极其费时间。

6.3 性能数据实测：RK3568 与模拟器的差距

最后，我把求解器在三种不同环境下跑了一遍同样的题库，数据差异很能说明问题：

这里有个值得注意的差异：模拟器上跑的时候，Flutter 引擎走的是 x86 指令集，RK3568 真机走 ARM64 指令集，架构差异本身不至于带来十倍差距。真正的差距在于 Debug 模式和 Release 模式的编译方式不同——Debug 模式是 JIT，不会做充分的优化；Release 模式是 AOT 预编译，对这类计算密集型的递归代码优化效果非常显著。

所以如果要做性能评估，一定不要用 Debug 模式的数据。我见过不少开发者在模拟器上测试后觉得性能完全够用，结果一上真机就卡得怀疑人生。

6.4 OpenHarmony 上 IAP 套件和宿主接入的一个补充

再补一个和数独应用直接相关的经验。如果你想在数独应用里做“移除广告”“解锁主题”之类的 IAP 功能，除了前面提到的插件适配，还要注意 OpenHarmony 的 IAP 服务是区域限制的。它依赖华为统一支付的账号体系，在没有登录华为账号的设备上，拉起支付会直接失败。

我当时在调试时，因为设备没登录华为账号，支付界面弹不出来，一度以为是插件配置有问题。后来查了社区才知道是账号问题。建议在开发早期就把账号登录流程接入，否则等到联调阶段才暴露，会很被动。

7. 从求解器到完整场景：下一步能做什么

说实话，数独求解器本身并不是什么生产力工具，但它把回溯算法、约束满足、位运算优化、跨端适配这几个知识点串成了一个完整的闭环。我在做完这个项目之后，有几个明确的体会：

第一，算法的选型和优化，要结合运行环境的硬件能力。同样一段 DPS，在 PC 上可能 5ms 就解完了，但在 RK3568 上就是 60ms。如果你的目标设备是低端 ARM 开发板，优化策略和针对手机的方案是完全不同的。

第二，Flutter for OpenHarmony 还处在快速迭代期。你在网上搜到的很多 Flutter 教程和插件用法，直接套到鸿蒙上大概率不适用。涉及平台能力（相册、IAP、传感器等）的部分需要交叉验证，纯 UI 和逻辑部分倒是可以无缝复用。

第三，数据结构和位运算这些底层基本功，在跨端开发中是最保值的能力。不管 Flutter 未来怎么变、OpenHarmony 怎么演进，那些不依赖任何框架的算法核心，永远是可以直接复用的。

最后再分享一个小技巧：在 Flutter 项目中做交互响应，核心逻辑一定要跑在独立 Isolate 里，但 Isolate 不要频繁创建。你可以用一个全局的 Isolate 池，只启动一次，后续所有求解任务都往同一个 Isolate 里塞——这样既省掉了每次创建约 100ms 的开销，也避免了多个 Isolate 间数据同步的麻烦。我在项目里实际就用了一个常驻的求解 Isolate，配上一个任务队列，效果非常稳。