野蛮人柯南先说结论：在 OpenHarmony 设备上用 Flutter 做一个可玩的迷宫游戏，完全可行，而且整个开发体验比我想象中顺。这个项目我从前年拖到去年，中间换了两次开发板，踩了设备树选错、插件加载失败、热重载失效三个大坑，最后把递归分割算法、手势控制和实时状态同步三块技术点完整串起来的时候，那种“终于跑通了”的感觉，是写纯业务代码给不了的。
如果你手头有一块 RK3568 或 RK3588 的开发板，想用 Flutter 跑点比 Hello World 更有说服力的东西，那这篇内容应该能帮上忙。我会把迷宫生成算法怎么选、手势怎么判、状态怎么刷，连同我在 OpenHarmony 上遇到的环境坑一起，按实际开发顺序讲清楚。文中的代码都是我从项目里摘出来的可运行版本，不是纸上谈兵的伪代码。
1. 为什么是迷宫：一个 Flutter 游戏项目的选型思考
1.1 一个小小的迷宫游戏覆盖了哪些技术环节
很多人学 Flutter 都是先跑一个计数器 demo，再套一个列表页。但计数器只覆盖了 StatefulWidget 的 setState，列表页只覆盖了 ListView 的懒加载，这些离真实产品还差得远。迷宫游戏不太一样，它像一个“压缩包”，把 Flutter 开发里最容易出问题的几块都装进去了。
第一块是算法层。迷宫不能每次启动都一样，否则可玩性为零，所以要用随机生成算法在运行时动态出新迷宫。这里涉及递归分割、随机数分布、二维数组的状态判断，是整篇文章里最需要动脑子的一部分。第二块是渲染层。迷宫网格和玩家角色不能靠贴图，那会显得非常笨重，应该用 CustomPainter 直接画在 Canvas 上，并且保证每一帧的画布重绘足够快。第三块是交互层。玩家用手指滑动控制角色移动，手势识别必须做到滑动不延迟、不回弹、不误触，这比按钮点击的难度高出一个量级。第四块是状态层。角色坐标、移动步数、计时器、胜利状态，每一秒都在变化，多个状态要同步刷新到界面，这时候再去用 setState 硬怼，代码会迅速变成一团乱麻。
把这四块都跑通，你基本就具备在 OpenHarmony 上把一个完整 Flutter 应用落地的能力了。我选择迷宫作为验证项目，就是因为它天然覆盖了这些。要是你只是想验证 OpenHarmony 能不能跑 Flutter，那随便写个按钮弹窗就行