本文最后更新于 2026 年 1 月 23 日。

摘要

本文是《Unity 电子书｜SO 模块化架构》系列文章的第五篇，利用 ScriptableObject 实现事件通道。通过 SO 作为中介，实现发布者与订阅者松耦合通信。相比单例或直接引用，该模式提供了更好的模块化、可测试性，并极大提升了设计师在编辑器中的工作自由度。

核心概念

观察者模式基础

在观察者模式中，发布者（Subject）负责向一个或多个观察者（Observer）广播消息。关键在于发布者不需要知道观察者的具体身份，观察者也不需要知道彼此的存在，从而实现了松耦合。

ScriptableObject 事件通道

SO 事件通道就像是一个无线电塔。发布者（如玩家控制器）向 SO 发送信号。SO 资产作为中介，将信号广播出去。订阅者（如 UI、音效管理器）监听这个 SO 资产，一旦收到信号就做出响应。

三个核心要素

一个标准的事件通道通常包含：委托（Delegate）使用 UnityAction 或 System.Action 来通知订阅者；event 关键字限制委托只能从 SO 内部调用，保证安全性；RaiseEvent 方法供外部对象调用以触发事件。

关键优势

项目级资产存在于项目文件夹中，全局可访问，不会随场景加载而销毁。无全局状态副作用，避免了单例模式带来的紧耦合和测试难题。

单例模式作为全局访问点，允许任何类直接调用，这使得依赖关系隐藏在代码深处，导致模块间紧密耦合，难以拆分重用。

同时，单例持有的全局状态在测试间共享，无法隔离，容易导致测试相互干扰。

即使使用独立场景并在测试前后复原值，也难以保证完全的隔离。单元测试强调的是“隔离性”而非“恢复性”，每个测试应当完全独立，不依赖执行顺序。状态恢复方案往往存在遗漏风险（如未注销的静态事件订阅、隐藏的内部缓存等），这不仅增加了测试的维护成本，还违背了单元测试快速、可靠的原则，容易导致难以排查的“幽灵”错误。

此外，单例难以被 Mock 对象替代，使得编写纯粹的单元测试变得异常困难。

Mock 对象是在单元测试中使用的模拟对象，用于替代真实的依赖项。开发者可以预设它的行为和返回值，从而隔离被测试的代码。这样能确保测试环境纯粹、可控，不再依赖数据库或网络等外部系统，让测试专注于逻辑本身。

与纯代码编写对比的优势

耦合度

纯代码模式高，对象间需要直接引用或依赖单例，难以拆分和扩展。SO 事件通道低，通过中介解耦，发布者和订阅者互不依赖。

可测试性

纯代码模式差，单例引入全局状态，单元测试困难。SO 事件通道好，可以轻松替换为测试用的 SO 实例。

设计师友好度

纯代码模式低，修改逻辑通常需要程序员介入。SO 事件通道高，设计师可在 Inspector 中拖拽配置事件连接，无需编程。

跨场景通信

纯代码模式需特殊处理（如 DontDestroyOnLoad）。SO 事件通道天然支持，SO 资产独立于场景生命周期。

调试便利性

纯代码模式需断点或 Log。SO 事件通道高，可通过 Editor 脚本添加按钮手动触发事件测试。

协作冲突

纯代码模式易冲突，逻辑硬编码在脚本或预制体中。SO 事件通道少，事件配置独立于场景，多人协作更安全。

简单最佳实践

基础事件通道（无参数）

最简单的事件通道不传递任何数据，仅作为信号。

using UnityEngine;
using UnityEngine.Events;
[CreateAssetMenu(menuName = "Events/Void Event Channel")]
publicclassVoidEventChannelSO : ScriptableObject
{
publicevent UnityAction OnEventRaised;
publicvoidRaiseEvent()
    {
if (OnEventRaised != null)
            OnEventRaised.Invoke();
    }
}

订阅与取消订阅

在 MonoBehaviour 中使用时，务必注意生命周期管理，防止内存泄漏。

publicclassStartGame : MonoBehaviour
{
    [SerializeField] private VoidEventChannelSO m_onNewGameButton;
privatevoidOnEnable()
    {
// 务必在 OnEnable 订阅
if (m_onNewGameButton != null)
            m_onNewGameButton.OnEventRaised += StartNewGame;
    }
privatevoidOnDisable()
    {
// 务必在 OnDisable 取消订阅
if (m_onNewGameButton != null)
            m_onNewGameButton.OnEventRaised -= StartNewGame;
    }
privatevoidStartNewGame()
    {
// 游戏逻辑...
    }
}

带参数的事件通道

你可以创建携带数据的事件通道，例如传递整数（分数、伤害）或向量（位置）。

[CreateAssetMenu(menuName = "Events/Int Event Channel")]
publicclassIntEventChannelSO : ScriptableObject
{
publicevent UnityAction<int> OnEventRaised;
publicvoidRaiseEvent(intvalue)
    {
if (OnEventRaised != null)
            OnEventRaised.Invoke(value);
    }
}
</int>

EventListener 组件

为了让非程序员也能配置响应逻辑，可以创建一个通用的监听器组件。

publicclassVoidEventListener : MonoBehaviour
{
    [SerializeField] private VoidEventChannelSO m_channel;
public UnityEvent OnEventRaised; // 在 Inspector 中配置响应
privatevoidOnEnable()
    {
if (m_channel != null) m_channel.OnEventRaised += Respond;
    }
privatevoidOnDisable()
    {
if (m_channel != null) m_channel.OnEventRaised -= Respond;
    }
privatevoidRespond()
    {
        OnEventRaised?.Invoke();
    }
}

这样，设计师只需将 VoidEventListener 挂载到物体上，拖入对应的事件通道 SO，然后在 OnEventRaised 列表中关联如 AudioSource.Play 或 GameObject.SetActive 等方法。

不同人群锐评

纯程序员角度

“这实现了真正的发布-订阅解耦，非常符合依赖倒置原则（DIP）。相比于满天飞的单例和静态事件，SO 事件通道让代码更加干净、可测试。虽然需要手动在 Inspector 中拖拽引用稍微繁琐，且必须严格管理 += 和 -= 以防内存泄漏，但为了架构的整洁性，这些代价是值得的。”

纯策划角度

“这简直是革命性的工具！以前我想改个‘吃到金币后播放特效’的逻辑，都得求程序改代码。现在我只需要在编辑器里把‘金币事件’连上‘特效播放器’就行了。我可以随意尝试不同的玩法组合，比如让‘跳跃’也触发‘得分’，完全不需要写代码，太自由了。”

独立开发者角度

“这是一个前期投入与长期收益的权衡。如果是两天的 Game Jam，我可能直接写代码更快。但如果是要做一个长线项目，SO 事件通道是必选项。它特别适合我这种既写代码又做设计的人——写代码时我搭建好通道，做设计时我就能像搭积木一样组装玩法。不过要注意别过早优化，只有当系统确实需要解耦时再引入，避免把简单逻辑搞复杂。”

写在最后

事件通道模式又体现了“一切皆资产”思维的另一个方面—事件关系也可以资产化。

这种极致的资产化思维，将编程工作从单纯的“编写逻辑”转变为“搭建框架 + 配置资产”。

对于团队协作和长期维护的项目，这是一种非常值得投资的架构方式。

不过，事件驱动架构的松耦合可能也会造成事件触发调试困难，可能需要一些追踪办法。

电子书中有一点内容：任何一个对象都可以是发布者，任何一个对象也都可以是订阅者。

在代码编写中，通常是发布者，拥有一个公共 event 事件字段。而订阅者只有一个订阅事件的方法，他们是不能直接转换的，如果想要修改角色，则必须修改代码。

而 SO 事件通道，只要对象拥有事件通道的引用，那么他可以同时担任发布者和订阅者，不需要修改代码的结构。分析原因，实际上是代码层面直接让每一个对象都持有了一个事件字段和触发方法。