UE4反射

本文主要是個人對UE4反射系統的一些總結和理解。

1. UE4反射系統

什么是反射系統

在UE4里面，你無時無刻都會看到類似UFUNCTION（）這樣的宏。官方文檔告訴你，只要在一個函數的前面加上這個宏，然后在括號里面加上BlueprintCallable就可以在編輯器里面調用了。按照他的指示，我們就能讓我們的函數實現各種各樣特別的功能，那這個效果就是通過UE4的反射系統來實現的。這看起來確實非常棒，不過同時給UE4的反射系統增添了一點神秘感。我們可能一開始嘗試著去找一下這個宏的定義，但是翻了幾層發現沒有頭緒，可能也就懶得再去研究他是怎么實現的了。

其實，所謂反射，是程序在運行時進行自檢的一種能力，自檢什么呢？我認為就是檢查自己的C++類，函數，成員變量，結構體等等（對應起來也就是大家在UE4能看到的UCLASS，UFUNCTON，UPROPERTY，USTRUCT后面還會提到）。

那檢查這些東西做什么呢？最明顯的就是支持藍圖和C++的交互功能，說的更通俗一點，就是可以更自由的控制這些結構，讓他在我們想出現的地方出現，讓他在我們想使用的地方使用。要知道我們在虛幻4中聲明的任意一個類，都是繼承于UObject類的，所以他遠遠不是我們所以為的那個普通的C++類。我們可以使用這個類進行網絡復制，執行垃圾回收，讓他和藍圖交互等等。而這一切原生的C++是并不支持的，也正是因此虛幻4才構建了一個這樣的反射系統。

反射一般用于哪些地方

#define UPROPERTY(...) #define UFUNCTION(...) #define USTRUCT(...) #define UMETA(...) #define UPARAM(...) #define UENUM(...) #define UDELEGATE(...) #define UCLASS(...) BODY_MACRO_COMBINE(CURRENT_FILE_ID,_,__LINE__,_PROLOG) #define UINTERFACE(...) UCLASS()

在UE4里面， 基本上所有的游戲工程的類都需要用到。比如，你用編輯器新建一個類，類的前面會自動添加UCLASS()；新建一個結構體，需要使用USTRUCT()；新建一個枚舉變量，需要在前面聲明UENUM()；在類的里面，也必須要加上GENERATED_UCLASS_BODY()才行。當你添加這些宏的時候，UHT就會幫你生成反射機制。

如果你想讓你的變量能顯示在編輯器里面，想讓你的函數可以被藍圖調用或者通過讓這個函數實現RPC網絡通信功能，或者你想讓你的變量被系統自動的回收，這些都離不開反射系統以及這些宏定義。

所以，我們這里起碼能認識到，在網絡通信，藍圖交互以及垃圾回收方面，這與反射系統是密不可分的。

另外，如果要說引擎中哪部分使用到反射系統功能的話，那基本上整個引擎都脫不了干系了。

2. 反射實現機制和基本原理

在了解反射系統前，我們必須要知道兩個UE4獨特的文件類型—“.generate.h”以及“.generate.cpp”。“.generate.h”文件在每一個類的聲明前面都會被包含到對應的頭文件里面。（這也是官方建議我們要用編輯器來創建類的原因，他們并不是常規的C++類）而“.generate.cpp”對于一整個項目只會有一個。這兩種文件可以說是反射系統的關鍵所在，他們是通過Unreal Build Tool(UBT) 和UnrealHeaderTool(UHT)來生成的。

2.1 UBT 和UHT

UnrealBuildTool（UBT，C#）：UE4的自定義工具，來編譯UE4的逐個模塊并處理依賴等。我們編寫的Target.cs，Build.cs都是為這個工具服務的。

UnrealHeaderTool （UHT，C++）：UE4的C++代碼解析生成工具，我們在代碼里寫的那些宏UCLASS等和#include “*.generated.h”都為UHT提供了信息來生成相應的C++反射代碼。

代碼編譯在兩個階段中進行：1.UHT 被調用。它將解析 C++ 頭中引擎相關類元數據，并生成自定義代碼，以實現諸多 UObject 相關的功能。2.普通 C++ 編譯器被調用，以便對結果進行編譯。）

Unreal Build Tool(UBT)和Unreal Header Tool (UHT)兩個協同工作來生成運行時反射需要的數據。UBT屬性通過掃描頭文件，記錄任何至少有一個反射類型的頭文件的模塊。如果其中任意一個頭文件從上一次編譯起發生了變化，那么 UHT就會被調用來利用和更新反射數據。UHT分析頭文件，創建一系列反射數據，并且生成包含反射數據的C++代碼（放到每一個模塊的moulde.generated.inl中。注：最新版會生成到moudle.generated.cpp中），還有各種幫助函數以及thunk函數（每一個 頭文件 .generated.h）

思考：UHT如何實現反射？

打個比方：UClass其實就好比一張表，一張戶口本的東西，指向”真實家庭“的指針。上面記錄著一些信息，好比：

張三：

男

1995年出生

李四：

女

1991年出生

那虛幻引擎是如何實現這個機制的呢？一種方法是，一開始編譯的時候，把表格都填好，放到一個文件處，要找某家人的時候再取出來，但是有一個問題就是，每編譯一次的時候，函數地址會發生變化，所以直接存儲函數地址這種方法不行。第二種方法就是，存儲”進行查找戶口調查的過程”，比方說，它存儲了每個家庭哪些人需要登記信息。然后當運行開始的時候，逐個讓每一家人進行登記。而UHT就是在為這個過程提供幫助，它生成的.generate.h 和 .generate.cpp就是存儲進行查找戶口調查的過程。

2.2 .generate.h 和 .generate.cpp

“.generate.h”與“.generate.cpp”文件里面都是什么？有什么作用？

“.generate.h”里面是宏，而且包含一個非常龐大的宏，這個宏把所有和反射相關的方法（包括定義）和結構體連接到一起。

而“.generate.cpp”里面是許多的函數定義，UHT根據你在頭文件里面使用的宏（UFUNCTION等）自動的生成這個文件，所以這個文件并不需要你去修改，也不允許修改。UBT屬性通過掃描頭文件，記錄任何至少有一個反射類型的頭文件的模塊。如果其中任意一個頭文件從上一次編譯起發生了變化，那么 UHT就會被調用來利用和更新反射數據。UHT分析頭文件，創建一系列反射數據，并且生成包含反射數據的C++代碼。

2.3 反射類型和層次結構

官方文檔所給出的基本層次結構

UFieldUStructUClass (C++ class)UScriptStruct (C++ struct)UFunction (C++ function)UEnum (C++ enumeration)UProperty (C++ member variable or function parameter)(Many subclasses for different types)

下圖引自InsideUE4

2.4 熱重載

---

? 在編輯器模式下，UE4將工程代碼編譯成動態鏈接庫，這樣編輯器可以動態的加載和卸載某個動態鏈接庫。UE4為工程自動生成一個cpp文件（本工程為HelloUE4.generated.cpp），cpp文件包含了當前工程中所有需要反射的類信息，以及類成員列表和每個成員的類型信息。在動態鏈接庫被編輯器加載的時候，自動將類信息注冊到編輯器中。反之，卸載的時候，這樣類信息也會被反注冊。

? 在開發的過程中，當我們編譯完成工程的時候，UE4編輯器會自動檢測動態鏈接庫的變化，然后自動熱重載這些動態鏈接庫中的類信息。

這部分還不是很熟悉，所以在本文中不對熱重載進行探討。

3. 反射代碼實例分析

UE4引擎啟動時候，是分Module(dll)來構建類型信息的。Module采用模擬一般程序的構建流程的方法，大致需要以下幾個階段：生成、收集、注冊、鏈接。

生成階段：借助UHT(Unreal Header Tool)工具，生成UClass代碼，包括UClass構造，注冊屬性和函數等；

收集階段：利用Static自動注冊方式，在模塊加載的時候，將所有UClass登記，集中在Array管理；

注冊階段：在模塊初始化的時候，將Array中的所有UClass相關的Function和Property注冊；

鏈接階段：就是反射功能。

生成階段

要讓一個類支持反射，你需要讓這個類要繼承自UObject、在類聲明前添加UCLASS（或USTRUCT）標識，并且include “xxx.generated.h”頭文件（而且必須是最后一個include）。

當你啟動UE4編譯時，UE4會首先運行UHT (UnrealHeaderTool)，UHT成功運行后才會執行真正的編譯。UHT是一個頭文件解析和代碼生成工具，它會處理所有的頭文件，從中檢索UCLASS、GENERATED_BODY、UPROPERTY、UFUNTION等關鍵字，檢索到以后就為它們生成.generate.h 和 .generate.cpp。

以下是創建的一個小小的demo來對反射進行更好的理解

創建一個新的項目，然后創建一個類繼承AGamoModeBase。

// Fill out your copyright notice in the Description page of Project Settings. #pragma once#include "CoreMinimal.h" #include "GameFramework/GameModeBase.h" #include "HelloGameMode.generated.h" // 核心內容，必須放在最后一行，由UBT自動生成。UCLASS() class HELLOWORLD_API AHelloGameMode : public AGameModeBase {GENERATED_BODY() // 重中之重 protected:UPROPERTY(BlueprintReadWrite, Category = "AReflectionStudyGameMode")float Score;UFUNCTION(BlueprintCallable, Category = "AReflectionStudyGameMode")void CallableFuncTest();UFUNCTION(BlueprintNativeEvent, Category = "AReflectionStudyGameMode")void NavtiveFuncTest();UFUNCTION(BlueprintImplementableEvent, Category = "AReflectionStudyGameMode")void ImplementableFuncTest();};

首先UHT幫我自動生成了四個文件。

文件路徑為：helloworld\Intermediate\Build\Win64\UE4Editor\Inc\helloworld。

HelloGameMode.generated.h

UHT分析生成的文件內容如下：由于篇幅原因，只列出一部分代碼。

// ...// ... #define helloworld_Source_helloworld_Public_HelloGameMode_h_15_RPC_WRAPPERS_NO_PURE_DECLS \ virtual void NavtiveFuncTest_Implementation(); \ \ DECLARE_FUNCTION(execNavtiveFuncTest) \ { \ P_FINISH; \ P_NATIVE_BEGIN; \ P_THIS->NavtiveFuncTest_Implementation(); \ P_NATIVE_END; \ } \ \ DECLARE_FUNCTION(execCallableFuncTest) \ { \ P_FINISH; \ P_NATIVE_BEGIN; \ P_THIS->CallableFuncTest(); \ P_NATIVE_END; \ }#define helloworld_Source_helloworld_Public_HelloGameMode_h_15_EVENT_PARMS #define helloworld_Source_helloworld_Public_HelloGameMode_h_15_CALLBACK_WRAPPERS #define helloworld_Source_helloworld_Public_HelloGameMode_h_15_INCLASS_NO_PURE_DECLS \ private: \ static void StaticRegisterNativesAHelloGameMode(); \ friend struct Z_Construct_UClass_AHelloGameMode_Statics; \ public: \ DECLARE_CLASS(AHelloGameMode, AGameModeBase, COMPILED_IN_FLAGS(0 | CLASS_Transient), CASTCLASS_None, TEXT("/Script/helloworld"), NO_API) \ DECLARE_SERIALIZER(AHelloGameMode)#define helloworld_Source_helloworld_Public_HelloGameMode_h_15_ENHANCED_CONSTRUCTORS \ /** Standard constructor, called after all reflected properties have been initialized */ \ NO_API AHelloGameMode(const FObjectInitializer& ObjectInitializer = FObjectInitializer::Get()) : Super(ObjectInitializer) { }; \ private: \ /** Private move- and copy-constructors, should never be used */ \ NO_API AHelloGameMode(AHelloGameMode&&); \ NO_API AHelloGameMode(const AHelloGameMode&); \ public: \ DECLARE_VTABLE_PTR_HELPER_CTOR(NO_API, AHelloGameMode); \ DEFINE_VTABLE_PTR_HELPER_CTOR_CALLER(AHelloGameMode); \ DEFINE_DEFAULT_OBJECT_INITIALIZER_CONSTRUCTOR_CALL(AHelloGameMode)#define helloworld_Source_helloworld_Public_HelloGameMode_h_15_PRIVATE_PROPERTY_OFFSET \ FORCEINLINE static uint32 __PPO__Score() { return STRUCT_OFFSET(AHelloGameMode, Score); }#define helloworld_Source_helloworld_Public_HelloGameMode_h_15_GENERATED_BODY \ PRAGMA_DISABLE_DEPRECATION_WARNINGS \ public: \ helloworld_Source_helloworld_Public_HelloGameMode_h_15_PRIVATE_PROPERTY_OFFSET \ // 關于UPROPERTY部分，具體還沒研究透，看代碼像是獲取指針地址的偏移值helloworld_Source_helloworld_Public_HelloGameMode_h_15_RPC_WRAPPERS_NO_PURE_DECLS \ //helloworld_Source_helloworld_Public_HelloGameMode_h_15_CALLBACK_WRAPPERS \ // 空宏helloworld_Source_helloworld_Public_HelloGameMode_h_15_INCLASS_NO_PURE_DECLS \ helloworld_Source_helloworld_Public_HelloGameMode_h_15_ENHANCED_CONSTRUCTORS \ private: \ PRAGMA_ENABLE_DEPRECATION_WARNINGS#undef CURRENT_FILE_ID #define CURRENT_FILE_ID helloworld_Source_helloworld_Public_HelloGameMode_hPRAGMA_ENABLE_DEPRECATION_WARNINGS

GENERATED_BODY

我們在HelloGameMode.cpp中發現，有一個GENERATED_BODY() 宏，該宏是重中之重，其他的UCLASS宏只是提供信息，不參與編譯，而GENERATED_BODY正是把聲明和元數據定義關聯到一起的樞紐。繼續查看宏定義。 GENERATED_BODY()的宏定義 ：

#define BODY_MACRO_COMBINE_INNER(A,B,C,D) A##B##C##D #define BODY_MACRO_COMBINE(A,B,C,D) BODY_MACRO_COMBINE_INNER(A,B,C,D) #define GENERATED_BODY(...) BODY_MACRO_COMBINE(CURRENT_FILE_ID,_,__LINE__,_GENERATED_BODY)

而在。generated.h Line63中定義了CURRENT_FILE_ID。所以GENERATED_BODY() 展開就是helloworld_Source_helloworld_Public_HelloGameMode_h_15_GENERATED_BODY，而這個宏的定義則在generated.h Line51。

DECLARE_FUNCTION

通過helloworld_Source_helloworld_Public_HelloGameMode_h_15_GENERATED_BODY向上， 以helloworld_Source_helloworld_Public_HelloGameMode_h_15_RPC_WRAPPERS_NO_PURE_DECLS為例：

#define helloworld_Source_helloworld_Public_HelloGameMode_h_15_RPC_WRAPPERS_NO_PURE_DECLS \ virtual void NavtiveFuncTest_Implementation(); \ \ DECLARE_FUNCTION(execNavtiveFuncTest) \ { \ P_FINISH; \ P_NATIVE_BEGIN; \ P_THIS->NavtiveFuncTest_Implementation(); \ P_NATIVE_END; \ } \ \ DECLARE_FUNCTION(execCallableFuncTest) \ { \ P_FINISH; \ P_NATIVE_BEGIN; \ P_THIS->CallableFuncTest(); \ P_NATIVE_END; \ }// 由于NavtiveFuncTest是BlueprintNativeEvent，在藍圖和C++均可實現，而在C++我們定義的函數名稱為NavtiveFuncTest_Implementation();原來是因為UBT在內部已經幫我們實現了這部分的定義。 // DECLARE_FUNCTION(execNavtiveFuncTest)，聲明一個函數名字為execNavtiveFuncTest，由于藍圖執行的函數的命名規范是exec開頭的，當藍圖調用這個函數的時候，則會調用P_THIS->NavtiveFuncTest_Implementation();

由于NavtiveFuncTest是BlueprintNativeEvent，在藍圖和C++均可實現，而在C++我們定義的函數名稱為NavtiveFuncTest_Implementation();原來是因為UBT在內部已經幫我們實現了這部分的定義。

DECLARE_FUNCTION(execNavtiveFuncTest)，聲明一個函數名字為execNavtiveFuncTest，由于藍圖執行的函數的命名規范是exec開頭的，當藍圖調用這個函數的時候，則會調用P_THIS->NavtiveFuncTest_Implementation();

DECLARE_CLASS

helloworld_Source_helloworld_Public_HelloGameMode_h_15_INCLASS_NO_PURE_DECLS部分：

#define helloworld_Source_helloworld_Public_HelloGameMode_h_15_INCLASS_NO_PURE_DECLS \ private: \static void StaticRegisterNativesAHelloGameMode(); \ // 在HelloGameMode.gen.cpp中實現friend struct Z_Construct_UClass_AHelloGameMode_Statics; \ // 在HelloGameMode.gen.cpp中定義 public: \DECLARE_CLASS(AHelloGameMode, AGameModeBase, COMPILED_IN_FLAGS(0 | CLASS_Transient), CASTCLASS_None, TEXT("/Script/helloworld"), NO_API) \DECLARE_SERIALIZER(AHelloGameMode) // 序列化，先忽略

DECLARE_CLASS是最重要的一個聲明，對照著定義：DECLARE_CLASS(AHelloGameMode, AGameModeBase, COMPILED_IN_FLAGS(0 | CLASS_Transient), CASTCLASS_None, TEXT("/Script/helloworld"), NO_API)

• TClass：類名
• TSuperClass：基類名字
• TStaticFlags：類的屬性標記
• TStaticCastFlags：指定了該類可以轉換為哪些類，這里為0表示不能轉為那些默認的類，讀者可以自己查看EClassCastFlags聲明來查看具體有哪些默認類轉換。
• TPackage：類所處于的包名，所有的對象都必須處于一個包中，而每個包都具有一個名字，可以通過該名字來查找。這里是”/Script/helloworld”，指定是Script下的helloworld，Script可以理解為用戶自己的實現，不管是C++還是藍圖，都可以看作是引擎外的一種腳本，當然用這個名字也肯定有UE3時代UnrealScript的影子。Hello就是項目名字，該項目下定義的對象處于該包中。Package的概念涉及到后續Object的組織方式，目前可以簡單理解為一個大的Object包含了其他子Object。
• TRequiredAPI：就是用來Dll導入導出的標記，這里是NO_API1，因為是最終exe，不需要導出。

#define DECLARE_CLASS( TClass, TSuperClass, TStaticFlags, TStaticCastFlags, TPackage, TRequiredAPI ) \ private: \TClass& operator=(TClass&&); \TClass& operator=(const TClass&); \TRequiredAPI static UClass* GetPrivateStaticClass(); \ public: \/** Bitwise union of #EClassFlags pertaining to this class.*/ \enum {StaticClassFlags=TStaticFlags}; \/** Typedef for the base class ({{ typedef-type }}) */ \typedef TSuperClass Super;\/** Typedef for {{ typedef-type }}. */ \typedef TClass ThisClass;\/** Returns a UClass object representing this class at runtime */ \inline static UClass* StaticClass() \{ \return GetPrivateStaticClass(); \} \/** Returns the package this class belongs in */ \inline static const TCHAR* StaticPackage() \{ \return TPackage; \} \/** Returns the static cast flags for this class */ \inline static EClassCastFlags StaticClassCastFlags() \{ \return TStaticCastFlags; \} \/** For internal use only; use StaticConstructObject() to create new objects. */ \inline void* operator new(const size_t InSize, EInternal InInternalOnly, UObject* InOuter = (UObject*)GetTransientPackage(), FName InName = NAME_None, EObjectFlags InSetFlags = RF_NoFlags) \{ \return StaticAllocateObject(StaticClass(), InOuter, InName, InSetFlags); \} \/** For internal use only; use StaticConstructObject() to create new objects. */ \inline void* operator new( const size_t InSize, EInternal* InMem ) \{ \return (void*)InMem; \} //在這部分中，最重要部分則是我們常用的StaticClass(), 調用了GetPrivateStaticClass()，后續會講到這個函數在哪里實現。

StaticClass，是我們平時用到的一個獲取反射類型的一個函數，原來UHT已經在內部幫我們定義了。這個也是很重要的一個函數。具體后面會講述。

DefaultConstructor

helloworld_Source_helloworld_Public_HelloGameMode_h_15_ENHANCED_CONSTRUCTORS部分：

#define helloworld_Source_helloworld_Public_HelloGameMode_h_15_ENHANCED_CONSTRUCTORS \/** Standard constructor, called after all reflected properties have been initialized */ \NO_API AHelloGameMode(const FObjectInitializer& ObjectInitializer = FObjectInitializer::Get()) : Super(ObjectInitializer) { }; \ //根據注釋的意思，就是標準的構造函數，在所有反射的屬性初始化后調用。 private: \/** Private move- and copy-constructors, should never be used */ \ //永遠不要用這兩個函數NO_API AHelloGameMode(AHelloGameMode&&); \ //移動構造函數NO_API AHelloGameMode(const AHelloGameMode&); \ //拷貝構造函數 public: \DECLARE_VTABLE_PTR_HELPER_CTOR(NO_API, AHelloGameMode); \ // 熱加載，先忽略 DEFINE_VTABLE_PTR_HELPER_CTOR_CALLER(AHelloGameMode); \ // 空宏DEFINE_DEFAULT_OBJECT_INITIALIZER_CONSTRUCTOR_CALL(AHelloGameMode) // 定義一個構造函數

繼續查看DEFINE_DEFAULT_OBJECT_INITIALIZER_CONSTRUCTOR_CALL的定義：

#define DEFINE_DEFAULT_OBJECT_INITIALIZER_CONSTRUCTOR_CALL(TClass) \static void __DefaultConstructor(const FObjectInitializer& X) { new((EInternal*)X.GetObj())TClass(X); }

聲明定義了一個構造函數包裝器。需要這么做的原因是，在根據名字反射創建對象的時候，需要調用該類的構造函數。可是類的構造函數并不能用函數指針指向，因此這里就用一個static函數包裝一下，變成一個”平凡”的函數指針，而且所有類的簽名一致，就可以在UClass里用一個函數指針里保存起來 。

在上述的StaticClass中傳遞進去作為構造函數。

---

HelloGameMode.gen.cpp

由于這個類代碼太長，所以的話就分版塊討論。

ProcessEvent

static FName NAME_AHelloGameMode_ImplementableFuncTest = FName(TEXT("ImplementableFuncTest")); void AHelloGameMode::ImplementableFuncTest() {ProcessEvent(FindFunctionChecked(NAME_AHelloGameMode_ImplementableFuncTest),NULL); } // 為啥BlueprintImplementableEvent的函數不用我們去實現呢，是因為UBT幫我們自己實現了。而關于ProcessEvent部分, 這個方法在UObject中實現的。

• 剛接觸UE4的時候，如果是BlueprintImplementabeEvent的函數，是不是發現不需要自己去實現，那么當時有沒有覺得怪異呢，上面的代碼就解釋清楚了，那是UE4幫我們實現了，可以看到它調用了ProcessEvent方法，這個方法在UObject中實現的。
• 而且如果是BlueprintImplementabeEvent或者RPC的那些函數，我們是不需要實現其函數方法的，如果在CPP文件定義實現的話，則會報錯，那是因為在.gen.cpp中已經幫我們實現了這個函數。

IMPLEMENT_CLASS

IMPLEMENT_CLASS(AHelloGameMode, 1552540694); // in IMPLEMENT_CLASS // Register a class at startup time. UClass* TClass::GetPrivateStaticClass() {static UClass* PrivateStaticClass = NULL;if (!PrivateStaticClass){/* this could be handled with templates, but we want it external to avoid code bloat */// 主要實現內容GetPrivateStaticClassBody(StaticPackage(), (TCHAR*)TEXT(#TClass) + 1 + ((StaticClassFlags & CLASS_Deprecated) ? 11 : 0), PrivateStaticClass, StaticRegisterNatives##TClass, // StaticRegisterNativesAHelloGameMode，sizeof(TClass), (EClassFlags)TClass::StaticClassFlags, TClass::StaticClassCastFlags(), TClass::StaticConfigName(), (UClass::ClassConstructorType)InternalConstructor<TClass>, //構造函數，在DEFINE_DEFAULT_OBJECT_INITIALIZER_CONSTRUCTOR_CALL(AHelloGameMode) 實現 (UClass::ClassVTableHelperCtorCallerType)InternalVTableHelperCtorCaller<TClass>, &TClass::AddReferencedObjects, &TClass::Super::StaticClass, &TClass::WithinClass::StaticClass ); } return PrivateStaticClass; }

我們在DECLARE_CLASS中可以看到StaticClass調用了GetPrivateStaticClass，其實就是在IMPLEMENT_CLASS中實現的。這部分在下面收集階段會再詳細講解。

ConstructClass

static FCompiledInDefer Z_CompiledInDefer_UClass_AHelloGameMode(Z_Construct_UClass_AHelloGameMode, &AHelloGameMode::StaticClass, TEXT("/Script/helloworld"), TEXT("AHelloGameMode"), false, nullptr, nullptr, nullptr);UClass* Z_Construct_UClass_AHelloGameMode() {static UClass* OuterClass = nullptr;if (!OuterClass){UE4CodeGen_Private::ConstructUClass(OuterClass, Z_Construct_UClass_AHelloGameMode_Statics::ClassParams);}return OuterClass; }

通過聲明一個全局變量的形式，來靜態自動注冊的模式，從而達到收集信息的目的。具體的在收集階段詳細講解

---

收集階段

自動化注冊

思考：UE4如何實現自動注冊的呢？

主要是通過Static 自動注冊的方式。

而在本例子是如何通過Static自動注冊呢？

回顧生成階段的IMPLEMENT_CLASS和ConstructClass中靜態聲明了兩個變量。

#define IMPLEMENT_CLASS(TClass, TClassCrc) \static TClassCompiledInDefer<TClass> AutoInitialize##TClass(TEXT(#TClass), sizeof(TClass), TClassCrc); \

or

static FCompiledInDefer Z_CompiledInDefer_UClass_AHelloGameMode(Z_Construct_UClass_AHelloGameMode, &AHelloGameMode::StaticClass, TEXT("/Script/helloworld"), TEXT("AHelloGameMode"), false, nullptr, nullptr, nullptr);

• 這兩個全局靜態變量在Main函數之前就會初始化

• 初始化就會調用這兩個變量的構造函數

• 構造函數會分別調用UClassCompiledInDefer函數和UObjectCompiledInDefer函數。

• 這兩個函數會把ClassInfo放進延遲注冊的數組中去。

思考：為何需要TClassCompiledInDefer和FCompiledInDefer兩個靜態初始化來登記？

我們也觀察到了這二者是一一對應的，問題是為何需要兩個靜態對象來分別收集，為何不合二為一？關鍵在于我們首先要明白它們二者的不同之處，前者的目的主要是為后續提供一個TClass::StaticClass的Register方法（其會觸發GetPrivateStaticClassBody的調用，進而創建出UClass*對象），而后者的目的是在其UClass*身上繼續調用構造函數，初始化屬性和函數等一些注冊操作。我們可以簡單理解為就像是C++中new對象的兩個步驟，首先分配內存，繼而在該內存上構造對象。我們在后續的注冊章節里還會繼續討論到這個問題。

思考：為啥要采用延遲注冊的方式?為什么不在收集階段直接注冊呢？

主要考慮到UE4超多類，都在static初始化階段注冊，程序會表現啟動速度慢，用戶雙擊程序，沒反應。所以采用延遲注冊。

啟動過程分析

上面我們講解了這個注冊信息的過程，而它們的執行是伴隨著當前模塊的加載而執行的，我們都知道靜態變量的初始化是先于Main函數執行的。下面我們簡單畫了一下虛幻編輯器的啟動流程，這樣我們就可以準確地看到整個注冊反射信息的過程了。

void ProcessNewlyLoadedUObjects() {// ...UClassRegisterAllCompiledInClasses();const TArray<UClass* (*)()>& DeferredCompiledInRegistration = GetDeferredCompiledInRegistration();const TArray<FPendingStructRegistrant>& DeferredCompiledInStructRegistration = GetDeferredCompiledInStructRegistration();const TArray<FPendingEnumRegistrant>& DeferredCompiledInEnumRegistration = GetDeferredCompiledInEnumRegistration();bool bNewUObjects = false;while( GFirstPendingRegistrant || DeferredCompiledInRegistration.Num() || DeferredCompiledInStructRegistration.Num() || DeferredCompiledInEnumRegistration.Num() ){bNewUObjects = true;UObjectProcessRegistrants();UObjectLoadAllCompiledInStructs();UObjectLoadAllCompiledInDefaultProperties();} // ... }

在這個函數中，可以看到void ProcessNewlyLoadedUObjects()這個函數就是我們主要關注的函數，我們前面講到的注冊的信息，包括類、結構體以及枚舉類型的反射信息都會在這里進行注冊。

收集

在生成階段中，我們生成了很多Class、Property、Function的信息。但是我們需要它們的信息收集整合到我們需要的數據結構里保存，以便下一階段的使用。

通過UClassCompiledInDefer收集

深入UClassCompiledInDefer方法我們可以發現。

void UClassCompiledInDefer(FFieldCompiledInInfo* ClassInfo, const TCHAR* Name, SIZE_T ClassSize, uint32 Crc) {// We will either create a new class or update the static class pointer of the existing oneGetDeferredClassRegistration().Add(ClassInfo); //static TArray<FFieldCompiledInInfo*> DeferredClassRegistration; }

可以看到UClassCompiledInDefer(this, InName, InClassSize, InCrc)，傳進去4個參數，主要是收集三個數據，為啥要傳4個參數呢，是因為把自己的指針傳進去，為了方便后續調用Register()方法。

實現的功能主要是在一個靜態Array里添加信息記錄。

這個數組會在后續注冊Class的時候會被調用，然后調用Register()，實現注冊功能。

/** Register all loaded classes */ void UClassRegisterAllCompiledInClasses() {//...TArray<FFieldCompiledInInfo*>& DeferredClassRegistration = GetDeferredClassRegistration();for (const FFieldCompiledInInfo* Class : DeferredClassRegistration){UClass* RegisteredClass = Class->Register(); //實現注冊，關鍵步驟。 #if WITH_HOT_RELOADif (GIsHotReload && Class->OldClass == nullptr){AddedClasses.Add(RegisteredClass);} #endif}DeferredClassRegistration.Empty(); //注冊完成，清空注冊表//... }

而Register函數實際上傳進來的就是StaticClass函數

接著就是StaticClass()部分如何收集的解釋。

通過StaticClass()我們可以發現主要是調用了GetPrivateStaticClass()，而GetPrivateStaticClass()也主要是調用了GetPrivateStaticClassBody()函數，那么通過這個函數收集到了哪些信息呢。

以下是主要的信息：

**PackageName：**StaticPackage()

Name：類名，+1去掉U、A、F前綴，+11去掉_Deprecated前綴

ReturnClass：輸出引用，也就是收集信息后產生的UClass，PrivateStaticClass

void(*RegisterNativeFunc)()： StaticRegisterNativesAHelloGameMode()， 收集原生的函數。

InSize： 類的大小

InClassConstructor：構造函數，在DEFINE_DEFAULT_OBJECT_INITIALIZER_CONSTRUCTOR_CALL(AHelloGameMode)實現。

InSuperClassFn：&TClass::Super::StaticClass， 父類的注冊函數。

// in DECLARE_CLASS inline static UClass* StaticClass() {return GetPrivateStaticClass(); }// in IMPLEMENT_CLASS UClass* TClass::GetPrivateStaticClass() {static UClass* PrivateStaticClass = NULL;if (!PrivateStaticClass){/* this could be handled with templates, but we want it external to avoid code bloat */// 主要實現內容GetPrivateStaticClassBody(StaticPackage(),(TCHAR*)TEXT(#TClass) + 1 + ((StaticClassFlags & CLASS_Deprecated) ? 11 : 0), PrivateStaticClass, StaticRegisterNatives##TClass, // StaticRegisterNativesAHelloGameMode，sizeof(TClass), (EClassFlags)TClass::StaticClassFlags, TClass::StaticClassCastFlags(), TClass::StaticConfigName(), (UClass::ClassConstructorType)InternalConstructor<TClass>, //構造函數，在DEFINE_DEFAULT_OBJECT_INITIALIZER_CONSTRUCTOR_CALL(AHelloGameMode) 實現(UClass::ClassVTableHelperCtorCallerType)InternalVTableHelperCtorCaller<TClass>, &TClass::AddReferencedObjects, &TClass::Super::StaticClass, &TClass::WithinClass::StaticClass ); } return PrivateStaticClass; }

這里主要是通過收集到的信息構造UClass。

主要有三部分：

首先給ReturnClass分配內存，然后初始化構造。

首先確保自己的父類已經注冊了，設置SuperStruct和 在全局PendingRegistrantsMaps中添加自己身類，延遲注冊。（在注冊階段會對這部分進行解釋）

Register the class’s native functions，注冊自身原生的函數、藍圖可執行的函數，執行 StaticRegisterNativesAHelloGameMode()；

// 刪減部分代碼 void GetPrivateStaticClassBody(const TCHAR* PackageName,const TCHAR* Name,UClass*& ReturnClass,void(*RegisterNativeFunc)(),uint32 InSize,EClassFlags InClassFlags,EClassCastFlags InClassCastFlags,const TCHAR* InConfigName,UClass::ClassConstructorType InClassConstructor,UClass::ClassVTableHelperCtorCallerType InClassVTableHelperCtorCaller,UClass::ClassAddReferencedObjectsType InClassAddReferencedObjects,UClass::StaticClassFunctionType InSuperClassFn,UClass::StaticClassFunctionType InWithinClassFn,bool bIsDynamic /*= false*/) {if (!bIsDynamic){ReturnClass = (UClass*)GUObjectAllocator.AllocateUObject(sizeof(UClass), alignof(UClass), true); // 內存分配// 構造函數ReturnClass = ::new (ReturnClass)UClass(EC_StaticConstructor,Name,InSize,InClassFlags,InClassCastFlags,InConfigName,EObjectFlags(RF_Public | RF_Standalone | RF_Transient | RF_MarkAsNative | RF_MarkAsRootSet),InClassConstructor,InClassVTableHelperCtorCaller,InClassAddReferencedObjects);check(ReturnClass);}// 設置SuperStruct和 在全局PendingRegistrantsMaps中添加自己身類，后續注冊UClass的時候會從Maps去除自身。InitializePrivateStaticClass(InSuperClassFn(),ReturnClass,InWithinClassFn(),PackageName,Name);// Register the class's native functions.// 注冊自身原生的函數。藍圖可執行的函數// 執行 StaticRegisterNativesAHelloGameMode()；RegisterNativeFunc(); }

---

通過UObjectCompiledInDefer收集

深入UObjectCompiledInDefer方法我們可以發現：

void UObjectCompiledInDefer(UClass *(*InRegister)(), UClass *(*InStaticClass)(), const TCHAR* Name, const TCHAR* PackageName, bool bDynamic, const TCHAR* DynamicPathName, void (*InInitSearchableValues)(TMap<FName, FName>&)) {// ...TArray<UClass *(*)()>& DeferredCompiledInRegistration = GetDeferredCompiledInRegistration();checkSlow(!DeferredCompiledInRegistration.Contains(InRegister));DeferredCompiledInRegistration.Add(InRegister);// ... }

傳進去一個InRegister函數指針到延遲注冊數組中，也就是Z_Construct_UClass_AHelloGameMode函數。

然后在啟動階段會調用UObjectLoadAllCompiledInDefaultProperties函數，遍歷所有的延遲注冊數組，進行收集注冊。

static void UObjectLoadAllCompiledInDefaultProperties() {static FName LongEnginePackageName(TEXT("/Script/Engine"));TArray<UClass *(*)()>& DeferredCompiledInRegistration = GetDeferredCompiledInRegistration();const bool bHaveRegistrants = DeferredCompiledInRegistration.Num() != 0;if( bHaveRegistrants ){TArray<UClass*> NewClasses;TArray<UClass*> NewClassesInCoreUObject;TArray<UClass*> NewClassesInEngine;TArray<UClass* (*)()> PendingRegistrants = MoveTemp(DeferredCompiledInRegistration);for (UClass* (*Registrant)() : PendingRegistrants){UClass* Class = Registrant(); // 在這一步調用了Z_Construct_UClass_AHelloGameMode函數//...}// ...} }

而Z_Construct_UClass_AHelloGameMode函數主要是調用了ConstructClass函數。

UE4CodeGen_Private::ConstructUClass(OuterClass, Z_Construct_UClass_AHelloGameMode_Statics::ClassParams);

可以看到，Construct函數傳進去兩個參數，一個OuterClass，一個ClassParams。

OuterClass是我們注冊后得到的輸出對象。

而ClassParams是我們需要收集的數據。

---

以下讓我們對ClassParams的數據進行一些分析，下面是一些重要的數據部分：

ClassNoRegisterFunc： StaticClass，作用在上面有具體講述

DependencySingletonFuncArray： 所依賴的構建函數，確保自己所依賴部分都被構建成功。

FunctionLinkArray：需要反射的函數數組

PropertyArray: 屬性數組

---

const UE4CodeGen_Private::FClassParams Z_Construct_UClass_AHelloGameMode_Statics::ClassParams = {&AHelloGameMode::StaticClass,DependentSingletons, ARRAY_COUNT(DependentSingletons),0x009002A8u,FuncInfo, ARRAY_COUNT(FuncInfo),Z_Construct_UClass_AHelloGameMode_Statics::PropPointers, ARRAY_COUNT(Z_Construct_UClass_AHelloGameMode_Statics::PropPointers),nullptr,&StaticCppClassTypeInfo,nullptr, 0,METADATA_PARAMS(Z_Construct_UClass_AHelloGameMode_Statics::Class_MetaDataParams, ARRAY_COUNT(Z_Construct_UClass_AHelloGameMode_Statics::Class_MetaDataParams)) };struct FClassParams {UClass* (*ClassNoRegisterFunc)(); // 傳進來StaticClass的函數UObject* (*const *DependencySingletonFuncArray)(); // 傳進所依賴函數的函數數組int32 NumDependencySingletons; //上述函數的個數uint32 ClassFlags; // EClassFlagsconst FClassFunctionLinkInfo* FunctionLinkArray; // 需要反射的函數，具體的后面會講述int32 NumFunctions; //同上const FPropertyParamsBase* const* PropertyArray; // 后續再講這個int32 NumProperties; //同上const char* ClassConfigNameUTF8;const FCppClassTypeInfoStatic* CppClassInfo;const FImplementedInterfaceParams* ImplementedInterfaceArray; //本例子中沒用上int32 NumImplementedInterfaces; // 0 #if WITH_METADATAconst FMetaDataPairParam* MetaDataArray;int32 NumMetaData; #endif };

以下是ConstructUclass的部分內容。

根據流程圖，可以看到，首先是執行的DependecySingletonFunctions，檢測自己所依賴的單例是否都建立了反射關系。接著就是StaticClass函數部分，這也是我們重點關注的部分。在StaticClass，實現了構建了一個基礎的UClass的反射，但是還沒有完善細節，因此在后續部分給NewClass添加細節部分。

步驟：

執行DependecySingletonFunctions數組中所依賴的函數，確保自身的父類反射已經被構建和自身所在的Package反射被構建。

UObjectForceRegistration，把自己從等待注冊的Map中去掉， 并且注冊。

ConstructUFunction，組建Function，并且注冊Function。（這部分后續再探討

ConstructUProperties，組建Properties。（這部分后續再探討

下面是ConstructUClass的部分內容，刪減了一部分代碼。

void ConstructUClass(UClass*& OutClass, const FClassParams& Params) // 關鍵點，用了引用 {if (OutClass && (OutClass->ClassFlags & CLASS_Constructed)) // 如果已經構建過了，則返回{return;}// 執行所依賴過的函數， 需要所依賴部分已經建立反射關系。(PS: Ue4源碼部分 充斥著大量的懶漢單例模式)for (UObject* (*const *SingletonFunc)() = Params.DependencySingletonFuncArray, *(*const *SingletonFuncEnd)() = SingletonFunc + Params.NumDependencySingletons; SingletonFunc != SingletonFuncEnd; ++SingletonFunc){(*SingletonFunc)();}// 所傳進來的是StaticClass函數UClass* NewClass = Params.ClassNoRegisterFunc(); OutClass = NewClass;if (NewClass->ClassFlags & CLASS_Constructed) // 如果這個已經構建過了，返回{return;}// 延遲注冊 // 把自己從等待注冊的Map中去掉UObjectForceRegistration(NewClass); NewClass->ClassFlags |= (EClassFlags)(Params.ClassFlags | CLASS_Constructed);// Make sure the reference token stream is empty since it will be reconstructed later on// This should not apply to intrinsic classes since they emit native references before AssembleReferenceTokenStream is called.if ((NewClass->ClassFlags & CLASS_Intrinsic) != CLASS_Intrinsic){check((NewClass->ClassFlags & CLASS_TokenStreamAssembled) != CLASS_TokenStreamAssembled);NewClass->ReferenceTokenStream.Empty(); #if ENABLE_GC_OBJECT_CHECKSNewClass->DebugTokenMap.Empty(); #endif}// 創建Function的反射，利用傳進來的構建函數來構建函數。NewClass->CreateLinkAndAddChildFunctionsToMap(Params.FunctionLinkArray, Params.NumFunctions);// 如果看過上一篇blog的話，就可以發現其實屬性構建部分是沒有單獨的函數構建的// 原來在這部分實現。ConstructUProperties(NewClass, Params.PropertyArray, Params.NumProperties);// ConstructClass還有很多內容，但是由于篇幅關系，這里就不一一放出來。 }

注冊階段

注冊階段主要分為兩個過程，首先構建UClass的時候添加進等待注冊表，等待注冊，在收集完成UClass所有信息的時候，延遲注冊。

添加進等待注冊表，等待注冊

在InitializePrivateStaticClass函數中執行Register函數，實現添加進等待注冊表，等待注冊過程。

COREUOBJECT_API void InitializePrivateStaticClass(class UClass* TClass_Super_StaticClass,class UClass* TClass_PrivateStaticClass,class UClass* TClass_WithinClass_StaticClass,const TCHAR* PackageName,const TCHAR* Name) { // ...// DeferTClass_PrivateStaticClass->Register(PackageName, Name);// ... }/** Enqueue the registration for this object. */ void UObjectBase::Register(const TCHAR* PackageName,const TCHAR* InName) {TMap<UObjectBase*, FPendingRegistrantInfo>& PendingRegistrants = FPendingRegistrantInfo::GetMap();FPendingRegistrant* PendingRegistration = new FPendingRegistrant(this);PendingRegistrants.Add(this, FPendingRegistrantInfo(InName, PackageName));if(GLastPendingRegistrant){GLastPendingRegistrant->NextAutoRegister = PendingRegistration;}else{check(!GFirstPendingRegistrant);GFirstPendingRegistrant = PendingRegistration;}GLastPendingRegistrant = PendingRegistration; }

收集信息完成，延遲注冊

現在，已經進入了等待注冊表內，而當我們收集完所有的UClass的信息的時候，我們注冊UClass。

void UObjectForceRegistration(UObjectBase* Object) {TMap<UObjectBase*, FPendingRegistrantInfo>& PendingRegistrants = FPendingRegistrantInfo::GetMap();FPendingRegistrantInfo* Info = PendingRegistrants.Find(Object);if (Info){const TCHAR* PackageName = Info->PackageName;const TCHAR* Name = Info->Name;PendingRegistrants.Remove(Object); // delete this first so that it doesn't try to do it twiceObject->DeferredRegister(UClass::StaticClass(),PackageName,Name);} }

注冊過程分析

Ue4是如何完成注冊的呢？

/*** Convert a boot-strap registered class into a real one, add to uobject array, etc** @param UClassStaticClass Now that it is known, fill in UClass::StaticClass() as the class*/ void UObjectBase::DeferredRegister(UClass *UClassStaticClass,const TCHAR* PackageName,const TCHAR* InName) {check(Internal::GObjInitialized);// Set object properties.UPackage* Package = CreatePackage(nullptr, PackageName);check(Package);Package->SetPackageFlags(PKG_CompiledIn);OuterPrivate = Package;check(UClassStaticClass);check(!ClassPrivate);ClassPrivate = UClassStaticClass;// Add to the global object table.AddObject(FName(InName), EInternalObjectFlags::None);// Make sure that objects disregarded for GC are part of root set.check(!GUObjectArray.IsDisregardForGC(this) || GUObjectArray.IndexToObject(InternalIndex)->IsRootSet()); }

其實就是把UClass放到一個Hash表中去。

void HashObject(UObjectBase* Object) {auto& ThreadHash = FUObjectHashTables::Get();Hash = GetObjectHash(Name); ThreadHash.AddToHash(Hash, Object);Hash = GetObjectOuterHash( Name, (PTRINT)Object->GetOuter() );ThreadHash.HashOuter.Add( Hash, Object );AddToOuterMap( ThreadHash, Object );AddToClassMap( ThreadHash, Object ); }

通過上面的代碼，我們可以發現通過名字生成Index和通過OuterName（也就是PackageName）來生成Index，然后添加進Map內部中。具體如何添加進HashMap中呢？請看下面的分析。

TUObjectHashTables

在這里就不得不介紹這個類TUObjectHashTables了，主要的存儲的類。注冊的反射的數據都以存放在這里。

首先看看這個類的定義

class FUObjectHashTables {FCriticalSection CriticalSection;public:/** Hash sets */TMap<int32, FHashBucket> Hash;TMultiMap<int32, class UObjectBase*> HashOuter;/** Map of object to their outers, used to avoid an object iterator to find such things. **/TMap<UObjectBase*, FHashBucket> ObjectOuterMap;TMap<UClass*, TSet<UObjectBase*> > ClassToObjectListMap;TMap<UClass*, TSet<UClass*> > ClassToChildListMap;static FUObjectHashTables& Get() // 餓漢單例{static FUObjectHashTables Singleton;return Singleton;}FORCEINLINE void AddToHash(int32 InHash, UObjectBase* Object){FHashBucket& Bucket = Hash.FindOrAdd(InHash);Bucket.Add(Object);} }

首先這個類用了餓漢單例的設計模式，保證只有一個存儲數據的實例，

從這個類中我們可以看到有5個Map，具體的映射方式也都顯而易見了，看看我們注冊的時候用了這幾個Map是怎樣處理的。

void HashObject(UObjectBase* Object) {auto& ThreadHash = FUObjectHashTables::Get(); //獲取存儲單例Hash = GetObjectHash(Name); //把FName轉化為Int Index，來映射 ThreadHash.AddToHash(Hash, Object);Hash = GetObjectOuterHash( Name, (PTRINT)Object->GetOuter() );ThreadHash.HashOuter.Add( Hash, Object );AddToOuterMap( ThreadHash, Object );AddToClassMap( ThreadHash, Object ); }

第一個Map：Hash，TMap<int32, FHashBucket> Hash，映射方式通過int32映射到一個桶。（每個桶我們其實都可以看成是一個類的集合）（為了容易理解，此處的int32亦可以理解為FName）

ThreadHash.AddToHash(Hash, Object);FORCEINLINE void AddToHash(int32 InHash, UObjectBase* Object) {FHashBucket& Bucket = Hash.FindOrAdd(InHash);Bucket.Add(Object); }

通過代碼可以看出來，通過自己的名字找到了屬于自己的那個桶，并且在桶中把自己添加進去。

由此可以看出HashMap的用處其實就是通過自身名字找到屬于自己的桶集合。

---

第二個Map：HashOuter，TMultiMap<int32, class UObjectBase*> HashOuter，映射方式通過int32映射到一個UObjectBase類。（為了容易理解，此處的int32亦可以理解為OuterFName）

ThreadHash.HashOuter.Add( Hash, Object );

通過代碼可以看出，HashOuterMap的用處其實是通過OuterFName的名字來找到自己的Outer。

---

第三個Map：ObjectOuterMap，TMap<UObjectBase*, FHashBucket> ObjectOuterMap，映射方式是用過Outer來找到自己的Bucket。

AddToOuterMap( ThreadHash, Object );// Assumes that ThreadHash's critical is already locked FORCEINLINE static void AddToOuterMap(FUObjectHashTables& ThreadHash, UObjectBase* Object) {FHashBucket& Bucket = ThreadHash.ObjectOuterMap.FindOrAdd(Object->GetOuter());checkSlow(!Bucket.Contains(Object)); // if it already exists, something is wrong with the external codeBucket.Add(Object); }

通過代碼可以看出, ObjectOuterMap是通過Outer來獲取到Outer的Bucket。（Outer實際上就是Package）（類似于第二個Map）

---

第四個Map：ClassToObjectListMap，TMap<UClass*, TSet<UObjectBase*> > ClassToObjectListMap。

{check(Object->GetClass());TSet<UObjectBase*>& ObjectList = ThreadHash.ClassToObjectListMap.FindOrAdd(Object->GetClass());bool bIsAlreadyInSetPtr = false;ObjectList.Add(Object, &bIsAlreadyInSetPtr);check(!bIsAlreadyInSetPtr); // if it already exists, something is wrong with the external code }

通過代碼可以看出, ClassToObjectListMap是通過自身來獲取到自身所包含的一個Set（類似于第一個Map）。

---

第五個Map：ClassToChildListMap，TMap<UClass*, TSet<UClass*> > ClassToChildListMap

UObjectBaseUtility* ObjectWithUtility = static_cast<UObjectBaseUtility*>(Object); if ( ObjectWithUtility->IsA(UClass::StaticClass()) ) {UClass* Class = static_cast<UClass*>(ObjectWithUtility);UClass* SuperClass = Class->GetSuperClass();if ( SuperClass ){TSet<UClass*>& ChildList = ThreadHash.ClassToChildListMap.FindOrAdd(SuperClass);bool bIsAlreadyInSetPtr = false;ChildList.Add(Class, &bIsAlreadyInSetPtr);check(!bIsAlreadyInSetPtr); // if it already exists, something is wrong with the external code} }

通過代碼我們可以看出這個是通過繼承關系來映射。

---

總結

目前只針對UCLASS部分的分析，而且由于筆者對UE4確實也還不太了解，只能作比較表面的理解，所以其中可能有說的不準確的地方，如果有錯誤的地方，還請指正 。

UE4版本 4.20

參考：

insideUe4

虛幻4屬性系統（反射）翻譯 By 風戀殘雪

---

這是一個空宏。 ?

總結

以上是生活随笔為你收集整理的UE4反射原理的探究的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。