Flutter鸿蒙游戏开发实战：俄罗斯方块跨平台实现解析

1. 项目背景与技术选型：为什么用 Flutter 做鸿蒙游戏

1.1 需求场景：一套代码到底能省多少事

这次的任务很明确：做一款能在鸿蒙设备上流畅运行的俄罗斯方块游戏，同时这套代码后续还要能复用到 Android、iOS，甚至是桌面端。团队现有的业务应用已经用 Flutter 框架写了不少页面，所以游戏模块必须跟现有技术栈保持一致，不能为了一个小游戏单独引入一套原生 ArkTS 开发流程。这个约束直接决定了技术选型不会有太多悬念，剩下要做的就是验证 Flutter 在鸿蒙平台上的完整落地链路。

很多人对“跨平台”的理解停留在“代码能跑就行”，但真正到工程层面，跨平台的价值体现在三个地方：业务逻辑不重写、UI 描述不重写、调试流程能复用。俄罗斯方块这种游戏，核心是网格状态、碰撞计算和图形渲染，这三块占了整个项目七成以上的工作量。如果用 Flutter 写，这七成可以一次性写好，剩下三成留给鸿蒙工程的接入、触控差异适配和打包签名。这个比例在小游戏里已经有了很强的说服力，如果是业务型应用，跨平台的收益还会更高。

俄罗斯方块特别适合做跨平台打样项目。它复杂度不高，但五脏俱全：有网格数据、有计时器、有用户输入、有状态持久化、有音效跳转接口、有平台通道可接。把它的完整链路在鸿蒙上跑通，后面再写任何 Flutter 应用心里都有底。我身边不少团队一上来就想用 Flutter 去接重型游戏引擎，反而因为生态不匹配卡在中间，像这种用经典小游戏验证框架能力的路子，其实更稳。

1.2 为什么选 Flutter 而不是 React Native 或原生 ArkTS

先把几套方案摆在一起看。原生 ArkTS 的优势是系统能力支持最直接，新特性跟进最快，性能上限最高，但代价是鸿蒙、Android、iOS 三端各写一套，维护成本直接翻三倍。React Native 在鸿蒙上也有社区适配，但桥接层效率与生态成熟度，目前在我实际体验里不如 Flutter 的渲染一致性来得干脆。

Flutter 走的是自绘渲染路线，所有控件都通过 Skia 引擎画出来，不依赖系统原生控件，所以 UI 表现几乎不会因为平台差异出现“长得不一样”的问题。这对游戏开发是加分项：俄罗斯方块的方格、边框、阴影，都是确定性的矩形绘制，Flutter 自绘能保证在鸿蒙手机、鸿蒙平板、PC 模拟器上看到完全一致的视觉效果，不需要像原生方案那样各自调样式。

选型对比我常用这张表说话：

俄罗斯方块没有特别重的原生依赖，但对输入延迟和渲染帧率敏感，Flutter 的自绘模型等于把渲染控制权交到了开发者手里，在这个场景下反而是最优解。

1.3 为什么选俄罗斯方块作为演示项目

俄罗斯方块堪称“游戏开发界的 Hello World”，但它比 Hello World 值钱得多。它的核心逻辑闭环覆盖了游戏开发最典型的问题域：方块形状定义、旋转矩阵、碰撞检测、行消除、计分规则、等级加速、游戏结束状态。这些逻辑加起来大概千行左右，单文件就能放下，非常适合作为技术验证载体。

这个游戏天然适合多形态设备的验证。手机竖屏单手玩很顺，折叠屏展开后网格可以居中加宽，平板和 PC 窗口上还可以做更复杂的键盘操作。鸿蒙生态正好覆盖手机、平板、PC、车机等多种形态，用俄罗斯方块验证 Flutter 在多尺寸屏幕下的自适应能力，比抽象的业务 Demo 直观得多。开发过程中，我只需要保证网格边长和屏幕高度成比例，其他交给 Flex 布局和 AspectRatio 处理，就能在不同设备上保持基本一致的体验。

2. 开发环境搭建与工程初始化

2.1 版本搭配：Flutter、鸿蒙 SDK、DevEco Studio 怎么选

环境搭建是整个项目的第一道坎，版本选错后面全是泪。我自己实测下来比较稳的一套组合是：Flutter 3.16 以上版本、DevEco Studio 4.0 Release、HarmonyOS SDK API 10 及以上的模拟器环境。鸿蒙对 Flutter 的支持，本质上是通过 OpenHarmony 的 Flutter 适配分支落地的，所以光装官方 Flutter 还不够，得把适配分支映射到本地 SDK 上，这步是很多人卡住的地方。

版本这块我踩过一个大坑：如果 DevEco Studio 版本太老，新建的鸿蒙工程默认模板不支持 Flutter 模块注入，后面跑起来全是“Unable to find FlutterModule”之类的报错。建议直接装新版本，用空 Ability 模板创建工程，然后手动把 Flutter 模块接进去，这样反而比依赖自动模板更可控。SDK 版本也要注意，API 9 和 API 10 对 NDK、C++ 支持差异很大，Flutter 引擎在鸿蒙上运行依赖 C++ 层的编译，API 版本低了会直接连编译都过不去。

code复制实测环境清单
Flutter SDK：3.19.x
DevEco Studio：4.0 Release
HarmonyOS SDK：API 10
目标设备：鸿蒙模拟器 API 10 + 真机 HarmonyOS 4.0

2.2 在 VSCode 里完成 Flutter 安装与配置

如果你习惯用 VSCode 写 Flutter 代码，那日常开发可以完全留在 VSCode 里，只是鸿蒙侧工程的 HAP 编译、签名配置还需要 DevEco Studio 来承担。两把刀配合使用，体验其实不错。具体步骤是：先装好 Flutter 插件，执行一遍 flutter doctor 确认 SDK 路径和 Dart 路径都没问题；然后打开鸿蒙工程根目录，VSCode 会识别成 Flutter 工程，再装 Dart 插件，确保 flutter attach 端口能正常输出。

配置完成后，日常迭代就是这样的节奏：在 DevEco Studio 里点击构建，构建成功后切到 VSCode，热重载的日志会实时滚出来。Dart 代码改了直接按快捷键热重载，UI 立刻刷新；碰到需要动鸿蒙原生能力的场景才切回 DevEco 改 ets 代码，改完再重新编译一次。这套流程走顺之后，写代码的体验跟纯 Flutter 开发几乎没差别。

需要额外提醒的是环境变量。鸿蒙 SDK 的 hdc 工具路径、DevEco 自带的 Node 路径，最好都手动配到系统 PATH 里，不然 flutter devices 可能识别不到鸿蒙设备。我遇到过一次很诡异的现象：模拟器开着，但 DevEco 能看到设备，VSCode 里 flutter devices 就是死活不显示，最后排查下来就是 hdc 工具路径没暴露到命令行环境里。

2.3 创建项目模板与连接鸿蒙设备

创建 Flutter 工程本身很简单，flutter create tetris_app 一条命令搞定，默认会生成 Android、iOS、Web 等相关目录。但 Flutter 原生脚手架不会生成鸿蒙的 ohos 目录，这一步需要额外处理：要么手动把 Flutter 适配分支提供的 ohos 工程模板拷贝进来，要么在适配分支里跑专门的初始化脚本。做这一步时务必确认模板版本跟 Flutter SDK 版本匹配，版本错位会导致编译期各种 C++ 符号找不到。

设备连接方面，鸿蒙模拟器电脑版启动后，默认就能被 DevEco Studio 识别。到了 flutter devices 层面，鸿蒙设备通常会以 ohos 开头标识，比如 ohos-emulator-4.0。真机的话，需要先在设置里打开开发者模式，再在“系统与更新-开发人员选项”里打开 USB 调试。连接成功后，DevEco 里配置签名文件，跑一次构建，能看到应用安装到设备的过程：

code复制flutter devices
ohos-emulator-4.0  •  emulator-4.0  •  harmonyos  •  ARM64

这一步跑通意味着跨平台游戏开发的“最后一公里”已经打通，后面所有游戏逻辑的调试都不需要反复处理设备问题了。

3. 俄罗斯方块核心逻辑设计拆解

3.1 网格建模：10 列 20 行的二维空间

俄罗斯方块的基础玩法都发生在一个固定大小的网格里，我沿用经典规则：宽 10 格、高 20 格。网格在代码里就是一个二维数组，我用整形数组表示，0 代表空格，1 代表已固定的方块。之所以不用布尔值，是因为后续可能扩展消除特效、方块颜色标记，整形数组更灵活。

code复制dart
class GameBoard {
  static const int cols = 10;
  static const int rows = 20;
  late List<List<int>> grid;

  GameBoard() {
    grid = List.generate(rows, (_) => List.filled(cols, 0));
  }
}

这块的建模直接决定了整个游戏逻辑的复杂度。网格坐标我采用“行号从上往下递增、列号从左往右递增”的方式，跟屏幕上看到的网格完全一致。这比数学里常见的笛卡尔坐标系更直观，因为遍历行、计算消行时，不需要做坐标翻转，出错概率大幅降低。

3.2 七个方块的数据结构与旋转算法

俄罗斯方块有七种经典形状，术语叫 Tetromino，分别是 I、O、T、S、Z、J、L。每种方块我用一组相对坐标来定义，基准点取方块的左上角逻辑位置。比如 I 形，占据同一行的连续四格；T 形，横向三格加下方中间一格。代码里用二维数组表示：

code复制dart
const Map<String, List<List<int>>> tetrominoes = {
  'I': [[0, 0], [0, 1], [0, 2], [0, 3]],
  'O': [[0, 0], [0, 1], [1, 0], [1, 1]],
  'T': [[0, 0], [0, 1], [0, 2], [1, 1]],
  'S': [[0, 1], [0, 2], [1, 0], [1, 1]],
  'Z': [[0, 0], [0, 1], [1, 1], [1, 2]],
  'J': [[0, 0], [1, 0], [1, 1], [1, 2]],
  'L': [[0, 2], [1, 0], [1, 1], [1, 2]],
};

旋转算法是这节的重点。最简洁的做法是矩阵坐标变换：绕方块中心旋转 90 度，顺时针旋转的变换公式是 (x, y) -> (y, -x)。但直接套公式会出现负坐标，所以我在实现时加了偏移修正：旋转前先找方块的最小行和最小列，旋转后再平移回正数区域。这样比预置四套旋转姿态的“土办法”代码量更少，而且新增自定义形状时依然通用。

code复制dart
List<List<int>> rotate(List<List<int>> cells) {
  int minRow = cells.map((c) => c[0]).reduce(min);
  int minCol = cells.map((c) => c[1]).reduce(min);
  List<List<int>> rotated = cells.map((c) {
    int newRow = c[1] - minCol;
    int newCol = -c[0] + minRow;
    return [newRow, newCol];
  }).toList();
  return rotated;
}

旋转后会先做碰撞检查，只要旋转后的坐标都在网格内且不与已固定的方块重叠，才真正提交这次旋转；否则就维持原状。这种“先预测、后提交”的模式，是游戏逻辑稳健的关键，后面移动方块的判定也是一样的套路。

3.3 碰撞检测、消行与游戏结束判定

碰撞检测是对当前活动方块的所有格子逐一做合法性校验：新位置列号是否在 0 到 9 之间，行号是否小于 20，以及网格对应位置是否为 0。只要有一个格子不满足，就视为碰撞，不能移动。

code复制dart
bool canMove(List<List<int>> cells, int dr, int dc) {
  for (var cell in cells) {
    int nr = cell[0] + dr;
    int nc = cell[1] + dc;
    if (nc < 0 || nc >= GameBoard.cols || nr >= GameBoard.rows) return false;
    if (nr >= 0 && grid[nr][nc] != 0) return false;
  }
  return true;
}

消行逻辑也比较直接：方块固定到网格后，从下往上扫描每一行，如果一整行都是 1，就把这一行删掉，再在网格头部插入一填空行。注意扫描方向必须是从下往上，因为删除一行后上面的行会下移，从下往上处理不会漏掉连续消行的情况。

游戏结束判定则发生在新方块生成时：如果生成位置已经被已有方块占用，说明网格堆满了，游戏结束。这套逻辑写下来只有几个方法，但覆盖了完整的状态闭环，调试时只需要盯住“生成-移动-旋转-固定-消行”这条主线。

4. 游戏界面与跨平台交互

4.1 用 CustomPaint 绘制游戏面板的思路

游戏面板的 UI，我推荐用 CustomPaint 自绘矩形格子，而不是用 200 个单独的 Widget 去拼格子。原因是性能差异太大了。一个 10x20 的网格如果用 Widget 拼，就是 200 个容器组件，每次刷新都是几百个 Widget 重建；用 CustomPaint 的话，一帧只画一次画布，Dart 代码里只负责把网格数据传进去，绘制开销小一个量级。

具体绘制思路是这样的：先把画布按网格尺寸等分，每个格子的像素宽度等于画布宽度除以 10。然后遍历网格数组，0 的画背景色，1 的画方块填充色，再给每个格子描一个 1 像素的浅色边框。活动方块和固定方块用不同颜色区分，我习惯活动方块用亮色，固定方块用暗一档的颜色，这样玩家的视觉注意力能自然集中在正在操作的目标上。

code复制dart
class BoardPainter extends CustomPainter {
  final List<List<int>> grid;
  final List<List<int>> activeCells;
  // 绘制网格、格子、活动方块等逻辑
  @override
  void paint(Canvas canvas, Size size) {
    final cellWidth = size.width / GameBoard.cols;
    final cellHeight = size.height / GameBoard.rows;
    // 绘制背景与格子
  }
}

如果对 CustomPaint 不熟，也可以用 GridView 或 Table 先做出一个能玩的版本，但跑起来之后会发现每次刷新都明显卡顿，尤其是消行动画阶段。我建议直接一步到位用自绘，后面做“下落高亮”“消除闪烁”这些动画特效时，CustomPaint 的处理能力完全够用，不用再推倒重来。

4.2 触控、键盘与外部输入的适配

输入适配是跨平台项目最容易翻车的地方。鸿蒙手机上的输入是触控，PC 模拟器上是键盘和鼠标，如果只监听触控事件，键盘操作就全废了。俄罗斯方块需要区分左移、右移、旋转、加速下落、硬降底五个操作，我分别针对触控和键盘做了两套处理。

触控端，我通过 GestureDetector 的 onPanUpdate 判断手势滑动方向，手指左滑触发左移，右滑触发右移，下滑触发加速下落，双击触发旋转。这里有个细节：判断方向时用滑动距离的绝对值比较 dx 和 dy，可以避免斜向滑动被误判成两个方向操作。键盘端则监听 RawKeyboardListener 或 HardwareKeyboard，方向键控制移动和旋转，空格键硬降底，P 键暂停。同一套逻辑里按平台能力做能力检测，有键盘就用键盘事件，没有就回退到触控。

这套方案实测下来，在鸿蒙模拟器上键盘操作延迟很低，游戏反馈跟原生应用没区别。真机触控方面，要特别注意 onPanUpdate 事件的触发阈值，手滑速度过快时会丢事件，我在每次 onPanUpdate 里加了事件合并逻辑，只取 delta 累计值做大动一步，避免一次滑动触发无数次微动。

4.3 计分、等级与下落速度曲线

计分规则直接决定游戏的上头和流失曲线。我采用的是经典规则加微调：消 1 行得 100 分，2 行得 300 分，3 行得 500 分，4 行得 800 分。这个分值表是按“难度陡增”的原则设计的，鼓励玩家追求一次消四行。每消除 10 行升一级，等级越高，方块下落速度越快。

下落速度曲线是游戏手感的核心。我用的公式是 800 - (level - 1) * 70，单位毫秒，也就是第一级方块每 800 毫秒下落一格，每升一级加速 70 毫秒，最低速不低于 100 毫秒。这个曲线在 10 级左右的区间内手感比较适中，不会突然快到没法操作。落到底部后的“锁定延迟”我保留了 300 毫秒，让玩家在最后关头还能微调方块位置，这是消除挫败感很关键的一个参数。

code复制dart
int getDropInterval(int level) {
  return max(100, 800 - (level - 1) * 70);
}

游戏循环用 Timer.periodic 驱动，每次 Tick 触发方块下落一格。这里要注意的是，Timer 回调里不能直接操作 Flutter 的 BuildContext，所有数据变更要汇总到游戏控制器，再由控制器统一通知 UI 刷新，否则会出现“一帧内多次 setState”的性能警告和潜在的数据竞态。

5. 状态管理、本地存储与平台能力接入

5.1 状态管理方案怎么选

俄罗斯方块这种规模的项目，状态管理不需要上重型框架。我用了 Flutter 自带的 ChangeNotifier 加一个继承自它的 GameController，外面用 ListenableBuilder 监听状态变化。代码里所有游戏逻辑都收拢在控制器里，UI 组件只需要调方法，比如 controller.moveLeft()、controller.rotate()，然后监听控制器通知并重绘界面。

很多人写小游戏喜欢把游戏状态直接放在 StatefulWidget 里，玩到后期就会发现一个问题：页面一重建，状态全丢。把状态放到独立控制器的好处，不只是复用，更重要的是可测试。消行逻辑、碰撞检测、计分函数，都可以在控制器层面写单元测试，不依赖任何 Widget 生命周期。我写这个项目的时候，核心逻辑的单元测试就跑了十几个用例，后面改旋转算法、调速度曲线都大胆多了。

至于 Bloc、Riverpod 这些方案，功能更强大，但对这个项目属于杀鸡用牛刀。它们带来的样板代码和管理复杂度，在小项目里的收益基本可以忽略。我见过太多小游戏项目被状态管理框架拖到写不下去的情况，所以这里只推荐最朴素的方案，够用且可控。

5.2 排行榜用 shared_preferences 还是 SQLite

游戏肯定要存最高分、记录最近几局成绩和游戏时间。存储方案我分了两层：最外层存排行榜，用 shared_preferences 保存 JSON 字符串，简单直接；如果后续要做更复杂的玩家统计，比如按日期查历史、导出成绩，那就得上本地数据库。

shared_preferences 的本质是键值对存储，底层在 Android 是 SharedPreferences，在 iOS 是 NSUserDefaults，在鸿蒙上适配分支则会映射到 Preferences 相关实现。使用它不需要初始化数据库、不需要建表、不需要处理升级迁移，非常适合量小、结构简单的数据。我把排行榜设计成最多存 10 条记录，每条包含玩家名、分数、等级、时间戳，序列化成 JSON 数组塞进一个 key 里，读写都很快。

如果项目需求变成“每局详情都要保留、支持按日期范围查询、还要跟服务端同步”，那就得换 SQLite。热词里提到的“flutter 做本地数据库+后端同步”就是这个方向。Flutter 里常见的 sqflite 插件，在鸿蒙适配环境下也能工作，原理还是平台通道调用原生数据库能力。但一定要先验证插件对鸿蒙的兼容性，有些插件版本只实现了 Android/iOS 原生代码，鸿蒙上会直接报 MissingPluginException。

5.3 平台通道：调用鸿蒙原生能力的通路

Flutter 和鸿蒙原生之间的通信靠平台通道，MethodChannel 是最常用的一种。它的工作方式很简单：Dart 侧定义一个通道名，调用 invokeMethod 往原生侧发消息；鸿蒙侧在对应的 Engine 代理或 AbilityStage 里注册同名通道，接收调用并返回结果。俄罗斯方块里我用到的最典型场景，是读取系统全局的最高分、请求系统弹窗确认、以及拉起系统分享把成绩分享出去。

Dart 侧代码：

code复制dart
static const MethodChannel _channel = MethodChannel('tetris_harmony/channel');

Future<int> getBestScore() async {
  final int score = await _channel.invokeMethod('getBestScore');
  return score;
}

Future<void> saveScore(int score) async {
  await _channel.invokeMethod('saveScore', {'score': score});
}

鸿蒙原生侧接这种调用时，核心是按适配分支提供的接口实现 MethodCallHandler，在里面通过 call.arguments 拿到参数，再返回给 Dart 层。我踩过的一个坑是通道名必须完全一致，大小写、下划线都不能差，否则静默失败，Dart 侧会一直等不到结果。另外，Dart 层调用原生方法要包 try-catch，防止原生侧抛异常导致整个游戏崩溃。

平台通道的能力边界其实很大，鸿蒙图库、IAP 支付、扫码、推送，都可以通过这个通路接入。虽然俄罗斯方块用到的原生能力不多，但把这条链路验证好，后续接支付、接登录都只是换一个方法名的事。

6. 鸿蒙打包发布与性能调优

6.1 HAP、HSP、HAR 三种包怎么选

鸿蒙的应用打包格式跟 Android 的 APK 体系有相似处，但差异也很大。开发文档常看到 HAP、HSP、HAR 三个词，实际区别是这样的：HAP 是应用安装包，可以独立安装运行，一个 App 可以有多个 HAP，最常见的是 entry 模块；HSP 是动态共享包，运行时才加载，适合多个 HAP 之间共享代码和资源；HAR 是静态共享包，编译期直接打进 HAP，相当于一个静态依赖库。

俄罗斯方块这种单模块小游戏，只需要打一个 entry HAP 就够了。但如果以后要做多端协同，比如手机端和平板端各有独立功能模块，可以考虑拆成多个 HAP；如果团队内部有多个应用要共享一个“游戏引擎”模块，HSP 是更好的选择，更新共享模块时不用重新发布整个应用。

打包过程主要在 DevEco Studio 里完成，选择 Build > Build Hap(s)/APP(s)，然后配置签名证书。第一次打包一定要先申请签名证书，调试签名和应用签名是两套独立的体系，很多人第一次卡在“HAP 安装不上”就是签名不对。打包成功后，产物是一个 .hap 文件，可以通过 hdc 命令直接安装到真机：

code复制bash
hdc install entry-default-signed.hap

6.2 让游戏更流畅的几个调优点

跨平台应用最容易被人吐槽的就是“不跟手”。俄罗斯方块这种实时性强的游戏，性能调优比功能实现更重要。我做了四件事，实测下来效果明显。

第一，整个游戏面板用 RepaintBoundary 包裹，避免面板重绘时牵连整个页面。第二，所有游戏状态变更统一合并到同一个通知周期，任何输入事件都只触发一次 setState 或 notifyListeners，杜绝一帧内多次刷新。第三，渲染层面用 CustomPaint 而非 Widget 拼装，规模差距前面说过了。第四，固定方块的渲染缓存到图片层，每次重绘只画活动方块，固定方块层直接复用上一帧的图片，把每帧绘制开销降到最低。

帧率方面，在鸿蒙模拟器上跑到 60FPS 完全没问题，真机更是稳得一批。高刷设备上要注意一点：没有强制刷新帧率的游戏在 120Hz 屏上可能会出现“手感过快”的错觉，我建议把游戏内计时器按毫秒计算，不要依赖帧率驱动，这样高低刷设备上的下落速度是一致的。

另外一个容易被忽视的点是内存。典型一局游戏如果从开局玩到 Game Over，网格、活动方块、操作记录都会积累内存，长时间运行后要主动清理不再使用的历史记录，防止应用被系统回收导致数据丢失。

6.3 模拟器与真机兼容性实测

鸿蒙模拟器电脑版和真机有差异，游戏开发必须两个环境都测。模拟器上最明显的问题是图形渲染依赖宿主机 GPU，性能波动比真机大；真机上最明显的差异是触控精度和屏幕尺寸。我用同一套代码分别跑了一遍，结果如下：

测试结论：两个环境都能正常完整体验游戏，但真机的触控体验明显优于模拟器。所以日常逻辑调试用模拟器足够，但手感调优和发布前验收一定要上真机。另外，折叠屏和平板的分屏适配也要考虑，俄罗斯方块在宽屏上如果直接把网格拉伸到全屏会很丑，我通过限制网格最大宽高比加居中策略，让它在任何尺寸下都能保持经典比例。

7. 常见问题与排查记录

7.1 高频报错速查表

开发过程踩过的坑不少，我整理了一张速查表，遇到类似问题可以直接对号入座：

我最想单独说的是第一条。Windows 上编译 Flutter 鸿蒙工程，第一次构建几乎必报 CMake Error，提示找不到 Visual Studio 生成器。这个问题的根源不是 Flutter 代码，而是鸿蒙引擎的 C++ 层编译需要 MSVC 工具链。装一个 Visual Studio Build Tools，把“使用 C++ 的桌面开发”工作负载勾上，重启电脑后再构建就好了。

showLicensePage 相关的主题问题也值得一提。如果你在应用启动页调用了 showLicensePage，它默认会套用独立路由的 Material 主题，跟应用全局主题可能对不上。要让它跟随全局主题，需要在调用前用 Theme 包一圈，或者直接给 MaterialApp 设定全局 ThemeData，否则许可证页面会突然“变脸”，颜色、字体都跟整体风格不一致。

7.2 调试手段与热重载技巧

调试跨平台应用的痛点是：Dart 代码和鸿蒙原生代码跑在两个不同的执行环境里。我推荐的做法是双端同时调试。Dart 侧，在 VSCode 里打断点，配合 Flutter DevTools 看 Widget 树和性能分析；鸿蒙侧，在 DevEco Studio 里对 ets 代码打断点，通过 Log 面板看原生日志。两边日志打上同一个请求 id，排查跨端问题时能快速定位是哪一层的问题。

鸿蒙端的打断点，我是在 DevEco Studio 的调试模式下直接断在 ArkTS 代码行上，启动调试会话后应用会停在断点处。这里有个技巧：不要把断点打在平台通道处理器内部，因为 Dart 侧的 invokeMethod 是异步等待，断住原生侧太久会影响超时判断，建议查看调用参数直接用日志，要断也只是断在耗时逻辑附近。

热重载方面，Dart 代码修改后按 R 键即可热重载，UI 立即刷新，游戏状态大部分情况能保留。改到原生侧代码后，热重载无法生效，必须从 DevEco 重新构建安装。这里我建议构建安装时用 debug 签名，可以大幅减少重复签名配置的麻烦；发布前再切到 release 签名做最终验证。

7.3 写在最后的一点个人体会

这个项目做下来，我对 Flutter 做鸿蒙游戏的态度还是那句话：不神话，也不劝退。它解决了一部分真问题，比如一套核心逻辑三端复用、UI 渲染一致性高、调试效率不输原生方案；但也存在需要注意的边界，比如插件生态对鸿蒙的兼容程度参差不齐，有些依赖原生能力的第三方库需要等适配或自己写平台通道兜底。

如果让我重新做一遍，我会在一开始就把平台通道的封装抽象出来，而不是写到哪个功能才加哪个通道。为后续接支付、接登录、接系统分享留好统一的扩展口，能让项目在从 Demo 走向正规应用时少改很多代码。游戏开发的成就感不只在代码跑起来那一刻，更在把一个想法打磨成完整产品的过程里。这个俄罗斯方块项目很小，但它把 Flutter 跨平台鸿蒙开发的整条链路完整跑通了，光是这一点，就已经值回所有折腾的时间。