基于局部可见性的沉浸式迷宫游戏：Flutter在OpenHarmony上的实现与优化

做个全图可见的迷宫游戏很容易，难的是让玩家明明只能看见一小团光晕，却愿意在黑漆漆的迷宫里走十几分钟。这个项目最开始的版本其实是个普通迷宫，整张地图摊开，玩家在左上角，终点在右下角，五秒钟就能规划好路径，三分钟后就没人想玩了。后来我把地图藏进了黑暗里，只保留玩家周围一圈可视区域，奇怪的事情发生了——测试的人开始贴着墙走、在岔路口犹豫、甚至把远处一盏灯的微光当成了剧情线索。

这就是标题里说的“基于局部可见性的沉浸式探索游戏设计”，技术实现不复杂，但背后涉及的体验机制、渲染方案和真机适配问题不少。这篇文章主要写给想在OpenHarmony设备上用Flutter做交互类应用的开发者，尤其是对游戏式体验、自定义绘制、真机调优感兴趣的朋友。我会从设计动机、技术选型、环境搭建、核心算法、内容设计和性能优化几个方面展开，全部是实际项目中验证过的方案。

1. 为什么“看不见”反而更有探索欲：光影迷宫的设计原点

1.1 一次试玩反馈把“全知视角”改成了“手电筒视角”

最初的迷宫demo挺传统的：白底黑线，整张地图都亮着，玩家拿方向键控制一个小方块从起点走到终点。功能上没有任何问题，碰撞检测、路径连通都正常，但测试反馈非常一致——无聊。玩家扫一眼屏幕就已经知道了路线，剩下的动作只是“走过去”，没有任何决策成本。

后来我想到一个很直觉的改动：把地图全部涂黑，只在玩家周围留一个圆形的视野范围。当时第一版做得很粗糙，只是用黑色遮罩盖住地图，在玩家周围挖个圆洞。结果效果出乎意料，最先参与测试的几个同事，连玩了好几把，而且开始讨论“刚才那个岔路左边好像有东西”“这扇墙后面是不是有条隐藏通道”。那是我第一次意识到，限制信息反而创造了游戏性。

1.2 局部可见性带来的三个心理变化

我把这种体验拆解成三个可复用的设计要素，后来做关卡时一直按这三条来检查：

• 未知感制造警觉。黑暗里的一切都是未知的，玩家无法确认转角后面是路还是死胡同，每走一步都在做预判。这种警觉状态下，玩家对微弱的声音、光影变化的感知会明显增强，整个探索过程变得专注。

• 掌控感来自“光晕内安全”。视野范围虽然有限，但它是确定的。玩家在光晕范围内可以放心移动，能清楚地判断距离、朝向、可走的方向，这种“安全区加危险区”的对比，比单纯的全黑恐怖游戏更容易让人接受，也能维持更长的游玩时间。

• 空间记忆驱动成就感。由于看不到全局地图，玩家只能靠记忆在脑中拼接路线，每走一段路就会形成一次“哦，这里到过”“这条路通往刚才那个岔口”的认知更新。这种在脑内建立地图的过程，比跟着小地图箭头跑路有成就感得多。

这三点合在一起，形成了一个很有意思的体验循环：恐惧未知、控制当下、记忆全局。玩家表面上在迷宫里找路，实际上是在自己脑内搭建攻略。

1.3 视野半径该设多大：参数实验得出的结论

视野半径是整个游戏最重要的参数，我做过一组简单对比实验，用固定迷宫、固定光源位置，只改视野半径，记录测试者的主观体验。结果大致如下：

我最终把默认半径定在5格。这个值的好处是：玩家能看清当前房间和临近通道，但又无法看清下一个岔路的完整走向，恰好维持了那种“再往前一步就能看到更多”的拉扯感。如果你的场景分辨率或者行走速度不同，这个值需要重新测，但测试方法可以直接复用。

2. 技术选型：为什么是Flutter for OpenHarmony而不是ArkTS或Unity

2.1 三条候选路线的真实对比

做技术选型时，我认真列过几条路：OpenHarmony原生ArkTS、Flutter for OpenHarmony、Unity/Godot移植、React Native for OpenHarmony。各有各的坑，但我的选择很明确：

2.2 Flutter引擎在OpenHarmony上的适配边界

这里要先说清楚一个关键背景：Flutter官方主线的SDK并不会直接生成OpenHarmony工程，目前能跑通的是OpenHarmony SIG维护的flutter_flutter和flutter_engine适配分支。这决定了你在用这套技术时，不要把“OpenHarmony支持”当成Flutter官方特性，而要当成一个活跃社区项目去对待。

在我实际测试下来的结果，Dart层的大部分能力、Widget组件树、手势系统、动画系统、CustomPainter自定义绘制，在OpenHarmony上都能正常使用，因为适配层已经把OpenHarmony的渲染接口接入了Skia。这意味着光影迷宫的核心玩法，尤其是大量Canvas绘制和Path运算，基本不需要改动就能跑。

真正会疼的地方是插件。很多pub上的Flutter插件只有Android/iOS实现，没有ohos实现，一旦依赖了这类插件，编译阶段就会出现类似“flutter error resolving plugin”的报错。我的处理原则是：能用Dart纯逻辑解决的就不用插件，必要情况下自己写PlatformChannel，或者裁剪掉不支持的功能。

2.3 我当时做决策的真实理由

技术选型没有绝对最优，只有适不适合你的团队和产品目标。我当时的核心约束有三条：

第一，这个项目虽然跑在OpenHarmony设备上，但产品后续很可能会出Android版本，需要一套代码多端复用。Flutter在这方面的优势是现成的。

第二，团队只有两个人，一个人写逻辑，一个人做关卡设计，没有专职前端也没有TA。Flutter的CustomPainter允许我们用Dart直接写渲染逻辑，不需要引入Unity编辑器的工作流。

第三，光影迷宫的视觉效果本质上是2D矢量绘制加遮罩运算，这点正好是Flutter的强项。射线、多边形、渐变、模糊这些能力Skia都封装好了，我可以把精力放在玩法而不是引擎底层。

所以我最终的结论是：Flutter for OpenHarmony虽然不是最成熟的方案，但在“OpenHarmony + 2D自定义绘制 + 跨端复用”这个交叉需求下，它是能让你用最小成本跑起来的选择。

3. 环境准备：从电脑到RK3568真机，搭建一条能跑的链路

3.1 工具链全景：Flutter SDK分支、OpenHarmony SDK、DevEco Studio

这段环境准备是最劝退人的部分，但走通一次之后后续就很顺。我当时的工具链是这样组合的：

• DevEco Studio：负责OpenHarmony工程的构建、签名、安装管理。版本建议和OpenHarmony SDK配套，不要用太新的预览版。
• Flutter SDK：需要单独准备一份OHOS适配分支，而不是你平时写Android用的Flutter SDK。可以理解为两个Flutter SDK共存，日常写Android用官方版，做OpenHarmony用SIG分支。
• OpenHarmony SDK：通过DevEco Studio下载，里面包含系统API、toolchain、模拟器镜像等。

配置时最需要注意的是环境变量。我当时把OHOS的Flutter SDK路径单独配了一个别名，避免和官方flutter命令冲突。否则你很容易出现“明明写的是Flutter项目，却把Android的Gradle配置带进了OpenHarmony工程”这种混乱。

3.2 初始化工程：Flutter代码和OpenHarmony壳工程如何配合

Flutter for OpenHarmony的项目结构，本质上是在Flutter工程外面包了一层OpenHarmony壳工程。Flutter侧负责游戏逻辑和渲染，OpenHarmony侧负责设备入口、权限声明、应用图标和生命周期托管。

我建议按这个顺序初始化：

1. 先用OHOS的Flutter SDK创建Flutter工程，跑通默认计数器页面。
2. 使用适配工具或模板生成ohos目录下的壳工程。
3. 用DevEco Studio打开该壳工程，配置签名、权限、应用名称。
4. 在Flutter侧把默认页面替换成自定义Widget，确保Flutter引擎能在设备上正常上屏。

第一次跑通“Flutter页面在OpenHarmony设备上显示出来”这个目标时，整个链路就被验证了，后面所有开发都是在Dart侧进行，不用反复折腾壳工程。

3.3 hdc连接设备：查看系统版本、装应用、抓日志

hdc是OpenHarmony的调试命令行工具，相当于Android的adb。我在开发中高频使用的几个命令：

• hdc list targets：查看当前连接的设备列表。
• hdc shell param get const.product.software.version：查看OpenHarmony系统版本。很多人问的“hdc查看openharmony系统版本”就是这个命令。
• hdc install entry-default-signed.hap：安装编译出的hap包到设备。
• hdc shell hilog：实时查看设备端日志。Flutter的print输出也会打到这个日志里。
• hdc shell param get const.product.serial：获取设备序列号，做设备标识或存档绑定时会用到。

这些命令看起来简单，但真机调试几乎天天要用，尤其是hilog，我每改一次代码都要盯着它排查异常。

3.4 早期最容易卡住的两个坑

环境搭建阶段我踩了两个印象很深的坑，网上相关的报错文章也很多，值得提前说明。

第一个是插件解析问题，对应那句常见的报错：“you are applying flutter's main gradle plugin imperatively using the apply s...”。这个问题的根源通常是：工程的Gradle配置还带着Android插件解析逻辑，而OpenHarmony壳工程根本不走那套流程。解决办法不是去改Gradle脚本，而是确认插件目录里是否存在ohos实现，以及壳工程的插件声明是否正确。没有ohos实现的插件，直接移除或换方案。

第二个是Flutter SDK分支和OpenHarmony系统版本不匹配。有时候你在设备上能装上hap，但Flutter页面白屏或者启动即崩，大多是因为flutter_flutter分支、flutter_engine分支和设备的OpenHarmony版本不兼容。我当时的做法是固定一套验证过的组合，记到项目的README里，不轻易升级。它不一定是新的，但一定能跑。

4. 核心玩法实现：局部可见性系统的设计与编码

4.1 把画面拆成四层，让迷雾只作用于特定内容

光影迷宫的画面不能一个Canvas全画完，分清楚图层的职责，性能和效果都更好。我最终拆成了四层：

• 背景层：迷宫地图、地面纹理、墙壁填充。这一层不会频繁变化，放在RepaintBoundary里，不参与每帧重绘。
• 迷雾层：全屏半透明深色遮罩，用来盖住不可见区域，但中间需要“挖”出玩家可见的多边形。这一层是局部可见性渲染的核心。
• 光晕层：在视野范围内绘制径向渐变，模拟灯光从中心向四周衰减的效果。
• 动态实体层：玩家角色、光源闪烁特效、收集品、粒子等。

实际绘制顺序是：先画迷宫背景，再画迷雾层，再画光晕，最后画玩家。这样玩家头顶永远是亮的，不会被迷雾盖住。

4.2 视野多边形：用射线求交算出来的“光”

局部可见性并不能只是画一个圆形视野，因为迷宫里有墙壁，墙壁会挡住视线。如果直接画个圆，玩家会隔着墙看到不该看的内容，沉浸感瞬间破碎。

正确的做法是计算视野多边形：从玩家位置向四周均匀发射N条射线，每条射线和最近的墙壁求交，交点就是可视边界；把这些交点连起来，就得到一个不规则的视野多边形。墙壁后面的区域自然不会被包括进来，遇到走廊拐角时会形成残缺的光边，效果非常像手电筒照进迷宫。

核心计算分两步。第一步是射线与矩形求交，因为迷宫墙壁都可以表示成矩形：

dart复制Offset? _rayRectIntersection(
    Offset origin,
    Offset direction,
    Rect rect,
    double maxDistance) {
  double tMin = 0.0;
  double tMax = maxDistance;
  for (int axis = 0; axis < 2; axis++) {
    final double originAxis = axis == 0 ? origin.dx : origin.dy;
    final double dirAxis = axis == 0 ? direction.dx : direction.dy;
    final double rectMin = axis == 0 ? rect.left : rect.top;
    final double rectMax = axis == 0 ? rect.right : rect.bottom;
    if (dirAxis.abs() < 1e-6) {
      if (originAxis < rectMin || originAxis > rectMax) return null;
    } else {
      double t1 = (rectMin - originAxis) / dirAxis;
      double t2 = (rectMax - originAxis) / dirAxis;
      if (t1 > t2) {
        final double temp = t1;
        t1 = t2;
        t2 = temp;
      }
      tMin = max(tMin, t1);
      tMax = min(tMax, t2);
      if (tMin > tMax) return null;
    }
  }
  return origin + direction * tMin;
}

第二步是生成视野多边形：

dart复制List<Offset> _computeVisiblePolygon({
  required Offset origin,
  required double viewRadius,
  required int rayCount,
  required List<Rect> walls,
}) {
  final vertices = <Offset>[];
  for (int i = 0; i < rayCount; i++) {
    final double angle = 2 * pi * i / rayCount;
    final direction = Offset(cos(angle), sin(angle));
    double hitDistance = viewRadius;
    for (final wall in walls) {
      final hit = _rayRectIntersection(origin, direction, wall, hitDistance);
      if (hit != null) {
        final d = (hit - origin).distance;
        if (d < hitDistance) {
          hitDistance = d;
        }
      }
    }
    vertices.add(origin + direction * hitDistance);
  }
  return vertices;
}

这一段是局部可见性系统的核心。实际性能优化时，我不会每帧遍历全部墙壁，而是先用网格把墙壁按格子索引，射线只需要检测穿过的几个格子里的墙就够了。迷宫本身是网格结构，这个优化非常好做。

4.3 迷雾渲染：Path差集加低分辨率缓冲

拿到视野多边形之后，迷雾层的渲染就比较直白了。我先把整个画面铺上一层黑色半透明遮罩，然后把视野多边形从遮罩里“挖”出去：

dart复制final fullScreenRectPath = Path()..addRect(Offset.zero & screenSize);
final visionPath = Path()..addPolygon(vertices, true);
final overlayPath = Path.combine(
  PathOperation.difference,
  fullScreenRectPath,
  visionPath,
);
canvas.drawPath(overlayPath, fogPaint);

这里会有一个视觉问题：Path差集产生的边缘是锋利的，看起来像硬纸板剪出来的洞，不像光。我为了做出柔和的光影边缘，叠加了两层处理。

第一层，用MaskFilter.blur对边缘做模糊，让视野边界产生羽化感。代码如下：

dart复制final blurPaint = Paint()
  ..color = Colors.black.withOpacity(0.85)
  ..maskFilter = const MaskFilter.blur(BlurStyle.normal, 8);
canvas.drawPath(overlayPath, blurPaint);

第二层，在可见域内部画一个径向渐变光晕，从玩家位置向外由亮到暗，模拟灯光在近距离更亮、远处逐渐衰减的效果：

dart复制final lightPaint = Paint()
  ..shader = RadialGradient(
    colors: [
      Colors.white.withOpacity(0.35),
      Colors.white.withOpacity(0.0),
    ],
  ).createShader(
    Rect.fromCircle(center: playerPos, radius: viewRadius),
  );
canvas.drawCircle(playerPos, viewRadius, lightPaint);

这里我用的fogPaint颜色是黑色半透明，配合光晕层后，可见区域内会有一层淡淡的暖色感，而视野外的黑暗又保持了足够的遮挡性。

性能上还有一个关键技巧：迷雾层不需要在全分辨率下绘制。我实际使用canvas.save(); canvas.scale(0.25);把迷雾绘制压到四分之一分辨率，再scale回全屏。因为迷雾层本身就是大片半透明色块，低分辨率绘制后上屏几乎看不出差别，但Path差集和光栅化开销能降低一个数量级。这个优化在RK3568上效果非常明显。

4.4 移动手感：视角平滑、去抖与稳定性

视野计算如果每一帧都跟着玩家位置重新跑，会带来两个问题：一是玩家高速移动时视野多边形变化太剧烈，视觉上像闪烁；二是射线求交的抖动会让视野边缘看起来不稳定。

我做了三件事来稳定手感：

第一，维护一个“当前视野中心”变量，每帧通过插值向玩家真实位置逼近，而不是直接等于玩家位置：

dart复制viewCenter = Offset.lerp(viewCenter, playerPos, 0.2)!;

这个值只用于视野计算和迷雾绘制，玩家的碰撞和移动逻辑仍然使用真实坐标，不受影响。

第二，射线采样角度固定从0度开始均匀分布，不要跟着玩家朝向旋转。否则玩家一转身，整个视野多边形会跟着旋转，边缘的锯齿和抖动会被放大。固定角度之后，多边形边缘在静止时是稳定的，玩家移动时只产生自然的平移和变化。

第三，当玩家移动距离小于0.5像素时，直接复用上一帧的视野多边形；跨过一个完整格子时才重算。这个优化减少了重复计算，同时让视野更新有明确的“节拍感”，玩家不会觉得画面在无规律地跳。

5. 内容设计：迷宫生成、光源节奏与沉浸感构建

5.1 迷宫生成：递归回溯加“房间”混合，避免千篇一律的走廊

局部可见性游戏里，迷宫本身的形状直接决定体验。如果全是窄走廊，玩家会觉得一直在钻洞；如果太开阔，局部可见性的紧张感又会被稀释。我用的方案是：递归回溯生成基础迷宫，再在随机位置挖出若干房间。

递归回溯的核心逻辑很经典：

dart复制void _generateMaze(List<List<int>> grid, int startX, int startY) {
  final stack = <(int, int)>[(startX, startY)];
  grid[startY][startX] = 0;
  final random = Random();
  while (stack.isNotEmpty) {
    final (x, y) = stack.last;
    final directions = [
      (2, 0, 1, 0),
      (-2, 0, -1, 0),
      (0, 2, 0, 1),
      (0, -2, 0, -1),
    ]..shuffle(random);
    bool moved = false;
    for (final (dx, dy, wallDx, wallDy) in directions) {
      final nx = x + dx;
      final ny = y + dy;
      if (nx >= 0 && ny >= 0 && nx < cols && ny < rows && grid[ny][nx] == 1) {
        grid[y + wallDy][x + wallDx] = 0;
        grid[ny][nx] = 0;
        stack.add((nx, ny));
        moved = true;
        break;
      }
    }
    if (!moved) {
      stack.removeLast();
    }
  }
}

生成的迷宫有很好的连通性，但单纯递归回溯容易产生长且直的走廊。加入房间后，空间结构会更有记忆点。我在生成迷宫后，随机选几个不相邻的位置，把周围3x3或5x5的区域全部挖空，再在边缘开几个口子。由于房间本身占据了一定空间，玩家经过时会明显感到节奏变化：窄通道、开阔房间、再回到窄通道，形成一紧一松的体验。

为了渲染和碰撞的高效，迷宫生成完并挖完房间之后，我会把墙壁格子的坐标转换成List<Rect>，后续所有射线求交、碰撞检测、阴影计算都基于这个矩形列表，不总是扫描二维数组。

5.2 光源布局：用灯的位置偷偷引导玩家

在局部可见性游戏里，光不只是照明，它还是最强的方向暗示。玩家在黑暗迷宫里看见远处有一点光，几乎一定会朝着那个方向走，这是本能级的行为。

我部署了三种灯：

• 长明灯：放在关键岔路口和长走廊中点。作用是让玩家始终知道“前方有路”，避免在岔路上完全摸黑。灯的颜色偏暖黄，安定感强，视觉设计上是火把或小挂灯。
• 闪烁灯：放在收集品或隐藏区域旁边，光强随时间正弦波动。闪烁会吸引玩家注意，形成“那里好像有什么东西”的探索欲。
• 终点灯：用完全不同的色温，比如冷白光或蓝色，让整个迷宫的最终目标在远处就能被识别。玩家在迷宫里转悠时，偶然一转头看到远处冷白的终点亮光，会立刻建立起方向感。

灯本身不参与全局光照计算，只是绘制层上的光晕效果，所以在OpenHarmony设备上的开销可以忽略。我只需要给每个灯记录位置和光强，绘制时叠加一个径向渐变即可。

5.3 低成本高回报的沉浸补充：脚步声回响、尘埃粒子与震动

局部可见性天生带有一种“封闭空间”的氛围，低成本加入声音和粒子，沉浸感会立刻上一个台阶。

脚步声回响是一个性价比极高的设计：我根据玩家到最近墙壁的距离，动态调整步声音量和混响感。距离越近，回声越闷、音量越大；距离越远，声音越空灵。玩家虽然看不见墙，但能通过声音判断自己是不是走进了死胡同，这也反过来强化了空间感知。

尘埃粒子则是视觉上的点睛。在光晕边缘随机生成一些缓慢漂浮的灰色小点，它们会被“光照”照亮，制造出一种空气中有尘埃浮动的质感。这个效果用Flutter的粒子列表加随机位置就能实现，每帧最多二三十个粒子，对性能影响很小。

另外，撞墙时我尝试过震动反馈，但发现部分OpenHarmony设备不支持或者驱动不完整，所以改成视觉反馈兜底：撞墙瞬间在墙上画一条短促的高亮线，同时播放低沉的碰撞音。这样即便没有震动，玩家也能明确感知到“碰壁了”。

5.4 探索节奏：迷宫规模、视野半径、光源间隔的配比

“局部可见性”这个机制最怕的是玩家彻底迷失，产生挫败感。我总结出几个控制节奏的经验参数，不一定普适，但可以作为设计的起点：

• 迷宫规模：15x15到20x20格是比较舒服的范围，太小没有探索感，太大如果没有足够光源玩家会烦躁。
• 视野半径5格时，岔路口的光源间距控制在7-8格以内。超过这个范围，玩家从一个光源到下一个光源之间会经历长时间的完全黑暗，容易失去方向和耐心。
• 每经过3-5个岔路，设置一个“安全区”，也就是一个较开阔的房间或者一盏高亮长明灯，给玩家一个喘息点。这种节奏和人呼吸的节拍类似，一整段都是紧张的迷宫会让玩家疲惫。

我实际测试中，20x20的迷宫、视野半径5格、全程约12盏长明灯加5个隐藏闪烁灯，一局探索时间大约在八到十二分钟，玩家普遍反馈“刚好可以坐下来玩一局”。这个体量适合演示、独立小游戏，也适合作为更大型项目的一章。

6. 性能调优与真机适配：在RK3568和RK3588上实测

6.1 我的调试基准：分辨率、迷宫规模、采样数

性能优化不能靠感觉，必须在具体设备上测数据。我的测试基准是：

• 设备：RK3568开发板、RK3588开发板
• 画布分辨率：2560x1440，竖屏铺满
• 迷宫规模：20x20，tileSize=64像素
• 初始配置：120条射线，全分辨率迷雾，每帧重算视野多边形

优化前的实测结果比较惨：RK3568上帧率只有20到30fps，肉眼可见卡顿；RK3588稍好，约35到45fps，但离流畅还有距离。主要的性能瓶颈非常集中：射线求交次数过多、迷雾层全分辨率Path运算、动态层整帧重绘。

6.2 三个收益最明显的优化手段

第一个优化：把射线采样数从120降到60，同时加入空间网格索引。视觉上，60条射线的视野多边形边缘已经足够平滑，降到48条才会看到明显棱角。配合网格索引后，单帧视野计算从6到8毫秒降到1毫秒左右，这是性价比最高的一步。

第二个优化：迷雾低分辨率绘制。前面提到过，我用canvas.scale(0.25)把迷雾绘制分辨率降到360p左右。迷雾层的Path差集、模糊、光栅化开销直接降低一个数量级。这一步做完，RK3568的帧率大概能从30fps提升到45到50fps。

第三个优化：静态层缓存。把迷宫背景层放进RepaintBoundary，并且在背景没有任何变化时，系统会跳过该层的重绘。动态层只保留迷雾层、光晕层、玩家层和粒子层。对于20x20的迷宫，背景层缓存后CPU和GPU的负担明显下降，尤其减少了对内存带宽的占用。

优化后的最终配置是：60条射线、视野半径5格、迷雾绘制分辨率0.25x、静态地面缓存。在这个配置下，RK3568能稳定在50到60fps，RK3588基本跑满帧，整个光影效果在两种设备上都保持完整。

6.3 OpenHarmony设备上的专项适配

性能之外，OpenHarmony设备还有几个专项问题需要处理。

生命周期管理：一开始我发现在设备上按Home键再回到应用，游戏计时和动画会错乱。原因是壳工程没有正确把生命周期事件转发给Flutter引擎。需要在OpenHarmony壳工程侧检查onPause、onResume等回调是否完整通知到了FlutterView，确保Flutter的WidgetsBindingObserver能收到AppLifecycleState变化。

插件解析问题：我遇到过一个诡异的现象，代码里并没有直接依赖高德地图之类的插件，但编译时仍然报插件解析错误。排查后发现是某个间接依赖把Android插件带了进来，而OHOS侧没有对应实现。处理办法是把依赖关系理清楚，找到那个间接引入的库，替换成纯Dart实现或者直接移除。

编译体积和中间产物：OpenHarmony工程的编译中间文件非常多，有些目录可以安全清理。具体来说，ohos目录下类似build、.cxx、oh_modules这类生成物，如果只是为了重新构建，可以删除后由IDE重新生成。正式发布时用release构建，hap包体积会明显小于debug包。

6.4 最终效果与这套方案的适用边界

最终跑下来的画面效果是：玩家站在迷宫里，脚下有温暖的径向光晕，光照到墙壁边缘会形成不规则的光边，墙后是完全不可见的黑暗；远处偶尔有长明灯的闪烁，光晕边缘漂浮着尘埃粒子。在60fps下，这个沉浸感是达标的。

但我也要提醒一句，这套方案适用于2D网格类迷宫，局部可见性系统的核心就是射线求交加多边形遮罩。如果后续想升级到3D场景，或者加入动态光源、实时阴影，那Flutter的CustomPainter方案就吃力了，需要切换到真正的游戏引擎或者3D渲染管线。所以这套方案的价值边界同样在这里：它在一个明确的2D交互游戏领域内足够好用，但不要试图把它硬扛到所有场景。

最后分享一个非常实用的小技巧：在游戏里保留一个“调试模式”开关，用键盘或隐藏按钮触发，把视野多边形、射线采样点、帧耗时直接绘制在屏幕上。真机适配这种事，数据比感觉可靠得多。我后来排查性能问题时，几乎全靠这个开关快速定位是哪一层导致的掉帧。这个开关留着也不占什么性能，上线时隐藏入口就行。