1. 項(xiàng)目概述為什么UE C Interface是解耦的利器在虛幻引擎UE的C開(kāi)發(fā)中我們經(jīng)常面臨一個(gè)經(jīng)典的設(shè)計(jì)難題如何讓兩個(gè)或多個(gè)原本沒(méi)有直接繼承關(guān)系的類能夠以一種靈活、低耦合的方式進(jìn)行通信和交互比如一個(gè)PlayerCharacter玩家角色需要攻擊一個(gè)Enemy敵人同時(shí)也可能需要攻擊一個(gè)DestructibleBox可破壞的箱子。按照傳統(tǒng)的繼承思路我們可能會(huì)讓Enemy和DestructibleBox都繼承自一個(gè)共同的Attackable基類。但這會(huì)迅速導(dǎo)致類繼承樹(shù)的膨脹和僵化特別是當(dāng)Enemy和DestructibleBox本身已經(jīng)屬于不同的、復(fù)雜的繼承體系時(shí)強(qiáng)行修改基類往往是災(zāi)難性的。這時(shí)UE C Interface接口就登場(chǎng)了。它不是一個(gè)具體的類而是一份“契約”或“能力聲明”。任何類無(wú)論它原本的父類是誰(shuí)只要它“簽署”了這份契約即實(shí)現(xiàn)了這個(gè)接口就承諾自己擁有接口中定義的那套方法。對(duì)于上面的例子我們可以定義一個(gè)IDamageable可受傷接口里面聲明一個(gè)TakeDamage函數(shù)。然后讓Enemy類、DestructibleBox類甚至未來(lái)的NPC非玩家角色類都去實(shí)現(xiàn)這個(gè)IDamageable接口。這樣PlayerCharacter的武器系統(tǒng)就只需要關(guān)心“我擊中的目標(biāo)是否實(shí)現(xiàn)了IDamageable接口”如果是就調(diào)用它的TakeDamage方法完全不用關(guān)心目標(biāo)具體是怪物、箱子還是別的什么東西。這種設(shè)計(jì)帶來(lái)的核心好處是解耦和可擴(kuò)展性。系統(tǒng)各部分之間依賴的是抽象的接口而非具體的實(shí)現(xiàn)。新增一種可被攻擊的對(duì)象比如一個(gè)Robot你只需要讓這個(gè)新類實(shí)現(xiàn)IDamageable接口即可無(wú)需修改攻擊者的代碼。這對(duì)于大型項(xiàng)目、插件開(kāi)發(fā)以及團(tuán)隊(duì)協(xié)作來(lái)說(shuō)至關(guān)重要它能顯著降低代碼的維護(hù)成本提升架構(gòu)的清晰度。如果你是從藍(lán)圖轉(zhuǎn)向C或者習(xí)慣了傳統(tǒng)C的虛函數(shù)多態(tài)那么掌握UE特有的Interface實(shí)現(xiàn)方式將是你在UE中編寫(xiě)高質(zhì)量、可維護(hù)代碼的關(guān)鍵一步。2. Interface的核心概念與UE實(shí)現(xiàn)機(jī)制2.1 接口的本質(zhì)一份“能力”契約在面向?qū)ο缶幊讨薪涌诘暮诵乃枷胧嵌x一組行為規(guī)范而不關(guān)心具體由誰(shuí)、以何種方式實(shí)現(xiàn)這些行為。在純C中我們通常使用只包含純虛函數(shù)的抽象類來(lái)模擬接口。然而UE在此基礎(chǔ)上構(gòu)建了一套更強(qiáng)大、與引擎反射系統(tǒng)深度集成的接口機(jī)制。UE的接口不僅能在C層面使用還能無(wú)縫暴露給藍(lán)圖系統(tǒng)這意味著設(shè)計(jì)師可以在藍(lán)圖中實(shí)現(xiàn)C定義的接口或者調(diào)用實(shí)現(xiàn)了某個(gè)接口的對(duì)象的功能。這是UE Interface相比純C抽象類最大的優(yōu)勢(shì)之一。為了實(shí)現(xiàn)這一點(diǎn)UE的接口本身也是一個(gè)特殊的UClass它通過(guò)一套以U和I為前綴的宏與反射系統(tǒng)進(jìn)行綁定。一個(gè)典型的UE接口類由兩部分組成一個(gè)是普通的C類通常以I開(kāi)頭用于在C代碼中聲明函數(shù)另一個(gè)是與之關(guān)聯(lián)的UInterface它負(fù)責(zé)處理UE對(duì)象模型、反射和藍(lán)圖交互的底層邏輯。當(dāng)你使用UINTERFACE宏時(shí)你生成的是一個(gè)UClass它不包含你的業(yè)務(wù)邏輯而是引擎用來(lái)識(shí)別“這個(gè)類是一個(gè)接口”的元數(shù)據(jù)。而與之配對(duì)的、以I開(kāi)頭的類才是你編寫(xiě)函數(shù)聲明的地方。2.2 UINTERFACE與IInterface的配對(duì)關(guān)系理解UINTERFACE和IInterface的配對(duì)是掌握UE接口的第一步。我們通過(guò)一個(gè)最簡(jiǎn)單的例子來(lái)看// 在頭文件 DamageableInterface.h 中 #pragma once #include “UObject/Interface.h” #include “DamageableInterface.generated.h” // 這是給UE反射系統(tǒng)用的“殼”不包含函數(shù)聲明。 UINTERFACE(MinimalAPI, Blueprintable) class UDamageableInterface : public UInterface { GENERATED_BODY() }; // 這才是我們真正使用的接口類在這里聲明接口函數(shù)。 class IDamageableInterface { GENERATED_BODY() public: // 聲明一個(gè)藍(lán)圖可調(diào)用、可覆蓋的接口函數(shù)。 UFUNCTION(BlueprintNativeEvent, BlueprintCallable, Category “Damage”) void TakeDamage(float DamageAmount, class AController* EventInstigator, AActor* DamageCauser); };我們來(lái)拆解一下UINTERFACE宏它聲明了UDamageableInterface類。這個(gè)類繼承自UInterface并且體內(nèi)部只有GENERATED_BODY()宏。MinimalAPI是一個(gè)重要的元數(shù)據(jù)它意味著這個(gè)接口的反射信息只在當(dāng)前模塊內(nèi)被完整導(dǎo)出其他模塊只能以IInterface指針的形式使用它這有助于縮短編譯時(shí)間。Blueprintable則表明這個(gè)接口可以在藍(lán)圖中被實(shí)現(xiàn)。IInterface類這里聲明了真正的接口函數(shù)TakeDamage。注意它使用了UFUNCTION宏并且指定了BlueprintNativeEvent和BlueprintCallable。BlueprintNativeEvent意味著這個(gè)函數(shù)在C中有一個(gè)默認(rèn)實(shí)現(xiàn)后綴為_(kāi)Implementation同時(shí)也可以在藍(lán)圖中被覆蓋。GENERATED_BODY()在這里同樣必不可少它確保了接口函數(shù)與反射系統(tǒng)的連接。這種“一體兩面”的設(shè)計(jì)是UE為了兼顧C(jī)運(yùn)行時(shí)效率和藍(lán)圖可視化腳本靈活性而采用的經(jīng)典模式。在代碼中我們幾乎總是使用IDamageableInterface*這樣的指針來(lái)引用接口。2.3 接口函數(shù)聲明與“_Implementation”后綴約定在UE中聲明一個(gè)接口函數(shù)有其特定的規(guī)則尤其是當(dāng)它需要同時(shí)支持C默認(rèn)實(shí)現(xiàn)和藍(lán)圖覆蓋時(shí)。以上面的TakeDamage為例它的完整實(shí)現(xiàn)通常如下// 在頭文件 DamageableInterface.h 中的 IDamageableInterface 類內(nèi) UFUNCTION(BlueprintNativeEvent, BlueprintCallable, Category “Damage”) void TakeDamage(float DamageAmount, AController* EventInstigator, AActor* DamageCauser); // 在源文件 DamageableInterface.cpp 中如果需要默認(rèn)實(shí)現(xiàn) void IDamageableInterface::TakeDamage_Implementation(float DamageAmount, AController* EventInstigator, AActor* DamageCauser) { // 這里提供一個(gè)空的或基礎(chǔ)的默認(rèn)實(shí)現(xiàn)。 // 例如可以打印一條日志或者扣除一個(gè)默認(rèn)的生命值屬性如果接口知道的話。 UE_LOG(LogTemp, Warning, TEXT(“%s took %f damage.”), *GetNameSafe(CastUObject(this)), DamageAmount); }關(guān)鍵點(diǎn)在于_Implementation后綴。當(dāng)你在接口類中使用BlueprintNativeEvent聲明一個(gè)函數(shù)Foo時(shí)編譯器會(huì)期望存在一個(gè)Foo_Implementation函數(shù)作為其C默認(rèn)實(shí)現(xiàn)。在調(diào)用端你不能直接調(diào)用Foo_Implementation而是調(diào)用Foo。UE的底層機(jī)制會(huì)自動(dòng)判斷如果該對(duì)象是C對(duì)象且沒(méi)有重寫(xiě)Foo則路由到Foo_Implementation如果該對(duì)象是藍(lán)圖對(duì)象或在C中重寫(xiě)了Foo則路由到相應(yīng)的重寫(xiě)版本。注意BlueprintNativeEvent函數(shù)必須有一個(gè)_Implementation版本的函數(shù)體即使它是空的。否則在鏈接時(shí)可能會(huì)報(bào)錯(cuò)。如果你確定這個(gè)接口函數(shù)不應(yīng)該有默認(rèn)實(shí)現(xiàn)即所有實(shí)現(xiàn)者都必須自己實(shí)現(xiàn)可以考慮使用BlueprintImplementableEvent它沒(méi)有C默認(rèn)實(shí)現(xiàn)也無(wú)需_Implementation函數(shù)。3. 實(shí)現(xiàn)接口賦予類特定的“能力”3.1 在C類中實(shí)現(xiàn)接口讓一個(gè)C類實(shí)現(xiàn)接口非常簡(jiǎn)單主要分為兩步在類聲明中指定以及為接口函數(shù)提供實(shí)現(xiàn)。首先在類的頭文件中使用UCLASS宏的Implements元數(shù)據(jù)或者在繼承列表中直接添加接口類。Implements是更現(xiàn)代和推薦的方式。// 在 Enemy.h 中 UCLASS() class AMyEnemy : public ACharacter, public IDamageableInterface // 方式一直接繼承 { GENERATED_BODY() // ... 其他代碼 }; // 或者更推薦使用 Implements 元數(shù)據(jù)對(duì)于Actor組件或其他情況尤其清晰 UCLASS(ImplementsInterface DamageableInterface) // 方式二使用元數(shù)據(jù) class AMyDestructibleBox : public AActor { GENERATED_BODY() // ... 其他代碼 };然后在類的源文件中你需要提供接口函數(shù)的具體實(shí)現(xiàn)。注意你實(shí)現(xiàn)的是帶_Implementation后綴的函數(shù)。// 在 Enemy.cpp 中 #include “DamageableInterface.h” void AMyEnemy::TakeDamage_Implementation(float DamageAmount, AController* EventInstigator, AActor* DamageCauser) { // 1. 減少生命值 CurrentHealth - DamageAmount; UE_LOG(LogTemp, Log, TEXT(“Enemy %s took %f damage from %s. Health: %f”), *GetName(), DamageAmount, *GetNameSafe(DamageCauser), CurrentHealth); // 2. 播放受擊動(dòng)畫(huà)或音效如果存在 if (HitAnimation) { PlayAnimMontage(HitAnimation); } // 3. 判斷死亡 if (CurrentHealth 0.0f) { Die(EventInstigator, DamageCauser); } }對(duì)于ImplementsInterface方式實(shí)現(xiàn)完全一樣。UE的反射系統(tǒng)會(huì)知道AMyDestructibleBox類實(shí)現(xiàn)了IDamageableInterface接口。3.2 在藍(lán)圖中實(shí)現(xiàn)接口這是UE接口強(qiáng)大之處的一個(gè)直觀體現(xiàn)。設(shè)計(jì)師無(wú)需觸碰C代碼就可以讓一個(gè)藍(lán)圖類擁有某種能力。在藍(lán)圖編輯器中創(chuàng)建一個(gè)新的藍(lán)圖類例如基于Actor的BP_ExplosiveBarrel。在“類設(shè)置”Class Settings面板中找到“接口”Interfaces部分。點(diǎn)擊“添加”Add按鈕搜索并選擇你在C中定義的接口例如DamageableInterface。添加后在藍(lán)圖的“事件圖表”Event Graph中右鍵搜索你會(huì)發(fā)現(xiàn)多出了一個(gè)新的事件“事件 Take Damage”Event Take Damage。這是一個(gè)藍(lán)圖定義的事件它對(duì)應(yīng)著接口中的BlueprintNativeEvent函數(shù)。你可以像處理其他事件一樣對(duì)這個(gè)事件進(jìn)行連線實(shí)現(xiàn)受傷害的邏輯比如播放粒子特效、生成掉落物等。實(shí)操心得在藍(lán)圖中實(shí)現(xiàn)接口函數(shù)時(shí)函數(shù)名和參數(shù)列表會(huì)自動(dòng)與C接口定義同步。如果C中修改了接口函數(shù)比如增加了一個(gè)參數(shù)所有實(shí)現(xiàn)了該接口的藍(lán)圖在編譯時(shí)都會(huì)報(bào)錯(cuò)并提示需要更新節(jié)點(diǎn)。這是一個(gè)非常好的契約維護(hù)機(jī)制能及時(shí)發(fā)現(xiàn)接口變更造成的影響。3.3 多重接口與實(shí)現(xiàn)沖突處理一個(gè)類可以實(shí)現(xiàn)多個(gè)接口這賦予了它多種不同的“角色”或“能力”。例如一個(gè)AdvancedEnemy類可以同時(shí)實(shí)現(xiàn)IDamageableInterface可受傷和IInteractableInterface可交互。UCLASS(ImplementsInterface {DamageableInterface, InteractableInterface}) class AMyAdvancedEnemy : public ACharacter { GENERATED_BODY() // ... 實(shí)現(xiàn)兩個(gè)接口的所有函數(shù) };當(dāng)多個(gè)接口包含同名函數(shù)時(shí)就會(huì)發(fā)生沖突。在純C中這需要通過(guò)顯式限定或重命名來(lái)解決。但在UE的接口系統(tǒng)中由于每個(gè)接口函數(shù)最終都是通過(guò)其所屬的UInterface元數(shù)據(jù)來(lái)查找和調(diào)用的所以同名函數(shù)不會(huì)引起編譯沖突。不過(guò)這帶來(lái)了語(yǔ)義上的模糊一個(gè)AMyAdvancedEnemy對(duì)象如果同時(shí)被當(dāng)作IDamageableInterface和IInteractableInterface而它們都有一個(gè)Execute函數(shù)那么調(diào)用哪個(gè)實(shí)際上在調(diào)用時(shí)你必須通過(guò)某個(gè)具體的接口指針來(lái)調(diào)用函數(shù)。引擎會(huì)根據(jù)你用來(lái)進(jìn)行函數(shù)調(diào)用的那個(gè)接口“視圖”來(lái)決定執(zhí)行哪個(gè)實(shí)現(xiàn)。通常一個(gè)類會(huì)為它實(shí)現(xiàn)的每個(gè)接口的同名函數(shù)提供同一個(gè)實(shí)現(xiàn)即只有一個(gè)Execute_Implementation函數(shù)體。如果你真的需要為不同接口提供不同行為可能需要重新思考接口設(shè)計(jì)或者在該實(shí)現(xiàn)函數(shù)內(nèi)部根據(jù)調(diào)用者的類型進(jìn)行分支判斷但這通常不是好的設(shè)計(jì)。4. 查詢與調(diào)用接口安全地使用“能力”4.1 判斷對(duì)象是否實(shí)現(xiàn)了接口在嘗試調(diào)用接口方法前必須先檢查對(duì)象是否支持該接口。這是避免運(yùn)行時(shí)崩潰的關(guān)鍵。UE提供了多種方法1.Cast轉(zhuǎn)換這是最直接、在C中最常用的方法。Cast不僅會(huì)檢查是否實(shí)現(xiàn)了接口還會(huì)在成功時(shí)返回一個(gè)類型正確的接口指針。void AMyWeapon::OnHit(AActor* HitActor) { // 嘗試將HitActor轉(zhuǎn)換為IDamageableInterface指針 if (IDamageableInterface* DamageableTarget CastIDamageableInterface(HitActor)) { // 轉(zhuǎn)換成功說(shuō)明HitActor實(shí)現(xiàn)了該接口 DamageableTarget-TakeDamage(BaseDamage, GetInstigatorController(), this); } else { // 轉(zhuǎn)換失敗HitActor不可被傷害 UE_LOG(LogTemp, Verbose, TEXT(“%s is not damageable.”), *GetNameSafe(HitActor)); } }2.Implements函數(shù)當(dāng)你不需要調(diào)用接口方法只需要做布爾判斷時(shí)可以使用Implements函數(shù)。它比Cast稍微輕量一點(diǎn)。if (HitActor HitActor-ImplementsUDamageableInterface()) // 注意這里用的是UInterface類 { // 對(duì)象實(shí)現(xiàn)了接口 }3. 藍(lán)圖節(jié)點(diǎn)在藍(lán)圖中有專門(mén)的節(jié)點(diǎn)來(lái)檢查接口和調(diào)用接口函數(shù)?！癉oes Implement Interface”判斷一個(gè)對(duì)象是否實(shí)現(xiàn)了指定接口?！癈ast to XXX Interface”類似于C的Cast失敗會(huì)觸發(fā)“未實(shí)現(xiàn)”的執(zhí)行流。注意事項(xiàng)在性能敏感的循環(huán)中如果只需要做存在性檢查Implements可能略優(yōu)于Cast因?yàn)镃ast在成功時(shí)還需要構(gòu)造一個(gè)智能指針。但絕大多數(shù)情況下兩者的差異可以忽略不計(jì)使用Cast并直接獲得可用的指針是更常見(jiàn)的做法。4.2 調(diào)用接口函數(shù)一旦確認(rèn)對(duì)象實(shí)現(xiàn)了接口調(diào)用函數(shù)就很簡(jiǎn)單了。對(duì)于聲明為BlueprintNativeEvent的函數(shù)你直接調(diào)用其函數(shù)名即可引擎會(huì)自動(dòng)處理是調(diào)用C默認(rèn)實(shí)現(xiàn)還是藍(lán)圖/子類重寫(xiě)。// 接上面的Cast成功后的代碼 DamageableTarget-TakeDamage(BaseDamage, GetInstigatorController(), this);這里調(diào)用的TakeDamage并不是你之前實(shí)現(xiàn)的TakeDamage_Implementation。它是一個(gè)由UE代碼生成器創(chuàng)建的“分發(fā)”函數(shù)內(nèi)部邏輯會(huì)決定最終調(diào)用TakeDamage_ImplementationC默認(rèn)實(shí)現(xiàn)還是藍(lán)圖實(shí)現(xiàn)。對(duì)于純虛函數(shù)無(wú)默認(rèn)實(shí)現(xiàn)如果接口函數(shù)在C端被聲明為純虛函數(shù)沒(méi)有BlueprintNativeEvent和_Implementation那么實(shí)現(xiàn)該接口的C類必須直接覆蓋這個(gè)函數(shù)。調(diào)用方式不變。// 在接口中 virtual void PerformAction() 0; // 在實(shí)現(xiàn)類中 virtual void PerformAction() override; // 調(diào)用 MyInterfacePtr-PerformAction();4.3 獲取接口的UClass與藍(lán)圖交互有時(shí)我們需要在運(yùn)行時(shí)獲取接口對(duì)應(yīng)的UClass例如用于動(dòng)態(tài)生成或類型過(guò)濾。由于接口本身也是一個(gè)UClass我們可以這樣做UClass* DamageableInterfaceClass UDamageableInterface::StaticClass();在編輯器中比如在數(shù)據(jù)表Data Table里定義一個(gè)列希望這列只能選擇實(shí)現(xiàn)了特定接口的類就可以使用Meta(MustImplement”DamageableInterface”)這樣的元數(shù)據(jù)。在藍(lán)圖中接口可以作為類型引腳Pin出現(xiàn)。例如一個(gè)函數(shù)的參數(shù)可以定義為“Damageable Interface”類型這樣任何實(shí)現(xiàn)了該接口的對(duì)象都可以連接進(jìn)來(lái)極大地增加了藍(lán)圖的靈活性和復(fù)用性。5. 高級(jí)應(yīng)用與設(shè)計(jì)模式5.1 接口與事件分發(fā)Delegate的結(jié)合接口和委托Delegate是UE中兩種強(qiáng)大的解耦工具它們經(jīng)常結(jié)合使用形成一種松耦合的觀察者模式或事件驅(qū)動(dòng)架構(gòu)。設(shè)想一個(gè)場(chǎng)景一個(gè)QuestSystem任務(wù)系統(tǒng)需要通知多個(gè)不同類型的對(duì)象UI、音效管理器、成就系統(tǒng)任務(wù)狀態(tài)更新。讓任務(wù)系統(tǒng)直接持有所有這些具體類型的引用是緊耦合的。更好的做法是定義一個(gè)IQuestListener接口里面有一個(gè)OnQuestUpdated函數(shù)。然后讓UI、音效管理器等各自實(shí)現(xiàn)這個(gè)接口。任務(wù)系統(tǒng)只需要維護(hù)一個(gè)TArrayIQuestListener*列表在任務(wù)更新時(shí)遍歷列表調(diào)用OnQuestUpdated即可。// 定義接口 UINTERFACE() class UQuestListenerInterface : public UInterface { ... }; class IQuestListenerInterface { ... public: virtual void OnQuestUpdated(const FQuest Quest) 0; }; // 任務(wù)系統(tǒng) void UQuestSystem::AddListener(IQuestListenerInterface* Listener) { Listeners.Add(Listener); } void UQuestSystem::CompleteQuest(FQuestID QuestID) { // ... 完成任務(wù)邏輯 for (auto* Listener : Listeners) { Listener-OnQuestUpdated(UpdatedQuest); } }更進(jìn)一步我們可以用多播委托Multicast Delegate來(lái)替代手動(dòng)管理的監(jiān)聽(tīng)者列表這樣連遍歷調(diào)用都省了接口實(shí)現(xiàn)者只需要訂閱委托即可。這種“接口定義事件委托廣播事件”的模式在UE插件和模塊化設(shè)計(jì)中非常普遍。5.2 接口作為T(mén)SubclassOf和TSoftClassPtr的約束在定義可配置的類引用時(shí)我們經(jīng)常使用TSubclassOf來(lái)限制選擇范圍。結(jié)合接口我們可以做出更精確的約束。UPROPERTY(EditDefaultsOnly, Category “Gameplay”) TSubclassOfAActor SpawnActorClass; // 可以選任何Actor類 UPROPERTY(EditDefaultsOnly, Category “Gameplay”, Meta (MustImplement “DamageableInterface”)) TSubclassOfAActor SpawnDamageableActorClass; // 只能選實(shí)現(xiàn)了DamageableInterface的Actor類在編輯器下拉菜單中SpawnDamageableActorClass只會(huì)列出那些實(shí)現(xiàn)了IDamageableInterface的AActor派生類這避免了配置錯(cuò)誤。TSoftClassPtr軟類引用也支持同樣的MustImplement元數(shù)據(jù)用于異步加載時(shí)的類型安全。5.3 在數(shù)據(jù)資產(chǎn)Data Asset和表格Data Table中使用接口數(shù)據(jù)驅(qū)動(dòng)的設(shè)計(jì)是UE的強(qiáng)項(xiàng)。我們可以在數(shù)據(jù)資產(chǎn)或數(shù)據(jù)表中定義一些字段要求其引用的類必須實(shí)現(xiàn)某個(gè)接口。例如在一個(gè)LootDropTable戰(zhàn)利品掉落表中我們定義一種掉落物它必須是一個(gè)可以“被拾取”的Actor。我們可以創(chuàng)建一個(gè)FPickupLootEntry結(jié)構(gòu)體USTRUCT() struct FPickupLootEntry { GENERATED_BODY() UPROPERTY(EditAnywhere) TSubclassOfAActor PickupActorClass; // 使用接口作為T(mén)ag不直接用于邏輯但用于編輯器和數(shù)據(jù)驗(yàn)證 UPROPERTY(EditAnywhere, Meta (MustImplement “PickupInterface”)) TSubclassOfAActor PickupActorClass_Safe; // 這個(gè)更安全 UPROPERTY(EditAnywhere) float DropChance 0.5f; };這樣策劃人員在數(shù)據(jù)表中配置時(shí)如果錯(cuò)誤地選擇了一個(gè)不能拾取的Actor類編輯器會(huì)給出警告或直接過(guò)濾掉保證了數(shù)據(jù)配置的有效性。5.4 接口與Gameplay Ability System (GAS) 的協(xié)同在UE的Gameplay Ability System中接口扮演著至關(guān)重要的角色。GAS的核心類AbilitySystemComponent,GameplayAbility,GameplayEffect之間通常不直接互相引用而是通過(guò)接口進(jìn)行通信。例如一個(gè)GameplayEffect需要修改目標(biāo)的屬性。它并不關(guān)心目標(biāo)具體是Character還是Vehicle它只關(guān)心目標(biāo)是否實(shí)現(xiàn)了IGameplayEffectAggregatorInterface實(shí)際上GAS內(nèi)部有類似的機(jī)制。同樣一個(gè)GameplayAbility觸發(fā)時(shí)可能需要判斷目標(biāo)是否具有某種“標(biāo)簽”Tag或?qū)崿F(xiàn)了某個(gè)接口如ICrowdControlable可被控制來(lái)決定能力是否生效。你可以自定義接口來(lái)擴(kuò)展GAS。比如創(chuàng)建一個(gè)ICombatUnitInterface里面定義GetAttackRange()、GetTeam()等方法。那么你的UGameplayAbility_Attack就可以通過(guò)這個(gè)接口來(lái)獲取攻擊者的數(shù)據(jù)而不需要綁定到具體的AMyCharacter類上使得這套攻擊能力可以復(fù)用于玩家、AI、甚至塔防建筑等任何實(shí)現(xiàn)了該接口的對(duì)象。6. 性能考量、調(diào)試與最佳實(shí)踐6.1 接口調(diào)用的開(kāi)銷分析相比于直接調(diào)用類的虛函數(shù)通過(guò)接口指針進(jìn)行調(diào)用會(huì)多一層開(kāi)銷。這層開(kāi)銷主要來(lái)自于UE的反射系統(tǒng)因?yàn)榻涌谡{(diào)用需要?jiǎng)討B(tài)查找正確的函數(shù)實(shí)現(xiàn)尤其是處理BlueprintNativeEvent時(shí)需要判斷是調(diào)用C實(shí)現(xiàn)還是藍(lán)圖實(shí)現(xiàn)。對(duì)于BlueprintImplementableEvent開(kāi)銷會(huì)更大一些因?yàn)樗耆蕾囉谒{(lán)圖虛擬機(jī)。然而在絕大多數(shù)游戲邏輯中這種開(kāi)銷是微不足道的完全不需要擔(dān)心。只有在每幀對(duì)成千上萬(wàn)個(gè)對(duì)象進(jìn)行接口調(diào)用的極端性能熱點(diǎn)處才需要考慮優(yōu)化。優(yōu)化手段包括批量處理避免在每幀對(duì)大量對(duì)象進(jìn)行單獨(dú)的接口查詢和調(diào)用。緩存結(jié)果如果某個(gè)對(duì)象是否實(shí)現(xiàn)接口的狀態(tài)不會(huì)改變可以將Cast的結(jié)果緩存起來(lái)而不是每次查詢。直接調(diào)用在絕對(duì)確定類型且性能至關(guān)重要的地方可以考慮使用直接的非虛函數(shù)調(diào)用或靜態(tài)函數(shù)但這犧牲了靈活性應(yīng)謹(jǐn)慎使用。實(shí)操心得不要過(guò)早優(yōu)化。先使用清晰、解耦的接口設(shè)計(jì)把功能做出來(lái)。只有在性能分析工具如UE內(nèi)置的Profiler明確顯示接口調(diào)用成為瓶頸時(shí)再去考慮針對(duì)性的優(yōu)化?？删S護(hù)的代碼遠(yuǎn)比微小的性能提升重要。6.2 調(diào)試接口相關(guān)的問(wèn)題接口相關(guān)的常見(jiàn)問(wèn)題主要有兩類調(diào)用失敗和函數(shù)實(shí)現(xiàn)未生效。調(diào)用失敗Cast返回nullptr檢查對(duì)象類型首先確認(rèn)你嘗試轉(zhuǎn)換的對(duì)象指針不是nullptr。檢查接口實(shí)現(xiàn)在編輯器中選中該對(duì)象的藍(lán)圖或C類查看其“類詳情”Class Details面板確認(rèn)“已實(shí)現(xiàn)的接口”Implemented Interfaces列表中包含目標(biāo)接口。檢查拼寫(xiě)和模塊依賴確保調(diào)用方代碼#include了接口的頭文件并且項(xiàng)目構(gòu)建Build正確。模塊間的接口使用要確保依賴關(guān)系正確。函數(shù)實(shí)現(xiàn)未生效調(diào)用了默認(rèn)實(shí)現(xiàn)而非重寫(xiě)實(shí)現(xiàn)藍(lán)圖覆蓋檢查如果是在藍(lán)圖中覆蓋接口函數(shù)請(qǐng)確保事件節(jié)點(diǎn)正確連接并且沒(méi)有啟用“上下文相關(guān)”Context Sensitive等可能阻止其執(zhí)行的條件。C重寫(xiě)檢查在C中重寫(xiě)_Implementation函數(shù)確保函數(shù)簽名返回值、參數(shù)、const修飾完全一致并且使用了override關(guān)鍵字雖然不是必須但有助于編譯器檢查。使用調(diào)試器在C調(diào)試器中在接口函數(shù)和其_Implementation函數(shù)內(nèi)設(shè)置斷點(diǎn)觀察執(zhí)行流程。也可以使用UE_LOG在兩者中都打印日志看哪個(gè)被觸發(fā)。一個(gè)有用的調(diào)試技巧是在接口的默認(rèn)實(shí)現(xiàn)_Implementation中添加一條顯眼的日志或確保它有一個(gè)不會(huì)錯(cuò)過(guò)的行為比如將角色染成亮粉色這樣如果調(diào)用了默認(rèn)實(shí)現(xiàn)你就能立刻發(fā)現(xiàn)。6.3 接口設(shè)計(jì)的最佳實(shí)踐與常見(jiàn)陷阱保持接口小巧、專注一個(gè)接口應(yīng)該只定義一組緊密相關(guān)的方法。遵循“接口隔離原則”。不要?jiǎng)?chuàng)建一個(gè)龐大的IGameEntity接口把移動(dòng)、攻擊、庫(kù)存所有方法都塞進(jìn)去。應(yīng)該拆分成IMovable、IAttackable、IInventoryHolder等多個(gè)小接口。以“能力”或“角色”命名接口接口名通常使用形容詞或名詞清晰表達(dá)其提供的“能力”例如IDamageable可受傷的、IInteractable可交互的、ISaveGame可保存的。避免使用IXXXManager、IXXXSystem這類暗示“管理”或“系統(tǒng)”的名字接口定義的是契約不是管理器。謹(jǐn)慎添加新方法一旦接口被廣泛實(shí)現(xiàn)再修改它添加、刪除、修改方法的成本會(huì)很高因?yàn)樗袑?shí)現(xiàn)類都需要同步修改。在設(shè)計(jì)初期應(yīng)盡量考慮周全。如果必須擴(kuò)展考慮創(chuàng)建新的接口如IDamageableV2或者使用默認(rèn)參數(shù)需謹(jǐn)慎會(huì)影響藍(lán)圖。避免在接口中包含數(shù)據(jù)成員標(biāo)準(zhǔn)的UE接口使用UINTERFACE宏不支持定義UPROPERTY。接口應(yīng)該專注于行為定義。如果需要共享數(shù)據(jù)可以考慮將數(shù)據(jù)封裝在一個(gè)結(jié)構(gòu)體USTRUCT中通過(guò)接口的getter/setter方法來(lái)訪問(wèn)。注意循環(huán)依賴如果模塊A定義的接口被模塊B中的類實(shí)現(xiàn)而模塊B中的某個(gè)類又需要被模塊A中的接口引用就可能形成模塊間的循環(huán)依賴。UE的構(gòu)建系統(tǒng)不允許循環(huán)依賴。解決方法是重新設(shè)計(jì)模塊劃分或?qū)⒐膊糠痔崛〉降谌齻€(gè)模塊中。區(qū)分藍(lán)圖可用與純C接口如果接口不需要在藍(lán)圖中使用可以不添加Blueprintable、BlueprintType等元數(shù)據(jù)并將函數(shù)聲明為普通的C虛函數(shù)。這可以減少生成的反射代碼略微提升編譯速度。反之如果確定需要藍(lán)圖支持則務(wù)必正確使用UFUNCTION和BlueprintNativeEvent/BlueprintImplementableEvent。我個(gè)人在大型項(xiàng)目中實(shí)踐下來(lái)的體會(huì)是善用接口是構(gòu)建彈性架構(gòu)的關(guān)鍵。它像是一種“膠水”將系統(tǒng)中功能獨(dú)立但需要協(xié)作的部分以一種標(biāo)準(zhǔn)化的方式粘合起來(lái)。初期多花點(diǎn)時(shí)間設(shè)計(jì)好接口后期面對(duì)需求變更和功能擴(kuò)展時(shí)會(huì)輕松很多。當(dāng)你發(fā)現(xiàn)需要讓一個(gè)原本無(wú)關(guān)的類突然擁有某種行為時(shí)第一個(gè)想到的不應(yīng)該是去修改它的繼承樹(shù)而是問(wèn)“我能不能定義一個(gè)接口然后讓它實(shí)現(xiàn)” 這通常會(huì)是更優(yōu)雅、破壞性更小的解決方案。