Game architecture and design patterns
查看所有标签
你的 AudioManager 播放背景音乐。它订阅了 OnLevelStart，在玩家进入新区域时切换曲目。你把 AudioManager 放在 DontDestroyOnLoad 对象上保持跨场景存活。开发期间一切正常，因为你一直在同一个场景里测试。
然后有人第一次从关卡 1 加载到关卡 2。音乐不切了。AudioManager 还活着 —— DontDestroyOnLoad 尽职了 —— 但事件订阅没有存活下来。或者更糟：旧的订阅还在，指向关卡 1 里已经被销毁的事件触发方，下次有东西尝试调用它时你会在游戏中途收到一个 MissingReferenceException。
这就是持久化问题，每个有多个场景的 Unity 项目迟早都会撞上。
你一直在每次测试 5 分钟。跑得好好的。然后 QA 提了个 Bug："30 分钟游玩过程中内存持续增长。加载 6 个场景后帧率从 60 降到 40。"你去 Profile。一个应该只有 12 个监听器的事件上注册了 847 个。每次场景加载都添加了新的订阅但从未移除旧的。对象被销毁了，但它们的委托引用还活着，把已经死掉的 MonoBehaviour 钉在内存里，垃圾回收器碰都碰不到。
或者这个："第二次进入 Play Mode 后血量数值不对。第一次运行没问题。"你按 Play，测战斗，停止。再按 Play，玩家以 73 HP 开始而不是 100。上一个会话的 ScriptableObject 状态泄漏了，因为没人重置它。
再或者经典的：游戏卡了 3 秒，然后 Unity 崩溃。事件 A 的监听器触发了事件 B，事件 B 的监听器触发了事件 A。栈溢出。但有时候它不崩溃 —— 只是卡住，在一个不产生任何可见错误的死循环里吃 CPU。
这些不是假设。这些是我见过的上线游戏里的真实 Bug。根本原因都一样：事件系统的模式单独看没问题，但到了规模化的时候就崩了。
玩家死了。死亡音效和死亡粒子应该同一瞬间开始——没必要等一个完了再开始另一个。但屏幕淡出绝对必须在重生点加载之前完成。重生加载必须在传送之前完成。传送必须在屏幕淡入之前完成。
这就是并行和顺序执行同时存在于一个流程中，由一个事件触发。而尴尬的现实是：大多数 Unity 事件系统只给你一种模式。触发事件，所有监听器响应，完事。至于这些响应应该同时发生还是严格按顺序来？你自己想办法。
于是你就去解决了。用协程。用回调。用名为 _hasFadeFinished 的布尔值。不知不觉间，你搭了一个散落在六个文件里的临时状态机，包括未来的你在内没人能看懂。
你开了一个新 Unity 项目，创建了十个事件。OnPlayerDeath、OnScoreChanged、OnLevelComplete。命名合理，扔进一个文件夹，继续干活。日子很美好。你脑子里装得下整个事件结构。
快进六个月。你有了 200 个事件。Project 窗口变成了一面 ScriptableObject 文件墙。你需要 OnPlayerHealthDepleted——还是叫 OnPlayerHPLow？还是 OnPlayerHealthZero？你在列表里上下滚动，眯着眼看一堆全以 OnPlayer 开头的名字。三分钟后你放弃了，直接创建了一个新的，因为你甚至不确定你要的那个事件是不是已经存在了。
每个事件驱动的 Unity 项目最终都会走到这一步。不是因为事件模式本身有问题，而是因为没人构建过大规模管理事件的工具。Unity 给了你 Animation 窗口、Shader Graph、Timeline、Input System 调试器。事件呢……只有 Project 窗口。
Unity Asset Store 上每一个事件系统插件的描述里都写着"高性能"。就夹在"易于使用"和"完整文档"中间。但问题是——1ms 和 0.001ms 对人来说都很快，可一个比另一个慢了一千倍。当一个插件说"高性能"时，到底在说什么？跟什么比？怎么测的？
我以前也不在意这些。大多数人都不在意。接几个事件，游戏在开发机上跑得好好的，发布就完了。但后来我做了一个移动端项目，几百个实体各自监听多个事件，突然"高性能"就不再是营销打勾项了——而是 60 FPS 和幻灯片之间的区别。
这篇文章讲的是"高性能"对于事件系统到底应该意味着什么、为什么大多数实现达不到、以及 GES 如何通过 Expression Tree 编译实现接近零开销。用真实数据说话，不打太极。
你写了一个 GameEvent<T>。干净、类型安全、优雅。你创建了一个 GameEvent<float> 字段用来广播血量变化，打上 [SerializeField]。切到 Inspector 一看——字段消失了。就像你让 Unity 除以零一样，它用一片空白面板回敬你。
这是 Unity 最古老的架构痛点。序列化系统不懂泛型，从来没懂过。每一个试图构建类型安全、数据驱动事件系统的开发者都一头撞上了这堵墙。
这不是什么小麻烦，而是那种会毒化整个架构的限制。你要么放弃类型安全，要么淹没在样板代码里，要么接受你那漂亮的泛型设计永远无法触及 Inspector。多年来社区的标准答案一直是"手写具体类就行了"。但问题来了——如果样板代码是 100% 可预测的，为什么要人来写？
你改了一个方法名。就一个——把 OnPlayerDied 改成了 OnPlayerDefeated，因为策划觉得措辞需要柔和一点。点击 Play，什么都没发生。没有编译报错，没有警告。场景里十个通过 Inspector 用 UnityEvent 绑定的对象就这么……哑了。悄无声息。你可能三天后才从 QA 那里听到，更惨的情况是玩家先发现。
如果你觉得这场景似曾相识，恭喜——你已经亲身领教过"隐形意大利面代码"了。这种技术债不会出现在 IDE 里，不会触发编译器警告，也不会出现在任何依赖关系图上。它就这么潜伏着，等着在最要命的时候给你一刀。
这不是水平问题，是架构问题。而且比大多数 Unity 开发者愿意承认的要普遍得多。