EventBus设计模式

一. 引言

EventBus（事件总线）是一种消息发布-订阅模式（Publish–Subscribe）的实现方式，用来在应用中不同模块之间传递事件，而无需它们直接依赖彼此。

可以把它理解成一个“中间邮局”：

• 发布者（Publisher） 只管把信（事件）交给邮局（EventBus）。
• 订阅者（Subscriber） 只管告诉邮局自己想要哪些类型的信（事件）。
• 邮局会自动把符合条件的信派送给所有订阅者。

为什么需要EventBus?

在大型项目中，如果多个模块要互相通信，常见的方式是：

• 直接调用方法 → 强耦合，修改一个类会牵连很多地方。
• 接口回调 → 耦合度比直接调用低，但仍然需要知道对方的存在。

痛点：

• 模块之间强耦合，导致维护困难。
• 事件传播路径复杂，逻辑变得难以追踪。
• 某个模块可能需要同时监听多个来源的事件，代码会很乱。

EventBus的优点：

• 模块不需要知道谁会接收事件，这就意味着模块之间完全解耦。
• 事件广播后，所有关心它的订阅者都能收到。
• 添加新订阅者不需要改动发布者代码。
• 方便动态注册 / 注销监听（特别适合游戏或 UI 界面）。

EventBus的缺点：

• 事件传播路径隐形，调试可能困难。
• 滥用可能导致系统逻辑分散，难以追踪。
• 过多的事件注册/注销可能带来性能开销（尤其是反射实现时）。

二. 核心概念

典型的EventBus有三个主要角色：

• EventBus（事件总线）：中介，保存事件类型与订阅者的映射关系，负责事件的分发。
• Publisher（事件发布者）：产生事件并交给EventBus。
• Subscriber（事件订阅者）：注册自己关心的事件，并在事件触发时执行回调。

运行机制（事件流转过程）：

流程可以分为 订阅 → 发布 → 分发：

1. 订阅事件
   订阅者告诉EventBus：“我关心某种事件（例如 PlayerDeathEvent），这是我的回调方法。”
2. 发布事件
   发布者创建事件对象，并调用EventBus的Publish() 方法。
3. 分发事件
   EventBus查找所有对该事件类型感兴趣的订阅者，调用它们的回调。

三. 核心代码

1