最近在RK3568开发板上折腾OpenHarmony系统跑起来之后总觉得缺点什么——开机就是桌面没有那种“能用”的感觉。干脆自己写一个数独生成器顺便验证一下Flutter在OpenHarmony上的适配程度。这个项目表面上是“写个小游戏”本质上其实是一趟跨端框架落地鸿蒙的实战。数独的好处在于它的算法边界非常清晰生成终盘、挖洞出题、判定唯一解、用户输入校验每一块都能独立拆开测试。UI呢又比一般的“Hello World”复杂一点需要处理网格绘制、高亮联动、数字键盘、笔记模式正好能暴露Flutter在OpenHarmony上的真实渲染情况。这篇文章把整个项目的思路、算法、界面实现、部署调试的完整过程写下来适合正在做Flutter跨端开发、或者想在OpenHarmony上跑点正经应用的朋友参考。1. 为什么用Flutter给OpenHarmony写一个数独我的选型逻辑1.1 从一次“无应用可用”的尴尬说起OpenHarmony的设备尤其是RK3568、RK3588这类开发板装好系统之后最大的问题不是跑不起来而是没有让人愿意点开的应用。系统自带的设置、相册、桌面看一眼就关掉了。当时我拿到的板子预装的是OpenHarmony 4.0应用商店里的第三方应用少得可怜ArkTS开发的demo也大多是列表页和按钮点击缺乏有交互深度的样例。那我为什么不直接用ArkTS写因为团队的存量代码和技术栈都是Flutter。跨端框架的价值恰恰体现在“一套代码多端复用”上。OpenHarmony目前的官方应用开发语言是ArkTS但它是支持Flutter的社区也有对应的SDK适配。我想验证的正是一个纯Flutter项目从Android迁移到OpenHarmony需要改多少代码、踩多少坑、性能是否可用。数独这种游戏对性能的要求很微妙它不像游戏引擎那样需要60帧满帧渲染但也不像静态页面那样完全无压力。网格重绘、点击响应、动画过渡每一项都对UI框架有实际要求。拿它当探路石比跑一个空白模板有说服力得多。1.2 项目结构把算法和皮肤拆干净很多小游戏写着写着就乱了尤其是界面和逻辑混在一起后面想加功能、想测试都变得无比痛苦。这个项目从一开始就定了三条规矩核心算法必须是纯Dart不依赖任何Flutter组件UI层只负责绘制和事件转发不持有游戏状态平台相关代码尽量隔离保留Android/iOS/OpenHarmony三个平台的壳目录方便交叉验证最终的项目结构大概是这样的sudoku_flutter/ ├── lib/ │ ├── core/ # 纯Dart算法层 │ │ ├── generator.dart # 终盘生成 │ │ ├── solver.dart # 求解器唯一解判定 │ │ ├── puzzle.dart # 挖洞出题 │ │ └── models.dart # 格子、坐标、难度枚举 │ ├── ui/ │ │ ├── board_view.dart # 棋盘绘制 │ │ ├── number_pad.dart # 底部数字键盘 │ │ ├── note_mode.dart # 笔记模式 │ │ └── game_page.dart # 游戏主页面 │ └── main.dart ├── android/ # Android壳工程 ├── ohos/ # OpenHarmony壳工程 └── test/ # 算法单测核心算法层单独拆出来带来的直接好处是flutter test可以秒级验证生成器和求解器的正确性不用跑到设备上才发现算法有bug。后面在OpenHarmony上调试时UI出问题我能确定是渲染层的锅不会怀疑到算法头上。1.3 关于“鸿蒙风”的设计风格标题里写了“鸿蒙风”不少朋友可能会以为是鸿蒙的原生设计语言。其实我理解的是“轻、透、简洁”。HarmonyOS的设计风格偏向圆角、柔和阴影、白色卡片底跟Material Design的厚重感不一样。所以在Flutter里做主题时我没有直接用Material的默认样式而是自定义了一套背景色用浅灰白#F2F3F7不用纯白避免刺眼卡片和按键用大圆角16~20不用Material默认的4圆角数字和线条用深蓝色系#1A3A5C比纯黑更柔和切换动画用200ms左右的淡入淡出不搞花哨的弹性动画这种风格在OpenHarmony设备上跑起来很协调因为OpenHarmony原生应用本身也是这种“轻量卡片”的调性Flutter这边自定义Theme后不会有违和感。2. 数独生成器最难的部分不是界面是“盘面算法”很多第一次写数独的人都会低估出题这个环节。以为随机填几个数字进去就行结果生成出来的盘面要么无解要么多解要么难度分布完全失控。这一章详细讲一下我落地时的完整思路和代码。2.1 生成终盘三步填充法为什么比纯回溯快这么多生成一个合法的数独终盘最直观的方法是全盘回溯从左上角开始逐个格子尝试填入1~9冲突就回退。这个方法能跑但性能很看运气运气不好回溯几万次都可能。尤其是填入中盘时频繁冲突在低端设备上会有肉眼可见的卡顿。我采用的是三步填充法核心思想是把9×9的盘面按3×3宫划分成9个宫先填充对角线上的3个宫再填充剩余区域。为什么先填对角线宫因为对角线上的3个宫互不相交每个宫独立填1~9是1的排列组合排列怎么填都是合法的不存在冲突回退。而填充完这三个宫后剩下的行和列已经有不少确定数字后续回溯的搜索空间会大幅缩小几乎不会碰到死胡同。生成终盘的Dart代码如下import dart:math; class Generator { static Listint generate() { final board Listint.filled(81, 0); _fillDiagonalBoxes(board); _solveBacktrack(board); return board; } static void _fillDiagonalBoxes(Listint board) { for (int i 0; i 9; i 3) { _fillBox(board, i, i); } } static void _fillBox(Listint board, int row, int col) { final nums Listint.generate(9, (i) i 1)..shuffle(Random()); int idx 0; for (int r row; r row 3; r) { for (int c col; c col 3; c) { board[r * 9 c] nums[idx]; } } } static bool _solveBacktrack(Listint board) { for (int i 0; i 81; i) { if (board[i] ! 0) continue; final candidates _getCandidates(board, i); candidates.shuffle(Random()); for (final num in candidates) { board[i] num; if (_solveBacktrack(board)) return true; board[i] 0; } return false; } return true; } static Listint _getCandidates(Listint board, int index) { final row index ~/ 9, col index % 9; final used int{}; for (int i 0; i 9; i) { used.add(board[row * 9 i]); used.add(board[i * 9 col]); } final br (row ~/ 3) * 3, bc (col ~/ 3) * 3; for (int r br; r br 3; r) { for (int c bc; c bc 3; c) { used.add(board[r * 9 c]); } } return [1, 2, 3, 4, 5, 6, 7, 8, 9] .where((n) !used.contains(n)) .toList(); } }看起来代码量不大但性能差距是数量级的。实测在RK3568上纯回溯生成一个终盘平均要几十毫秒到几百毫秒三步填充法稳定在5毫秒以内基本感觉不到。顺带提一下还有一种“已知合法盘面随机变换”的生成法先准备一个固定的合法终盘对它做行组交换、列组交换、数字映射、转置等操作生成另一个合法终盘。这种方法更快但生成的盘面会有比较明显的“结构痕迹”长期玩的人能看出来。移动端小游戏用三步填充法完全够用。2.2 挖洞出题不是随便挖答案唯一是底线有了终盘接下来就是挖洞删除部分数字生成题目。这步最常见的坑是挖完洞之后题目存在多个解。一个标准的数独题目应当有且仅有一个解。怎么保证我的做法是每次尝试删除一个数字然后用求解器跑一遍检查解是否唯一。如果不唯一就把这个数字放回去。挖洞的完整逻辑class PuzzleGenerator { static Listint generate({required Difficulty difficulty}) { final solution Generator.generate(); final board Listint.from(solution); final holes Listint.generate(81, (i) i)..shuffle(Random()); int targetHint _hintCountFor(difficulty); // 简单45中等36困难30 int hint 81; for (final index in holes) { if (hint targetHint) break; final backup board[index]; board[index] 0; if (_uniqueSolutionCount(board) ! 1) { board[index] backup; // 挖掉会多解放回去 } else { hint--; } } return board; } static int _hintCountFor(Difficulty d) { switch (d) { case Difficulty.easy: return 45; case Difficulty.medium: return 36; case Difficulty.hard: return 30; } } }这里有个关键细节判断唯一解时不能“找到一个解就停”而应该“尝试找第二个解找到就立即返回”。如果完整跑完全部搜索性能会非常差。下面2.3会详细讲求解器的实现。另一个坑是挖洞顺序。如果不打乱顺序从第0格开始依次挖题目会呈现明显的“左少右多、上少下多”的偏斜。用shuffle打乱后挖洞位置均匀分布题目观感更好难度也更稳定。2.3 求解器用“最少候选数优先”让唯一解判定提速求解器不仅用于挖洞校验还用于玩家填错时的“机会提示”。我用了最基本的回溯加候选数剪枝。class Solver { static bool hasUniqueSolution(Listint board) { return _solve(board, 0) SolutionStatus.unique; } static SolutionStatus _solve(Listint board, int foundCount) { if (foundCount 1) return SolutionStatus.multiple; int bestIndex -1; Listint bestCandidates []; for (int i 0; i 81; i) { if (board[i] ! 0) continue; final candidates _candidatesFor(board, i); if (candidates.isEmpty) return SolutionStatus.none; if (bestIndex -1 || candidates.length bestCandidates.length) { bestIndex i; bestCandidates candidates; if (candidates.length 1) break; // 只有一种可能不用再找 } } if (bestIndex -1) return SolutionStatus.unique; for (final num in bestCandidates) { board[bestIndex] num; final status _solve(board, foundCount); board[bestIndex] 0; if (status SolutionStatus.unique) { foundCount; if (foundCount 1) return SolutionStatus.multiple; } else if (status SolutionStatus.multiple) { return SolutionStatus.multiple; } } return foundCount 0 ? SolutionStatus.unique : SolutionStatus.none; } static Listint _candidatesFor(Listint board, int index) { final row index ~/ 9, col index % 9; final used int{}; for (int i 0; i 9; i) { used.add(board[row * 9 i]); used.add(board[i * 9 col]); } final br (row ~/ 3) * 3, bc (col ~/ 3) * 3; for (int r br; r br 3; r) { for (int c bc; c bc 3; c) { used.add(board[r * 9 c]); } } return [1, 2, 3, 4, 5, 6, 7, 8, 9] .where((n) !used.contains(n)) .toList(); } }核心优化是“最少候选数优先”每次都选候选数最少的空格尝试这样能让回溯的搜索树快速变窄。在挖洞校验时大多数情况下只需要搜索很少的节点就能判断是否有第二个解。补充一点这段代码直接操作Listint而不是用二维数组是为了减少对象分配。81个格子的游戏虽然不大但在低端OpenHarmony设备上一次操作分配一堆对象GC一频繁就会出现掉帧。用扁平数组配合index ~/ 9和index % 9换算坐标性能会明显更稳。3. Flutter界面网格绘制与交互细节3.1 网格不用GridView硬拼我用CustomPaint数独界面最核心的组件是9×9网格。很多新手会直接用GridView.builder生成81个Container颜色和边框用BoxDecoration设置。这个方案在真机上有个明显问题81个widget在每次setState时全部重建即使只填了一个数字也会触发所有格子的layout在低端设备上会有可感知的卡顿。我的做法是分层绘制底层用CustomPaint画网格线细线、粗线、宫线上面只放数字文本和笔记文本数字用一个Widget列表按坐标Position放置不参与重新布局绘制网格线的核心代码class BoardPainter extends CustomPainter { override void paint(Canvas canvas, Size size) { final cell size.width / 9; final thin Paint() ..color const Color(0xFFD0D8E8) ..strokeWidth 1; final thick Paint() ..color const Color(0xFF1A3A5C) ..strokeWidth 2.5; for (int i 0; i 9; i) { final isThick i % 3 0; final paint isThick ? thick : thin; canvas.drawLine(Offset(i * cell, 0), Offset(i * cell, size.width), paint); canvas.drawLine(Offset(0, i * cell), Offset(size.width, i * cell), paint); } } override bool shouldRepaint(covariant CustomPainter oldDelegate) false; }为什么这样快因为shouldRepaint返回false网格线只在首次创建时绘制一次后续填数字、高亮切换都不会重绘网格。而81个数字文本本身是最轻量的Text组件不涉及栅格布局系统。3.2 选中态与高亮联动一次遍历别搞复杂的监听数独里一个很能提升体验的交互是选中某个格子后它所在的行、列、宫、以及相同数字的其他格子都会高亮。这个功能如果做成“每个格子独立监听选中状态”代码会非常啰嗦而且容易出bug。正确做法是在build里基于当前选中的坐标一次性计算出所有需要高亮的格子索引集合然后每个格子绘制时查询这个集合。Setint _buildHighlightSet(int selectedIndex, Listint board) { final result int{}; if (selectedIndex -1) return result; final row selectedIndex ~/ 9; final col selectedIndex % 9; final selectedValue board[selectedIndex]; for (int i 0; i 9; i) { result.add(row * 9 i); // 同行 result.add(i * 9 col); // 同列 } final br (row ~/ 3) * 3, bc (col ~/ 3) * 3; for (int r br; r br 3; r) { for (int c bc; c bc 3; c) { result.add(r * 9 c); // 同宫 } } // 相同数字高亮排除自己 for (int i 0; i 81; i) { if (board[i] selectedValue selectedValue ! 0 i ! selectedIndex) { result.add(i); } } return result; }这个集合在每次setState时重新计算81个格子的遍历在设备上耗时可以忽略。格子绘制逻辑里final isSelected index selectedIndex; final isHighlighted highlightSet.contains(index); final isSameValue board[index] selectedValue selectedValue ! 0; bgColor isSelected ? const Color(0xFFBBDDFF) : isHighlighted ? const Color(0xFFEAF2FF) : isSameValue ? const Color(0xFFFFE8CC) : Colors.transparent;这套逻辑写出来非常直观后续想改高亮颜色、增加“错误数字标红”都是在自己的格子里加一个分支不会牵扯到兄弟组件。3.3 数字输入、笔记模式和撤销栈底部数字键盘我用了最简单的“横向一排”1到9加上一个橡皮擦。点击数字时向当前选中格子填入或移除数字。这里有几个交互细节值得注意数字键盘要禁用无效按钮如果当前格子已经固定题面给出的数字玩家点击数字应该无响应而不是填上后又被重置。可以在数字键盘接口里传入canEdit状态。笔记模式用Set存储候选数每个格子可能被填入多个笔记用Mapint, Setint存储简单直观。错误提示不能靠颜色误导玩家填错时我用一个淡红色背景标记但不会弹窗打断节奏。数独这种游戏最怕就是被频繁打断。撤销功能是“能玩”和“好用”的分水岭。我用一个简单的快照栈实现final _history Listint[]; final _noteHistory Mapint, Setint[]; void _snapshot() { _history.add(List.from(board)); _noteHistory.add({ for (final e in notes.entries) e.key: Set.from(e.value), }); if (_history.length 100) { _history.removeAt(0); _noteHistory.removeAt(0); } } void undo() { if (_history.isEmpty) return; board _history.removeLast(); notes _noteHistory.removeLast(); setState(() {}); }快照栈的细节是每次push的是新List和新的Set集合绝不能直接存引用。否则后续修改board时历史记录也会跟着变撤销就会失效。这个bug我一开始就踩过排查了半天才发现是引用共享的问题。保存100步足够长局使用了再多会占内存在低端设备上不划算。4. OpenHarmony部署与调试这一路踩的坑不踩一遍真不知道4.1 从Flutter工程到OpenHarmony壳工程如果你熟悉Flutter的Android工程那OpenHarmony壳工程的目录结构并不陌生。Flutter官方在OpenHarmony上的适配是通过“Flutter SDK for OpenHarmony”提供的需要在工程里新增一个ohos目录并配置好对应的构建脚本。整体配置步骤大致如下下载适配OpenHarmony的Flutter SDK并在flutter config里指定在项目根目录执行flutter create --platformsohos .生成壳工程在ohos/目录下检查module.json5和build-profile.json5中的bundleName和versionCode执行hdc list targets确认开发板连接用DevEco Studio或命令行完成签名配置再执行安装第一步其实是最大的坑。因为Flutter官方主分支优先支持Android/iOSOpenHarmony的适配分支是单独维护的。如果你用普通Flutter SDK执行flutter create根本看不到ohos这个平台选项。正确做法是下载适配了OpenHarmony的Flutter SDK并把它配置为当前项目的SDK路径。配置好之后flutter devices应该能看到OpenHarmony设备flutter run -d deviceId就能把调试包推上去。如果卡在了“设备不显示”这一步先确认hdc list targets能列出设备hdc是OpenHarmony的命令行工具类似Android的adb。4.2 hdc命令的日常查看系统版本和推送文件开发调试过程中我跟hdc打交道非常多。这里列出几个实用命令# 查看当前连接的设备 hdc list targets # 查看OpenHarmony系统版本 hdc shell param get const.product.name # 查看SDK版本 hdc shell param get const.ohos.version # 推送文件到设备 hdc file send ./app.hap /data/local/tmp/app.hap # 安装hap包 hdc install /data/local/tmp/app.hap # 查看应用日志 hdc shell hilog | grep your_app_tag尤其是hdc shell param get这组命令排查版本问题时特别好用。有几次应用装上去闪退我第一反应就是看系统版本和API Level是否匹配。OpenHarmony的API版本跟Flutter SDK的适配版本有对应关系版本不匹配会报奇怪的符号链接错误。4.3 签名配置那不叫坑叫连环坑OpenHarmony真机安装应用需要签名。这个流程跟Android的debug签名类似但手续更繁琐。最典型的报错是error: failed to install bundle. code: 9568320 error: verify signature failed.这个错误出现时我一度以为是hap包损坏后来才发现是签名证书和设备的UDID不匹配。OpenHarmony的签名需要一个.p7b文件和一个对应的.cer证书可以通过DevEco Studio的自动签名功能生成。自动签名要求登录开发者账号并且设备必须处于联网状态。我自己遇到的一个细节是开发板的UDID也可以叫devudid可以用hdc shell bm get -u查到和模拟器的UDID不一样换设备就要重新生成签名。如果你在一个开发板上调试得好好的换另一台板子突然签名失败优先检查是不是签名没重新配置。4.4 在RK3568和RK3588上的实际表现我手头有两块开发板一块RK3568一块RK3588。前者四核A55定位是低功耗入门级后者四核A76加四核A55性能明显更强。数独这个游戏两者跑起来帧率差别不太大但有一个现象很典型RK3588上丝滑流畅点击响应几乎是即时的RK3568上如果打开系统动画或者后台有大量应用Flutter的图形栈有时会出现掉帧问题不在Flutter本身而在OpenHarmony的图形合成器上。Flutter是自渲染引擎它的每一帧都是自己画好再交给系统合成的。如果系统合成压力大Flutter的提交会被排队。解决办法是在FlutterEngine初始化时设置final engine FlutterEngine(); engine.setCompatibilityMode(true); // 兼容模式降低部分渲染优化以提升稳定性这个参数不是所有场景都需要但如果你的游戏在特定设备上出现不均匀的卡顿可以试试看。另一个经验是数独这种静态页面不需要高频刷新整个Surface。我后来把不需要动画的区域用RepaintBoundary包起来实测在RK3568上的帧时间从平均16ms降到了10ms左右掉帧明显减少。4.5 如果你同时保留Android目录那个Gradle报错项目里如果同时保留了android目录有时在Android Studio或命令行构建时会弹出类似这样的Gradle错误You are applying Flutters main Gradle plugin imperatively using the apply script method.这个报错提示的是Flutter Gradle插件的新旧版本兼容问题。我一开始没管它因为反正目标平台是OpenHarmony。但它会影响flutter build命令的整体流程导致构建中断。解决办法很简单在android/settings.gradle里把旧的apply from: $flutterRoot/packages/flutter_tools/gradle/app_plugin_loader.gradle改成新版插件引入方式或者如果你暂时不需要Android包直接把android目录移出项目根目录等需要的时候再加回来。这个坑虽然小但很容易让人误以为是OpenHarmony环境没配好白白排查半小时。5. 从能玩到好玩难度曲线、状态恢复和几个隐藏Bug5.1 难度分级不能只看“挖洞数量”还要看逻辑链深度前面提到我用“已填数字数量”来粗略控制难度简单45个中等36个困难30个。但实际试玩下来发现单纯按数量分级有个毛病有时候挖了45个洞仍然简单得离谱有时候30个洞却简单得反常。原因是数独的难度本质由“解题需要用到的高级技巧链长度”决定。一个只有30个已知数的盘面如果每个格子的候选数都很容易排除可能比40个已知数但候选数密集的盘面更容易解。后来我在项目里加了一个“候选数最少格子”的统计出题时计算所有空格候选数的平均数和中位数。如果平均数超过4.2并且有至少一个空格候选数是6个以上就把难度标记为困难。这个指标不是最精确的难度评估但对移动端小游戏来说简单、可解释、调试方便比复杂的“人类解题策略模拟”实用得多。5.2 状态恢复不是存进度是存“撤销栈”很多小游戏只做了“暂停保存当前盘面”但玩家一退出再进来连之前填错想撤销的记录都没了。我当时做了一个更完整的恢复机制把board、notes、history三个对象序列化成JSON用shared_preferences存在本地每次玩家输入新数字时延迟1秒写入应用启动时检查是否有未完成的游戏有则弹出“继续上次”的提示notes和history序列化的细节比较容易出问题history是一个最多100层的ListListint直接JSON序列化没问题但反序列化时要确保每个内层都是新的List对象否则又会出现“引用共享”导致撤销失效。ListListint restoreHistory(Listdynamic raw) { return raw .map((layer) Listint.from(layer as Listdynamic)) .toList(); }5.3 我遇到的三个隐藏Bug附排查思路Bug 1完成判定偶发失灵现象玩家明明填满了整个棋盘且没有错误但“成功弹窗”不出现。排查链路我先去检查完成判定函数逻辑很简单——遍历81格board[i] ! 0且与solution[i]相等。但漏掉了一个场景如果玩家用笔记模式覆盖了数字board仍然是0notes里却有值。完成判定就会失败。修复方案是把完成判定改成同时校验board和solution且当board[i] 0时直接判未完成。Bug 2换肤后数字颜色不更新现象在设置里切换“深色模式”后棋盘上的数字颜色没变但背景变成了深色。深色背景上的深蓝色数字几乎看不清。排查链路第一反应是主题没刷新检查后发现Color确实变了但格子里的数字Widget在外层PageView重建时没有触发自身的build。原因是BoardPainter的shouldRepaint返回了false导致网格线和数字文本的绘制不更新。修复方案是把shouldRepaint改为比较背景色override bool shouldRepaint(covariant BoardPainter oldDelegate) oldDelegate.backgroundColor ! backgroundColor;Bug 3点击数字时偶尔出现“填格没反应”现象在RK3568上快速连续点击数字按钮部分点击没有生效。排查链路一开始以为是触摸事件丢失后来加日志发现是“数字键盘的onPressed回调里每次都会执行一次_snapshot()然后setState()”连续点击时第一次setState还没完成第二次就进来了导致中间某次点击被丢弃。修复方案是在输入处理函数开头加一个简单的防抖bool _isProcessing false; void _onNumberTap(int num) { if (_isProcessing) return; _isProcessing true; setState(() { // 填入数字 }); // 注意setState是同步的但build是异步的用下一帧清零防抖 WidgetsBinding.instance.addPostFrameCallback((_) { _isProcessing false; }); }这个防抖并不是真正的“丢弃输入”而是给UI一帧的缓冲时间避免极端快速点击下的竞态问题。用了之后触发率恢复正常在低端设备上连续点击再也没有丢过。5.4 后续可以继续扩展的方向这个数独生成器跑通后我脑子里浮现了好几个升级方向但目前还没有全部落地接入Flame游戏引擎做动画特效把“填对数字”的反馈做成粒子效果加入联机对战用OpenHarmony的分布式软总线做设备间实时同步做一个“每日挑战”模式用当前日期做随机种子保证所有用户拿到同一道题把所有逻辑抽成ArkTS版本做一个纯ArkUI的对照版对比两种开发方式的差异最后一个方向我觉得最有意思。如果把“同一套需求、同一套UI逻辑”分别用Flutter和ArkTS写一遍两份代码都跑在同一块RK3568上对比包体积、启动时间、帧率、内存占用那对这个生态里正在选型的团队会是特别有价值的参考资料。最后说说我的实际感受这个项目从零到能玩花了大概一周的业余时间。最大感受是在OpenHarmony上跑Flutter可行性早已不是问题问题在于一些“系统细节”需要多花时间适应。签名、hdc、部分渲染行为都跟Android有微妙差异但不会让你卡死。反而Flutter本身的跨端能力帮了大忙——算法层和UI层一次写好Android上能跑OpenHarmony上也能跑几乎不用改。如果你正打算用Flutter给OpenHarmony做一个工具类或者小游戏应用我的建议是把核心逻辑做成纯Dart把UI依赖降到最低然后在真机上尽早开始联调。别等全部写完再上设备那样遇到渲染兼容问题会非常难受。最后分享一个小技巧OpenHarmony设备调试时我习惯在代码里加一个“本机性能浮层”用FPS 帧时间的实时数据显示在屏幕角落。这样你在不同开发板上切换时能立刻看到当前设备的性能表现不用每次都拿电脑看日志。这个小功能对优化低端设备体验非常有效强烈建议在项目早期就做进去。
Flutter跨端实战：为OpenHarmony打造数独生成器
最近在RK3568开发板上折腾OpenHarmony系统跑起来之后总觉得缺点什么——开机就是桌面没有那种“能用”的感觉。干脆自己写一个数独生成器顺便验证一下Flutter在OpenHarmony上的适配程度。这个项目表面上是“写个小游戏”本质上其实是一趟跨端框架落地鸿蒙的实战。数独的好处在于它的算法边界非常清晰生成终盘、挖洞出题、判定唯一解、用户输入校验每一块都能独立拆开测试。UI呢又比一般的“Hello World”复杂一点需要处理网格绘制、高亮联动、数字键盘、笔记模式正好能暴露Flutter在OpenHarmony上的真实渲染情况。这篇文章把整个项目的思路、算法、界面实现、部署调试的完整过程写下来适合正在做Flutter跨端开发、或者想在OpenHarmony上跑点正经应用的朋友参考。1. 为什么用Flutter给OpenHarmony写一个数独我的选型逻辑1.1 从一次“无应用可用”的尴尬说起OpenHarmony的设备尤其是RK3568、RK3588这类开发板装好系统之后最大的问题不是跑不起来而是没有让人愿意点开的应用。系统自带的设置、相册、桌面看一眼就关掉了。当时我拿到的板子预装的是OpenHarmony 4.0应用商店里的第三方应用少得可怜ArkTS开发的demo也大多是列表页和按钮点击缺乏有交互深度的样例。那我为什么不直接用ArkTS写因为团队的存量代码和技术栈都是Flutter。跨端框架的价值恰恰体现在“一套代码多端复用”上。OpenHarmony目前的官方应用开发语言是ArkTS但它是支持Flutter的社区也有对应的SDK适配。我想验证的正是一个纯Flutter项目从Android迁移到OpenHarmony需要改多少代码、踩多少坑、性能是否可用。数独这种游戏对性能的要求很微妙它不像游戏引擎那样需要60帧满帧渲染但也不像静态页面那样完全无压力。网格重绘、点击响应、动画过渡每一项都对UI框架有实际要求。拿它当探路石比跑一个空白模板有说服力得多。1.2 项目结构把算法和皮肤拆干净很多小游戏写着写着就乱了尤其是界面和逻辑混在一起后面想加功能、想测试都变得无比痛苦。这个项目从一开始就定了三条规矩核心算法必须是纯Dart不依赖任何Flutter组件UI层只负责绘制和事件转发不持有游戏状态平台相关代码尽量隔离保留Android/iOS/OpenHarmony三个平台的壳目录方便交叉验证最终的项目结构大概是这样的sudoku_flutter/ ├── lib/ │ ├── core/ # 纯Dart算法层 │ │ ├── generator.dart # 终盘生成 │ │ ├── solver.dart # 求解器唯一解判定 │ │ ├── puzzle.dart # 挖洞出题 │ │ └── models.dart # 格子、坐标、难度枚举 │ ├── ui/ │ │ ├── board_view.dart # 棋盘绘制 │ │ ├── number_pad.dart # 底部数字键盘 │ │ ├── note_mode.dart # 笔记模式 │ │ └── game_page.dart # 游戏主页面 │ └── main.dart ├── android/ # Android壳工程 ├── ohos/ # OpenHarmony壳工程 └── test/ # 算法单测核心算法层单独拆出来带来的直接好处是flutter test可以秒级验证生成器和求解器的正确性不用跑到设备上才发现算法有bug。后面在OpenHarmony上调试时UI出问题我能确定是渲染层的锅不会怀疑到算法头上。1.3 关于“鸿蒙风”的设计风格标题里写了“鸿蒙风”不少朋友可能会以为是鸿蒙的原生设计语言。其实我理解的是“轻、透、简洁”。HarmonyOS的设计风格偏向圆角、柔和阴影、白色卡片底跟Material Design的厚重感不一样。所以在Flutter里做主题时我没有直接用Material的默认样式而是自定义了一套背景色用浅灰白#F2F3F7不用纯白避免刺眼卡片和按键用大圆角16~20不用Material默认的4圆角数字和线条用深蓝色系#1A3A5C比纯黑更柔和切换动画用200ms左右的淡入淡出不搞花哨的弹性动画这种风格在OpenHarmony设备上跑起来很协调因为OpenHarmony原生应用本身也是这种“轻量卡片”的调性Flutter这边自定义Theme后不会有违和感。2. 数独生成器最难的部分不是界面是“盘面算法”很多第一次写数独的人都会低估出题这个环节。以为随机填几个数字进去就行结果生成出来的盘面要么无解要么多解要么难度分布完全失控。这一章详细讲一下我落地时的完整思路和代码。2.1 生成终盘三步填充法为什么比纯回溯快这么多生成一个合法的数独终盘最直观的方法是全盘回溯从左上角开始逐个格子尝试填入1~9冲突就回退。这个方法能跑但性能很看运气运气不好回溯几万次都可能。尤其是填入中盘时频繁冲突在低端设备上会有肉眼可见的卡顿。我采用的是三步填充法核心思想是把9×9的盘面按3×3宫划分成9个宫先填充对角线上的3个宫再填充剩余区域。为什么先填对角线宫因为对角线上的3个宫互不相交每个宫独立填1~9是1的排列组合排列怎么填都是合法的不存在冲突回退。而填充完这三个宫后剩下的行和列已经有不少确定数字后续回溯的搜索空间会大幅缩小几乎不会碰到死胡同。生成终盘的Dart代码如下import dart:math; class Generator { static Listint generate() { final board Listint.filled(81, 0); _fillDiagonalBoxes(board); _solveBacktrack(board); return board; } static void _fillDiagonalBoxes(Listint board) { for (int i 0; i 9; i 3) { _fillBox(board, i, i); } } static void _fillBox(Listint board, int row, int col) { final nums Listint.generate(9, (i) i 1)..shuffle(Random()); int idx 0; for (int r row; r row 3; r) { for (int c col; c col 3; c) { board[r * 9 c] nums[idx]; } } } static bool _solveBacktrack(Listint board) { for (int i 0; i 81; i) { if (board[i] ! 0) continue; final candidates _getCandidates(board, i); candidates.shuffle(Random()); for (final num in candidates) { board[i] num; if (_solveBacktrack(board)) return true; board[i] 0; } return false; } return true; } static Listint _getCandidates(Listint board, int index) { final row index ~/ 9, col index % 9; final used int{}; for (int i 0; i 9; i) { used.add(board[row * 9 i]); used.add(board[i * 9 col]); } final br (row ~/ 3) * 3, bc (col ~/ 3) * 3; for (int r br; r br 3; r) { for (int c bc; c bc 3; c) { used.add(board[r * 9 c]); } } return [1, 2, 3, 4, 5, 6, 7, 8, 9] .where((n) !used.contains(n)) .toList(); } }看起来代码量不大但性能差距是数量级的。实测在RK3568上纯回溯生成一个终盘平均要几十毫秒到几百毫秒三步填充法稳定在5毫秒以内基本感觉不到。顺带提一下还有一种“已知合法盘面随机变换”的生成法先准备一个固定的合法终盘对它做行组交换、列组交换、数字映射、转置等操作生成另一个合法终盘。这种方法更快但生成的盘面会有比较明显的“结构痕迹”长期玩的人能看出来。移动端小游戏用三步填充法完全够用。2.2 挖洞出题不是随便挖答案唯一是底线有了终盘接下来就是挖洞删除部分数字生成题目。这步最常见的坑是挖完洞之后题目存在多个解。一个标准的数独题目应当有且仅有一个解。怎么保证我的做法是每次尝试删除一个数字然后用求解器跑一遍检查解是否唯一。如果不唯一就把这个数字放回去。挖洞的完整逻辑class PuzzleGenerator { static Listint generate({required Difficulty difficulty}) { final solution Generator.generate(); final board Listint.from(solution); final holes Listint.generate(81, (i) i)..shuffle(Random()); int targetHint _hintCountFor(difficulty); // 简单45中等36困难30 int hint 81; for (final index in holes) { if (hint targetHint) break; final backup board[index]; board[index] 0; if (_uniqueSolutionCount(board) ! 1) { board[index] backup; // 挖掉会多解放回去 } else { hint--; } } return board; } static int _hintCountFor(Difficulty d) { switch (d) { case Difficulty.easy: return 45; case Difficulty.medium: return 36; case Difficulty.hard: return 30; } } }这里有个关键细节判断唯一解时不能“找到一个解就停”而应该“尝试找第二个解找到就立即返回”。如果完整跑完全部搜索性能会非常差。下面2.3会详细讲求解器的实现。另一个坑是挖洞顺序。如果不打乱顺序从第0格开始依次挖题目会呈现明显的“左少右多、上少下多”的偏斜。用shuffle打乱后挖洞位置均匀分布题目观感更好难度也更稳定。2.3 求解器用“最少候选数优先”让唯一解判定提速求解器不仅用于挖洞校验还用于玩家填错时的“机会提示”。我用了最基本的回溯加候选数剪枝。class Solver { static bool hasUniqueSolution(Listint board) { return _solve(board, 0) SolutionStatus.unique; } static SolutionStatus _solve(Listint board, int foundCount) { if (foundCount 1) return SolutionStatus.multiple; int bestIndex -1; Listint bestCandidates []; for (int i 0; i 81; i) { if (board[i] ! 0) continue; final candidates _candidatesFor(board, i); if (candidates.isEmpty) return SolutionStatus.none; if (bestIndex -1 || candidates.length bestCandidates.length) { bestIndex i; bestCandidates candidates; if (candidates.length 1) break; // 只有一种可能不用再找 } } if (bestIndex -1) return SolutionStatus.unique; for (final num in bestCandidates) { board[bestIndex] num; final status _solve(board, foundCount); board[bestIndex] 0; if (status SolutionStatus.unique) { foundCount; if (foundCount 1) return SolutionStatus.multiple; } else if (status SolutionStatus.multiple) { return SolutionStatus.multiple; } } return foundCount 0 ? SolutionStatus.unique : SolutionStatus.none; } static Listint _candidatesFor(Listint board, int index) { final row index ~/ 9, col index % 9; final used int{}; for (int i 0; i 9; i) { used.add(board[row * 9 i]); used.add(board[i * 9 col]); } final br (row ~/ 3) * 3, bc (col ~/ 3) * 3; for (int r br; r br 3; r) { for (int c bc; c bc 3; c) { used.add(board[r * 9 c]); } } return [1, 2, 3, 4, 5, 6, 7, 8, 9] .where((n) !used.contains(n)) .toList(); } }核心优化是“最少候选数优先”每次都选候选数最少的空格尝试这样能让回溯的搜索树快速变窄。在挖洞校验时大多数情况下只需要搜索很少的节点就能判断是否有第二个解。补充一点这段代码直接操作Listint而不是用二维数组是为了减少对象分配。81个格子的游戏虽然不大但在低端OpenHarmony设备上一次操作分配一堆对象GC一频繁就会出现掉帧。用扁平数组配合index ~/ 9和index % 9换算坐标性能会明显更稳。3. Flutter界面网格绘制与交互细节3.1 网格不用GridView硬拼我用CustomPaint数独界面最核心的组件是9×9网格。很多新手会直接用GridView.builder生成81个Container颜色和边框用BoxDecoration设置。这个方案在真机上有个明显问题81个widget在每次setState时全部重建即使只填了一个数字也会触发所有格子的layout在低端设备上会有可感知的卡顿。我的做法是分层绘制底层用CustomPaint画网格线细线、粗线、宫线上面只放数字文本和笔记文本数字用一个Widget列表按坐标Position放置不参与重新布局绘制网格线的核心代码class BoardPainter extends CustomPainter { override void paint(Canvas canvas, Size size) { final cell size.width / 9; final thin Paint() ..color const Color(0xFFD0D8E8) ..strokeWidth 1; final thick Paint() ..color const Color(0xFF1A3A5C) ..strokeWidth 2.5; for (int i 0; i 9; i) { final isThick i % 3 0; final paint isThick ? thick : thin; canvas.drawLine(Offset(i * cell, 0), Offset(i * cell, size.width), paint); canvas.drawLine(Offset(0, i * cell), Offset(size.width, i * cell), paint); } } override bool shouldRepaint(covariant CustomPainter oldDelegate) false; }为什么这样快因为shouldRepaint返回false网格线只在首次创建时绘制一次后续填数字、高亮切换都不会重绘网格。而81个数字文本本身是最轻量的Text组件不涉及栅格布局系统。3.2 选中态与高亮联动一次遍历别搞复杂的监听数独里一个很能提升体验的交互是选中某个格子后它所在的行、列、宫、以及相同数字的其他格子都会高亮。这个功能如果做成“每个格子独立监听选中状态”代码会非常啰嗦而且容易出bug。正确做法是在build里基于当前选中的坐标一次性计算出所有需要高亮的格子索引集合然后每个格子绘制时查询这个集合。Setint _buildHighlightSet(int selectedIndex, Listint board) { final result int{}; if (selectedIndex -1) return result; final row selectedIndex ~/ 9; final col selectedIndex % 9; final selectedValue board[selectedIndex]; for (int i 0; i 9; i) { result.add(row * 9 i); // 同行 result.add(i * 9 col); // 同列 } final br (row ~/ 3) * 3, bc (col ~/ 3) * 3; for (int r br; r br 3; r) { for (int c bc; c bc 3; c) { result.add(r * 9 c); // 同宫 } } // 相同数字高亮排除自己 for (int i 0; i 81; i) { if (board[i] selectedValue selectedValue ! 0 i ! selectedIndex) { result.add(i); } } return result; }这个集合在每次setState时重新计算81个格子的遍历在设备上耗时可以忽略。格子绘制逻辑里final isSelected index selectedIndex; final isHighlighted highlightSet.contains(index); final isSameValue board[index] selectedValue selectedValue ! 0; bgColor isSelected ? const Color(0xFFBBDDFF) : isHighlighted ? const Color(0xFFEAF2FF) : isSameValue ? const Color(0xFFFFE8CC) : Colors.transparent;这套逻辑写出来非常直观后续想改高亮颜色、增加“错误数字标红”都是在自己的格子里加一个分支不会牵扯到兄弟组件。3.3 数字输入、笔记模式和撤销栈底部数字键盘我用了最简单的“横向一排”1到9加上一个橡皮擦。点击数字时向当前选中格子填入或移除数字。这里有几个交互细节值得注意数字键盘要禁用无效按钮如果当前格子已经固定题面给出的数字玩家点击数字应该无响应而不是填上后又被重置。可以在数字键盘接口里传入canEdit状态。笔记模式用Set存储候选数每个格子可能被填入多个笔记用Mapint, Setint存储简单直观。错误提示不能靠颜色误导玩家填错时我用一个淡红色背景标记但不会弹窗打断节奏。数独这种游戏最怕就是被频繁打断。撤销功能是“能玩”和“好用”的分水岭。我用一个简单的快照栈实现final _history Listint[]; final _noteHistory Mapint, Setint[]; void _snapshot() { _history.add(List.from(board)); _noteHistory.add({ for (final e in notes.entries) e.key: Set.from(e.value), }); if (_history.length 100) { _history.removeAt(0); _noteHistory.removeAt(0); } } void undo() { if (_history.isEmpty) return; board _history.removeLast(); notes _noteHistory.removeLast(); setState(() {}); }快照栈的细节是每次push的是新List和新的Set集合绝不能直接存引用。否则后续修改board时历史记录也会跟着变撤销就会失效。这个bug我一开始就踩过排查了半天才发现是引用共享的问题。保存100步足够长局使用了再多会占内存在低端设备上不划算。4. OpenHarmony部署与调试这一路踩的坑不踩一遍真不知道4.1 从Flutter工程到OpenHarmony壳工程如果你熟悉Flutter的Android工程那OpenHarmony壳工程的目录结构并不陌生。Flutter官方在OpenHarmony上的适配是通过“Flutter SDK for OpenHarmony”提供的需要在工程里新增一个ohos目录并配置好对应的构建脚本。整体配置步骤大致如下下载适配OpenHarmony的Flutter SDK并在flutter config里指定在项目根目录执行flutter create --platformsohos .生成壳工程在ohos/目录下检查module.json5和build-profile.json5中的bundleName和versionCode执行hdc list targets确认开发板连接用DevEco Studio或命令行完成签名配置再执行安装第一步其实是最大的坑。因为Flutter官方主分支优先支持Android/iOSOpenHarmony的适配分支是单独维护的。如果你用普通Flutter SDK执行flutter create根本看不到ohos这个平台选项。正确做法是下载适配了OpenHarmony的Flutter SDK并把它配置为当前项目的SDK路径。配置好之后flutter devices应该能看到OpenHarmony设备flutter run -d deviceId就能把调试包推上去。如果卡在了“设备不显示”这一步先确认hdc list targets能列出设备hdc是OpenHarmony的命令行工具类似Android的adb。4.2 hdc命令的日常查看系统版本和推送文件开发调试过程中我跟hdc打交道非常多。这里列出几个实用命令# 查看当前连接的设备 hdc list targets # 查看OpenHarmony系统版本 hdc shell param get const.product.name # 查看SDK版本 hdc shell param get const.ohos.version # 推送文件到设备 hdc file send ./app.hap /data/local/tmp/app.hap # 安装hap包 hdc install /data/local/tmp/app.hap # 查看应用日志 hdc shell hilog | grep your_app_tag尤其是hdc shell param get这组命令排查版本问题时特别好用。有几次应用装上去闪退我第一反应就是看系统版本和API Level是否匹配。OpenHarmony的API版本跟Flutter SDK的适配版本有对应关系版本不匹配会报奇怪的符号链接错误。4.3 签名配置那不叫坑叫连环坑OpenHarmony真机安装应用需要签名。这个流程跟Android的debug签名类似但手续更繁琐。最典型的报错是error: failed to install bundle. code: 9568320 error: verify signature failed.这个错误出现时我一度以为是hap包损坏后来才发现是签名证书和设备的UDID不匹配。OpenHarmony的签名需要一个.p7b文件和一个对应的.cer证书可以通过DevEco Studio的自动签名功能生成。自动签名要求登录开发者账号并且设备必须处于联网状态。我自己遇到的一个细节是开发板的UDID也可以叫devudid可以用hdc shell bm get -u查到和模拟器的UDID不一样换设备就要重新生成签名。如果你在一个开发板上调试得好好的换另一台板子突然签名失败优先检查是不是签名没重新配置。4.4 在RK3568和RK3588上的实际表现我手头有两块开发板一块RK3568一块RK3588。前者四核A55定位是低功耗入门级后者四核A76加四核A55性能明显更强。数独这个游戏两者跑起来帧率差别不太大但有一个现象很典型RK3588上丝滑流畅点击响应几乎是即时的RK3568上如果打开系统动画或者后台有大量应用Flutter的图形栈有时会出现掉帧问题不在Flutter本身而在OpenHarmony的图形合成器上。Flutter是自渲染引擎它的每一帧都是自己画好再交给系统合成的。如果系统合成压力大Flutter的提交会被排队。解决办法是在FlutterEngine初始化时设置final engine FlutterEngine(); engine.setCompatibilityMode(true); // 兼容模式降低部分渲染优化以提升稳定性这个参数不是所有场景都需要但如果你的游戏在特定设备上出现不均匀的卡顿可以试试看。另一个经验是数独这种静态页面不需要高频刷新整个Surface。我后来把不需要动画的区域用RepaintBoundary包起来实测在RK3568上的帧时间从平均16ms降到了10ms左右掉帧明显减少。4.5 如果你同时保留Android目录那个Gradle报错项目里如果同时保留了android目录有时在Android Studio或命令行构建时会弹出类似这样的Gradle错误You are applying Flutters main Gradle plugin imperatively using the apply script method.这个报错提示的是Flutter Gradle插件的新旧版本兼容问题。我一开始没管它因为反正目标平台是OpenHarmony。但它会影响flutter build命令的整体流程导致构建中断。解决办法很简单在android/settings.gradle里把旧的apply from: $flutterRoot/packages/flutter_tools/gradle/app_plugin_loader.gradle改成新版插件引入方式或者如果你暂时不需要Android包直接把android目录移出项目根目录等需要的时候再加回来。这个坑虽然小但很容易让人误以为是OpenHarmony环境没配好白白排查半小时。5. 从能玩到好玩难度曲线、状态恢复和几个隐藏Bug5.1 难度分级不能只看“挖洞数量”还要看逻辑链深度前面提到我用“已填数字数量”来粗略控制难度简单45个中等36个困难30个。但实际试玩下来发现单纯按数量分级有个毛病有时候挖了45个洞仍然简单得离谱有时候30个洞却简单得反常。原因是数独的难度本质由“解题需要用到的高级技巧链长度”决定。一个只有30个已知数的盘面如果每个格子的候选数都很容易排除可能比40个已知数但候选数密集的盘面更容易解。后来我在项目里加了一个“候选数最少格子”的统计出题时计算所有空格候选数的平均数和中位数。如果平均数超过4.2并且有至少一个空格候选数是6个以上就把难度标记为困难。这个指标不是最精确的难度评估但对移动端小游戏来说简单、可解释、调试方便比复杂的“人类解题策略模拟”实用得多。5.2 状态恢复不是存进度是存“撤销栈”很多小游戏只做了“暂停保存当前盘面”但玩家一退出再进来连之前填错想撤销的记录都没了。我当时做了一个更完整的恢复机制把board、notes、history三个对象序列化成JSON用shared_preferences存在本地每次玩家输入新数字时延迟1秒写入应用启动时检查是否有未完成的游戏有则弹出“继续上次”的提示notes和history序列化的细节比较容易出问题history是一个最多100层的ListListint直接JSON序列化没问题但反序列化时要确保每个内层都是新的List对象否则又会出现“引用共享”导致撤销失效。ListListint restoreHistory(Listdynamic raw) { return raw .map((layer) Listint.from(layer as Listdynamic)) .toList(); }5.3 我遇到的三个隐藏Bug附排查思路Bug 1完成判定偶发失灵现象玩家明明填满了整个棋盘且没有错误但“成功弹窗”不出现。排查链路我先去检查完成判定函数逻辑很简单——遍历81格board[i] ! 0且与solution[i]相等。但漏掉了一个场景如果玩家用笔记模式覆盖了数字board仍然是0notes里却有值。完成判定就会失败。修复方案是把完成判定改成同时校验board和solution且当board[i] 0时直接判未完成。Bug 2换肤后数字颜色不更新现象在设置里切换“深色模式”后棋盘上的数字颜色没变但背景变成了深色。深色背景上的深蓝色数字几乎看不清。排查链路第一反应是主题没刷新检查后发现Color确实变了但格子里的数字Widget在外层PageView重建时没有触发自身的build。原因是BoardPainter的shouldRepaint返回了false导致网格线和数字文本的绘制不更新。修复方案是把shouldRepaint改为比较背景色override bool shouldRepaint(covariant BoardPainter oldDelegate) oldDelegate.backgroundColor ! backgroundColor;Bug 3点击数字时偶尔出现“填格没反应”现象在RK3568上快速连续点击数字按钮部分点击没有生效。排查链路一开始以为是触摸事件丢失后来加日志发现是“数字键盘的onPressed回调里每次都会执行一次_snapshot()然后setState()”连续点击时第一次setState还没完成第二次就进来了导致中间某次点击被丢弃。修复方案是在输入处理函数开头加一个简单的防抖bool _isProcessing false; void _onNumberTap(int num) { if (_isProcessing) return; _isProcessing true; setState(() { // 填入数字 }); // 注意setState是同步的但build是异步的用下一帧清零防抖 WidgetsBinding.instance.addPostFrameCallback((_) { _isProcessing false; }); }这个防抖并不是真正的“丢弃输入”而是给UI一帧的缓冲时间避免极端快速点击下的竞态问题。用了之后触发率恢复正常在低端设备上连续点击再也没有丢过。5.4 后续可以继续扩展的方向这个数独生成器跑通后我脑子里浮现了好几个升级方向但目前还没有全部落地接入Flame游戏引擎做动画特效把“填对数字”的反馈做成粒子效果加入联机对战用OpenHarmony的分布式软总线做设备间实时同步做一个“每日挑战”模式用当前日期做随机种子保证所有用户拿到同一道题把所有逻辑抽成ArkTS版本做一个纯ArkUI的对照版对比两种开发方式的差异最后一个方向我觉得最有意思。如果把“同一套需求、同一套UI逻辑”分别用Flutter和ArkTS写一遍两份代码都跑在同一块RK3568上对比包体积、启动时间、帧率、内存占用那对这个生态里正在选型的团队会是特别有价值的参考资料。最后说说我的实际感受这个项目从零到能玩花了大概一周的业余时间。最大感受是在OpenHarmony上跑Flutter可行性早已不是问题问题在于一些“系统细节”需要多花时间适应。签名、hdc、部分渲染行为都跟Android有微妙差异但不会让你卡死。反而Flutter本身的跨端能力帮了大忙——算法层和UI层一次写好Android上能跑OpenHarmony上也能跑几乎不用改。如果你正打算用Flutter给OpenHarmony做一个工具类或者小游戏应用我的建议是把核心逻辑做成纯Dart把UI依赖降到最低然后在真机上尽早开始联调。别等全部写完再上设备那样遇到渲染兼容问题会非常难受。最后分享一个小技巧OpenHarmony设备调试时我习惯在代码里加一个“本机性能浮层”用FPS 帧时间的实时数据显示在屏幕角落。这样你在不同开发板上切换时能立刻看到当前设备的性能表现不用每次都拿电脑看日志。这个小功能对优化低端设备体验非常有效强烈建议在项目早期就做进去。
