1. 项目概述为什么要在UE里再造一个事件分发轮子在虚幻引擎UE的开发中事件驱动是构建复杂交互和系统解耦的核心模式。引擎本身提供了强大的委托Delegate和多播委托Multicast Delegate系统以及蓝图事件分发Event Dispatcher等机制。那么为什么我们还需要自己动手实现一套事件分发机制呢这并非重复造轮子而是为了在特定场景下获得更高的灵活性、性能优化和架构清晰度。想象一下你正在开发一个大型多人在线游戏服务器端有成千上万个实体玩家、NPC、道具需要相互通信。如果所有通信都直接使用UE原生的多播委托虽然方便但可能会带来一些问题委托的绑定和解绑管理在复杂对象生命周期下容易出错导致崩溃跨模块、跨线程的事件传递需要额外的封装或者你希望事件能携带更丰富的元数据如发送者、时间戳、优先级并支持更复杂的路由逻辑如事件过滤、拦截、延迟处理。这时一个量身定制的、更“重”一些的事件分发系统就显得非常有必要。我自己在几个UE项目中都实践过自定义事件系统特别是在服务器逻辑和编辑器工具开发中。它不仅能让你对事件流的控制力更强还能显著提升代码的可维护性和可调试性。本文将基于C带你从零开始设计并实现一个适用于UE项目的高效、安全、可扩展的自定义事件分发机制。无论你是想深入理解事件系统的原理还是为了解决项目中特定的通信难题这篇文章都将提供一套可直接复用的方案和大量避坑经验。2. 核心设计思路与架构选型在动手写代码之前我们必须先想清楚这个事件系统要解决什么问题以及它的边界在哪里。一个好的设计是成功的一半。2.1 需求分析与设计目标首先我们需要明确自定义事件分发机制的核心需求类型安全这是C的底线。事件的数据类型和监听函数的签名必须在编译期就确定避免运行时因类型不匹配导致的崩溃。高性能事件分发通常是高频操作。系统需要尽可能减少开销特别是在游戏每帧的主循环中。生命周期安全这是UE开发中最容易踩坑的地方。当事件监听者例如一个Actor被销毁时必须能自动或便捷地解除其所有的事件监听防止出现悬空指针和崩溃。易用性API应该直观、简洁让团队成员能快速上手。理想情况下绑定和解绑事件的代码行数应该尽可能少。可扩展性系统应该能方便地支持新的事件类型并能适应未来可能的需求如事件优先级、异步分发、事件日志等。基于这些目标我们决定采用基于模板和唯一标识符FName或自定义枚举的设计。为什么不直接用UE的委托因为我们要在其之上构建一个管理层增加事件“类型”的概念并集中管理订阅关系。2.2 架构蓝图核心类设计我们的系统将由以下几个核心类构成FGameEvent基类所有具体事件的基类。它可能包含一些通用数据如事件ID、发送时间戳、发送者标识等。采用继承体系是为了方便通过基类指针进行统一存储和传递同时保留具体类型的运行时信息可以通过RTTI或自定义类型标识实现。FEventDispatcher单例或全局可访问对象事件分发器的核心。它负责维护一个“事件类型”到“监听者列表”的映射。这里的关键是监听者列表存储的不是裸函数指针而是包装了UE委托和弱引用TWeakPtr或TWeakObjectPtr的辅助对象以实现生命周期安全。IEventListener接口可选一个可选的监听者接口。让需要监听事件的类实现此接口可以强制它们提供统一的处理函数如OnEventReceived但这会增加耦合度。更灵活的方式是直接绑定类的成员函数。事件宏/辅助函数为了提升易用性我们会封装一组宏或内联函数让事件绑定和触发的代码看起来更清晰。整个数据流是这样的某个系统如战斗系统创建一个具体的FCombatEvent然后调用FEventDispatcher::DispatchEvent(MyCombatEvent)。分发器根据事件类型找到所有订阅了该类型的监听者并安全地调用它们绑定的回调函数。注意这里有一个重要的设计取舍是否使用单例。单例模式让全局访问变得简单但也带来了测试困难和潜在的全局状态问题。在UE中我们可以考虑将FEventDispatcher实例作为游戏实例UGameInstance或某个核心子系统UEngineSubsystem的成员通过依赖注入的方式提供给需要它的模块。本文为了演示清晰将使用一个全局可访问的静态类但在实际项目中请根据架构选择更合适的管理方式。3. 核心细节解析与实现要点接下来我们深入到代码层面看看如何实现上述设计。我会先给出关键代码片段然后解释其背后的原理和注意事项。3.1 定义事件基类与具体事件首先定义事件的基类。我们给它一个类型ID用于快速识别和路由。// GameEventTypes.h #pragma once #include CoreMinimal.h #include GameEventTypes.generated.h // 如果希望蓝图也能派生子类则需要UCLASS // 事件类型枚举用于高效路由。你也可以用FName但枚举的查找速度更快。 UENUM(BlueprintType) enum class EGameEventType : uint8 { Unknown 0, CombatDamage, // 战斗伤害事件 PlayerStateChange, // 玩家状态改变 ItemAcquired, // 获得物品 DialogueTriggered, // 对话触发 // ... 添加你的事件类型 CustomEvent UMETA(DisplayName Custom Event), // 留给动态扩展 }; // 事件基类。这里不使用UOBJECT以保持轻量。如果需要跨蓝图或序列化可改为USTRUCT。 class MYGAME_API FGameEvent { public: virtual ~FGameEvent() default; // 获取事件类型 virtual EGameEventType GetEventType() const 0; // 可选获取事件描述用于调试 virtual FString ToString() const { return FString::Printf(TEXT(EventType: %d), (uint8)GetEventType()); } // 可以在这里添加通用字段如时间戳、发送者GUID等。 // double Timestamp 0.0; // FGuid SenderId; }; // 一个具体的事件示例战斗伤害事件 class MYGAME_API FCombatDamageEvent : public FGameEvent { public: FCombatDamageEvent(AActor* InTarget, AActor* InInstigator, float InDamageAmount) : Target(InTarget), Instigator(InInstigator), DamageAmount(InDamageAmount) {} virtual EGameEventType GetEventType() const override { return EGameEventType::CombatDamage; } virtual FString ToString() const override { return FString::Printf(TEXT(CombatDamage: %.2f damage from %s to %s), DamageAmount, Instigator ? *Instigator-GetName() : TEXT(None), Target ? *Target-GetName() : TEXT(None)); } // 事件具体数据 TWeakObjectPtrAActor Target; // 使用弱引用避免影响对象生命周期 TWeakObjectPtrAActor Instigator; float DamageAmount; };关键点解析使用枚举而非字符串EGameEventType枚举比FName或FString在查找和比较时性能更高更适合高频分发。FName的哈希比较也很快但枚举是编译期常量更直观。事件数据使用弱引用在FCombatDamageEvent中我们使用TWeakObjectPtrAActor来保存目标Target和施加者Instigator。这是UE中处理对象引用的黄金法则之一。它确保了即使这些Actor在事件被处理前就被销毁了我们也不会访问到无效内存TWeakObjectPtr会安全地变为nullptr。虚析构函数基类FGameEvent的虚析构函数至关重要它确保了通过基类指针删除派生类对象时派生类的析构函数能被正确调用防止内存泄漏。3.2 构建事件分发器核心这是系统最复杂的部分。我们需要一个中心仓库来管理“事件类型”和“监听者”的映射关系。监听者可能是一个UObject的成员函数也可能是一个全局静态函数。// EventDispatcher.h #pragma once #include CoreMinimal.h #include GameEventTypes.h #include Delegates/DelegateCombinations.h // 引入UE委托系统 // 前置声明 class UObject; class MYGAME_API FEventDispatcher { public: static FEventDispatcher Get(); // 绑定事件监听针对UObject成员函数自动处理生命周期 templatetypename UserClass, typename... VarTypes void BindEvent(EGameEventType EventType, UserClass* InUserObject, void (UserClass::*InFunc)(const FGameEvent, VarTypes...), VarTypes... Vars); // 绑定事件监听针对全局/静态函数无自动生命周期管理 void BindEventStatic(EGameEventType EventType, TFunctionvoid(const FGameEvent) InCallback); // 解绑某个对象的所有事件监听 void UnbindAll(UObject* InUserObject); // 解绑特定事件类型的监听 void UnbindEvent(EGameEventType EventType, UObject* InUserObject); // 分发事件 void DispatchEvent(const FGameEvent InEvent); // 清空所有绑定例如在关卡切换时 void ClearAllBindings(); private: FEventDispatcher() default; ~FEventDispatcher() default; // 禁止拷贝 FEventDispatcher(const FEventDispatcher) delete; FEventDispatcher operator(const FEventDispatcher) delete; private: // 定义一个事件处理委托的类型 DECLARE_DELEGATE_OneParam(FEventDelegate, const FGameEvent); // 存储单个监听者的信息 struct FEventListenerHandle { // 对于UObject绑定我们存储其弱引用和委托 TWeakObjectPtrUObject ListenerObject; FEventDelegate Delegate; // 可以添加优先级字段 int32 Priority; }; // 事件类型到监听者列表的映射 TMapEGameEventType, TArrayFEventListenerHandle EventListenerMap; // 用于防止在事件分发过程中修改监听者列表递归分发可能导致迭代器失效 TArrayEGameEventType EventsBeingDispatched; TMapEGameEventType, TArrayFEventListenerHandle PendingAdditions; TMapEGameEventType, TArrayTWeakObjectPtrUObject PendingRemovals; void ProcessPendingChanges(); };实现要点EventDispatcher.cpp 部分关键代码// EventDispatcher.cpp #include EventDispatcher.h FEventDispatcher FEventDispatcher::Get() { static FEventDispatcher Instance; return Instance; } templatetypename UserClass, typename... VarTypes void FEventDispatcher::BindEvent(EGameEventType EventType, UserClass* InUserObject, void (UserClass::*InFunc)(const FGameEvent, VarTypes...), VarTypes... Vars) { // 确保UserClass是UObject的派生类这样才能使用弱引用 static_assert(TIsDerivedFromUserClass, UObject::IsDerived, BindEvent only supports UObject derived classes for automatic lifetime management.); if (!InUserObject) { UE_LOG(LogTemp, Warning, TEXT(Attempted to bind event with a null object!)); return; } // 创建一个委托绑定到对象的成员函数并携带payload参数 FEventDelegate Delegate; Delegate.BindUObject(InUserObject, InFunc, Vars...); FEventListenerHandle NewHandle; NewHandle.ListenerObject InUserObject; NewHandle.Delegate Delegate; // 如果当前正在分发此类型的事件则将绑定操作推迟 if (EventsBeingDispatched.Contains(EventType)) { PendingAdditions.FindOrAdd(EventType).Add(NewHandle); } else { EventListenerMap.FindOrAdd(EventType).Add(NewHandle); } } void FEventDispatcher::DispatchEvent(const FGameEvent InEvent) { EGameEventType EventType InEvent.GetEventType(); EventsBeingDispatched.Add(EventType); // 标记此事件类型正在分发 // 处理之前推迟的变更 ProcessPendingChanges(); if (TArrayFEventListenerHandle* Listeners EventListenerMap.Find(EventType)) { // 注意我们需要遍历一个副本因为回调函数内部可能会修改当前列表如解绑自身 TArrayFEventListenerHandle ListenersCopy *Listeners; for (auto Handle : ListenersCopy) { // 关键的安全检查检查监听者对象是否仍然有效 if (Handle.ListenerObject.IsValid()) { Handle.Delegate.ExecuteIfBound(InEvent); } else { // 对象已失效标记为待移除 PendingRemovals.FindOrAdd(EventType).Add(Handle.ListenerObject); } } } EventsBeingDispatched.Remove(EventType); // 分发结束 // 再次处理分发过程中可能产生的待移除项 ProcessPendingChanges(); // 调试输出 // UE_LOG(LogTemp, Log, TEXT(Dispatched Event: %s), *InEvent.ToString()); } void FEventDispatcher::ProcessPendingChanges() { // 处理待添加的监听者 for (auto KVP : PendingAdditions) { EventListenerMap.FindOrAdd(KVP.Key).Append(KVP.Value); } PendingAdditions.Empty(); // 处理待移除的监听者 for (auto KVP : PendingRemovals) { if (TArrayFEventListenerHandle* Listeners EventListenerMap.Find(KVP.Key)) { Listeners-RemoveAll([KVP](const FEventListenerHandle Handle) { return KVP.Value.Contains(Handle.ListenerObject); }); } } PendingRemovals.Empty(); } void FEventDispatcher::UnbindAll(UObject* InUserObject) { if (!InUserObject) return; for (auto KVP : EventListenerMap) { KVP.Value.RemoveAll([InUserObject](const FEventListenerHandle Handle) { return Handle.ListenerObject.Get() InUserObject; }); } // 也需要清理待处理队列中的 // ... (省略) }避坑经验实录迭代器失效问题这是事件分发系统最常见的崩溃原因。在DispatchEvent中遍历监听者列表时如果某个监听者的回调函数内部又触发了对同一事件类型的绑定或解绑操作就会导致我们正在遍历的容器TArray结构发生变化迭代器失效进而崩溃。解决方案遍历容器副本ListenersCopy或者使用索引而非迭代器并配合“待处理队列”PendingAdditions/PendingRemovals机制。弱引用检查在调用委托前必须检查TWeakObjectPtr是否有效IsValid()。这是防止监听者对象已被销毁后仍被调用的关键安全锁。静态函数绑定的生命周期BindEventStatic绑定的函数没有自动的生命周期管理。如果绑定的函数依赖于某个已被销毁的对象状态会导致未定义行为。因此强烈建议优先使用针对UObject的BindEvent让系统自动管理。性能考量TMapEGameEventType, TArray...的查找和遍历效率很高。如果事件类型非常多成千上万可以考虑使用更紧凑的数据结构。但对于大多数游戏项目几百个事件类型完全够用。4. 在游戏逻辑中的实际应用理论说再多不如看实际怎么用。我们假设有一个玩家角色AMyPlayerCharacter和一个UI伤害数字组件UDamageNumberWidgetComponent。4.1 发送事件战斗系统当玩家攻击命中敌人时战斗系统创建并分发一个伤害事件。// CombatSystem.cpp void UCombatSystem::ApplyDamage(AActor* Target, AActor* Instigator, float Damage) { // ... 计算伤害、应用护甲等逻辑 ... // 1. 直接修改目标的生命值等属性 if (UHealthComponent* HealthComp Target-FindComponentByClassUHealthComponent()) { HealthComp-TakeDamage(Damage, Instigator); } // 2. 创建并分发事件让其他系统如UI、音效、成就做出反应 FCombatDamageEvent DamageEvent(Target, Instigator, Damage); FEventDispatcher::Get().DispatchEvent(DamageEvent); // 还可以分发其他相关事件如击杀事件、连击事件等 if (HealthComp HealthComp-IsDead()) { FKillEvent KillEvent(Target, Instigator); FEventDispatcher::Get().DispatchEvent(KillEvent); } }4.2 接收事件UI伤害数字伤害数字组件在创建时如BeginPlay订阅战斗伤害事件并在收到事件时在屏幕上显示一个飘动的数字。// DamageNumberWidgetComponent.cpp void UDamageNumberWidgetComponent::BeginPlay() { Super::BeginPlay(); // 绑定到战斗伤害事件 FEventDispatcher::Get().BindEvent(EGameEventType::CombatDamage, this, UDamageNumberWidgetComponent::OnCombatDamageEvent); } void UDamageNumberWidgetComponent::EndPlay(const EEndPlayReason::Type EndPlayReason) { // 非常重要在组件销毁时解绑所有事件防止回调时访问已销毁的this指针。 FEventDispatcher::Get().UnbindAll(this); Super::EndPlay(EndPlayReason); } void UDamageNumberWidgetComponent::OnCombatDamageEvent(const FGameEvent InEvent) { // 安全地将基类事件转换为具体的伤害事件 if (InEvent.GetEventType() EGameEventType::CombatDamage) { const FCombatDamageEvent DamageEvent static_castconst FCombatDamageEvent(InEvent); // 检查这个伤害事件是否与当前组件关心的目标相关例如只显示对所属玩家角色的伤害 // 假设这个组件附着在玩家控制的角色上 AMyPlayerCharacter* MyPlayer CastAMyPlayerCharacter(GetOwner()); if (MyPlayer DamageEvent.Target.Get() MyPlayer) { // 在UI上创建并显示一个伤害数字 SpawnDamageNumber(DamageEvent.DamageAmount, DamageEvent.Instigator.Get()); } // 也可以显示自己对别人造成的伤害 if (MyPlayer DamageEvent.Instigator.Get() MyPlayer) { SpawnDamageNumber(DamageEvent.DamageAmount, DamageEvent.Target.Get(), FLinearColor::Green); } } } void UDamageNumberWidgetComponent::SpawnDamageNumber(float Damage, AActor* RelevantActor, FLinearColor Color /* FLinearColor::Red*/) { // 这里实现具体的UI生成逻辑可能是创建一个Widget添加到视口或者使用Niagara粒子等。 // 例如 if (DamageNumberWidgetClass) { UDamageNumberWidget* Widget CreateWidgetUDamageNumberWidget(GetWorld(), DamageNumberWidgetClass); if (Widget RelevantActor) { Widget-SetDamageValue(Damage); Widget-SetColorAndOpacity(Color); // ... 设置初始位置、播放动画 ... } } }应用心得解耦的威力战斗系统ApplyDamage函数完全不知道伤害数字UI的存在。它只负责分发一个事件。UI、音效系统、成就系统、数据分析模块都可以独立地订阅这个事件做自己该做的事情。这极大地降低了模块间的耦合度让代码更容易维护和扩展。生命周期管理的纪律性在BeginPlay中绑定在EndPlay或Destroy中解绑这是必须遵守的纪律。我们的FEventDispatcher::UnbindAll(this)提供了便捷的方法。忘记解绑是内存泄漏和崩溃的主要根源之一。事件过滤在OnCombatDamageEvent中我们通过检查DamageEvent.Target和DamageEvent.Instigator来决定是否处理该事件。这种过滤逻辑应该放在监听者内部而不是分发器里以保持分发器的简单和高效。5. 高级特性扩展与性能优化一个基础的事件系统已经能解决80%的问题。但对于更复杂的项目我们可能需要考虑以下扩展。5.1 事件优先级与消费机制有时我们希望某些监听者能优先处理事件或者允许某个监听者“消费”掉事件阻止其继续传播给后续监听者。实现思路在FEventListenerHandle结构体中增加一个Priorityint32字段。在DispatchEvent中对ListenersCopy按照优先级排序优先级数字大的先执行。同时修改FEventDelegate的返回值类型使用DECLARE_DELEGATE_RetVal_OneParam(bool, FEventDelegate, const FGameEvent)让回调函数返回一个bool值true表示事件已被消费。在分发循环中检查返回值如果为true则break跳出循环。// 修改后的委托和结构体 DECLARE_DELEGATE_RetVal_OneParam(bool, FEventDelegate, const FGameEvent); // 返回bool struct FEventListenerHandle { TWeakObjectPtrUObject ListenerObject; FEventDelegate Delegate; int32 Priority 0; // 默认优先级 }; // 在DispatchEvent中分发前排序 if (TArrayFEventListenerHandle* Listeners EventListenerMap.Find(EventType)) { TArrayFEventListenerHandle ListenersCopy *Listeners; // 按优先级降序排序优先级高的先执行 ListenersCopy.Sort([](const FEventListenerHandle A, const FEventListenerHandle B) { return A.Priority B.Priority; }); for (auto Handle : ListenersCopy) { if (Handle.ListenerObject.IsValid()) { // 如果委托返回true表示事件被消费停止分发 if (Handle.Delegate.ExecuteIfBound(InEvent)) { break; } } // ... 无效对象处理 } }5.2 异步事件队列对于非实时性要求高的事件或者需要在特定线程如游戏线程处理的事件我们可以引入一个异步队列。事件先被放入队列然后在主线程的Tick中集中处理。// 在FEventDispatcher中添加 TQueueTSharedPtrFGameEvent, EQueueMode::Mpsc EventQueue; // 线程安全的队列 void FEventDispatcher::DispatchEventAsync(TSharedPtrFGameEvent InEvent) { EventQueue.Enqueue(InEvent); } void FEventDispatcher::ProcessEventQueue() { // 在游戏线程的Tick函数中调用此方法 TSharedPtrFGameEvent Event; while (EventQueue.Dequeue(Event)) { if (Event.IsValid()) { DispatchEvent(*Event.Get()); // 同步分发 } } } // 在游戏实例或某个Manager的Tick中 void UMyGameInstance::Tick(float DeltaTime) { FEventDispatcher::Get().ProcessEventQueue(); }这样做的好处是线程安全可以从任何线程安全地投递事件DispatchEventAsync而实际处理总是在游戏线程避免了复杂的线程同步问题。控制处理时机可以在一帧的末尾集中处理所有累积的事件避免在复杂的逻辑中间处理事件导致的不可预测性。5.3 性能优化技巧事件池对于高频创建和销毁的事件如每帧的输入事件可以考虑使用对象池TObjectPool来复用事件对象减少动态内存分配的开销。委托使用内联函数UE的委托系统在绑定和调用时有一定的开销。对于性能极其敏感的路径可以考虑直接使用裸函数指针或std::function但这会牺牲一些安全性和便利性。通常UE委托的开销在绝大多数场景下都是可接受的。减少事件数据拷贝事件对象在分发时可能会被拷贝多次。如果事件数据很大可以考虑使用TSharedPtr或TSharedRef来包装事件数据在分发时只传递智能指针。使用稀疏事件类型如果事件类型枚举值非常稀疏例如中间有很多未使用的值TMap可能不是最高效的。可以考虑使用TArray以枚举值作为索引但需要确保枚举值是连续的或者使用一个映射表来转换。6. 常见问题排查与调试技巧即使设计再完善在实际使用中也会遇到各种问题。这里记录一些我踩过的坑和解决方法。6.1 崩溃问题排查表崩溃现象可能原因排查步骤与解决方案访问违例Access Violation通常在事件回调中。1. 监听者对象已被销毁但未解绑事件。2. 在事件回调函数中又触发了导致监听者列表修改的操作如绑定/解绑。1.检查EndPlay/Destroy中是否调用UnbindAll。使用内存分析工具检查对象生命周期。2.确保DispatchEvent中遍历的是容器副本并实现了待处理队列机制。在回调函数中避免进行复杂的绑定解绑。迭代器失效崩溃。在for (auto Handle : Listeners)循环中Listeners数组被修改添加/删除元素。强制使用容器副本进行遍历如TArrayFEventListenerHandle ListenersCopy *Listeners;。这是最根本的解决方法。断言失败Assertion failed对象不是预期的类型。在事件回调中将FGameEvent错误地强制转换static_cast为不匹配的具体事件类型。1.在转换前使用GetEventType()进行类型检查。2. 考虑使用dynamic_cast如果启用了RTTI或自定义的类型标识符进行安全转换。内存泄漏。绑定事件后从未解绑导致分发器持有对象的引用阻止其被垃圾回收。1.严格遵守“谁绑定谁解绑”的原则在对象的析构链中调用解绑。2. 使用UE的内存分析工具如MallocProfiler查看FEventDispatcher持有的引用。6.2 调试与日志良好的日志是调试事件系统的利器。可以在FEventDispatcher的关键路径添加详细的日志。// 在EventDispatcher.cpp中定义日志类别 DEFINE_LOG_CATEGORY_STATIC(LogEventDispatcher, Log, All); void FEventDispatcher::DispatchEvent(const FGameEvent InEvent) { UE_LOG(LogEventDispatcher, Verbose, TEXT(Dispatching Event: %s), *InEvent.ToString()); // ... 分发逻辑 ... UE_LOG(LogEventDispatcher, Verbose, TEXT(Finished Dispatching Event: %s), *InEvent.ToString()); } void FEventDispatcher::BindEvent(...) { UE_LOG(LogEventDispatcher, Log, TEXT(Binding event type %d to object %s), (uint8)EventType, InUserObject ? *InUserObject-GetName() : TEXT(NULL)); // ... 绑定逻辑 ... }你还可以添加一个调试命令或蓝图节点用于打印当前所有的事件绑定关系这在排查“事件为什么没触发”或“事件被谁消费了”时非常有用。6.3 事件没触发的排查流程确认事件已分发在DispatchEvent调用处打断点或加日志确认函数确实被调用且事件数据正确。确认监听者已绑定在BindEvent处加日志确认在事件分发前监听者已经成功绑定。检查绑定代码如BeginPlay是否确实被执行。检查事件类型匹配确认分发的事件类型GetEventType()与监听者绑定的事件类型完全一致。检查弱引用有效性在DispatchEvent的循环中检查Handle.ListenerObject.IsValid()是否为true。如果为false说明对象已销毁但未解绑事件不会被传递。检查事件消费如果实现了事件消费机制检查是否有更高优先级的监听者返回了true导致你的监听者没有被调用。实现自己的事件分发机制初看似乎有些复杂但一旦搭建起来它将成为你项目架构中非常可靠和强大的一环。它带来的解耦、灵活性和可维护性提升远超过最初的实现成本。最重要的是通过亲手实现你将对UE底层的委托系统、对象生命周期管理和C模板有更深刻的理解这些知识在任何大型C项目中都是无价之宝。