1. 为什么值得花时间啃 Notify 这块源码动画通知这套东西刚接触 UE5 的人多半觉得它就是个到点触发事件的小功能蓝图里挂一个 Notify写两行逻辑完事。但真做过几个动作向项目之后你会发现战斗判定、音效节奏、特效挂点、位移窗口、无敌帧几乎全都压在 Notify 和 Notify State 这两个类上。它们触发时机差一帧手感就是两个游戏。我最早做连招系统的时候用 AnimNotify 做伤害判定结果在低帧率机器上偶尔会丢判定排查了很久才发现是 Notify 的触发点落在两帧之间被跳过了。后来换成 AnimNotifyState 配合 Tick 才稳住。这件事让我意识到光会用不够得知道引擎内部到底怎么调度这两个东西。这篇内容就是把我读AnimationCore、Engine里 Notify 相关源码的笔记整理出来。核心讲清楚三件事Notify 和 Notify State 在源码层面到底怎么被触发、它们的数据结构长什么样、以及基于这些机制能玩出哪些常规文档里不写的操作。适合已经能写蓝图 Notify、但想搞清楚底层调度逻辑的开发者也适合准备做自定义 Notify 类型、需要继承引擎基类的人。读完之后你至少能明白为什么有的 Notify 会丢、Notify State 的 Begin 和 End 到底在哪个线程哪个时机被调、以及怎么写出一个不踩坑的自定义 Notify。2. Notify 与 Notify State 的源码结构拆解2.1 两个基类的继承关系与职责边界先看类定义。UAnimNotify和UAnimNotifyState都继承自UObject但它们并不是同一个父类分出来的兄弟而是各自独立的两个体系。UAnimNotify定义在Animation/AnimNotifies/AnimNotify.hUAnimNotifyState在Animation/AnimNotifies/AnimNotifyState.h。两者共享的只有UObject这个根没有公共的 Notify 基类。这个设计一开始让我有点意外因为从使用角度看它们很像。但想清楚就明白了Notify 是瞬时事件Notify State 是有持续区间的状态两者的生命周期模型完全不同硬抽一个公共基类反而会让接口变得别扭。引擎选择让它们各自独立通过FAnimNotifyEvent这个结构体在动画序列里统一管理。UAnimNotify的核心虚函数只有一个virtual void Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference);注意最后那个FAnimNotifyEventReference参数这是 UE5 新增的。UE4 时代只有前两个参数UE5 引入 EventReference 是为了让 Notify 能拿到更多上下文比如它对应的FAnimNotifyEvent本身、以及一些运行时标记。这个改动导致所有老版本自定义 Notify 在升级到 UE5 时都要改签名是个实打实的迁移坑。UAnimNotifyState则有三个虚函数virtual void NotifyBegin(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float TotalDuration, const FAnimNotifyEventReference EventReference); virtual void NotifyTick(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float FrameDeltaTime, const FAnimNotifyEventReference EventReference); virtual void NotifyEnd(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference);Begin 多一个TotalDuration告诉你这个 State 总共持续多久Tick 多一个FrameDeltaTime是当前帧的 delta。这三个函数的调用时机和顺序是理解整个 Notify 系统的关键。2.2 FAnimNotifyEvent真正被序列化存储的东西很多人以为动画序列里存的是UAnimNotify对象指针其实不是。真正被序列化进UAnimSequenceBase的是FAnimNotifyEvent结构体数组定义在Animation/AnimNotifies/AnimNotifyEvent.h。这个结构体里几个关键字段值得逐个看字段类型作用TriggerTimefloat触发时间点单位秒EndTriggerTimefloat结束时间点仅 Notify State 有效Durationfloat持续时间等于 EndTriggerTime - TriggerTimeNotifyUAnimNotify*瞬时通知对象指针NotifyStateClassUAnimNotifyState*状态通知对象指针NotifyNameFName通知名字蓝图里显示的就是它MontageTickTypeenum在 Montage 里的 Tick 方式关键点在于Notify和NotifyStateClass是互斥的一个FAnimNotifyEvent要么是瞬时 Notify要么是 State不会同时有值。引擎在编辑器里添加时就会根据类型填其中一个。这个结构体才是动画序列资产里真正存的东西UAnimNotify对象本身是作为子对象被引用保存的。理解这一点很重要因为它解释了为什么你在运行时动态改 Notify 参数有时候不生效——你改的是对象但触发判定用的是FAnimNotifyEvent里的TriggerTime两者不是一回事。2.3 触发链路从 Tick 到 Notify 回调动画播放时Notify 的触发发生在UAnimInstance的更新流程里。具体来说FAnimNode_SequencePlayer或 Montage 的求值过程中会调用到UAnimSequenceBase::GetAnimNotifies这类函数把当前帧时间区间内应该触发的 Notify 收集出来。核心逻辑在AnimSequenceBase.cpp里大致流程是拿到上一帧的播放位置PreviousPosition和当前帧位置CurrentPosition然后遍历所有FAnimNotifyEvent判断TriggerTime是否落在这个区间内。这里有个细节判断用的是半开区间还是闭区间直接影响边界帧的行为。引擎实际用的是TriggerTime PreviousPosition TriggerTime CurrentPosition这种形式也就是左开右闭。这个区间判断就是丢 Notify问题的根源。如果某一帧的 delta 特别大比如卡顿导致一帧跨过了两个 Notify 的触发点理论上两个都该触发但实际收集逻辑会怎么处理答案是它会都收集到但前提是这两个 Notify 的 TriggerTime 都落在(PreviousPosition, CurrentPosition]里。真正会丢的情况是 Notify 的 TriggerTime 恰好等于 PreviousPosition被左开区间排除了。所以如果你把 Notify 放在动画第 0 帧有时候不触发就是这个原因。对于 Notify State逻辑更复杂一点。它需要判断 State 的区间[TriggerTime, EndTriggerTime]和当前帧区间(PreviousPosition, CurrentPosition]是否有交集。如果有交集且上一帧还没进入这个 State就调NotifyBegin如果还在交集内就调NotifyTick如果这一帧离开了交集就调NotifyEnd。引擎用一个ActiveAnimNotifyState数组来跟踪当前处于激活状态的 State这个数组在FAnimInstanceProxy里维护。3. 核心机制里的关键细节与实操要点3.1 触发时机的帧对齐问题前面提到左开右闭区间这里展开讲一下实际影响。假设你有一个 30 帧的动画帧率 30fps每帧 delta 约 0.0333 秒。你在第 10 帧放一个 NotifyTriggerTime 算出来是 0.3333 秒。播放时第 10 帧的 CurrentPosition 正好是 0.3333PreviousPosition 是 0.3。判断0.3333 0.3 0.3333 0.3333成立触发。没问题。但如果帧率不稳定某一帧 delta 变成 0.05 秒播放位置从 0.3 直接跳到 0.35那0.3333 0.3 0.3333 0.35依然成立还是会触发。真正危险的是反向情况如果 PreviousPosition 恰好等于 0.3333那0.3333 0.3333为假这一帧不触发而下一帧 PreviousPosition 变成 0.3333 之后的位置CurrentPosition 更大TriggerTime 已经不在区间里了永久丢失。注意把 Notify 放在动画极靠前的位置尤其是第 0 帧时务必测试低帧率场景。稳妥做法是往后挪一两帧或者改用 Notify State 覆盖开头区间。这个问题的实操心得是对于关键判定比如伤害、位移不要依赖单个瞬时 Notify用 Notify State 的 Begin 来触发因为 State 的区间判断是交集逻辑容错性更高。Begin 只在进入区间时调一次即使帧率抖动只要区间有交集就会调不会因为边界问题丢失。3.2 Notify State 的 Tick 频率与 MontageTickTypeFAnimNotifyEvent里有个MontageTickType字段这个字段只在 Montage 里生效控制 Notify State 的 Tick 方式。它有两个值Queued和BranchingPoint。默认是Queued。Queued模式下Notify State 的 Tick 跟着动画求值的节奏走每帧调一次。BranchingPoint模式下这个 Notify 会被当作 Montage 的一个分支点Montage 的播放会在到达这个点时暂停求值先处理完 Notify 逻辑再继续。这个模式主要用于需要精确同步的场景比如 Montage 跳转。大部分情况下用默认的Queued就行。但如果你发现 Notify State 的 Tick 在 Montage 里偶尔不调或者调用的时机和预期对不上可以检查一下这个字段。我遇到过一次 Montage 里 Notify State 的 End 没触发最后发现是 Montage 被中断时引擎对BranchingPoint类型的处理路径和Queued不一样改成Queued就正常了。3.3 多线程与 Game Thread 的边界UE5 的动画系统大量使用任务图并行求值FAnimInstanceProxy的更新可能发生在工作线程。但 Notify 的回调包括Notify、NotifyBegin、NotifyTick、NotifyEnd最终都是在 Game Thread 上执行的。引擎会把在工作线程收集到的 Notify 事件排队然后在 Game Thread 的合适时机统一派发。这个机制意味着你在 Notify 回调里可以安全地访问和修改游戏逻辑对象不用担心线程问题。但也意味着 Notify 的触发相对于动画求值有一帧左右的延迟。如果你在做需要和动画严格同步的逻辑比如精确的碰撞检测这个延迟要考虑进去。实操中我一般这样处理Notify 回调里只做标记和事件派发真正的逻辑处理放到下一帧或者用委托异步处理。这样既避免了在动画回调里做重活导致卡顿也规避了潜在的时序问题。4. 自定义 Notify 的完整实现与源码级避坑4.1 从零写一个自定义 AnimNotify假设要做一个播放音效的自定义 Notify因为引擎自带的UAnimNotify_PlaySound有时候不够灵活需要根据角色状态动态选音效。步骤如下。第一步创建 C 类继承UAnimNotify// MyAnimNotify_PlayDynamicSound.h #pragma once #include CoreMinimal.h #include Animation/AnimNotifies/AnimNotify.h #include MyAnimNotify_PlayDynamicSound.generated.h UCLASS(meta (DisplayName Play Dynamic Sound)) class MYGAME_API UMyAnimNotify_PlayDynamicSound : public UAnimNotify { GENERATED_BODY() public: UPROPERTY(EditAnywhere, Category Sound) FName SoundRowName; virtual void Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) override; virtual FString GetNotifyName_Implementation() const override; };注意GetNotifyName_Implementation是蓝图可重载的重写它可以让 Notify 在编辑器时间轴上显示自定义名字方便识别。这个函数在UAnimNotify里是BlueprintNativeEvent所以带_Implementation后缀。第二步实现 Notify// MyAnimNotify_PlayDynamicSound.cpp #include MyAnimNotify_PlayDynamicSound.h #include Components/SkeletalMeshComponent.h #include Kismet/GameplayStatics.h void UMyAnimNotify_PlayDynamicSound::Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) { Super::Notify(MeshComp, Animation, EventReference); if (!MeshComp || !MeshComp-GetOwner()) { return; } // 根据 Owner 状态动态选音效这里只是示例 UGameplayStatics::PlaySoundAtLocation(MeshComp-GetOwner(), LoadedSound, MeshComp-GetComponentLocation()); } FString UMyAnimNotify_PlayDynamicSound::GetNotifyName_Implementation() const { return TEXT(DynamicSound); }这里有个坑Super::Notify一定要调虽然基类实现是空的但引擎未来可能在基类里加逻辑不调会埋隐患。另外MeshComp-GetOwner()可能为空尤其是 Notify 在编辑器预览时必须判空。第三步编译后在动画序列里右键添加 Notify就能看到 Play Dynamic Sound 选项。如果没看到检查UCLASS的meta标记和模块是否正确加载。4.2 自定义 AnimNotifyState 的注意事项Notify State 的自定义稍微复杂因为要处理三个回调的配对。写一个无敌帧State 为例UCLASS(meta (DisplayName Invincible Frame)) class MYGAME_API UMyAnimNotifyState_Invincible : public UAnimNotifyState { GENERATED_BODY() public: virtual void NotifyBegin(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float TotalDuration, const FAnimNotifyEventReference EventReference) override; virtual void NotifyTick(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float FrameDeltaTime, const FAnimNotifyEventReference EventReference) override; virtual void NotifyEnd(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) override; };实现里最关键的是 Begin 和 End 的配对。引擎保证在正常播放流程下Begin 和 End 一定成对出现。但如果动画被强制中断比如 Montage 被 StopEnd 会不会调答案是会引擎在清理 ActiveAnimNotifyState 时会补调 End。但如果你在 Begin 里做了资源申请在 End 里释放要确保 End 的逻辑是幂等的因为极端情况下可能被调多次。提示Notify State 的 Begin/End 配对不是绝对可靠的尤其是在网络同步和动画中断场景下。资源管理不要完全依赖这对回调最好加一层状态标记做保护。Tick 回调里要注意FrameDeltaTime的使用。这个值是当前帧的 delta不是 State 的总时长。如果你要做基于时间的插值用TotalDuration和累计的 Tick 时间来计算进度不要用帧数。4.3 蓝图 Notify 与 C Notify 的差异蓝图也能创建 Notify通过UAnimNotify_BlueprintBase和UAnimNotifyState_BlueprintBase。蓝图版本在底层会被包装成对应的 C 类回调转发到蓝图的Received_Notify等事件。性能上蓝图 Notify 比 C 慢因为每次回调都要走蓝图虚拟机。对于高频触发的 Notify State Tick这个开销不能忽略。我的经验是逻辑简单、触发频率低的用蓝图比如偶尔播个音效逻辑复杂或者每帧都跑的用 C比如战斗判定。另一个差异是调试。C Notify 可以打断点蓝图 Notify 只能靠打印。排查复杂问题时C 的可调试性优势明显。5. 常见问题排查与实战避坑速查5.1 Notify 不触发的排查思路Notify 不触发是最常见的问题原因五花八门。我整理了一个排查顺序按这个走基本能定位。排查项检查方法常见原因动画是否真的播放到该帧打印 CurrentPosition动画被中断或循环点设置错误TriggerTime 是否在区间内打印 PreviousPosition 和 CurrentPosition边界帧问题左开右闭Notify 对象是否有效检查 FAnimNotifyEvent 的 Notify 指针资产引用丢失是否在正确的 Mesh 上确认 MeshComp 和动画匹配多 Mesh 场景挂错对象Montage 的 Slot 是否正确检查 Slot 配置Slot 不匹配导致 Notify 被过滤其中Slot 不匹配这个坑比较隐蔽。Montage 里的 Notify 只有在对应的 Slot 被激活时才会触发。如果你有多个 SlotNotify 挂在 A Slot 上但播放时 B Slot 权重更高A Slot 的 Notify 可能就不触发。这个在混合动画场景里特别容易踩。5.2 Notify State 的 End 不触发问题End 不触发通常和动画中断有关。几种典型场景Montage 被Stop而不是自然播放结束、动画被 Blend 掉、角色死亡导致动画组件停止更新。引擎在FAnimInstanceProxy::UpdateAnimation里会处理 ActiveAnimNotifyState 的清理但清理时机依赖动画组件的 Tick。如果动画组件本身不 Tick 了清理就不会发生End 自然不调。应对办法是在角色死亡或动画组件停用前手动遍历并清理 ActiveAnimNotifyState。或者更简单在 Begin 里记录状态在角色逻辑里做超时保护不依赖 End 做关键清理。5.3 网络同步下的 Notify 行为多人项目里 Notify 的同步是个大话题。默认情况下Notify 只在本地触发不会自动同步到其他客户端。如果你在 Notify 里做伤害判定只有本地会执行其他玩家看不到。正确做法是把 Notify 当作本地事件源通过 RPC 或者属性同步把结果广播出去。比如 Notify 触发时在服务器上执行伤害逻辑然后同步结果。不要在 Notify 里直接改需要同步的状态除非你清楚同步机制。Notify State 的 Tick 在网络环境下更要注意因为不同客户端的帧率不同Tick 次数和时机都不一样。任何依赖 Tick 累计的逻辑都要考虑用服务器时间或者同步的变量来驱动而不是本地 Tick。5.4 性能相关的实操心得Notify State 的 Tick 是每帧调用的如果动画里有多个 State 重叠每帧的回调次数会累加。我见过一个项目在动画里叠了七八个 Notify State每个 Tick 里都做字符串查找和对象遍历结果动画一播 CPU 就飙。优化思路Tick 里只做最轻量的判断重活挪到 Begin 或者用事件驱动。能用缓存的就缓存比如把MeshComp-GetOwner()的结果在 Begin 里存下来Tick 里直接用。字符串操作绝对不要在 Tick 里做FName 比较比 FString 快得多。另外Notify 的收集本身也有开销。动画序列里 Notify 数量多的时候每帧遍历所有FAnimNotifyEvent判断区间这个循环不能忽略。如果 Notify 特别多可以考虑按时间排序后用二分查找优化不过引擎默认实现是线性遍历大部分项目够用。6. 从源码机制延伸出的几个实用技巧6.1 用 Notify 做精确的连招窗口理解了 Notify State 的区间判断逻辑后可以设计更精确的连招窗口。思路是用 Notify State 标记连招输入的有效区间Begin 时开启输入监听End 时关闭。因为 State 的区间判断是交集逻辑即使帧率抖动窗口的起止也不会丢。具体实现上Begin 里设置一个bComboWindowOpen标记Tick 里检查输入缓冲End 里关闭标记并清空缓冲。输入缓冲用一个小的时间窗口比如 0.2 秒这样玩家提前按键也能被识别。这套方案比用瞬时 Notify 做窗口稳定得多我在实际项目里用了两年没出过丢窗口的问题。6.2 动态修改 Notify 参数的时机有时候需要在运行时改 Notify 的参数比如根据难度调整伤害。前面说过触发判定用的是FAnimNotifyEvent的TriggerTime但 Notify 对象上的参数是可以改的。改的时机要在 Notify 触发之前。如果动画是循环播放的Notify 对象是复用的你改了一次参数下次循环还是这个值。所以要么在每次触发后重置要么在触发前根据当前状态设置。我一般用后者在 Notify 回调开头根据 Owner 状态计算参数这样每次触发都是最新的。6.3 调试 Notify 的实用手段引擎自带了一些 Notify 调试工具。控制台命令ShowDebug Animation可以显示当前动画状态包括激活的 Notify State。a.AnimNode.Notify.Enable之类的 CVar 可以开关 Notify 的调试输出。自己加日志的话建议在 Notify 回调里打印MeshComp-GetOwner()-GetName()和Animation-GetName()这样能快速定位是哪个角色的哪个动画触发的。多人场景下这个信息很关键不然一堆日志分不清是谁的。还有一个技巧是用FAnimNotifyEventReference拿到当前 Notify 的上下文。这个引用里包含了FAnimNotifyEvent的信息可以用来做更精细的调试比如打印 TriggerTime 和实际触发时间的差值判断是否有帧对齐问题。7. 我个人在实际项目中的几点体会读源码这件事最大的价值不是记住每个函数在哪一行而是建立起对系统行为的直觉。Notify 这套机制我用了很多年真正让我少踩坑的是理解了区间判断和Game Thread 派发这两个核心点。前者解释了为什么会有边界丢帧后者解释了为什么回调里能安全操作游戏对象。自定义 Notify 的时候我现在的习惯是先在 C 里写一个最小可用的版本跑通触发流程再往上加逻辑。蓝图 Notify 虽然方便但调试成本高复杂逻辑还是 C 靠谱。另外任何依赖 Begin/End 配对的资源管理我都会加一层状态保护因为动画中断的场景比想象中多。最后分享一个小习惯每次做新的 Notify 类型我都会在编辑器里把它拖到动画的最开头、最末尾、以及中间几个关键帧各测一遍。开头测边界末尾测结束时机中间测正常流程。这三组测试能覆盖大部分坑比出了问题再回头查效率高得多。
1. 为什么值得花时间啃 Notify 这块源码动画通知这套东西刚接触 UE5 的人多半觉得它就是个到点触发事件的小功能蓝图里挂一个 Notify写两行逻辑完事。但真做过几个动作向项目之后你会发现战斗判定、音效节奏、特效挂点、位移窗口、无敌帧几乎全都压在 Notify 和 Notify State 这两个类上。它们触发时机差一帧手感就是两个游戏。我最早做连招系统的时候用 AnimNotify 做伤害判定结果在低帧率机器上偶尔会丢判定排查了很久才发现是 Notify 的触发点落在两帧之间被跳过了。后来换成 AnimNotifyState 配合 Tick 才稳住。这件事让我意识到光会用不够得知道引擎内部到底怎么调度这两个东西。这篇内容就是把我读AnimationCore、Engine里 Notify 相关源码的笔记整理出来。核心讲清楚三件事Notify 和 Notify State 在源码层面到底怎么被触发、它们的数据结构长什么样、以及基于这些机制能玩出哪些常规文档里不写的操作。适合已经能写蓝图 Notify、但想搞清楚底层调度逻辑的开发者也适合准备做自定义 Notify 类型、需要继承引擎基类的人。读完之后你至少能明白为什么有的 Notify 会丢、Notify State 的 Begin 和 End 到底在哪个线程哪个时机被调、以及怎么写出一个不踩坑的自定义 Notify。2. Notify 与 Notify State 的源码结构拆解2.1 两个基类的继承关系与职责边界先看类定义。UAnimNotify和UAnimNotifyState都继承自UObject但它们并不是同一个父类分出来的兄弟而是各自独立的两个体系。UAnimNotify定义在Animation/AnimNotifies/AnimNotify.hUAnimNotifyState在Animation/AnimNotifies/AnimNotifyState.h。两者共享的只有UObject这个根没有公共的 Notify 基类。这个设计一开始让我有点意外因为从使用角度看它们很像。但想清楚就明白了Notify 是瞬时事件Notify State 是有持续区间的状态两者的生命周期模型完全不同硬抽一个公共基类反而会让接口变得别扭。引擎选择让它们各自独立通过FAnimNotifyEvent这个结构体在动画序列里统一管理。UAnimNotify的核心虚函数只有一个virtual void Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference);注意最后那个FAnimNotifyEventReference参数这是 UE5 新增的。UE4 时代只有前两个参数UE5 引入 EventReference 是为了让 Notify 能拿到更多上下文比如它对应的FAnimNotifyEvent本身、以及一些运行时标记。这个改动导致所有老版本自定义 Notify 在升级到 UE5 时都要改签名是个实打实的迁移坑。UAnimNotifyState则有三个虚函数virtual void NotifyBegin(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float TotalDuration, const FAnimNotifyEventReference EventReference); virtual void NotifyTick(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float FrameDeltaTime, const FAnimNotifyEventReference EventReference); virtual void NotifyEnd(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference);Begin 多一个TotalDuration告诉你这个 State 总共持续多久Tick 多一个FrameDeltaTime是当前帧的 delta。这三个函数的调用时机和顺序是理解整个 Notify 系统的关键。2.2 FAnimNotifyEvent真正被序列化存储的东西很多人以为动画序列里存的是UAnimNotify对象指针其实不是。真正被序列化进UAnimSequenceBase的是FAnimNotifyEvent结构体数组定义在Animation/AnimNotifies/AnimNotifyEvent.h。这个结构体里几个关键字段值得逐个看字段类型作用TriggerTimefloat触发时间点单位秒EndTriggerTimefloat结束时间点仅 Notify State 有效Durationfloat持续时间等于 EndTriggerTime - TriggerTimeNotifyUAnimNotify*瞬时通知对象指针NotifyStateClassUAnimNotifyState*状态通知对象指针NotifyNameFName通知名字蓝图里显示的就是它MontageTickTypeenum在 Montage 里的 Tick 方式关键点在于Notify和NotifyStateClass是互斥的一个FAnimNotifyEvent要么是瞬时 Notify要么是 State不会同时有值。引擎在编辑器里添加时就会根据类型填其中一个。这个结构体才是动画序列资产里真正存的东西UAnimNotify对象本身是作为子对象被引用保存的。理解这一点很重要因为它解释了为什么你在运行时动态改 Notify 参数有时候不生效——你改的是对象但触发判定用的是FAnimNotifyEvent里的TriggerTime两者不是一回事。2.3 触发链路从 Tick 到 Notify 回调动画播放时Notify 的触发发生在UAnimInstance的更新流程里。具体来说FAnimNode_SequencePlayer或 Montage 的求值过程中会调用到UAnimSequenceBase::GetAnimNotifies这类函数把当前帧时间区间内应该触发的 Notify 收集出来。核心逻辑在AnimSequenceBase.cpp里大致流程是拿到上一帧的播放位置PreviousPosition和当前帧位置CurrentPosition然后遍历所有FAnimNotifyEvent判断TriggerTime是否落在这个区间内。这里有个细节判断用的是半开区间还是闭区间直接影响边界帧的行为。引擎实际用的是TriggerTime PreviousPosition TriggerTime CurrentPosition这种形式也就是左开右闭。这个区间判断就是丢 Notify问题的根源。如果某一帧的 delta 特别大比如卡顿导致一帧跨过了两个 Notify 的触发点理论上两个都该触发但实际收集逻辑会怎么处理答案是它会都收集到但前提是这两个 Notify 的 TriggerTime 都落在(PreviousPosition, CurrentPosition]里。真正会丢的情况是 Notify 的 TriggerTime 恰好等于 PreviousPosition被左开区间排除了。所以如果你把 Notify 放在动画第 0 帧有时候不触发就是这个原因。对于 Notify State逻辑更复杂一点。它需要判断 State 的区间[TriggerTime, EndTriggerTime]和当前帧区间(PreviousPosition, CurrentPosition]是否有交集。如果有交集且上一帧还没进入这个 State就调NotifyBegin如果还在交集内就调NotifyTick如果这一帧离开了交集就调NotifyEnd。引擎用一个ActiveAnimNotifyState数组来跟踪当前处于激活状态的 State这个数组在FAnimInstanceProxy里维护。3. 核心机制里的关键细节与实操要点3.1 触发时机的帧对齐问题前面提到左开右闭区间这里展开讲一下实际影响。假设你有一个 30 帧的动画帧率 30fps每帧 delta 约 0.0333 秒。你在第 10 帧放一个 NotifyTriggerTime 算出来是 0.3333 秒。播放时第 10 帧的 CurrentPosition 正好是 0.3333PreviousPosition 是 0.3。判断0.3333 0.3 0.3333 0.3333成立触发。没问题。但如果帧率不稳定某一帧 delta 变成 0.05 秒播放位置从 0.3 直接跳到 0.35那0.3333 0.3 0.3333 0.35依然成立还是会触发。真正危险的是反向情况如果 PreviousPosition 恰好等于 0.3333那0.3333 0.3333为假这一帧不触发而下一帧 PreviousPosition 变成 0.3333 之后的位置CurrentPosition 更大TriggerTime 已经不在区间里了永久丢失。注意把 Notify 放在动画极靠前的位置尤其是第 0 帧时务必测试低帧率场景。稳妥做法是往后挪一两帧或者改用 Notify State 覆盖开头区间。这个问题的实操心得是对于关键判定比如伤害、位移不要依赖单个瞬时 Notify用 Notify State 的 Begin 来触发因为 State 的区间判断是交集逻辑容错性更高。Begin 只在进入区间时调一次即使帧率抖动只要区间有交集就会调不会因为边界问题丢失。3.2 Notify State 的 Tick 频率与 MontageTickTypeFAnimNotifyEvent里有个MontageTickType字段这个字段只在 Montage 里生效控制 Notify State 的 Tick 方式。它有两个值Queued和BranchingPoint。默认是Queued。Queued模式下Notify State 的 Tick 跟着动画求值的节奏走每帧调一次。BranchingPoint模式下这个 Notify 会被当作 Montage 的一个分支点Montage 的播放会在到达这个点时暂停求值先处理完 Notify 逻辑再继续。这个模式主要用于需要精确同步的场景比如 Montage 跳转。大部分情况下用默认的Queued就行。但如果你发现 Notify State 的 Tick 在 Montage 里偶尔不调或者调用的时机和预期对不上可以检查一下这个字段。我遇到过一次 Montage 里 Notify State 的 End 没触发最后发现是 Montage 被中断时引擎对BranchingPoint类型的处理路径和Queued不一样改成Queued就正常了。3.3 多线程与 Game Thread 的边界UE5 的动画系统大量使用任务图并行求值FAnimInstanceProxy的更新可能发生在工作线程。但 Notify 的回调包括Notify、NotifyBegin、NotifyTick、NotifyEnd最终都是在 Game Thread 上执行的。引擎会把在工作线程收集到的 Notify 事件排队然后在 Game Thread 的合适时机统一派发。这个机制意味着你在 Notify 回调里可以安全地访问和修改游戏逻辑对象不用担心线程问题。但也意味着 Notify 的触发相对于动画求值有一帧左右的延迟。如果你在做需要和动画严格同步的逻辑比如精确的碰撞检测这个延迟要考虑进去。实操中我一般这样处理Notify 回调里只做标记和事件派发真正的逻辑处理放到下一帧或者用委托异步处理。这样既避免了在动画回调里做重活导致卡顿也规避了潜在的时序问题。4. 自定义 Notify 的完整实现与源码级避坑4.1 从零写一个自定义 AnimNotify假设要做一个播放音效的自定义 Notify因为引擎自带的UAnimNotify_PlaySound有时候不够灵活需要根据角色状态动态选音效。步骤如下。第一步创建 C 类继承UAnimNotify// MyAnimNotify_PlayDynamicSound.h #pragma once #include CoreMinimal.h #include Animation/AnimNotifies/AnimNotify.h #include MyAnimNotify_PlayDynamicSound.generated.h UCLASS(meta (DisplayName Play Dynamic Sound)) class MYGAME_API UMyAnimNotify_PlayDynamicSound : public UAnimNotify { GENERATED_BODY() public: UPROPERTY(EditAnywhere, Category Sound) FName SoundRowName; virtual void Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) override; virtual FString GetNotifyName_Implementation() const override; };注意GetNotifyName_Implementation是蓝图可重载的重写它可以让 Notify 在编辑器时间轴上显示自定义名字方便识别。这个函数在UAnimNotify里是BlueprintNativeEvent所以带_Implementation后缀。第二步实现 Notify// MyAnimNotify_PlayDynamicSound.cpp #include MyAnimNotify_PlayDynamicSound.h #include Components/SkeletalMeshComponent.h #include Kismet/GameplayStatics.h void UMyAnimNotify_PlayDynamicSound::Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) { Super::Notify(MeshComp, Animation, EventReference); if (!MeshComp || !MeshComp-GetOwner()) { return; } // 根据 Owner 状态动态选音效这里只是示例 UGameplayStatics::PlaySoundAtLocation(MeshComp-GetOwner(), LoadedSound, MeshComp-GetComponentLocation()); } FString UMyAnimNotify_PlayDynamicSound::GetNotifyName_Implementation() const { return TEXT(DynamicSound); }这里有个坑Super::Notify一定要调虽然基类实现是空的但引擎未来可能在基类里加逻辑不调会埋隐患。另外MeshComp-GetOwner()可能为空尤其是 Notify 在编辑器预览时必须判空。第三步编译后在动画序列里右键添加 Notify就能看到 Play Dynamic Sound 选项。如果没看到检查UCLASS的meta标记和模块是否正确加载。4.2 自定义 AnimNotifyState 的注意事项Notify State 的自定义稍微复杂因为要处理三个回调的配对。写一个无敌帧State 为例UCLASS(meta (DisplayName Invincible Frame)) class MYGAME_API UMyAnimNotifyState_Invincible : public UAnimNotifyState { GENERATED_BODY() public: virtual void NotifyBegin(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float TotalDuration, const FAnimNotifyEventReference EventReference) override; virtual void NotifyTick(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float FrameDeltaTime, const FAnimNotifyEventReference EventReference) override; virtual void NotifyEnd(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) override; };实现里最关键的是 Begin 和 End 的配对。引擎保证在正常播放流程下Begin 和 End 一定成对出现。但如果动画被强制中断比如 Montage 被 StopEnd 会不会调答案是会引擎在清理 ActiveAnimNotifyState 时会补调 End。但如果你在 Begin 里做了资源申请在 End 里释放要确保 End 的逻辑是幂等的因为极端情况下可能被调多次。提示Notify State 的 Begin/End 配对不是绝对可靠的尤其是在网络同步和动画中断场景下。资源管理不要完全依赖这对回调最好加一层状态标记做保护。Tick 回调里要注意FrameDeltaTime的使用。这个值是当前帧的 delta不是 State 的总时长。如果你要做基于时间的插值用TotalDuration和累计的 Tick 时间来计算进度不要用帧数。4.3 蓝图 Notify 与 C Notify 的差异蓝图也能创建 Notify通过UAnimNotify_BlueprintBase和UAnimNotifyState_BlueprintBase。蓝图版本在底层会被包装成对应的 C 类回调转发到蓝图的Received_Notify等事件。性能上蓝图 Notify 比 C 慢因为每次回调都要走蓝图虚拟机。对于高频触发的 Notify State Tick这个开销不能忽略。我的经验是逻辑简单、触发频率低的用蓝图比如偶尔播个音效逻辑复杂或者每帧都跑的用 C比如战斗判定。另一个差异是调试。C Notify 可以打断点蓝图 Notify 只能靠打印。排查复杂问题时C 的可调试性优势明显。5. 常见问题排查与实战避坑速查5.1 Notify 不触发的排查思路Notify 不触发是最常见的问题原因五花八门。我整理了一个排查顺序按这个走基本能定位。排查项检查方法常见原因动画是否真的播放到该帧打印 CurrentPosition动画被中断或循环点设置错误TriggerTime 是否在区间内打印 PreviousPosition 和 CurrentPosition边界帧问题左开右闭Notify 对象是否有效检查 FAnimNotifyEvent 的 Notify 指针资产引用丢失是否在正确的 Mesh 上确认 MeshComp 和动画匹配多 Mesh 场景挂错对象Montage 的 Slot 是否正确检查 Slot 配置Slot 不匹配导致 Notify 被过滤其中Slot 不匹配这个坑比较隐蔽。Montage 里的 Notify 只有在对应的 Slot 被激活时才会触发。如果你有多个 SlotNotify 挂在 A Slot 上但播放时 B Slot 权重更高A Slot 的 Notify 可能就不触发。这个在混合动画场景里特别容易踩。5.2 Notify State 的 End 不触发问题End 不触发通常和动画中断有关。几种典型场景Montage 被Stop而不是自然播放结束、动画被 Blend 掉、角色死亡导致动画组件停止更新。引擎在FAnimInstanceProxy::UpdateAnimation里会处理 ActiveAnimNotifyState 的清理但清理时机依赖动画组件的 Tick。如果动画组件本身不 Tick 了清理就不会发生End 自然不调。应对办法是在角色死亡或动画组件停用前手动遍历并清理 ActiveAnimNotifyState。或者更简单在 Begin 里记录状态在角色逻辑里做超时保护不依赖 End 做关键清理。5.3 网络同步下的 Notify 行为多人项目里 Notify 的同步是个大话题。默认情况下Notify 只在本地触发不会自动同步到其他客户端。如果你在 Notify 里做伤害判定只有本地会执行其他玩家看不到。正确做法是把 Notify 当作本地事件源通过 RPC 或者属性同步把结果广播出去。比如 Notify 触发时在服务器上执行伤害逻辑然后同步结果。不要在 Notify 里直接改需要同步的状态除非你清楚同步机制。Notify State 的 Tick 在网络环境下更要注意因为不同客户端的帧率不同Tick 次数和时机都不一样。任何依赖 Tick 累计的逻辑都要考虑用服务器时间或者同步的变量来驱动而不是本地 Tick。5.4 性能相关的实操心得Notify State 的 Tick 是每帧调用的如果动画里有多个 State 重叠每帧的回调次数会累加。我见过一个项目在动画里叠了七八个 Notify State每个 Tick 里都做字符串查找和对象遍历结果动画一播 CPU 就飙。优化思路Tick 里只做最轻量的判断重活挪到 Begin 或者用事件驱动。能用缓存的就缓存比如把MeshComp-GetOwner()的结果在 Begin 里存下来Tick 里直接用。字符串操作绝对不要在 Tick 里做FName 比较比 FString 快得多。另外Notify 的收集本身也有开销。动画序列里 Notify 数量多的时候每帧遍历所有FAnimNotifyEvent判断区间这个循环不能忽略。如果 Notify 特别多可以考虑按时间排序后用二分查找优化不过引擎默认实现是线性遍历大部分项目够用。6. 从源码机制延伸出的几个实用技巧6.1 用 Notify 做精确的连招窗口理解了 Notify State 的区间判断逻辑后可以设计更精确的连招窗口。思路是用 Notify State 标记连招输入的有效区间Begin 时开启输入监听End 时关闭。因为 State 的区间判断是交集逻辑即使帧率抖动窗口的起止也不会丢。具体实现上Begin 里设置一个bComboWindowOpen标记Tick 里检查输入缓冲End 里关闭标记并清空缓冲。输入缓冲用一个小的时间窗口比如 0.2 秒这样玩家提前按键也能被识别。这套方案比用瞬时 Notify 做窗口稳定得多我在实际项目里用了两年没出过丢窗口的问题。6.2 动态修改 Notify 参数的时机有时候需要在运行时改 Notify 的参数比如根据难度调整伤害。前面说过触发判定用的是FAnimNotifyEvent的TriggerTime但 Notify 对象上的参数是可以改的。改的时机要在 Notify 触发之前。如果动画是循环播放的Notify 对象是复用的你改了一次参数下次循环还是这个值。所以要么在每次触发后重置要么在触发前根据当前状态设置。我一般用后者在 Notify 回调开头根据 Owner 状态计算参数这样每次触发都是最新的。6.3 调试 Notify 的实用手段引擎自带了一些 Notify 调试工具。控制台命令ShowDebug Animation可以显示当前动画状态包括激活的 Notify State。a.AnimNode.Notify.Enable之类的 CVar 可以开关 Notify 的调试输出。自己加日志的话建议在 Notify 回调里打印MeshComp-GetOwner()-GetName()和Animation-GetName()这样能快速定位是哪个角色的哪个动画触发的。多人场景下这个信息很关键不然一堆日志分不清是谁的。还有一个技巧是用FAnimNotifyEventReference拿到当前 Notify 的上下文。这个引用里包含了FAnimNotifyEvent的信息可以用来做更精细的调试比如打印 TriggerTime 和实际触发时间的差值判断是否有帧对齐问题。7. 我个人在实际项目中的几点体会读源码这件事最大的价值不是记住每个函数在哪一行而是建立起对系统行为的直觉。Notify 这套机制我用了很多年真正让我少踩坑的是理解了区间判断和Game Thread 派发这两个核心点。前者解释了为什么会有边界丢帧后者解释了为什么回调里能安全操作游戏对象。自定义 Notify 的时候我现在的习惯是先在 C 里写一个最小可用的版本跑通触发流程再往上加逻辑。蓝图 Notify 虽然方便但调试成本高复杂逻辑还是 C 靠谱。另外任何依赖 Begin/End 配对的资源管理我都会加一层状态保护因为动画中断的场景比想象中多。最后分享一个小习惯每次做新的 Notify 类型我都会在编辑器里把它拖到动画的最开头、最末尾、以及中间几个关键帧各测一遍。开头测边界末尾测结束时机中间测正常流程。这三组测试能覆盖大部分坑比出了问题再回头查效率高得多。
