简介面向移动游戏开发者的《Fault》避障游戏源码包基于开源框架Love2D并通过轻量级的Lua语言编写覆盖Android与iOS双平台。该工程不依赖复杂图形库而是利用Love2D提供的图像、音频、物理模拟和事件驱动API清晰展示了游戏循环、碰撞检测、渲染更新等核心模块的实现方式代码结构易读且可直接运行。同时源码中针对Android与iOS分别集成了Google Play Game Services和Game Center涵盖成就、排行榜等社交功能并考虑了屏幕适配与内存管理等移动端优化细节。压缩包约32MB便于下载解压后对照学习目前已有876人学习下载适合具备一定Lua或游戏开发基础、希望深入理解2D游戏框架与跨平台适配的开发者。通过研读源码可以掌握一款轻量级商业游戏从逻辑设计到平台接入的完整思路为后续独立开发同类小游戏提供可复用的参考实现。 避障游戏可能是移动端最容易上手、也最容易做砸的品类——规则一句话能说清真正做起来才发现手感、碰撞反馈、难度曲线全是细节。fault 是我用 Flutter Flame 做的一款面向 Android 和 iOS 的双端避障小游戏名字取的就是“一次失误就结束”玩家控制小方块在三条轨道之间切换躲开不断加速下落的障碍物直到第一次失误出现。这篇文章把它的立项设计、技术选型、核心玩法实现和双端上线经验完整拆一遍给同样想做轻量级休闲游戏的开发者一个参考。1. 立项时想清楚的事fault 到底要玩家玩什么1.1 避障品类为什么值得再做一次移动端避障游戏几乎是个永恒品类。规则不需要教程玩家看十秒钟就会玩天然适合通勤、排队的碎片时间。但“容易做”和“能做出来”之间隔着一条很大的沟——市面上大部分避障游戏死在同一个问题上难度曲线不对。要么开场三十秒就劝退要么玩十分钟难度毫无变化玩家很快就会删掉。fault 立项的时候我先给自己定了三个硬指标单局时长控制在 30 秒到 3 分钟适配碎片场景也让玩家有“再来一局”的冲动操作只保留一个核心动作——切换轨道把学习成本压到几乎为零死亡判定必须让玩家觉得“这次是我手滑了”而不是“这破游戏在坑我”。这三点看着简单实际上把后续所有设计都绑住了。比如第三点意味着碰撞范围、障碍物间距、生成规则都不能有刁钻的随机因素必须在“有挑战”和“讲理”之间找一个平衡。避障游戏的核心不是障碍本身而是玩家对“自己为什么会死”的归因。1.2 三轨制、障碍谱面与命名的逻辑fault 的玩法是最经典的三轨切换屏幕分左、中、右三条纵向轨道障碍物从顶部向下落玩家点击屏幕左侧或右侧区域让角色向左或向右移动一条轨道躲开障碍。第一版我做过五条轨道测试结论非常反直觉轨道越多玩家决策负担越大成绩反而没有提高。三轨正好卡在“需要思考但不需要犹豫”的区间。障碍谱面做了三种基础类型单格障碍占据一条轨道最基础的避让对象双格障碍同时占据两条轨道逼迫玩家做出方向选择移动障碍生成后在水平方向小范围晃动增加预判难度。“fault”这个名字取英语里“失误、过错”的意思。游戏内死亡结算界面只显示一个大写的 FAULT连 GAME OVER 都不用。这个细节能形成记忆点玩家会记住“我犯了一个错”。做休闲游戏命名和结算文案这种小事反而比一堆新手引导更有传播力。1.3 一局多久合适速度与难度的数学直觉难度曲线是避障游戏的命根子。我的做法是先建立一组基于人眼反应时间的初始参数再靠真机测试去微调。人在看到障碍到做出操作最快的反应时间大约在 200 到 300 毫秒。所以障碍物从“清晰可见”到“抵达玩家”的时间必须明显大于这个窗口。fault 在 1080p 设计分辨率下的初始参数是初始下落速度120 px/s每 10 秒增加 18 px/s最大到 420 px/s障碍物生成间隔从 1.2 秒递减最小 0.65 秒相邻轨道切换冷却0.15 秒防止玩家在压力下连续点按造成误判。这套数值不是拍脑袋。生成间隔如果低于 0.65 秒在双格障碍出现时玩家几乎不可能在两条轨道之间安全通过。上线之前我拿不同年龄段的朋友做了二十多轮盲测最终把加速度从每 10 秒 20 px/s 微调到 18 px/s——每局体验差异很大但死亡曲线稳定在了“前 15 秒基本不会死30 秒后开始紧张1 分钟后心态决定一切”的状态。2. 技术选型为什么用 Flutter Flame而不是顺手拿 Unity 去做2.1 三类技术方案的取舍fault 是一个 2D 轻量级游戏选型的时候我认真对比过 Unity、Cocos Creator 和 Flutter 加 Flame 的组合。Unity 在 3D 和复杂物理面前是王者但一个轨道切换玩法的游戏用 Unity就像开着货车去买菜——能到但笨重。维度Flutter FlameUnityCocos Creator包体大小约 20 到 40 MB约 80 到 150 MB约 20 到 50 MB开发语言DartC#TypeScript2D 游戏开发效率组件与 UI 一致代码主导编辑器强物理系统完整编辑器流畅资源商店丰富双端一致性渲染层自绘差异小平台差异需自己处理依赖 WebView 与原生桥接热更新与原生能力插件生态成熟需要额外插件国内渠道接入较方便我选 Flutter Flame 主要因为两点。第一避障游戏几乎不需要复杂物理Flame 提供的基础碰撞足够而 Flutter 自绘渲染让双端画面表现高度一致第二游戏里还有设置页、排行榜、结算页这些界面用 Flutter 做 UI 比在游戏引擎里拼界面顺手得多。一套代码覆盖 Android 和 iOS省下的维护时间是实打实的。2.2 Flame 引擎的项目骨架Flame 是 Flutter 社区里最主流的 2D 游戏引擎本质上是基于 Flutter 组件的一层游戏框架。核心思路是组件树FlameGame 是游戏根节点所有游戏实体玩家、障碍物、分数文本都是挂在树上的 Component。fault 的项目结构大致是这样的lib/ main.dart // 入口初始化 FlameGame挂在 GameWidget 上 game/ fault_game.dart // 游戏主逻辑轨道、生成器、碰撞、计分 player.dart // 玩家组件 obstacle.dart // 障碍物组件 spawner.dart // 障碍物生成器 hud.dart // 分数与状态 HUD constants.dart // 所有数值参数集中在这里把数值全部放进 constants.dart 是个很重要的习惯。调难度曲线时不需要去每个组件里翻代码改一个常量文件就能重跑整个体验。2.3 环境搭建与最小原型验证开发环境没有太多特别之处但版本之间偶有坑。我用的版本组合是 Flutter 3.13 之后、Flame 1.10 左右的组合Android 侧需要 Android Studio 和 Android SDKiOS 侧需要 Xcode 和 CocoaPods。至少准备两台真机不要只依赖模拟器避障游戏对触控延迟和帧率表现敏感模拟器代表不了真实手感。最小原型不需要做完整游戏。第一阶段只验证三件事屏幕尺寸变化时三轨的 x 坐标是否会自动适配持续移动的障碍物在双端是否都是 60 帧触控事件从按下到画面响应的延迟能否被感知。这三件事通过之后再开始堆玩法细节。3. 避障核心实现从障碍生成到“手感”落地3.1 轨道切换平滑移动还是瞬间移动玩家的操作是切换轨道这里有一个手感分水岭切换时角色是瞬移还是平滑移动。瞬移反馈更干脆像音游但视觉上容易显得像闪烁 bug平滑移动更自然但时间太长玩家会产生“明明按了却没立刻过去”的黏滞感。fault 选择的是 70 毫秒的短促插值移动。这个时长是一个平衡点短到不影响操作又长到让眼睛捕捉到位置变化。实现上不需要动画库手动在 update 里做线性插值就行。坐标建议用整数像素否则在低分辨率 Android 设备上会出现轨道边界的“半像素虚边”。3.2 障碍物生成与对象池障碍物的生成用定时器驱动。生成间隔不是固定值而是根据当前游戏时间动态计算这样难度曲线才能平滑上升。核心逻辑大概是void update(double dt) { _timer dt; double interval calculateInterval(elapsedTime); if (_timer interval) { _timer 0; spawnObstacle(); } }这里有一个新手容易踩的坑如果游戏暂停后不重置 _timer恢复时会连续生成一堆障碍物。一定要在生命周期回调里把计时器冻结。比起生成逻辑更值得说的是对象池。避障游戏一秒可能生成一两个障碍物每次 new 一个组件开销不大但问题在于 Dart 的垃圾回收是全局性的。游戏运行一两分钟后积攒的对象会触发 GC 停顿表现为肉眼可见的卡顿。我的做法是维护一个空闲障碍物列表障碍物移出屏幕后不销毁而是重置状态回收到池里。实测下来Android 中端机上的帧率稳定性提升非常明显。3.3 碰撞判定为什么不用物理引擎避障游戏的碰撞其实是纯粹的矩形相交判断不需要重力、反弹、动量守恒这些物理系统。用物理引擎反而引入不确定性一帧的微小数值误差就可能导致结果偏差而休闲游戏最忌讳的就是“好像碰了又好像没碰”的模糊判定。Flame 里给玩家组件挂上 Collider 后可以用自带的碰撞检测回调class Player extends PositionComponent with CollisionCallbacks { override void onCollision(SetVector2 intersectionPoints, PositionComponent other) { if (other is Obstacle) { gameRef.gameOver(); } } }这里的关键细节是碰撞体尺寸要比视觉尺寸略小 10% 到 15%。这是避障游戏的惯例目的不是作弊而是补偿玩家的视觉误差——人眼看到的“边缘”和物理上的“边缘”永远有偏差。如果碰撞体和贴图完全一样大玩家会频繁觉得“我明明躲开了却死了”这是最影响口碑的体验。3.4 计分与结算让玩家知道错在哪里结算页面除了显示本次得分我还会叠加一个“最佳连续避险数”。这个设计的初衷是引导玩家关注过程而不是单次结果。玩家看到“你连续躲了 47 个障碍才失误”下次挑战的目标就变成了超过 47而不是单纯追一个抽象分数。计分规则也很简单每安全通过一个障碍记 1 分双格障碍同时躲过两条轨道记 2 分。简单规则的好处是玩家能在游戏过程中心算出自己的表现这种“即时可评估”的感觉会显著提升再来一局的意愿。4. 双端真机适配同一套代码两种脾气4.1 屏幕安全区与宽高比的坑同样的避障游戏在 Android 和 iOS 上的形状差异比想象中更大。新 iPhone 有灵动岛和底部手势条安卓有挖孔屏、水滴屏、刘海屏还有各种细长比例。如果游戏直接铺满全屏底部手势条区域就可能被误触顶部挖孔又会挡住障碍物的可见路径。处理方式是利用屏幕安全区。Flutter 里通过 MediaQuery.of(context).padding 获取四个方向的边距把游戏的可玩区域收到安全区之内。fault 的做法是底部留出 34 到 48 像素的触控安全区顶部则把障碍物的“出生点”下调到挖孔下方确保障碍物出现的第一瞬间就在有效视野里。宽高比还需要做一版“以高为准”的坐标换算。所有游戏坐标用相对值而不是绝对像素例如三轨的 x 坐标按屏幕宽度的 20%、50%、80% 布局而不是写死像素值。这样无论是 iPad 还是窄屏安卓机轨道比例都不会变形。4.2 渲染器差异与 iOS 首帧问题Flutter 的双端渲染路径其实不同。Android 上走的是 SkiaiOS 从 Flutter 3.16 开始默认启用 Impeller。大多数情况下开发者感知不到区别但避障游戏用了大量半透明、残影和颗粒特效在 Impeller 的早期版本上可能出现 shader 编译导致的短暂卡顿我甚至遇到过 iOS 上首帧黑屏的情况。排查思路是二分法把特效逐个关掉看黑屏是否复现最后定位到某个带模糊效果的粒子。解决的临时方案是关闭该特效的模糊层或者调整 shader 写法避免在片元着色器里做太重的循环运算。遇到 Impeller 相关的诡异问题最直接的排查手段是把渲染器临时切回 Skia 试试。如果切回后问题消失基本就能确定是渲染器兼容性问题。4.3 生命周期、音频延迟与后台暂停避障游戏是最怕后台恢复后“满屏障碍物”的类型。iOS 上用户上滑回桌面再回来如果游戏没有正确暂停恢复瞬间画面已经崩了。fault 在 AppLifecycleState.paused 和 inactive 状态都强制暂停并显示遮罩等 resumed 后再继续。Flutter 的 lifecycle 插件把 Android 和 iOS 的差异封住了直接用系统状态即可。音频方面Flame 生态里常用的 audioplayers 插件在 Android 和 iOS 上打开音频的延迟体感不同。短音效比如“切换轨道”的 click 声在 Android 上偶尔会有几十毫秒延迟人耳对节奏敏感的话会觉得“声音和操作不同步”。我的处理是音效文件尽量用短小的 WAV 或低码率 OGG并提前加载避免播放时才解码。4.4 性能优化帧率稳定性比平均帧率更重要避障游戏对帧率的要求是“稳定”而不是“最高”。Android 中端机在复杂场景下帧率从 60 掉到 40比一直跑 30 帧的体验更糟因为卡顿感来自波动而非数值本身。我的优化清单按收益排序是对象池回收障碍物杜绝 GC 掉帧合并小图元为图片集减少 draw call限制屏幕上的粒子数量移动障碍的残影每 10 个封顶用 RepaintBoundary 把 HUD 和游戏场景隔离避免分数刷新触发整个场景重绘。这套优化做完fault 在骁龙 6 系级别的旧设备上也能保持 55 到 60 帧浮动。优化不是玄学先 profile 再动手比到处抄优化技巧有效得多。5. 从打包签名到应用商店发布阶段的一道道坎5.1 AndroidAAB、签名与 targetSdk发布到 Google Play 必须上传 AAB 而不是 APK。AAB 会根据目标设备的屏幕密度和 CPU 架构分发最精简的资源包这对包体敏感的休闲游戏很重要。签名方面用 Android Studio 生成一个妥善保管的 keystore注意如果采用 Play App Signing上传密钥和签名密钥是两把钥匙丢了上传密钥还能补救丢了签名密钥就真的无法更新旧包了。targetSdk 的要求每年都在涨。应用商店对新应用和更新应用会强制要求最新两年的 targetSdk 版本在写这篇文章时的门槛是 34 到 35 左右。如果 Flutter 版本太老可能不支持新 targetSdk所以发布前一定要查一下当前 Flutter SDK 与 targetSdk 的对应关系。fault 早期就因为 Flutter 版本偏旧不得不先升级 Flutter 再完整回归一遍双端功能。5.2 iOSTestFlight、隐私标签与审核iOS 侧的里程碑是 TestFlight 内测。在 App Store Connect 里上传构建版本后添加内部测试员邮箱他们就能在手机上装到接近正式版的体验包。这一步应该尽早做不要等到开发完成——我自己是原型阶段就上传了让几位朋友每周都玩最新版反馈速度比任何内部自测都快。隐私标签是 iOS 上架绕不开的一步。fault 不收集任何用户数据不需要广告 SDK不上传统计分析因此隐私标签可以如实填写“不收集数据”。这里要提醒一点如果后续接入了广告或统计 SDK必须回头更新隐私标签否则提交审核时会被拒绝。审核本身通常不需要太紧张——小游戏只要没有明显的崩溃和违规内容一般 1 到 3 天就能过。5.3 崩溃监控与灰度发布我做这款游戏期间最大的教训之一是没有在一开始就接入崩溃监控。等到 TestFlight 测试者反馈“打开就闪退”时才排查才发现是某款老 iPhone 的 32 位兼容问题。对于 Flutter 项目建议直接接入 Firebase Crashlytics 或 Sentry用几个小时的接入时间换之后排查崩溃的无数小时。注意接入后必须在真机上跑一遍确认 SDK 初始化正常模拟器里的崩溃收集经常是静默失败的。灰度发布方面Play 商店的分阶段发布和 App Store 的分阶段发布都能控制新版本的影响面。fault 的节奏是新版本先给 10% 用户观察 24 小时崩溃率和评价变化再逐步放量。独立开发者的测试覆盖永远比不过真实世界的设备多样性灰度发布是成本最低的安全网。本文还有配套的精品资源点击获取
Flutter+Flame实战：避障游戏开发与双端上线完整记录
简介面向移动游戏开发者的《Fault》避障游戏源码包基于开源框架Love2D并通过轻量级的Lua语言编写覆盖Android与iOS双平台。该工程不依赖复杂图形库而是利用Love2D提供的图像、音频、物理模拟和事件驱动API清晰展示了游戏循环、碰撞检测、渲染更新等核心模块的实现方式代码结构易读且可直接运行。同时源码中针对Android与iOS分别集成了Google Play Game Services和Game Center涵盖成就、排行榜等社交功能并考虑了屏幕适配与内存管理等移动端优化细节。压缩包约32MB便于下载解压后对照学习目前已有876人学习下载适合具备一定Lua或游戏开发基础、希望深入理解2D游戏框架与跨平台适配的开发者。通过研读源码可以掌握一款轻量级商业游戏从逻辑设计到平台接入的完整思路为后续独立开发同类小游戏提供可复用的参考实现。 避障游戏可能是移动端最容易上手、也最容易做砸的品类——规则一句话能说清真正做起来才发现手感、碰撞反馈、难度曲线全是细节。fault 是我用 Flutter Flame 做的一款面向 Android 和 iOS 的双端避障小游戏名字取的就是“一次失误就结束”玩家控制小方块在三条轨道之间切换躲开不断加速下落的障碍物直到第一次失误出现。这篇文章把它的立项设计、技术选型、核心玩法实现和双端上线经验完整拆一遍给同样想做轻量级休闲游戏的开发者一个参考。1. 立项时想清楚的事fault 到底要玩家玩什么1.1 避障品类为什么值得再做一次移动端避障游戏几乎是个永恒品类。规则不需要教程玩家看十秒钟就会玩天然适合通勤、排队的碎片时间。但“容易做”和“能做出来”之间隔着一条很大的沟——市面上大部分避障游戏死在同一个问题上难度曲线不对。要么开场三十秒就劝退要么玩十分钟难度毫无变化玩家很快就会删掉。fault 立项的时候我先给自己定了三个硬指标单局时长控制在 30 秒到 3 分钟适配碎片场景也让玩家有“再来一局”的冲动操作只保留一个核心动作——切换轨道把学习成本压到几乎为零死亡判定必须让玩家觉得“这次是我手滑了”而不是“这破游戏在坑我”。这三点看着简单实际上把后续所有设计都绑住了。比如第三点意味着碰撞范围、障碍物间距、生成规则都不能有刁钻的随机因素必须在“有挑战”和“讲理”之间找一个平衡。避障游戏的核心不是障碍本身而是玩家对“自己为什么会死”的归因。1.2 三轨制、障碍谱面与命名的逻辑fault 的玩法是最经典的三轨切换屏幕分左、中、右三条纵向轨道障碍物从顶部向下落玩家点击屏幕左侧或右侧区域让角色向左或向右移动一条轨道躲开障碍。第一版我做过五条轨道测试结论非常反直觉轨道越多玩家决策负担越大成绩反而没有提高。三轨正好卡在“需要思考但不需要犹豫”的区间。障碍谱面做了三种基础类型单格障碍占据一条轨道最基础的避让对象双格障碍同时占据两条轨道逼迫玩家做出方向选择移动障碍生成后在水平方向小范围晃动增加预判难度。“fault”这个名字取英语里“失误、过错”的意思。游戏内死亡结算界面只显示一个大写的 FAULT连 GAME OVER 都不用。这个细节能形成记忆点玩家会记住“我犯了一个错”。做休闲游戏命名和结算文案这种小事反而比一堆新手引导更有传播力。1.3 一局多久合适速度与难度的数学直觉难度曲线是避障游戏的命根子。我的做法是先建立一组基于人眼反应时间的初始参数再靠真机测试去微调。人在看到障碍到做出操作最快的反应时间大约在 200 到 300 毫秒。所以障碍物从“清晰可见”到“抵达玩家”的时间必须明显大于这个窗口。fault 在 1080p 设计分辨率下的初始参数是初始下落速度120 px/s每 10 秒增加 18 px/s最大到 420 px/s障碍物生成间隔从 1.2 秒递减最小 0.65 秒相邻轨道切换冷却0.15 秒防止玩家在压力下连续点按造成误判。这套数值不是拍脑袋。生成间隔如果低于 0.65 秒在双格障碍出现时玩家几乎不可能在两条轨道之间安全通过。上线之前我拿不同年龄段的朋友做了二十多轮盲测最终把加速度从每 10 秒 20 px/s 微调到 18 px/s——每局体验差异很大但死亡曲线稳定在了“前 15 秒基本不会死30 秒后开始紧张1 分钟后心态决定一切”的状态。2. 技术选型为什么用 Flutter Flame而不是顺手拿 Unity 去做2.1 三类技术方案的取舍fault 是一个 2D 轻量级游戏选型的时候我认真对比过 Unity、Cocos Creator 和 Flutter 加 Flame 的组合。Unity 在 3D 和复杂物理面前是王者但一个轨道切换玩法的游戏用 Unity就像开着货车去买菜——能到但笨重。维度Flutter FlameUnityCocos Creator包体大小约 20 到 40 MB约 80 到 150 MB约 20 到 50 MB开发语言DartC#TypeScript2D 游戏开发效率组件与 UI 一致代码主导编辑器强物理系统完整编辑器流畅资源商店丰富双端一致性渲染层自绘差异小平台差异需自己处理依赖 WebView 与原生桥接热更新与原生能力插件生态成熟需要额外插件国内渠道接入较方便我选 Flutter Flame 主要因为两点。第一避障游戏几乎不需要复杂物理Flame 提供的基础碰撞足够而 Flutter 自绘渲染让双端画面表现高度一致第二游戏里还有设置页、排行榜、结算页这些界面用 Flutter 做 UI 比在游戏引擎里拼界面顺手得多。一套代码覆盖 Android 和 iOS省下的维护时间是实打实的。2.2 Flame 引擎的项目骨架Flame 是 Flutter 社区里最主流的 2D 游戏引擎本质上是基于 Flutter 组件的一层游戏框架。核心思路是组件树FlameGame 是游戏根节点所有游戏实体玩家、障碍物、分数文本都是挂在树上的 Component。fault 的项目结构大致是这样的lib/ main.dart // 入口初始化 FlameGame挂在 GameWidget 上 game/ fault_game.dart // 游戏主逻辑轨道、生成器、碰撞、计分 player.dart // 玩家组件 obstacle.dart // 障碍物组件 spawner.dart // 障碍物生成器 hud.dart // 分数与状态 HUD constants.dart // 所有数值参数集中在这里把数值全部放进 constants.dart 是个很重要的习惯。调难度曲线时不需要去每个组件里翻代码改一个常量文件就能重跑整个体验。2.3 环境搭建与最小原型验证开发环境没有太多特别之处但版本之间偶有坑。我用的版本组合是 Flutter 3.13 之后、Flame 1.10 左右的组合Android 侧需要 Android Studio 和 Android SDKiOS 侧需要 Xcode 和 CocoaPods。至少准备两台真机不要只依赖模拟器避障游戏对触控延迟和帧率表现敏感模拟器代表不了真实手感。最小原型不需要做完整游戏。第一阶段只验证三件事屏幕尺寸变化时三轨的 x 坐标是否会自动适配持续移动的障碍物在双端是否都是 60 帧触控事件从按下到画面响应的延迟能否被感知。这三件事通过之后再开始堆玩法细节。3. 避障核心实现从障碍生成到“手感”落地3.1 轨道切换平滑移动还是瞬间移动玩家的操作是切换轨道这里有一个手感分水岭切换时角色是瞬移还是平滑移动。瞬移反馈更干脆像音游但视觉上容易显得像闪烁 bug平滑移动更自然但时间太长玩家会产生“明明按了却没立刻过去”的黏滞感。fault 选择的是 70 毫秒的短促插值移动。这个时长是一个平衡点短到不影响操作又长到让眼睛捕捉到位置变化。实现上不需要动画库手动在 update 里做线性插值就行。坐标建议用整数像素否则在低分辨率 Android 设备上会出现轨道边界的“半像素虚边”。3.2 障碍物生成与对象池障碍物的生成用定时器驱动。生成间隔不是固定值而是根据当前游戏时间动态计算这样难度曲线才能平滑上升。核心逻辑大概是void update(double dt) { _timer dt; double interval calculateInterval(elapsedTime); if (_timer interval) { _timer 0; spawnObstacle(); } }这里有一个新手容易踩的坑如果游戏暂停后不重置 _timer恢复时会连续生成一堆障碍物。一定要在生命周期回调里把计时器冻结。比起生成逻辑更值得说的是对象池。避障游戏一秒可能生成一两个障碍物每次 new 一个组件开销不大但问题在于 Dart 的垃圾回收是全局性的。游戏运行一两分钟后积攒的对象会触发 GC 停顿表现为肉眼可见的卡顿。我的做法是维护一个空闲障碍物列表障碍物移出屏幕后不销毁而是重置状态回收到池里。实测下来Android 中端机上的帧率稳定性提升非常明显。3.3 碰撞判定为什么不用物理引擎避障游戏的碰撞其实是纯粹的矩形相交判断不需要重力、反弹、动量守恒这些物理系统。用物理引擎反而引入不确定性一帧的微小数值误差就可能导致结果偏差而休闲游戏最忌讳的就是“好像碰了又好像没碰”的模糊判定。Flame 里给玩家组件挂上 Collider 后可以用自带的碰撞检测回调class Player extends PositionComponent with CollisionCallbacks { override void onCollision(SetVector2 intersectionPoints, PositionComponent other) { if (other is Obstacle) { gameRef.gameOver(); } } }这里的关键细节是碰撞体尺寸要比视觉尺寸略小 10% 到 15%。这是避障游戏的惯例目的不是作弊而是补偿玩家的视觉误差——人眼看到的“边缘”和物理上的“边缘”永远有偏差。如果碰撞体和贴图完全一样大玩家会频繁觉得“我明明躲开了却死了”这是最影响口碑的体验。3.4 计分与结算让玩家知道错在哪里结算页面除了显示本次得分我还会叠加一个“最佳连续避险数”。这个设计的初衷是引导玩家关注过程而不是单次结果。玩家看到“你连续躲了 47 个障碍才失误”下次挑战的目标就变成了超过 47而不是单纯追一个抽象分数。计分规则也很简单每安全通过一个障碍记 1 分双格障碍同时躲过两条轨道记 2 分。简单规则的好处是玩家能在游戏过程中心算出自己的表现这种“即时可评估”的感觉会显著提升再来一局的意愿。4. 双端真机适配同一套代码两种脾气4.1 屏幕安全区与宽高比的坑同样的避障游戏在 Android 和 iOS 上的形状差异比想象中更大。新 iPhone 有灵动岛和底部手势条安卓有挖孔屏、水滴屏、刘海屏还有各种细长比例。如果游戏直接铺满全屏底部手势条区域就可能被误触顶部挖孔又会挡住障碍物的可见路径。处理方式是利用屏幕安全区。Flutter 里通过 MediaQuery.of(context).padding 获取四个方向的边距把游戏的可玩区域收到安全区之内。fault 的做法是底部留出 34 到 48 像素的触控安全区顶部则把障碍物的“出生点”下调到挖孔下方确保障碍物出现的第一瞬间就在有效视野里。宽高比还需要做一版“以高为准”的坐标换算。所有游戏坐标用相对值而不是绝对像素例如三轨的 x 坐标按屏幕宽度的 20%、50%、80% 布局而不是写死像素值。这样无论是 iPad 还是窄屏安卓机轨道比例都不会变形。4.2 渲染器差异与 iOS 首帧问题Flutter 的双端渲染路径其实不同。Android 上走的是 SkiaiOS 从 Flutter 3.16 开始默认启用 Impeller。大多数情况下开发者感知不到区别但避障游戏用了大量半透明、残影和颗粒特效在 Impeller 的早期版本上可能出现 shader 编译导致的短暂卡顿我甚至遇到过 iOS 上首帧黑屏的情况。排查思路是二分法把特效逐个关掉看黑屏是否复现最后定位到某个带模糊效果的粒子。解决的临时方案是关闭该特效的模糊层或者调整 shader 写法避免在片元着色器里做太重的循环运算。遇到 Impeller 相关的诡异问题最直接的排查手段是把渲染器临时切回 Skia 试试。如果切回后问题消失基本就能确定是渲染器兼容性问题。4.3 生命周期、音频延迟与后台暂停避障游戏是最怕后台恢复后“满屏障碍物”的类型。iOS 上用户上滑回桌面再回来如果游戏没有正确暂停恢复瞬间画面已经崩了。fault 在 AppLifecycleState.paused 和 inactive 状态都强制暂停并显示遮罩等 resumed 后再继续。Flutter 的 lifecycle 插件把 Android 和 iOS 的差异封住了直接用系统状态即可。音频方面Flame 生态里常用的 audioplayers 插件在 Android 和 iOS 上打开音频的延迟体感不同。短音效比如“切换轨道”的 click 声在 Android 上偶尔会有几十毫秒延迟人耳对节奏敏感的话会觉得“声音和操作不同步”。我的处理是音效文件尽量用短小的 WAV 或低码率 OGG并提前加载避免播放时才解码。4.4 性能优化帧率稳定性比平均帧率更重要避障游戏对帧率的要求是“稳定”而不是“最高”。Android 中端机在复杂场景下帧率从 60 掉到 40比一直跑 30 帧的体验更糟因为卡顿感来自波动而非数值本身。我的优化清单按收益排序是对象池回收障碍物杜绝 GC 掉帧合并小图元为图片集减少 draw call限制屏幕上的粒子数量移动障碍的残影每 10 个封顶用 RepaintBoundary 把 HUD 和游戏场景隔离避免分数刷新触发整个场景重绘。这套优化做完fault 在骁龙 6 系级别的旧设备上也能保持 55 到 60 帧浮动。优化不是玄学先 profile 再动手比到处抄优化技巧有效得多。5. 从打包签名到应用商店发布阶段的一道道坎5.1 AndroidAAB、签名与 targetSdk发布到 Google Play 必须上传 AAB 而不是 APK。AAB 会根据目标设备的屏幕密度和 CPU 架构分发最精简的资源包这对包体敏感的休闲游戏很重要。签名方面用 Android Studio 生成一个妥善保管的 keystore注意如果采用 Play App Signing上传密钥和签名密钥是两把钥匙丢了上传密钥还能补救丢了签名密钥就真的无法更新旧包了。targetSdk 的要求每年都在涨。应用商店对新应用和更新应用会强制要求最新两年的 targetSdk 版本在写这篇文章时的门槛是 34 到 35 左右。如果 Flutter 版本太老可能不支持新 targetSdk所以发布前一定要查一下当前 Flutter SDK 与 targetSdk 的对应关系。fault 早期就因为 Flutter 版本偏旧不得不先升级 Flutter 再完整回归一遍双端功能。5.2 iOSTestFlight、隐私标签与审核iOS 侧的里程碑是 TestFlight 内测。在 App Store Connect 里上传构建版本后添加内部测试员邮箱他们就能在手机上装到接近正式版的体验包。这一步应该尽早做不要等到开发完成——我自己是原型阶段就上传了让几位朋友每周都玩最新版反馈速度比任何内部自测都快。隐私标签是 iOS 上架绕不开的一步。fault 不收集任何用户数据不需要广告 SDK不上传统计分析因此隐私标签可以如实填写“不收集数据”。这里要提醒一点如果后续接入了广告或统计 SDK必须回头更新隐私标签否则提交审核时会被拒绝。审核本身通常不需要太紧张——小游戏只要没有明显的崩溃和违规内容一般 1 到 3 天就能过。5.3 崩溃监控与灰度发布我做这款游戏期间最大的教训之一是没有在一开始就接入崩溃监控。等到 TestFlight 测试者反馈“打开就闪退”时才排查才发现是某款老 iPhone 的 32 位兼容问题。对于 Flutter 项目建议直接接入 Firebase Crashlytics 或 Sentry用几个小时的接入时间换之后排查崩溃的无数小时。注意接入后必须在真机上跑一遍确认 SDK 初始化正常模拟器里的崩溃收集经常是静默失败的。灰度发布方面Play 商店的分阶段发布和 App Store 的分阶段发布都能控制新版本的影响面。fault 的节奏是新版本先给 10% 用户观察 24 小时崩溃率和评价变化再逐步放量。独立开发者的测试覆盖永远比不过真实世界的设备多样性灰度发布是成本最低的安全网。本文还有配套的精品资源点击获取
