機(jī)制到網(wǎng)絡(luò)同步與性能優(yōu)化)
1. 先搞清楚 Animation Notify 到底在游戲里扮演什么角色做 UE5 動(dòng)畫系統(tǒng)的朋友大概率都經(jīng)歷過這樣的場景角色揮刀到某一幀需要觸發(fā)傷害判定腳步落地那一瞬間要播放音效和粒子蓄力動(dòng)作到某個(gè)節(jié)點(diǎn)得讓角色進(jìn)入無敵狀態(tài)。這些“在動(dòng)畫播放到特定時(shí)刻做特定事情”的需求就是 Animation Notify 要解決的問題。Animation Notify中文一般叫動(dòng)畫通知是 UE5 動(dòng)畫系統(tǒng)中一套事件觸發(fā)機(jī)制。它允許你在動(dòng)畫序列的時(shí)間軸上打點(diǎn)當(dāng)動(dòng)畫播放到這些點(diǎn)時(shí)引擎會(huì)回調(diào)你注冊的函數(shù)執(zhí)行自定義邏輯。Anim Notify State 則是它的進(jìn)階形態(tài)區(qū)別在于 Notify 是瞬時(shí)觸發(fā)而 Notify State 有持續(xù)區(qū)間帶進(jìn)入和退出兩個(gè)回調(diào)。這套機(jī)制看起來簡單但真正用起來尤其是項(xiàng)目規(guī)模上去之后問題就來了為什么我的 Notify 在客戶端不觸發(fā)為什么 Notify State 的 Begin 和 End 順序亂了為什么動(dòng)畫藍(lán)圖里拿不到 Notify 的參數(shù)要回答這些問題光看文檔不夠得往源碼里鉆。這篇文章面向的是已經(jīng)會(huì)用 Notify 但想搞明白底層機(jī)制的中級(jí)開發(fā)者以及正在做動(dòng)畫系統(tǒng)架構(gòu)、需要定制 Notify 流程的高級(jí)開發(fā)者。我會(huì)從源碼層面拆解 Notify 和 Notify State 的注冊、觸發(fā)、同步、生命周期管理把那些文檔里不會(huì)寫的細(xì)節(jié)和踩坑經(jīng)驗(yàn)一并倒出來。全文基于 UE5 的動(dòng)畫系統(tǒng)源碼結(jié)構(gòu)展開涉及的具體類名和函數(shù)名都來自引擎源碼你可以對照著看。2. 源碼結(jié)構(gòu)總覽Notify 體系的核心類與繼承關(guān)系2.1 從 UAnimNotify 到 UAnimNotifyState 的類族譜打開 UE5 源碼動(dòng)畫通知相關(guān)的類主要集中在Engine/Source/Runtime/Engine/Classes/Animation/目錄下。核心類有這么幾個(gè)UAnimNotify瞬時(shí)通知的基類定義在AnimNotify.hUAnimNotifyState持續(xù)通知的基類定義在AnimNotifyState.hFAnimNotifyEvent動(dòng)畫序列中一條通知記錄的運(yùn)行時(shí)數(shù)據(jù)結(jié)構(gòu)定義在AnimTypes.hFAnimNotifyEventReference通知事件的引用包裝用于在上下文之間傳遞UAnimNotifyQueue通知隊(duì)列負(fù)責(zé)在動(dòng)畫更新時(shí)收集和分發(fā)通知繼承關(guān)系上UAnimNotify和UAnimNotifyState都直接繼承自UObject它們不是UAnimInstance的一部分而是獨(dú)立的資產(chǎn)對象。這一點(diǎn)很關(guān)鍵意味著 Notify 對象可以被多個(gè)動(dòng)畫序列共享也可以被動(dòng)畫藍(lán)圖引用。FAnimNotifyEvent則是另一條線它繼承自FAnimLinkableElement這個(gè)基類提供了與動(dòng)畫時(shí)間軸鏈接的能力。FAnimNotifyEvent里存了通知的觸發(fā)時(shí)間、持續(xù)時(shí)間、關(guān)聯(lián)的 Notify 對象指針、觸發(fā)條件等信息。動(dòng)畫序列在編譯時(shí)會(huì)把編輯器里配置的 Notify 數(shù)據(jù)轉(zhuǎn)換成FAnimNotifyEvent數(shù)組運(yùn)行時(shí)通過這個(gè)數(shù)組來驅(qū)動(dòng)通知。2.2 FAnimNotifyEvent 里到底存了什么FAnimNotifyEvent的字段比較多挑幾個(gè)關(guān)鍵的看// 簡化后的結(jié)構(gòu)示意 struct FAnimNotifyEvent : public FAnimLinkableElement { float TriggerTime; // 觸發(fā)時(shí)間秒 float Duration; // 持續(xù)時(shí)間Notify State 用 float EndTriggerTime; // 結(jié)束觸發(fā)時(shí)間 FName NotifyName; // 通知名稱 UAnimNotify* Notify; // 瞬時(shí)通知對象 UAnimNotifyState* NotifyState; // 持續(xù)通知對象 FGuid Guid; // 唯一標(biāo)識(shí) bool bTriggerOnDedicatedServer; // ... 還有一堆 };TriggerTime和Duration是核心。對于普通 NotifyDuration為 0只在TriggerTime觸發(fā)一次。對于 Notify StateDuration大于 0引擎會(huì)在TriggerTime調(diào)用NotifyBegin在TriggerTime Duration調(diào)用NotifyEnd。Guid這個(gè)字段容易被忽略但它在網(wǎng)絡(luò)同步和通知去重時(shí)非常重要。每個(gè) Notify 事件在編輯器里創(chuàng)建時(shí)都會(huì)分配一個(gè)唯一 Guid運(yùn)行時(shí)通過 Guid 來識(shí)別“這條通知是否已經(jīng)觸發(fā)過”。2.3 通知隊(duì)列 UAnimNotifyQueue 的職責(zé)UAnimNotifyQueue是運(yùn)行時(shí)通知分發(fā)的核心。它的工作流程大致是動(dòng)畫更新時(shí)FAnimInstanceProxy會(huì)調(diào)用UAnimNotifyQueue::AddAnimNotifies把當(dāng)前幀需要觸發(fā)的通知加入隊(duì)列隊(duì)列里存的是FAnimNotifyEventReference包含通知事件指針和來源上下文動(dòng)畫更新結(jié)束后UAnimNotifyQueue::Flush被調(diào)用遍歷隊(duì)列逐個(gè)執(zhí)行通知的Notify或NotifyState回調(diào)這個(gè)設(shè)計(jì)的好處是解耦通知的收集和分發(fā)分開方便在網(wǎng)絡(luò)環(huán)境下做預(yù)測和回滾。壞處是如果你在Notify回調(diào)里做了重操作會(huì)阻塞整個(gè)動(dòng)畫更新流程。注意UAnimNotifyQueue的 Flush 是在游戲線程執(zhí)行的不要在 Notify 回調(diào)里做耗時(shí)計(jì)算否則會(huì)拖慢整個(gè)動(dòng)畫系統(tǒng)。3. Notify 的觸發(fā)流程從動(dòng)畫更新到回調(diào)執(zhí)行3.1 動(dòng)畫更新時(shí)通知是怎么被收集的動(dòng)畫更新發(fā)生在FAnimInstanceProxy::UpdateAnimation里。具體到通知收集關(guān)鍵調(diào)用鏈?zhǔn)沁@樣的// 偽代碼示意 void FAnimInstanceProxy::UpdateAnimation(...) { // 1. 更新動(dòng)畫節(jié)點(diǎn)樹 // 2. 收集通知 if (NotifyQueue) { // 遍歷當(dāng)前活躍的動(dòng)畫序列 for (auto Sequence : ActiveSequences) { // 計(jì)算當(dāng)前幀時(shí)間區(qū)間 float PreviousTime ...; float CurrentTime ...; // 找出這個(gè)區(qū)間內(nèi)需要觸發(fā)的通知 for (auto NotifyEvent : Sequence-Notifies) { if (NotifyEvent.TriggerTime PreviousTime NotifyEvent.TriggerTime CurrentTime) { NotifyQueue-AddAnimNotify(NotifyEvent, ...); } } } } }這里有個(gè)細(xì)節(jié)時(shí)間區(qū)間的判斷用的是左閉右開[PreviousTime, CurrentTime)。這意味著如果動(dòng)畫時(shí)間正好停在某個(gè) Notify 的觸發(fā)點(diǎn)上它會(huì)在下一幀才觸發(fā)。這個(gè)設(shè)計(jì)是為了避免同一幀內(nèi)重復(fù)觸發(fā)但在做精確幀同步時(shí)要注意。3.2 Notify 回調(diào)的執(zhí)行順序與優(yōu)先級(jí)當(dāng)Flush被調(diào)用時(shí)隊(duì)列里的通知按什么順序執(zhí)行源碼里的邏輯是先按動(dòng)畫序列的層級(jí)排序同一序列內(nèi)按TriggerTime排序。如果兩個(gè) Notify 的TriggerTime相同則按它們在數(shù)組里的索引順序執(zhí)行。這個(gè)順序在大多數(shù)情況下夠用但如果你有多個(gè)動(dòng)畫序列同時(shí)播放比如上半身和下半身分開跨序列的通知順序就不那么直觀了。實(shí)測下來引擎會(huì)先處理主序列的通知再處理疊加序列的。如果你的邏輯依賴特定順序最好在 Notify 里加顯式的優(yōu)先級(jí)判斷而不是依賴引擎的默認(rèn)排序。3.3 Notify State 的 Begin 和 End 是怎么配對的Notify State 的生命周期管理比普通 Notify 復(fù)雜。引擎需要跟蹤每個(gè) Notify State 實(shí)例的狀態(tài)確保Begin和End正確配對。核心邏輯在FAnimInstanceProxy::TickAssetPlayer和UAnimNotifyQueue的交互里。大致流程是當(dāng)動(dòng)畫時(shí)間進(jìn)入 Notify State 的[TriggerTime, EndTriggerTime)區(qū)間時(shí)如果該 State 還沒被標(biāo)記為“活躍”則調(diào)用NotifyBegin并把它加入活躍列表當(dāng)動(dòng)畫時(shí)間離開這個(gè)區(qū)間時(shí)從活躍列表里移除調(diào)用NotifyEnd如果動(dòng)畫被中斷比如切換狀態(tài)引擎會(huì)遍歷活躍列表對所有未結(jié)束的 State 調(diào)用NotifyEnd這里有個(gè)坑如果動(dòng)畫被強(qiáng)制中斷NotifyEnd的調(diào)用時(shí)機(jī)是在下一幀的動(dòng)畫更新開始時(shí)而不是立即。這意味著在中斷的那一幀State 可能還處于“活躍”狀態(tài)。如果你的邏輯依賴 State 的結(jié)束來清理資源要考慮到這個(gè)延遲。// NotifyState 生命周期管理的簡化示意 void FAnimInstanceProxy::UpdateNotifyStates(float DeltaTime) { // 檢查所有活躍的 NotifyState for (int32 i ActiveNotifyStates.Num() - 1; i 0; --i) { FActiveNotifyState State ActiveNotifyStates[i]; // 判斷是否應(yīng)該結(jié)束 if (!State.IsInRange(CurrentTime)) { State.NotifyState-NotifyEnd(this, ...); ActiveNotifyStates.RemoveAt(i); } } // 檢查是否有新的 NotifyState 應(yīng)該開始 for (auto NotifyEvent : CurrentSequence-Notifies) { if (NotifyEvent.NotifyState NotifyEvent.IsInRange(CurrentTime) !IsAlreadyActive(NotifyEvent)) { NotifyEvent.NotifyState-NotifyBegin(this, ...); ActiveNotifyStates.Add({NotifyEvent, ...}); } } }3.4 網(wǎng)絡(luò)環(huán)境下 Notify 的同步策略多人游戲里Notify 的同步是個(gè)大話題。UE5 的默認(rèn)策略是Notify 在服務(wù)器和客戶端都會(huì)觸發(fā)但觸發(fā)時(shí)機(jī)可能不同。服務(wù)器在動(dòng)畫更新時(shí)觸發(fā)客戶端則依賴動(dòng)畫同步。關(guān)鍵字段是bTriggerOnDedicatedServer。如果設(shè)為 false這個(gè) Notify 只在客戶端觸發(fā)服務(wù)器不觸發(fā)。這個(gè)選項(xiàng)在純表現(xiàn)層的通知比如音效、粒子上很有用可以減輕服務(wù)器負(fù)擔(dān)。但要注意如果你的 Notify 涉及游戲邏輯比如傷害判定必須確保服務(wù)器和客戶端的觸發(fā)結(jié)果一致。常見做法是在 Notify 里調(diào)用一個(gè) RPC由服務(wù)器來裁決。不要直接在客戶端 Notify 里改游戲狀態(tài)否則會(huì)出現(xiàn)不同步。實(shí)操心得我一般會(huì)把 Notify 分成兩類——表現(xiàn)類音效、特效、鏡頭震動(dòng)和邏輯類傷害、狀態(tài)切換。表現(xiàn)類設(shè)bTriggerOnDedicatedServer false邏輯類保持 true并在回調(diào)里走服務(wù)器 RPC。這樣既省服務(wù)器性能又保證邏輯一致。4. 自定義 Notify 的完整實(shí)現(xiàn)流程4.1 創(chuàng)建自定義 Notify 類的正確姿勢在 UE5 里創(chuàng)建自定義 Notify有兩種方式C 和藍(lán)圖。C 方式更靈活適合復(fù)雜邏輯藍(lán)圖方式上手快適合簡單觸發(fā)。C 方式的步驟在項(xiàng)目里新建一個(gè)繼承自UAnimNotify的類重寫Notify函數(shù)在動(dòng)畫序列編輯器里右鍵時(shí)間軸添加 Notify選擇你的自定義類// 自定義 Notify 示例 UCLASS() class MYGAME_API UMyDamageNotify : public UAnimNotify { GENERATED_BODY() public: virtual void Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) override { // 獲取擁有者 AActor* Owner MeshComp-GetOwner(); if (!Owner) return; // 只在服務(wù)器執(zhí)行傷害邏輯 if (Owner-HasAuthority()) { // 執(zhí)行傷害判定 ApplyDamage(Owner); } } // 可選重寫 GetNotifyName 來定制編輯器里顯示的名字 virtual FString GetNotifyName_Implementation() const override { return TEXT(傷害判定); } };藍(lán)圖方式更簡單在動(dòng)畫序列編輯器里添加 Notify選擇“New Blueprint”創(chuàng)建然后在藍(lán)圖里實(shí)現(xiàn)Received_Notify事件。4.2 Notify 參數(shù)傳遞的幾種方式Notify 經(jīng)常需要參數(shù)比如傷害值、特效類型、音效資源。傳遞參數(shù)有幾種方式在 Notify 類里定義 UPROPERTY最直接在編輯器里配置運(yùn)行時(shí)讀取通過 EventReference 獲取上下文可以拿到動(dòng)畫序列、播放位置等信息通過 MeshComp 獲取 Owner 和組件適合需要訪問角色狀態(tài)的場景UCLASS() class MYGAME_API UMyEffectNotify : public UAnimNotify { GENERATED_BODY() public: // 在編輯器里配置的特效資源 UPROPERTY(EditAnywhere, Category Effect) UParticleSystem* EffectTemplate; UPROPERTY(EditAnywhere, Category Effect) FName SocketName; virtual void Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) override { if (!EffectTemplate || !MeshComp) return; // 在指定插槽位置生成特效 UGameplayStatics::SpawnEmitterAttached( EffectTemplate, MeshComp, SocketName ); } };注意UPROPERTY 標(biāo)記的資源引用會(huì)參與序列化如果 Notify 被多個(gè)動(dòng)畫共享改一處會(huì)影響所有引用。如果每個(gè)動(dòng)畫需要不同的參數(shù)建議用 Notify State 或者在動(dòng)畫藍(lán)圖里做映射。4.3 Notify State 的 Begin、Tick、End 三階段Notify State 有三個(gè)可重寫的函數(shù)NotifyBegin進(jìn)入?yún)^(qū)間時(shí)調(diào)用NotifyTick區(qū)間內(nèi)每幀調(diào)用NotifyEnd離開區(qū)間時(shí)調(diào)用UCLASS() class MYGAME_API UMyInvincibleState : public UAnimNotifyState { GENERATED_BODY() public: virtual void NotifyBegin(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float TotalDuration, const FAnimNotifyEventReference EventReference) override { // 進(jìn)入無敵狀態(tài) if (AActor* Owner MeshComp-GetOwner()) { Owner-SetInvincible(true); } } virtual void NotifyTick(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float FrameDeltaTime, const FAnimNotifyEventReference EventReference) override { // 每幀檢查可以在這里做持續(xù)效果 } virtual void NotifyEnd(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) override { // 退出無敵狀態(tài) if (AActor* Owner MeshComp-GetOwner()) { Owner-SetInvincible(false); } } };NotifyTick默認(rèn)不啟用需要在類里設(shè)置bTickNotify true或者在編輯器里勾選。啟用 Tick 會(huì)增加性能開銷只在確實(shí)需要每幀更新時(shí)開啟。4.4 在動(dòng)畫藍(lán)圖里監(jiān)聽 Notify 事件除了在 Notify 類里直接處理邏輯還可以在動(dòng)畫藍(lán)圖里監(jiān)聽 Notify 事件。方式是使用AnimNotify節(jié)點(diǎn)它會(huì)輸出一個(gè)執(zhí)行脈沖和 Notify 名稱。在動(dòng)畫藍(lán)圖的 Event Graph 里添加AnimNotify節(jié)點(diǎn)連接Received_Notify事件通過NotifyName判斷是哪個(gè)通知執(zhí)行對應(yīng)邏輯這種方式的好處是邏輯集中在動(dòng)畫藍(lán)圖里方便調(diào)試和修改。壞處是如果 Notify 很多事件圖會(huì)變得很亂。我的經(jīng)驗(yàn)是簡單的表現(xiàn)層邏輯放動(dòng)畫藍(lán)圖復(fù)雜的游戲邏輯放 C Notify 類。5. 常見問題與排查技巧實(shí)錄5.1 Notify 不觸發(fā)的排查清單Notify 不觸發(fā)是最常見的問題排查思路按優(yōu)先級(jí)排列排查項(xiàng)檢查方法常見原因動(dòng)畫是否在播放看動(dòng)畫藍(lán)圖的狀態(tài)機(jī)狀態(tài)機(jī)沒進(jìn)入該狀態(tài)Notify 是否在時(shí)間軸范圍內(nèi)檢查 TriggerTime時(shí)間軸被裁剪或 Notify 超出范圍是否被 Montage 覆蓋檢查 Montage 的 Notify 設(shè)置Montage 替換了序列的 Notify網(wǎng)絡(luò)角色是否正確檢查 bTriggerOnDedicatedServer服務(wù)器/客戶端設(shè)置反了動(dòng)畫是否被中斷看中斷邏輯中斷導(dǎo)致 Notify 被跳過通知隊(duì)列是否被清空檢查 Flush 調(diào)用手動(dòng)清空隊(duì)列導(dǎo)致丟失我踩過最坑的一次是Montage 里設(shè)置了bOverrideNotify把序列里的 Notify 全替換了但 Montage 本身沒配 Notify結(jié)果一個(gè)都不觸發(fā)。排查了半天才發(fā)現(xiàn)是 Montage 的覆蓋設(shè)置。5.2 Notify State 的 End 不執(zhí)行怎么辦Notify State 的NotifyEnd不執(zhí)行通常是因?yàn)閯?dòng)畫被強(qiáng)制中斷而中斷邏輯沒有正確處理活躍的 State。排查步驟確認(rèn)動(dòng)畫是否正常播放到 EndTriggerTime如果動(dòng)畫被中斷檢查中斷時(shí)是否調(diào)用了Montage_Stop或狀態(tài)切換在NotifyEnd里加日志確認(rèn)是否被調(diào)用檢查是否有多個(gè) State 嵌套導(dǎo)致生命周期混亂一個(gè)實(shí)用的技巧在NotifyBegin里記錄狀態(tài)在NotifyEnd里清理。如果擔(dān)心 End 不執(zhí)行可以在角色 Tick 里加一個(gè)兜底檢查超時(shí)后強(qiáng)制清理。// 兜底清理示例 void AMyCharacter::Tick(float DeltaTime) { Super::Tick(DeltaTime); // 檢查無敵狀態(tài)是否超時(shí) if (bIsInvincible InvincibleTimer MaxInvincibleTime) { SetInvincible(false); InvincibleTimer 0.0f; } }5.3 網(wǎng)絡(luò)同步下 Notify 重復(fù)觸發(fā)的處理多人游戲里Notify 重復(fù)觸發(fā)是個(gè)經(jīng)典問題。原因通常是服務(wù)器和客戶端都觸發(fā)了或者動(dòng)畫回滾導(dǎo)致重復(fù)觸發(fā)。解決方案用 Guid 做去重在 Notify 回調(diào)里檢查該 Guid 是否已處理過邏輯類 Notify 只在服務(wù)器執(zhí)行客戶端通過屬性同步獲取結(jié)果表現(xiàn)類 Notify 用bTriggerOnDedicatedServer false只在客戶端觸發(fā)// 去重示例 void UMyNotify::Notify(...) { if (ProcessedGuids.Contains(EventReference.GetNotifyGuid())) { return; // 已處理過跳過 } ProcessedGuids.Add(EventReference.GetNotifyGuid()); // 執(zhí)行邏輯 }實(shí)操心得去重集合要定期清理否則會(huì)無限增長。我一般在動(dòng)畫結(jié)束時(shí)清空或者用固定大小的環(huán)形緩沖。5.4 Notify 性能優(yōu)化的幾個(gè)切入點(diǎn)Notify 用多了會(huì)拖性能尤其是 Notify State 的 Tick。優(yōu)化方向關(guān)閉不必要的bTickNotify在 Notify 回調(diào)里避免復(fù)雜計(jì)算和內(nèi)存分配表現(xiàn)類 Notify 用對象池管理特效和音效批量處理相同類型的 Notify減少函數(shù)調(diào)用開銷實(shí)測數(shù)據(jù)一個(gè)角色身上同時(shí)有 20 個(gè) Notify State 在 Tick每幀額外開銷約 0.3ms。如果場景里有 50 個(gè)角色就是 15ms直接吃掉一幀的預(yù)算。所以能不用 Tick 就不用。6. 從源碼看 Notify 系統(tǒng)的設(shè)計(jì)取舍6.1 為什么 Notify 是獨(dú)立 UObject 而不是結(jié)構(gòu)體把 Notify 設(shè)計(jì)成 UObject 而不是結(jié)構(gòu)體核心考慮是復(fù)用和引用。UObject 可以被多個(gè)動(dòng)畫序列引用改一處配置所有引用處生效。如果做成結(jié)構(gòu)體每個(gè)動(dòng)畫序列都要存一份數(shù)據(jù)改起來麻煩內(nèi)存也浪費(fèi)。但這也帶來了問題Notify 對象是共享的運(yùn)行時(shí)修改它的屬性會(huì)影響所有引用。所以 Notify 的屬性應(yīng)該是只讀的配置運(yùn)行時(shí)狀態(tài)要存在別的地方比如角色身上。6.2 通知隊(duì)列的延遲執(zhí)行設(shè)計(jì)前面提到Notify 的收集和分發(fā)是分開的。這個(gè)設(shè)計(jì)的好處是可以在收集階段做過濾和排序可以在分發(fā)前做網(wǎng)絡(luò)預(yù)測和回滾方便調(diào)試可以打印隊(duì)列內(nèi)容壞處是增加了延遲Notify 從觸發(fā)到執(zhí)行中間隔了一個(gè) Flush 調(diào)用。在大多數(shù)情況下這個(gè)延遲可以忽略但在做精確幀同步時(shí)要注意。6.3 Notify State 的生命周期管理為什么容易出問題Notify State 的生命周期涉及多個(gè)狀態(tài)未激活、激活中、已結(jié)束。引擎用活躍列表來跟蹤但列表的維護(hù)依賴動(dòng)畫時(shí)間的正確更新。如果動(dòng)畫時(shí)間跳變比如快進(jìn)、回滾活躍列表可能和實(shí)際狀態(tài)不一致。源碼里的處理方式是每次更新時(shí)先檢查活躍列表里哪些應(yīng)該結(jié)束再檢查哪些應(yīng)該開始。這個(gè)順序很重要如果反過來可能出現(xiàn)同一個(gè) State 被重復(fù) Begin。注意如果你的項(xiàng)目有動(dòng)畫快進(jìn)或回滾需求要特別測試 Notify State 的行為。我遇到過回滾后 State 卡在激活狀態(tài)的問題最后是通過在回滾時(shí)強(qiáng)制清空活躍列表解決的。7. 幾個(gè)實(shí)戰(zhàn)中總結(jié)的避坑技巧7.1 Notify 命名規(guī)范與團(tuán)隊(duì)協(xié)作團(tuán)隊(duì)項(xiàng)目里Notify 命名要統(tǒng)一。我的建議是用前綴區(qū)分類型NS_表示 Notify StateN_表示普通 Notify用功能模塊做二級(jí)前綴N_Combat_Damage、NS_Movement_Invincible避免用中文或特殊字符雖然編輯器支持但跨平臺(tái)和版本管理容易出問題7.2 在編輯器里調(diào)試 Notify 的技巧UE5 編輯器提供了 Notify 調(diào)試工具在動(dòng)畫序列編輯器里可以預(yù)覽 Notify 的觸發(fā)點(diǎn)在 PIE 里可以用ShowDebug Animation查看當(dāng)前活躍的 Notify在 Notify 回調(diào)里加UE_LOG輸出觸發(fā)時(shí)間和參數(shù)我習(xí)慣在開發(fā)階段給每個(gè) Notify 加日志上線前用宏關(guān)掉。這樣排查問題時(shí)不用重新加代碼。7.3 Notify 與 GameplayAbility 的配合如果你的項(xiàng)目用了 GameplayAbilitySystemNotify 可以作為觸發(fā) Ability 的入口。常見做法是在 Notify 里調(diào)用TryActivateAbility把動(dòng)畫和技能系統(tǒng)解耦。但要注意Ability 的激活有網(wǎng)絡(luò)延遲Notify 觸發(fā)時(shí) Ability 可能還沒準(zhǔn)備好。我的做法是在 Notify 里發(fā)一個(gè) GameplayEvent由 Ability 監(jiān)聽這個(gè)事件而不是直接激活 Ability。這樣更靈活也更好調(diào)試。7.4 版本升級(jí)時(shí) Notify 的兼容性UE5 從 EA 到正式版Notify 的 API 有過幾次調(diào)整。比如Notify函數(shù)的參數(shù)從USkeletalMeshComponent*變成了帶FAnimNotifyEventReference的版本。升級(jí)引擎版本時(shí)要檢查自定義 Notify 的簽名是否匹配。另外Notify 資產(chǎn)的序列化格式也可能變化。升級(jí)前備份動(dòng)畫資產(chǎn)升級(jí)后逐個(gè)檢查 Notify 是否正常。8. 從源碼延伸定制 Notify 系統(tǒng)的可能性8.1 自定義 Notify 的觸發(fā)條件引擎默認(rèn)的觸發(fā)條件是時(shí)間區(qū)間但你可以通過重寫FAnimNotifyEvent的相關(guān)函數(shù)來定制。比如基于角色狀態(tài)觸發(fā)只有在地面時(shí)才觸發(fā)基于輸入觸發(fā)只有玩家按下特定按鍵時(shí)才觸發(fā)基于概率觸發(fā)隨機(jī)決定是否觸發(fā)這些定制需要修改UAnimNotifyQueue的收集邏輯或者在 Notify 回調(diào)里做條件判斷。前者更徹底但改動(dòng)大后者更簡單但每個(gè) Notify 都要寫重復(fù)代碼。8.2 Notify 與動(dòng)畫通知窗口的結(jié)合UE5 引入了動(dòng)畫通知窗口Anim Notify Window允許在動(dòng)畫藍(lán)圖的特定狀態(tài)下啟用或禁用 Notify。這個(gè)功能在源碼里是通過FAnimNotifyEvent::bEnabled和動(dòng)畫藍(lán)圖的窗口狀態(tài)來控制的。如果你的項(xiàng)目有復(fù)雜的動(dòng)畫狀態(tài)切換通知窗口可以幫你精確控制 Notify 的生效范圍。比如只在“攻擊”狀態(tài)下啟用傷害 Notify其他狀態(tài)下自動(dòng)禁用。8.3 批量管理 Notify 的工具化思路項(xiàng)目大了之后Notify 數(shù)量會(huì)爆炸。手動(dòng)管理不現(xiàn)實(shí)需要工具化寫一個(gè)編輯器工具掃描所有動(dòng)畫序列列出 Notify 使用情況檢查重復(fù)的 Notify 配置合并冗余生成 Notify 使用報(bào)告方便 review這些工具可以用 Python 腳本或者 UE 的編輯器擴(kuò)展來實(shí)現(xiàn)。我寫過一個(gè)小工具能自動(dòng)檢測未使用的 Notify 資源清理后項(xiàng)目體積小了不少。9. 我個(gè)人在實(shí)際項(xiàng)目中的幾點(diǎn)體會(huì)做動(dòng)畫系統(tǒng)這些年Notify 是我用得最多也踩坑最多的模塊。最大的體會(huì)是不要把所有邏輯都塞進(jìn) Notify。Notify 適合做“動(dòng)畫驅(qū)動(dòng)的瞬時(shí)事件”不適合做“持續(xù)狀態(tài)管理”。狀態(tài)管理應(yīng)該交給 GameplayAbility 或者專門的組件Notify 只負(fù)責(zé)在正確的時(shí)機(jī)發(fā)出信號(hào)。另一個(gè)體會(huì)是網(wǎng)絡(luò)同步要提前設(shè)計(jì)。很多團(tuán)隊(duì)一開始不考慮多人等做到一半發(fā)現(xiàn) Notify 在客戶端和服務(wù)器行為不一致回頭改成本很高。我的建議是從第一個(gè) Notify 開始就明確它是表現(xiàn)類還是邏輯類按不同的同步策略處理。最后分享一個(gè)小技巧在動(dòng)畫序列編輯器里給重要的 Notify 加顏色標(biāo)記。UE5 支持自定義 Notify 的顯示顏色把傷害類標(biāo)紅、表現(xiàn)類標(biāo)藍(lán)、狀態(tài)類標(biāo)綠一眼就能看出動(dòng)畫里有哪些關(guān)鍵節(jié)點(diǎn)。這個(gè)習(xí)慣幫我省了很多溝通成本美術(shù)和策劃也能看懂動(dòng)畫里的邏輯分布。 UE5 Animation Notify 源碼深度解析：從觸發(fā)機(jī)制到網(wǎng)絡(luò)同步與性能優(yōu)化
1. 先搞清楚 Animation Notify 到底在游戲里扮演什么角色做 UE5 動(dòng)畫系統(tǒng)的朋友大概率都經(jīng)歷過這樣的場景角色揮刀到某一幀需要觸發(fā)傷害判定腳步落地那一瞬間要播放音效和粒子蓄力動(dòng)作到某個(gè)節(jié)點(diǎn)得讓角色進(jìn)入無敵狀態(tài)。這些“在動(dòng)畫播放到特定時(shí)刻做特定事情”的需求就是 Animation Notify 要解決的問題。Animation Notify中文一般叫動(dòng)畫通知是 UE5 動(dòng)畫系統(tǒng)中一套事件觸發(fā)機(jī)制。它允許你在動(dòng)畫序列的時(shí)間軸上打點(diǎn)當(dāng)動(dòng)畫播放到這些點(diǎn)時(shí)引擎會(huì)回調(diào)你注冊的函數(shù)執(zhí)行自定義邏輯。Anim Notify State 則是它的進(jìn)階形態(tài)區(qū)別在于 Notify 是瞬時(shí)觸發(fā)而 Notify State 有持續(xù)區(qū)間帶進(jìn)入和退出兩個(gè)回調(diào)。這套機(jī)制看起來簡單但真正用起來尤其是項(xiàng)目規(guī)模上去之后問題就來了為什么我的 Notify 在客戶端不觸發(fā)為什么 Notify State 的 Begin 和 End 順序亂了為什么動(dòng)畫藍(lán)圖里拿不到 Notify 的參數(shù)要回答這些問題光看文檔不夠得往源碼里鉆。這篇文章面向的是已經(jīng)會(huì)用 Notify 但想搞明白底層機(jī)制的中級(jí)開發(fā)者以及正在做動(dòng)畫系統(tǒng)架構(gòu)、需要定制 Notify 流程的高級(jí)開發(fā)者。我會(huì)從源碼層面拆解 Notify 和 Notify State 的注冊、觸發(fā)、同步、生命周期管理把那些文檔里不會(huì)寫的細(xì)節(jié)和踩坑經(jīng)驗(yàn)一并倒出來。全文基于 UE5 的動(dòng)畫系統(tǒng)源碼結(jié)構(gòu)展開涉及的具體類名和函數(shù)名都來自引擎源碼你可以對照著看。2. 源碼結(jié)構(gòu)總覽Notify 體系的核心類與繼承關(guān)系2.1 從 UAnimNotify 到 UAnimNotifyState 的類族譜打開 UE5 源碼動(dòng)畫通知相關(guān)的類主要集中在Engine/Source/Runtime/Engine/Classes/Animation/目錄下。核心類有這么幾個(gè)UAnimNotify瞬時(shí)通知的基類定義在AnimNotify.hUAnimNotifyState持續(xù)通知的基類定義在AnimNotifyState.hFAnimNotifyEvent動(dòng)畫序列中一條通知記錄的運(yùn)行時(shí)數(shù)據(jù)結(jié)構(gòu)定義在AnimTypes.hFAnimNotifyEventReference通知事件的引用包裝用于在上下文之間傳遞UAnimNotifyQueue通知隊(duì)列負(fù)責(zé)在動(dòng)畫更新時(shí)收集和分發(fā)通知繼承關(guān)系上UAnimNotify和UAnimNotifyState都直接繼承自UObject它們不是UAnimInstance的一部分而是獨(dú)立的資產(chǎn)對象。這一點(diǎn)很關(guān)鍵意味著 Notify 對象可以被多個(gè)動(dòng)畫序列共享也可以被動(dòng)畫藍(lán)圖引用。FAnimNotifyEvent則是另一條線它繼承自FAnimLinkableElement這個(gè)基類提供了與動(dòng)畫時(shí)間軸鏈接的能力。FAnimNotifyEvent里存了通知的觸發(fā)時(shí)間、持續(xù)時(shí)間、關(guān)聯(lián)的 Notify 對象指針、觸發(fā)條件等信息。動(dòng)畫序列在編譯時(shí)會(huì)把編輯器里配置的 Notify 數(shù)據(jù)轉(zhuǎn)換成FAnimNotifyEvent數(shù)組運(yùn)行時(shí)通過這個(gè)數(shù)組來驅(qū)動(dòng)通知。2.2 FAnimNotifyEvent 里到底存了什么FAnimNotifyEvent的字段比較多挑幾個(gè)關(guān)鍵的看// 簡化后的結(jié)構(gòu)示意 struct FAnimNotifyEvent : public FAnimLinkableElement { float TriggerTime; // 觸發(fā)時(shí)間秒 float Duration; // 持續(xù)時(shí)間Notify State 用 float EndTriggerTime; // 結(jié)束觸發(fā)時(shí)間 FName NotifyName; // 通知名稱 UAnimNotify* Notify; // 瞬時(shí)通知對象 UAnimNotifyState* NotifyState; // 持續(xù)通知對象 FGuid Guid; // 唯一標(biāo)識(shí) bool bTriggerOnDedicatedServer; // ... 還有一堆 };TriggerTime和Duration是核心。對于普通 NotifyDuration為 0只在TriggerTime觸發(fā)一次。對于 Notify StateDuration大于 0引擎會(huì)在TriggerTime調(diào)用NotifyBegin在TriggerTime Duration調(diào)用NotifyEnd。Guid這個(gè)字段容易被忽略但它在網(wǎng)絡(luò)同步和通知去重時(shí)非常重要。每個(gè) Notify 事件在編輯器里創(chuàng)建時(shí)都會(huì)分配一個(gè)唯一 Guid運(yùn)行時(shí)通過 Guid 來識(shí)別“這條通知是否已經(jīng)觸發(fā)過”。2.3 通知隊(duì)列 UAnimNotifyQueue 的職責(zé)UAnimNotifyQueue是運(yùn)行時(shí)通知分發(fā)的核心。它的工作流程大致是動(dòng)畫更新時(shí)FAnimInstanceProxy會(huì)調(diào)用UAnimNotifyQueue::AddAnimNotifies把當(dāng)前幀需要觸發(fā)的通知加入隊(duì)列隊(duì)列里存的是FAnimNotifyEventReference包含通知事件指針和來源上下文動(dòng)畫更新結(jié)束后UAnimNotifyQueue::Flush被調(diào)用遍歷隊(duì)列逐個(gè)執(zhí)行通知的Notify或NotifyState回調(diào)這個(gè)設(shè)計(jì)的好處是解耦通知的收集和分發(fā)分開方便在網(wǎng)絡(luò)環(huán)境下做預(yù)測和回滾。壞處是如果你在Notify回調(diào)里做了重操作會(huì)阻塞整個(gè)動(dòng)畫更新流程。注意UAnimNotifyQueue的 Flush 是在游戲線程執(zhí)行的不要在 Notify 回調(diào)里做耗時(shí)計(jì)算否則會(huì)拖慢整個(gè)動(dòng)畫系統(tǒng)。3. Notify 的觸發(fā)流程從動(dòng)畫更新到回調(diào)執(zhí)行3.1 動(dòng)畫更新時(shí)通知是怎么被收集的動(dòng)畫更新發(fā)生在FAnimInstanceProxy::UpdateAnimation里。具體到通知收集關(guān)鍵調(diào)用鏈?zhǔn)沁@樣的// 偽代碼示意 void FAnimInstanceProxy::UpdateAnimation(...) { // 1. 更新動(dòng)畫節(jié)點(diǎn)樹 // 2. 收集通知 if (NotifyQueue) { // 遍歷當(dāng)前活躍的動(dòng)畫序列 for (auto Sequence : ActiveSequences) { // 計(jì)算當(dāng)前幀時(shí)間區(qū)間 float PreviousTime ...; float CurrentTime ...; // 找出這個(gè)區(qū)間內(nèi)需要觸發(fā)的通知 for (auto NotifyEvent : Sequence-Notifies) { if (NotifyEvent.TriggerTime PreviousTime NotifyEvent.TriggerTime CurrentTime) { NotifyQueue-AddAnimNotify(NotifyEvent, ...); } } } } }這里有個(gè)細(xì)節(jié)時(shí)間區(qū)間的判斷用的是左閉右開[PreviousTime, CurrentTime)。這意味著如果動(dòng)畫時(shí)間正好停在某個(gè) Notify 的觸發(fā)點(diǎn)上它會(huì)在下一幀才觸發(fā)。這個(gè)設(shè)計(jì)是為了避免同一幀內(nèi)重復(fù)觸發(fā)但在做精確幀同步時(shí)要注意。3.2 Notify 回調(diào)的執(zhí)行順序與優(yōu)先級(jí)當(dāng)Flush被調(diào)用時(shí)隊(duì)列里的通知按什么順序執(zhí)行源碼里的邏輯是先按動(dòng)畫序列的層級(jí)排序同一序列內(nèi)按TriggerTime排序。如果兩個(gè) Notify 的TriggerTime相同則按它們在數(shù)組里的索引順序執(zhí)行。這個(gè)順序在大多數(shù)情況下夠用但如果你有多個(gè)動(dòng)畫序列同時(shí)播放比如上半身和下半身分開跨序列的通知順序就不那么直觀了。實(shí)測下來引擎會(huì)先處理主序列的通知再處理疊加序列的。如果你的邏輯依賴特定順序最好在 Notify 里加顯式的優(yōu)先級(jí)判斷而不是依賴引擎的默認(rèn)排序。3.3 Notify State 的 Begin 和 End 是怎么配對的Notify State 的生命周期管理比普通 Notify 復(fù)雜。引擎需要跟蹤每個(gè) Notify State 實(shí)例的狀態(tài)確保Begin和End正確配對。核心邏輯在FAnimInstanceProxy::TickAssetPlayer和UAnimNotifyQueue的交互里。大致流程是當(dāng)動(dòng)畫時(shí)間進(jìn)入 Notify State 的[TriggerTime, EndTriggerTime)區(qū)間時(shí)如果該 State 還沒被標(biāo)記為“活躍”則調(diào)用NotifyBegin并把它加入活躍列表當(dāng)動(dòng)畫時(shí)間離開這個(gè)區(qū)間時(shí)從活躍列表里移除調(diào)用NotifyEnd如果動(dòng)畫被中斷比如切換狀態(tài)引擎會(huì)遍歷活躍列表對所有未結(jié)束的 State 調(diào)用NotifyEnd這里有個(gè)坑如果動(dòng)畫被強(qiáng)制中斷NotifyEnd的調(diào)用時(shí)機(jī)是在下一幀的動(dòng)畫更新開始時(shí)而不是立即。這意味著在中斷的那一幀State 可能還處于“活躍”狀態(tài)。如果你的邏輯依賴 State 的結(jié)束來清理資源要考慮到這個(gè)延遲。// NotifyState 生命周期管理的簡化示意 void FAnimInstanceProxy::UpdateNotifyStates(float DeltaTime) { // 檢查所有活躍的 NotifyState for (int32 i ActiveNotifyStates.Num() - 1; i 0; --i) { FActiveNotifyState State ActiveNotifyStates[i]; // 判斷是否應(yīng)該結(jié)束 if (!State.IsInRange(CurrentTime)) { State.NotifyState-NotifyEnd(this, ...); ActiveNotifyStates.RemoveAt(i); } } // 檢查是否有新的 NotifyState 應(yīng)該開始 for (auto NotifyEvent : CurrentSequence-Notifies) { if (NotifyEvent.NotifyState NotifyEvent.IsInRange(CurrentTime) !IsAlreadyActive(NotifyEvent)) { NotifyEvent.NotifyState-NotifyBegin(this, ...); ActiveNotifyStates.Add({NotifyEvent, ...}); } } }3.4 網(wǎng)絡(luò)環(huán)境下 Notify 的同步策略多人游戲里Notify 的同步是個(gè)大話題。UE5 的默認(rèn)策略是Notify 在服務(wù)器和客戶端都會(huì)觸發(fā)但觸發(fā)時(shí)機(jī)可能不同。服務(wù)器在動(dòng)畫更新時(shí)觸發(fā)客戶端則依賴動(dòng)畫同步。關(guān)鍵字段是bTriggerOnDedicatedServer。如果設(shè)為 false這個(gè) Notify 只在客戶端觸發(fā)服務(wù)器不觸發(fā)。這個(gè)選項(xiàng)在純表現(xiàn)層的通知比如音效、粒子上很有用可以減輕服務(wù)器負(fù)擔(dān)。但要注意如果你的 Notify 涉及游戲邏輯比如傷害判定必須確保服務(wù)器和客戶端的觸發(fā)結(jié)果一致。常見做法是在 Notify 里調(diào)用一個(gè) RPC由服務(wù)器來裁決。不要直接在客戶端 Notify 里改游戲狀態(tài)否則會(huì)出現(xiàn)不同步。實(shí)操心得我一般會(huì)把 Notify 分成兩類——表現(xiàn)類音效、特效、鏡頭震動(dòng)和邏輯類傷害、狀態(tài)切換。表現(xiàn)類設(shè)bTriggerOnDedicatedServer false邏輯類保持 true并在回調(diào)里走服務(wù)器 RPC。這樣既省服務(wù)器性能又保證邏輯一致。4. 自定義 Notify 的完整實(shí)現(xiàn)流程4.1 創(chuàng)建自定義 Notify 類的正確姿勢在 UE5 里創(chuàng)建自定義 Notify有兩種方式C 和藍(lán)圖。C 方式更靈活適合復(fù)雜邏輯藍(lán)圖方式上手快適合簡單觸發(fā)。C 方式的步驟在項(xiàng)目里新建一個(gè)繼承自UAnimNotify的類重寫Notify函數(shù)在動(dòng)畫序列編輯器里右鍵時(shí)間軸添加 Notify選擇你的自定義類// 自定義 Notify 示例 UCLASS() class MYGAME_API UMyDamageNotify : public UAnimNotify { GENERATED_BODY() public: virtual void Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) override { // 獲取擁有者 AActor* Owner MeshComp-GetOwner(); if (!Owner) return; // 只在服務(wù)器執(zhí)行傷害邏輯 if (Owner-HasAuthority()) { // 執(zhí)行傷害判定 ApplyDamage(Owner); } } // 可選重寫 GetNotifyName 來定制編輯器里顯示的名字 virtual FString GetNotifyName_Implementation() const override { return TEXT(傷害判定); } };藍(lán)圖方式更簡單在動(dòng)畫序列編輯器里添加 Notify選擇“New Blueprint”創(chuàng)建然后在藍(lán)圖里實(shí)現(xiàn)Received_Notify事件。4.2 Notify 參數(shù)傳遞的幾種方式Notify 經(jīng)常需要參數(shù)比如傷害值、特效類型、音效資源。傳遞參數(shù)有幾種方式在 Notify 類里定義 UPROPERTY最直接在編輯器里配置運(yùn)行時(shí)讀取通過 EventReference 獲取上下文可以拿到動(dòng)畫序列、播放位置等信息通過 MeshComp 獲取 Owner 和組件適合需要訪問角色狀態(tài)的場景UCLASS() class MYGAME_API UMyEffectNotify : public UAnimNotify { GENERATED_BODY() public: // 在編輯器里配置的特效資源 UPROPERTY(EditAnywhere, Category Effect) UParticleSystem* EffectTemplate; UPROPERTY(EditAnywhere, Category Effect) FName SocketName; virtual void Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) override { if (!EffectTemplate || !MeshComp) return; // 在指定插槽位置生成特效 UGameplayStatics::SpawnEmitterAttached( EffectTemplate, MeshComp, SocketName ); } };注意UPROPERTY 標(biāo)記的資源引用會(huì)參與序列化如果 Notify 被多個(gè)動(dòng)畫共享改一處會(huì)影響所有引用。如果每個(gè)動(dòng)畫需要不同的參數(shù)建議用 Notify State 或者在動(dòng)畫藍(lán)圖里做映射。4.3 Notify State 的 Begin、Tick、End 三階段Notify State 有三個(gè)可重寫的函數(shù)NotifyBegin進(jìn)入?yún)^(qū)間時(shí)調(diào)用NotifyTick區(qū)間內(nèi)每幀調(diào)用NotifyEnd離開區(qū)間時(shí)調(diào)用UCLASS() class MYGAME_API UMyInvincibleState : public UAnimNotifyState { GENERATED_BODY() public: virtual void NotifyBegin(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float TotalDuration, const FAnimNotifyEventReference EventReference) override { // 進(jìn)入無敵狀態(tài) if (AActor* Owner MeshComp-GetOwner()) { Owner-SetInvincible(true); } } virtual void NotifyTick(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float FrameDeltaTime, const FAnimNotifyEventReference EventReference) override { // 每幀檢查可以在這里做持續(xù)效果 } virtual void NotifyEnd(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) override { // 退出無敵狀態(tài) if (AActor* Owner MeshComp-GetOwner()) { Owner-SetInvincible(false); } } };NotifyTick默認(rèn)不啟用需要在類里設(shè)置bTickNotify true或者在編輯器里勾選。啟用 Tick 會(huì)增加性能開銷只在確實(shí)需要每幀更新時(shí)開啟。4.4 在動(dòng)畫藍(lán)圖里監(jiān)聽 Notify 事件除了在 Notify 類里直接處理邏輯還可以在動(dòng)畫藍(lán)圖里監(jiān)聽 Notify 事件。方式是使用AnimNotify節(jié)點(diǎn)它會(huì)輸出一個(gè)執(zhí)行脈沖和 Notify 名稱。在動(dòng)畫藍(lán)圖的 Event Graph 里添加AnimNotify節(jié)點(diǎn)連接Received_Notify事件通過NotifyName判斷是哪個(gè)通知執(zhí)行對應(yīng)邏輯這種方式的好處是邏輯集中在動(dòng)畫藍(lán)圖里方便調(diào)試和修改。壞處是如果 Notify 很多事件圖會(huì)變得很亂。我的經(jīng)驗(yàn)是簡單的表現(xiàn)層邏輯放動(dòng)畫藍(lán)圖復(fù)雜的游戲邏輯放 C Notify 類。5. 常見問題與排查技巧實(shí)錄5.1 Notify 不觸發(fā)的排查清單Notify 不觸發(fā)是最常見的問題排查思路按優(yōu)先級(jí)排列排查項(xiàng)檢查方法常見原因動(dòng)畫是否在播放看動(dòng)畫藍(lán)圖的狀態(tài)機(jī)狀態(tài)機(jī)沒進(jìn)入該狀態(tài)Notify 是否在時(shí)間軸范圍內(nèi)檢查 TriggerTime時(shí)間軸被裁剪或 Notify 超出范圍是否被 Montage 覆蓋檢查 Montage 的 Notify 設(shè)置Montage 替換了序列的 Notify網(wǎng)絡(luò)角色是否正確檢查 bTriggerOnDedicatedServer服務(wù)器/客戶端設(shè)置反了動(dòng)畫是否被中斷看中斷邏輯中斷導(dǎo)致 Notify 被跳過通知隊(duì)列是否被清空檢查 Flush 調(diào)用手動(dòng)清空隊(duì)列導(dǎo)致丟失我踩過最坑的一次是Montage 里設(shè)置了bOverrideNotify把序列里的 Notify 全替換了但 Montage 本身沒配 Notify結(jié)果一個(gè)都不觸發(fā)。排查了半天才發(fā)現(xiàn)是 Montage 的覆蓋設(shè)置。5.2 Notify State 的 End 不執(zhí)行怎么辦Notify State 的NotifyEnd不執(zhí)行通常是因?yàn)閯?dòng)畫被強(qiáng)制中斷而中斷邏輯沒有正確處理活躍的 State。排查步驟確認(rèn)動(dòng)畫是否正常播放到 EndTriggerTime如果動(dòng)畫被中斷檢查中斷時(shí)是否調(diào)用了Montage_Stop或狀態(tài)切換在NotifyEnd里加日志確認(rèn)是否被調(diào)用檢查是否有多個(gè) State 嵌套導(dǎo)致生命周期混亂一個(gè)實(shí)用的技巧在NotifyBegin里記錄狀態(tài)在NotifyEnd里清理。如果擔(dān)心 End 不執(zhí)行可以在角色 Tick 里加一個(gè)兜底檢查超時(shí)后強(qiáng)制清理。// 兜底清理示例 void AMyCharacter::Tick(float DeltaTime) { Super::Tick(DeltaTime); // 檢查無敵狀態(tài)是否超時(shí) if (bIsInvincible InvincibleTimer MaxInvincibleTime) { SetInvincible(false); InvincibleTimer 0.0f; } }5.3 網(wǎng)絡(luò)同步下 Notify 重復(fù)觸發(fā)的處理多人游戲里Notify 重復(fù)觸發(fā)是個(gè)經(jīng)典問題。原因通常是服務(wù)器和客戶端都觸發(fā)了或者動(dòng)畫回滾導(dǎo)致重復(fù)觸發(fā)。解決方案用 Guid 做去重在 Notify 回調(diào)里檢查該 Guid 是否已處理過邏輯類 Notify 只在服務(wù)器執(zhí)行客戶端通過屬性同步獲取結(jié)果表現(xiàn)類 Notify 用bTriggerOnDedicatedServer false只在客戶端觸發(fā)// 去重示例 void UMyNotify::Notify(...) { if (ProcessedGuids.Contains(EventReference.GetNotifyGuid())) { return; // 已處理過跳過 } ProcessedGuids.Add(EventReference.GetNotifyGuid()); // 執(zhí)行邏輯 }實(shí)操心得去重集合要定期清理否則會(huì)無限增長。我一般在動(dòng)畫結(jié)束時(shí)清空或者用固定大小的環(huán)形緩沖。5.4 Notify 性能優(yōu)化的幾個(gè)切入點(diǎn)Notify 用多了會(huì)拖性能尤其是 Notify State 的 Tick。優(yōu)化方向關(guān)閉不必要的bTickNotify在 Notify 回調(diào)里避免復(fù)雜計(jì)算和內(nèi)存分配表現(xiàn)類 Notify 用對象池管理特效和音效批量處理相同類型的 Notify減少函數(shù)調(diào)用開銷實(shí)測數(shù)據(jù)一個(gè)角色身上同時(shí)有 20 個(gè) Notify State 在 Tick每幀額外開銷約 0.3ms。如果場景里有 50 個(gè)角色就是 15ms直接吃掉一幀的預(yù)算。所以能不用 Tick 就不用。6. 從源碼看 Notify 系統(tǒng)的設(shè)計(jì)取舍6.1 為什么 Notify 是獨(dú)立 UObject 而不是結(jié)構(gòu)體把 Notify 設(shè)計(jì)成 UObject 而不是結(jié)構(gòu)體核心考慮是復(fù)用和引用。UObject 可以被多個(gè)動(dòng)畫序列引用改一處配置所有引用處生效。如果做成結(jié)構(gòu)體每個(gè)動(dòng)畫序列都要存一份數(shù)據(jù)改起來麻煩內(nèi)存也浪費(fèi)。但這也帶來了問題Notify 對象是共享的運(yùn)行時(shí)修改它的屬性會(huì)影響所有引用。所以 Notify 的屬性應(yīng)該是只讀的配置運(yùn)行時(shí)狀態(tài)要存在別的地方比如角色身上。6.2 通知隊(duì)列的延遲執(zhí)行設(shè)計(jì)前面提到Notify 的收集和分發(fā)是分開的。這個(gè)設(shè)計(jì)的好處是可以在收集階段做過濾和排序可以在分發(fā)前做網(wǎng)絡(luò)預(yù)測和回滾方便調(diào)試可以打印隊(duì)列內(nèi)容壞處是增加了延遲Notify 從觸發(fā)到執(zhí)行中間隔了一個(gè) Flush 調(diào)用。在大多數(shù)情況下這個(gè)延遲可以忽略但在做精確幀同步時(shí)要注意。6.3 Notify State 的生命周期管理為什么容易出問題Notify State 的生命周期涉及多個(gè)狀態(tài)未激活、激活中、已結(jié)束。引擎用活躍列表來跟蹤但列表的維護(hù)依賴動(dòng)畫時(shí)間的正確更新。如果動(dòng)畫時(shí)間跳變比如快進(jìn)、回滾活躍列表可能和實(shí)際狀態(tài)不一致。源碼里的處理方式是每次更新時(shí)先檢查活躍列表里哪些應(yīng)該結(jié)束再檢查哪些應(yīng)該開始。這個(gè)順序很重要如果反過來可能出現(xiàn)同一個(gè) State 被重復(fù) Begin。注意如果你的項(xiàng)目有動(dòng)畫快進(jìn)或回滾需求要特別測試 Notify State 的行為。我遇到過回滾后 State 卡在激活狀態(tài)的問題最后是通過在回滾時(shí)強(qiáng)制清空活躍列表解決的。7. 幾個(gè)實(shí)戰(zhàn)中總結(jié)的避坑技巧7.1 Notify 命名規(guī)范與團(tuán)隊(duì)協(xié)作團(tuán)隊(duì)項(xiàng)目里Notify 命名要統(tǒng)一。我的建議是用前綴區(qū)分類型NS_表示 Notify StateN_表示普通 Notify用功能模塊做二級(jí)前綴N_Combat_Damage、NS_Movement_Invincible避免用中文或特殊字符雖然編輯器支持但跨平臺(tái)和版本管理容易出問題7.2 在編輯器里調(diào)試 Notify 的技巧UE5 編輯器提供了 Notify 調(diào)試工具在動(dòng)畫序列編輯器里可以預(yù)覽 Notify 的觸發(fā)點(diǎn)在 PIE 里可以用ShowDebug Animation查看當(dāng)前活躍的 Notify在 Notify 回調(diào)里加UE_LOG輸出觸發(fā)時(shí)間和參數(shù)我習(xí)慣在開發(fā)階段給每個(gè) Notify 加日志上線前用宏關(guān)掉。這樣排查問題時(shí)不用重新加代碼。7.3 Notify 與 GameplayAbility 的配合如果你的項(xiàng)目用了 GameplayAbilitySystemNotify 可以作為觸發(fā) Ability 的入口。常見做法是在 Notify 里調(diào)用TryActivateAbility把動(dòng)畫和技能系統(tǒng)解耦。但要注意Ability 的激活有網(wǎng)絡(luò)延遲Notify 觸發(fā)時(shí) Ability 可能還沒準(zhǔn)備好。我的做法是在 Notify 里發(fā)一個(gè) GameplayEvent由 Ability 監(jiān)聽這個(gè)事件而不是直接激活 Ability。這樣更靈活也更好調(diào)試。7.4 版本升級(jí)時(shí) Notify 的兼容性UE5 從 EA 到正式版Notify 的 API 有過幾次調(diào)整。比如Notify函數(shù)的參數(shù)從USkeletalMeshComponent*變成了帶FAnimNotifyEventReference的版本。升級(jí)引擎版本時(shí)要檢查自定義 Notify 的簽名是否匹配。另外Notify 資產(chǎn)的序列化格式也可能變化。升級(jí)前備份動(dòng)畫資產(chǎn)升級(jí)后逐個(gè)檢查 Notify 是否正常。8. 從源碼延伸定制 Notify 系統(tǒng)的可能性8.1 自定義 Notify 的觸發(fā)條件引擎默認(rèn)的觸發(fā)條件是時(shí)間區(qū)間但你可以通過重寫FAnimNotifyEvent的相關(guān)函數(shù)來定制。比如基于角色狀態(tài)觸發(fā)只有在地面時(shí)才觸發(fā)基于輸入觸發(fā)只有玩家按下特定按鍵時(shí)才觸發(fā)基于概率觸發(fā)隨機(jī)決定是否觸發(fā)這些定制需要修改UAnimNotifyQueue的收集邏輯或者在 Notify 回調(diào)里做條件判斷。前者更徹底但改動(dòng)大后者更簡單但每個(gè) Notify 都要寫重復(fù)代碼。8.2 Notify 與動(dòng)畫通知窗口的結(jié)合UE5 引入了動(dòng)畫通知窗口Anim Notify Window允許在動(dòng)畫藍(lán)圖的特定狀態(tài)下啟用或禁用 Notify。這個(gè)功能在源碼里是通過FAnimNotifyEvent::bEnabled和動(dòng)畫藍(lán)圖的窗口狀態(tài)來控制的。如果你的項(xiàng)目有復(fù)雜的動(dòng)畫狀態(tài)切換通知窗口可以幫你精確控制 Notify 的生效范圍。比如只在“攻擊”狀態(tài)下啟用傷害 Notify其他狀態(tài)下自動(dòng)禁用。8.3 批量管理 Notify 的工具化思路項(xiàng)目大了之后Notify 數(shù)量會(huì)爆炸。手動(dòng)管理不現(xiàn)實(shí)需要工具化寫一個(gè)編輯器工具掃描所有動(dòng)畫序列列出 Notify 使用情況檢查重復(fù)的 Notify 配置合并冗余生成 Notify 使用報(bào)告方便 review這些工具可以用 Python 腳本或者 UE 的編輯器擴(kuò)展來實(shí)現(xiàn)。我寫過一個(gè)小工具能自動(dòng)檢測未使用的 Notify 資源清理后項(xiàng)目體積小了不少。9. 我個(gè)人在實(shí)際項(xiàng)目中的幾點(diǎn)體會(huì)做動(dòng)畫系統(tǒng)這些年Notify 是我用得最多也踩坑最多的模塊。最大的體會(huì)是不要把所有邏輯都塞進(jìn) Notify。Notify 適合做“動(dòng)畫驅(qū)動(dòng)的瞬時(shí)事件”不適合做“持續(xù)狀態(tài)管理”。狀態(tài)管理應(yīng)該交給 GameplayAbility 或者專門的組件Notify 只負(fù)責(zé)在正確的時(shí)機(jī)發(fā)出信號(hào)。另一個(gè)體會(huì)是網(wǎng)絡(luò)同步要提前設(shè)計(jì)。很多團(tuán)隊(duì)一開始不考慮多人等做到一半發(fā)現(xiàn) Notify 在客戶端和服務(wù)器行為不一致回頭改成本很高。我的建議是從第一個(gè) Notify 開始就明確它是表現(xiàn)類還是邏輯類按不同的同步策略處理。最后分享一個(gè)小技巧在動(dòng)畫序列編輯器里給重要的 Notify 加顏色標(biāo)記。UE5 支持自定義 Notify 的顯示顏色把傷害類標(biāo)紅、表現(xiàn)類標(biāo)藍(lán)、狀態(tài)類標(biāo)綠一眼就能看出動(dòng)畫里有哪些關(guān)鍵節(jié)點(diǎn)。這個(gè)習(xí)慣幫我省了很多溝通成本美術(shù)和策劃也能看懂動(dòng)畫里的邏輯分布。