基于Flutter自绘的轻量粒子系统：爆炸特效与得分飞字实战

做游戏最绕不开的两个反馈表现一个是打击感一个是得分反馈。打击感靠画面震动、特效、音效堆出来得分反馈靠的就是飞字和飘分。之前在某跨平台系统上做一个休闲小游戏到了表现层优化阶段发现手头现成的特效库要么太重要么和自绘渲染管线配合不顺畅就决定自己手搓一个轻量粒子系统。正好借这个机会把 Flutter 自定义绘制和 OpenHarmony 的跨端适配都走了一遍最后做出来的简易爆炸效果和得分飞字虽然不算华丽但胜在干净、可控、性能稳正好把整套粒子系统的骨架搭起来了。这篇东西适合谁看如果你已经用 Flutter 写过一点界面想在游戏或互动场景里加一些自绘特效又不想直接引一个大而全的粒子引擎那这篇的拆解思路和代码骨架应该能帮你省不少时间。我尽量把设计取舍、参数调优和踩过的坑都写明白不光是贴代码更把这些操作背后的为什么讲清楚。1. 项目概述与整体设计思路1.1 为什么从粒子系统切入游戏表现层粒子系统在游戏开发里是个很经典的基础模块。几乎所有动态视觉反馈都能拆成粒子的组合爆炸是粒子高速扩散、烟雾是粒子缓慢上飘、得分飞字是粒子上浮淡出、连击提示也可以做成一簇特殊粒子。把这个系统搭好后面再做其他特效只是换参数的事不用重复造轮子。我选这个方向还有个现实原因当时在 OpenHarmony 设备上跑 Flutter 应用发现很多现成的 Flutter 特效插件在这个环境上多多少少有些水土不服要么是用了不兼容的底层 API要么是性能表现一般。而粒子系统用 Flutter 自带的 CustomPaint 就能实现依赖极少跨端适配也相对省心。与其到处找库不如把基础能力握在自己手里。从游戏开发进阶的角度看粒子系统是绕不开的一个分水岭。单纯做界面布局、状态管理和做有表现力的游戏化交互中间隔着的就是这类动态效果的自研能力。学会自己控制粒子的生成、运动、消亡和控制渲染开销才算真正摸到了游戏表现层的边。1.2 技术方案选型自绘 CustomPaint 还是外部粒子引擎技术选型的时候我纠结过一阵子。市面上有现成的粒子引擎功能丰富粒子数几千上万都不怕内置发射器、重力场、碰撞检测这些高级功能。但对这个项目来说它有几个问题第一体积问题。一个游戏小项目引一个大型粒子库包体积和启动开销都不划算。第二可控性问题。现成引擎的参数体系是为通用场景设计的真要到某一个特效上做精细调优反而是背着一大堆用不上的概念在操作。第三也是最重要的适配问题。在 OpenHarmony 的 Flutter 环境里第三方库的底层实现不一定都做了充分兼容出了问题排查成本很高。所以最终方案回到了 Flutter 自带的 CustomPaint CustomPainter自己管理粒子对象、生命周期、绘制逻辑。这个方案有几个明显优势不引额外依赖纯 Flutter 标准能力跨端表现一致绘制逻辑完全在自己手里100 个粒子和 300 个粒子的行为差异自己说了算可以方便地和游戏逻辑层做事件对接比如点击位置触发爆炸、得分回调触发飞字方案也有代价高级效果得自己写。比如粒子碰撞、涡流扰动、纹理贴图这些都得后续一点点加。但对爆炸和飞字这两个场景来说这是很合理的选择——杀鸡不用牛刀核心逻辑自己掌控。2. 粒子系统核心架构设计2.1 粒子类设计位置、速度、生命周期的抽象在动手写代码之前先把粒子抽象成什么样想清楚后面会省很多事情。我见过不少人一上来就写一个又大又全的粒子类把所有可能的属性都塞进去结果大部分字段在大多数场景里都用不上还白白占内存。更好的做法是先定义最小公共接口再针对具体效果做扩展。我这里的粒子基类只保留了四个最基本的东西位置、速度、生命值、存活状态。真要说的话大小和颜色也是必须的但这两个在不同特效里差异很大更适合放到子类里去定义基类里只留一个统一的绘制接口和更新接口。abstract class Particle { Offset position; Offset velocity; double life; // 剩余生命单位秒 double maxLife; // 初始生命用于计算生命比例 bool alive; Particle({ required this.position, required this.velocity, required this.life, }) : maxLife life, alive true; void update(double dt) { if (!alive) return; life - dt; if (life 0) { alive false; return; } position velocity * dt; } void draw(Canvas canvas, Paint paint) {} double get lifeRatio (life / maxLife).clamp(0.0, 1.0); }这个抽象的精髓在于lifeRatio它把生命周期归一化到 0 到 1所有渐入渐出、缩放、颜色变化都基于这个比例计算。爆炸粒子从 1 降到 0 的过程就是它从亮到暗、从大到小、从清晰到消散的过程。飞字粒子的透明度变化也基于同样的逻辑。2.2 粒子管理器统一驱动更新与绘制有了粒子还需要一个管理器来统一调度。它的职责很单纯持有所有存活粒子的列表用链表或类似结构方便移除死粒子、提供生成粒子的入口、每帧驱动所有粒子走一遍更新逻辑再把存活的粒子交给 Painter 绘制。这里有个细节值得注意不要在遍历列表的时候直接删除元素。一边遍历一边删要么用下标逆序遍历要么先标记、遍历完再统一移除。我在早期版本里吃过这个亏用正序遍历加removeAt结果跳过了元素一部分粒子提前被回收了。管理器的更新入口由一个Ticker驱动。Flutter 里启动一个动画帧循环非常方便不用自己写循环class ParticleSystemManager with ChangeNotifier { final ListParticle _particles []; Ticker? _ticker; void start() { _ticker ?? createTicker((elapsed) { final dt _lastElapsed null ? 1 / 60 : (elapsed - _lastElapsed!) / Duration.millisecondsPerSecond; _lastElapsed elapsed; update(dt); notifyListeners(); }); _ticker!.start(); } void update(double dt) { for (var p in _particles) { p.update(dt); } _particles.removeWhere((p) !p.alive); _particles.sort(_compareByLayer); // 飞字在顶层 } void spawn(Particle particle) { _particles.add(particle); } void draw(Canvas canvas, Size size) { for (var p in _particles) { p.draw(canvas, Paint()); } } }注意ChangeNotifier的引入。粒子系统是独立于 Widget 之外的数据层但它需要通知 UI 重绘。与其手动调setState不如让粒子管理器继承ChangeNotifier然后用ListenableBuilder或AnimatedBuilder包裹 CustomPaint数据一更新就自动重绘。这样把 UI 刷新和业务逻辑解耦得很干净。2.3 渲染层结构Stack 叠加与 RepaintBoundary 隔离渲染层的结构我用了最简单的方案一个 Stack底层放游戏内容顶层放一个 IgnorePointer 包裹的 CustomPaint 作为粒子覆盖层。IgnorePointer很关键因为粒子层要响应点击位置生成特效但它本身不能拦截点击事件——点击还是要透传给下面的游戏内容区的。class ParticleOverlay extends StatelessWidget { final ParticleSystemManager manager; const ParticleOverlay({super.key, required this.manager}); override Widget build(BuildContext context) { return IgnorePointer( child: RepaintBoundary( child: ListenableBuilder( listenable: manager, builder: (context, _) { return CustomPaint( size: Size.infinite, painter: ParticlePainter(manager), ); }, ), ), ); } }RepaintBoundary是性能安全的保证。它能隔离粒子层的重绘区域避免粒子每帧刷新的时候把下面整个游戏界面也带着重绘一遍。没有这层隔离的话粒子一多就会明显感到帧率下降因为 CPU 和 GPU 的开销都被放大了。这个结构搭好之后整个系统就有了统一入口游戏任何位置需要触发爆炸或者得分飞字只需要拿到ParticleSystemManager的引用调用对应的spawnExplosion或spawnScoreText方法就行不需要关心渲染细节。这也是分层设计的好处——数据和行为统一走管理器UI 只是被动的展示者。3. 简易爆炸特效实现3.1 爆炸粒子的数据模型速度向量与颜色生命周期爆炸的特效本质是一群粒子从中心点向外高速扩散同时经历颜色变化、尺寸衰减和透明度淡出。数据模型上我在粒子基类基础上做了扩展增加了半径、初始颜色和结束颜色。颜色渐变是爆炸视觉冲击力的重要来源。刚炸开的时候是亮白色因为温度最高然后快速过渡到橙红色因为温度在下降最后慢慢淡出消失在背景里。这个效果不用复杂算法用Color.lerp结合生命比例就能做得很自然class ExplosionParticle extends Particle { double radius; Color startColor; Color endColor; override void draw(Canvas canvas, Paint paint) { final t lifeRatio; final color Color.lerp(startColor, endColor, 1 - t)!; paint.color color.withOpacity(t); // 生命越少越透明 paint.maskFilter MaskFilter.blur(BlurStyle.normal, radius * 0.3); canvas.drawCircle(position, radius * (0.6 0.4 * t), paint); } }这里t从 1 慢慢变成 0Color.lerp(startColor, endColor, 1 - t)就是从 startColor 过渡到 endColor。透明度用t本身刚开始完全不透明快消失的时候趋近于完全透明。半径也做了处理生命初期粒子略大逐渐缩小这样爆炸的消散感更强。有个小细节MaskFilter.blur会给粒子加一点柔和的边缘避免一整圈硬边圆点看起来像撒了一地小米粒。但模糊效果是有额外渲染开销的粒子数量多的时候要注意后文性能优化部分我会专门再提这一点。3.2 爆炸粒子初始化随机方向与扇形分布初始化的时候关键是把粒子速度的分布做好。如果所有粒子速度都一模一样爆炸出来就是规则的圆形扩散很假。真实爆炸应该是各个方向不均匀的——有些粒子飞得远、有些飞得近、有些先冲出去、有些明显更慢。代码里我用随机角度加随机速度的做法void spawnExplosion(Offset center, {int count 80, double power 400}) { for (int i 0; i count; i) { final angle Random().nextDouble() * 2 * math.pi; final speed power * (0.3 Random().nextDouble() * 0.7); final velocity Offset(math.cos(angle), math.sin(angle)) * speed; final life 0.5 Random().nextDouble() * 0.4; _manager.spawn( ExplosionParticle( position: center, velocity: velocity, life: life, radius: 3 Random().nextDouble() * 4, startColor: Colors.white, endColor: Colors.orange, ), ); } }速度分布从 30% 到 100% 之间随机取再配合不同粒子 0.5 到 0.9 秒不等的寿命爆炸整体看上去就是跌宕起伏的粒子纷纷扬扬往外飞而不是整齐划一的圆环扩散。这里的经验是所有参数都不要给固定值尽量给一个范围随机化才是自然感的第一来源。爆炸位置如果发生在游戏场景里最好再配合一次小范围震动。震动不在粒子系统内实现而是在逻辑层感知爆炸事件的时候做一个屏幕偏移动画。粒子系统和屏幕震动解耦反而更灵活。3.3 爆炸事件对接点击位置与逻辑回调爆炸特效要能响应实际游戏逻辑。比如玩家点击得分点就得分加爆炸角色死亡就在死亡位置爆一簇粒子。事件对接的核心是把逻辑层的位置坐标正确传递到粒子层。这里最容易踩的坑是坐标系不一致。Flutter 里的GestureDetector返回的localPosition是相对于手势组件坐标系的而粒子层可能覆盖在整个 Stack 上坐标系原点不同。直接用的话爆炸位置会偏。解决办法是在入口做一次坐标转换把粒子层 CustomPaint 的全局位置取出来减去偏移量。void onTapDown(TapDownDetails details) { final globalPos details.globalPosition; final overlayLocal overlayKey.currentContext.findRenderObject() as RenderBox; final localPos overlayLocal.globalToLocal(globalPos); _manager.spawnExplosion(localPos); }这样无论游戏场景怎么嵌套布局粒子都能准确地炸在用户点击的那一点上。如果粒子层和手势组件在同一坐标系下也可以直接用localPosition但多一步转换成本很低却能彻底规避坐标偏差问题。逻辑回调和特效的配合也要注意先后顺序。先更新游戏逻辑状态再触发特效还是先触发特效再更新逻辑我的习惯是先更新逻辑、后触发特效这样特效的位置和状态都是最新值避免出现粒子炸在错误位置或者分数已经变了特效却是旧数值的情况。4. 得分飞字粒子实现4.1 与爆炸粒子的本质区别文字绘制与静态呈现得分飞字和爆炸粒子看着差别很大一个是文字标识一个是颗粒特效但在粒子系统框架下它们的本质是高度统一的都是一群“有位置、有生命周期、会变化”的绘制对象。唯一不同的是爆炸粒子每帧画的是圆形飞字粒子每帧画的是文字。飞字粒子继承粒子基类把绘制内容换成文字更新逻辑简化一些——它不需要速度向量扩散只需要垂直上浮和透明度变化。甚至可以复用基类的velocity字段把速度的 y 轴设成负值让它自然向上飘。class ScoreTextParticle extends Particle { final String text; final double fontSize; final Color color; override void update(double dt) { if (!alive) return; life - dt; if (life 0) { alive false; return; } // 先快后慢的上浮缓动 position Offset(position.dx, position.dy - 60 * dt * lifeRatio); } override void draw(Canvas canvas, Paint paint) { final tp TextPainter( text: TextSpan( text: text, style: TextStyle( color: color.withOpacity(lifeRatio), fontSize: fontSize * (1.0 (1 - lifeRatio) * 0.2), fontWeight: FontWeight.bold, ), ), textDirection: TextDirection.ltr, textAlign: TextAlign.center, )..layout(); tp.paint( canvas, Offset(position.dx - tp.width / 2, position.dy - tp.height / 2), ); } }文字绘制用TextPainter是 Flutter 的标准做法。需要特别注意textDirection必须显式指定否则在有些环境上可能不渲染文字或者抛异常。另外TextPainter在使用前要先调用layout()否则paint不会画出任何内容这是个经常被新手忽略的坑。4.2 飞字动效参数上浮距离、持续时长与缩放节奏飞字动效讲究一个适度。飞得太快看不清楚内容飞得太慢拖节奏飞得太高飘出屏幕外飞得太低显得局促。我反复试过几组参数最后敲定了一套比较舒服的默认值参数数值说明持续时长0.7 秒不长不短刚好够扫一眼又不拖沓上浮距离50~60 像素和字号匹配不会飘太远初始字号20~24在手机上适中大屏可以调大透明度变化前 60% 保持后 40% 渐出先让玩家看清文字再淡出轻微放大最大 20%给飞字一点点“弹出来”的张力感上浮距离我用的是缓动方式而不是固定速度早期移动快、后期移动慢。这样飞字刚出现的时候有一种“冒出来”的冲劲快要消失时又稳稳停住视觉上更舒服。如果用固定速度匀速上浮看起来就很僵硬像字被线拉着跑。飞字的缩放我做得很克制。只在最前面 20% 的生命周期内放大到 1.2 倍后面快速收回。这样既有弹出来的瞬间感又不会让字一直忽大忽小地闪烁。做特效的审美原则就是动效越克制高级感越强。爆炸可以狂野但得分反馈要清楚利落。4.3 批量飞字与多得分点并发处理游戏里往往不止一个得分点。连击的时候可能同一帧冒出三个“100”多个敌人同时死亡时也可能出现五六簇飞字同时飘起。这种情况下飞字粒子系统要有两个能力批量生成无视性能和语义冲突多粒子并存不会互相覆盖。批量生成只需要在入口做一个循环调用void spawnScoreTexts(ListScoreInfo scores) { for (final score in scores) { final randOffset Offset( Random().nextDouble() * 30 - 15, Random().nextDouble() * 20 - 10, ); _manager.spawn( ScoreTextParticle( text: ${score.value}, position: score.position randOffset, life: 0.7, fontSize: 22, color: Colors.amber, ), ); } }每个飞字的位置加一点随机偏移避免同一得分点上的多个飞字完全重叠、互相遮挡看不清。偏移范围控制在 15 像素以内不会让人觉得文字乱飘但又足够错开层次。多粒子并存这块粒子管理器的_particles列表天然支持只要每次spawn都是新增粒子对象就行。需要注意的点是绘制顺序粒子管理器里最好维护一个简单的层级概念。爆炸粒子属于底层飞字粒子属于顶层这样飞字永远压在爆炸特效上面不会被抢了视觉焦点。实现方式很简单给粒子基类加一个layer字段默认 0飞字赋值 1绘制前按 layer 排一次序即可。粒子数量少排序开销可以忽略。5. 完整实操流程与参数调优记录5.1 从零搭建 Flutter 粒子 Demo 的七个步骤整个项目从零开始搭大概经历七个步骤。把它们串一遍方便你直接照做第一步创建 Flutter 工程。如果你要跑 OpenHarmony记得确保 Flutter 环境已适配到对应系统具体在工程配置里选择目标设备即可。第二步定义粒子基类和管理器。把上面的Particle抽象类和ParticleSystemManager写进项目。这一步是整个系统的地基后面所有特效类型都往里面挂。第三步实现爆炸粒子和飞字粒子两个子类。先不追求效果完美能画出来、能动起来就行。跑通后再慢慢调参。第四步搭建粒子覆盖层。用Stack包裹游戏内容顶层放IgnorePointer RepaintBoundary ListenableBuilder CustomPaint的组件链。第五步把粒子管理器和游戏逻辑层对接。点击事件里解析坐标并调用spawnExplosion得分回调里调用spawnScoreText。第六步启动粒子管理器。在页面初始化时调用manager.start()页面销毁时调用manager.dispose()避免资源泄漏。第七步调参。把爆炸粒子的速度、数量、颜色飞字的时长、距离、字号逐个调到自己项目里最舒服的手感。5.2 爆炸效果核心参数速查与调优心得给你一张参数速查表这是我反复试出来的实用区间可以直接当起点用参数项默认区间调优方向爆炸粒子数量60~120数量越多视觉越密但超过 150 会明显影响低端机性能初始速度200~500 px/s越大扩散越猛适合大招特效粒子寿命0.4~0.9 秒寿命越短越清脆越长越有余韵粒子半径3~7 px小半径显细腻大半径更有冲击力颜色过渡白→橙红也可以白→黄、红→黑不同色调表达不同打击类型透明度曲线线性衰减想强化爆发感可以改为前半段保持后半段骤降调参的心得最重要的一点是不要试图一次性调到位。我习惯把参数全部抽成常量比如kExplosionCount、kExplosionPower改一个就重启看一次每次只变一个维度这样能准确知道哪个参数影响的是什么观感。有一次我一次性调了数量和速度两个维度结果视觉变化了也说不清是谁贡献的。这种“控制变量法”在参数调优里比什么都好使。爆炸强烈的打击效果还有一个秘密配方粒子分层。把粒子分成三层来生成内圈速度快、数量少、粒子大中圈速度中等、数量多外圈速度慢、粒子小。三层叠加观感一下子从一个稀薄的圆环变成有层次的火花柱真实感提升非常明显。这个技巧我只在自己项目里反复实验过才琢磨明白文档里很少见到。5.3 飞字参数的 UI 动效平衡字号、间距与节奏控制飞字参数调的思路和爆炸不同。爆炸追求冲击力飞字追求可读性和节奏感。字体太小看不清太大又挡游戏画面出现太快看不清太慢又让玩家等。我实测下来在 1080P 级别的屏幕上20~24 号字的飞字清晰度和存在感最好。如果是 4K 大屏按屏幕宽度等比放大到 28~32 也不过分。飞字和爆炸效果之间的时间配合也很重要得分飞字应该在爆炸开始后 0.1 秒左右出现太早会被爆炸的光效盖住太晚又显得得分和打击脱离玩家会感觉迟疑。飞字叠加时还要注意间距。如果大量飞字从同一得分点冒出要确保它们最密的时候也不会糊成一团看不清。经验值是飞字之间的最小间距在 24 像素以上随机偏移能保证这一点就够用。我之前做过一组密集连击测试12 个飞字同屏随机偏移后依然能逐个辨认基本就是合格的。6. 常见问题与排查技巧实录6.1 粒子不显示的三种排查路径做了这么多次特效粒子不显示是最常见的故障而且往往原因很低级。我总结了三类排查路径按概率排序第一类CustomPaint 没有尺寸。CustomPaint 的 child 或者 size 参数必须至少有一个有效值否则画布尺寸为 0什么都不会画出来。排查方法很简单给 CustomPaint 包一层SizedBox.expand()或者渲染层用size: Size.infinite。第二类粒子管理器没启动或者每帧没有触发刷新。确认Ticker在运行ChangeNotifier有监听者。粒子更新了但 UI 不重绘视觉上就是“没反应”。检查ListenableBuilder是否包裹了 CustomPaint以及监听对象是否就是同一个 manager 实例。第三类粒子生命周期算错了。如果粒子的life初始值设置成负数或者dt传入了 NaN/巨大值粒子可能在第一帧就被判为死亡。我曾在 dt 计算上踩过坑首帧_lastElapsed为空时直接取 1/60否则elapsed差值会把整个生命周期归零。所以在管理器代码里我做了首帧保护这段代码值得保留。这三个路径排查完粒子显示问题大概率能解决。如果还没显示再检查一下spawn是否真的被调用到了——可以在spawn方法里加一行打印确认入口确实有数据进来。6.2 爆炸后残留残影或粒子卡死的处理方法残影问题通常是粒子淡出逻辑不够彻底导致的。透明度的计算是color.withOpacity(t)理论上 t 到 0 时粒子应该完全透明。但如果在life 0之前就提前把透明度衰减到一个很低但非 0 的值就会留下很淡的“幽灵残影”特别是爆炸粒子数量多的时候满屏都是细小的半透明圆点。解决方法是把存活判定和淡出计算对齐t 0.05就强制标记死亡而不是等着完全归零。我一般会在 update 里做一个if (lifeRatio 0.03) alive false;的提前回收。既避免了残影也给系统省出一点性能。粒子卡死则可能是管理器里排序或删除逻辑出现问题。比如排序比较器有副作用或者removeWhere里写错了条件。排查这类问题最直接的方式是给管理器加一个调试面板实时显示当前存活粒子数暂停时还能逐帧观察粒子的速度和位置。粒子数异常飙升或者长时间不变一眼就能看出来。6.3 低端机上掉帧的四个优化方向粒子系统性能问题的核心就一句话一帧内绘制的量太大。低端机上掉帧按下面四个方向排查基本能覆盖所有情况第一减少粒子总数。爆炸粒子从 100 个减到 60 个视觉差异其实有限但性能直接省了 40%。我做了一个自适应机制根据设备的屏幕分辨率和刷新率动态调整粒子总数高刷高分辨率设备开满低端设备自动降档。第二减少模糊效果。MaskFilter.blur很吃 GPU 性能粒子一多帧率就会垮。可以只在关键特效上保留模糊或者把模糊半径调小。如果追求性能极致直接放弃 blur用多层渐变色圆叠加模拟柔和边缘。第三重绘区域的隔离。确保 RepaintBoundary 包裹粒子层避免重绘扩散到整个页面。如果不确定有没有生效可以用 Flutter 的性能调试工具显示重绘边界看到粒子层的独立边界框就说明隔离成功了。第四避免每帧创建新对象。粒子绘制里频繁创建 Paint、TextPainter 是很大的开销。Paint 可以复用一个实例虽然在有状态变化时需要重置TextPainter 建议在粒子生成时就 layout 好绘制时直接复用结果对象。我在早期版本里飞字粒子每帧都新建一个 TextPainter 并 layout粒子一多就开始掉帧改成缓存之后就顺畅多了。6.4 跨端渲染差异与字体渲染细节Flutter 项目跑到 OpenHarmony 上大部分渲染能力是统一的但有几个细节要特别留意。第一是字体差异OpenHarmony 系统默认字体和 Android 不完全一致中文飞字的字形渲染效果可能不同需要在文本样式里显式指定fontFamily否则在不同设备上看会有细微差别。第二是TextPainter的国际化行为。没有显式设置textDirection时中英文混排的默认结果可能不一样。我所有飞字文本都强制指定TextDirection.ltr规避了大多数坑。第三是自定义绘制的纹理适配。如果在粒子系统里用了图片纹理而不是简单图形要确认图片资源在 OpenHarmony 环境下的加载路径正确。我建议粒子初期都用纯 Canvas 图元简单稳定等全部功能稳定后再考虑加纹理贴图。颜色渐变、透明度这些基础能力已经足够撑起不错的视觉效果没必要一开始就上纹理。7. 性能优化进阶与后续扩展方向7.1 粒子池化避免 GC 卡顿的实用方案粒子系统跑时间长了会有一个非常隐蔽的性能问题频繁生成和销毁粒子对象导致 GC垃圾回收压力增大表现为周期性掉帧。游戏挂机几分钟后突然卡一下多半就是这种问题。解法是粒子池化。预先分配一定数量的粒子对象用的时候从池子里取用完了归还池子而不是直接让 GC 回收。对爆炸这种高频生成场景效果立竿见影。class ParticlePoolT extends Particle { final ListT _pool []; final T Function() _factory; ParticlePool(this._factory); T obtain() { if (_pool.isNotEmpty) { return _pool.removeLast()..reset(); } return _factory(); } void release(T particle) { particle.alive false; _pool.add(particle); } }实现时要给粒子类加一个reset()方法把所有字段恢复初始值。这样才能重复使用而不残留上一次的状态。池子的初始大小根据峰值粒子数来定爆炸和飞字同时出现的峰值场景能覆盖到就行。使用池化之后粒子对象创建从“每帧新建”变成“缓存复用”GC 频率显著下降。我实测挂机 30 分钟卡顿次数从每分钟 2~3 次降低到几乎为 0。如果你的游戏场景也是高频触发特效的池化是必做项不是可选优化。7.2 分层渲染与独立画布的最佳实践粒子系统再往后发展单一画布会撑不住。爆炸粒子、飞字粒子、背景飘花、前景烟雾全都画在一层的话每次任何一类粒子更新所有粒子都要跟着重新绘制一遍浪费巨大。更优的做法是分层渲染爆炸一层、飞字一层、漂浮层一层每层是一个独立的 CustomPaint 和 RepaintBoundary。某一层粒子变化只触发该层重绘其他层原样不动。代价是多几个画布对象但对性能的收益是实打实的。分层的时候要注意 z 轴顺序。飞字永远在最上层爆炸在中层背景烟雾在下层。层与层之间的混合模式也可以做文章底层烟雾用BlendMode.plus叠加会让整个场景有一种发光的高级的氛围感而不是死板的简单覆盖。我现在项目的标准结构就是三层画布叠在 Stack 里每层一个管理器互不干扰。代码组织起来也更清晰——爆炸管理器只管爆炸飞字管理器只管飞字不用在一个大数组里做各种类型判断。7.3 从爆炸到烟火粒子系统的自然扩展路径这套粒子系统搭好之后扩展空间其实很大。爆炸粒子改一下初始化参数就是烟花粒子先被发射到空中到达指定高度后再二次爆炸。二次爆炸的实现只需要在粒子死亡时生成一组新的粒子相当于触发一个“子粒子回调”。过渡的效果连续小爆炸的节奏雨滴落地的粒子溅射甚至金币翻转的粒子撒落都可以在这一套骨架里派生出来。关键是抽象层设计得对——粒子基类只关心位置、速度和生命周期具体绘制内容完全由子类决定新特效只写子类就行不用改任何管理器逻辑。如果后面想做更高级的 GPU 粒子可以考虑用 Flutter 的片段着色器或者原生纹理贴图配合 BlendMode 混合来实现更加复杂的视觉效果。但作为第一版纯 Canvas 方案已经足够覆盖绝大多数游戏的常规反馈需求。我个人在实际操作中的体会是粒子系统的核心不是抄代码而是建立一套“参数直觉”。当你看到爆炸效果不满意能立刻判断出是该调速度还是该调数量还是该调颜色曲线而不是盲试参数当你想做新特效能快速判断出它需要哪种粒子类型、是否需要子粒子回调、应该放哪个渲染层——有了这种直觉任何特效在你手里都只是配置问题而不是技术问题。这篇粒子系统的骨架希望能帮你尽快建立起属于自己的那套参数直觉。之后再做火焰、烟雾、碎片飞溅都只是在这个基础之上再加一些细节罢了。