使用ConstructorHelpers::FClassFinder静态加载蓝图

既然动态创建不行那么要不试试静态方法？抱着这个想法我就开始尝试这个方法，先说结果，已经成功了，那么就来说下怎么实现的。

首先这个函数是只能在每个类的构造函数中使用。函数原型是

template
	struct FClassFinder : public FGCObject
	{
		TSubclassOf Class;
		FClassFinder(const TCHAR* ClassToFind)
		{
			CheckIfIsInConstructor(ClassToFind);
			FString PathName(ClassToFind);
			StripObjectClass(PathName, true);
			Class = ConstructorHelpersInternal::FindOrLoadClass(PathName, T::StaticClass());
			ValidateObject(*Class, PathName, *PathName);
		}
		bool Succeeded()
		{
			return !!*Class;
		}
		
		virtual void AddReferencedObjects( FReferenceCollector& Collector ) override
		{
			UClass* ReferencedClass = Class.Get();
			Collector.AddReferencedObject(ReferencedClass);
			Class = ReferencedClass;
		}

		virtual FString GetReferencerName() const override
		{
			return TEXT("FClassFinder");
		}
	};

使用的话其实很简单的，大概就像这样

ConstructorHelpers::FClassFinderActor_BP(TEXT("你蓝图的路径"));

但是为了凑点字数（其实是因为这个流程挺有意思的），我还是想讲解下这个操作流程。重点就是这个部分

                TSubclassOf Class;
		FClassFinder(const TCHAR* ClassToFind)
		{
			CheckIfIsInConstructor(ClassToFind);
			FString PathName(ClassToFind);
			StripObjectClass(PathName, true);
			Class = ConstructorHelpersInternal::FindOrLoadClass(PathName, T::StaticClass());
			ValidateObject(*Class, PathName, *PathName);
		}

当输入了蓝图路径后会先调用CheckIfIsInConstructor函数来获取到你要的蓝图在这个游戏线程中的位置。这里稍微说下虚幻引擎的启动顺序，当资源加载完成的时候（比如你地图啊模型啊之类的）就会开始加载蓝图中这个时候就会调用蓝图/C++类的构造函数，这个也是为什么有时候编译完成后引擎会崩溃的问题。这个时候你的蓝图/C++类已经在游戏线程中了。

void ConstructorHelpers::CheckIfIsInConstructor(const TCHAR* ObjectToFind)
{
	auto& ThreadContext = FUObjectThreadContext::Get();
	UE_CLOG(!ThreadContext.IsInConstructor, LogUObjectGlobals, Fatal, TEXT("FObjectFinders can't be used outside of constructors to find %s"), ObjectToFind);
}

FUObjectThreadContext::Get()继承于TThreadSingleton这个类中

OK，那么现在获取到了线程中的路径了，那么就要加载UClass类了，但是这里就是比较有意思的地方了。

Class = ConstructorHelpersInternal::FindOrLoadClass(PathName, T::StaticClass());

这里的话其实逻辑上就是一个StaticLoadClass的封装而已，那么我为什么说有趣呢，其实就在这个StaticLoadClass上，之前因为一直使用LoadClass也是没怎么在意，但是翻了下源代码后突然找到了个比较有意思的地方

UClass* StaticLoadClass( UClass* BaseClass, UObject* InOuter, const TCHAR* InName, const TCHAR* Filename, uint32 LoadFlags, UPackageMap* Sandbox )
{
	check(BaseClass);

	UClass* Class = LoadObject( InOuter, InName, Filename, LoadFlags, Sandbox );
	if( Class && !Class->IsChildOf(BaseClass) )
	{
		FFormatNamedArguments Arguments;
		Arguments.Add(TEXT("ClassName"), FText::FromString( Class->GetFullName() ));
		Arguments.Add(TEXT("BaseClassName"), FText::FromString( BaseClass->GetFullName() ));
		const FString Error = FText::Format( NSLOCTEXT( "Core", "LoadClassMismatch", "{ClassName} is not a child class of {BaseClassName}" ), Arguments ).ToString();
		SafeLoadError(InOuter, LoadFlags, *Error);

		// return NULL class due to error
		Class = NULL;
	}
	return Class;
}

注意到了这里了嘛

UClass* Class = LoadObject( InOuter, InName, Filename, LoadFlags, Sandbox );

在生成UClass的时候其实是从UObject中派生出来的，这里的话其实说实在的如果仔细看过UObject和UClass的关系的应该不会太惊讶，我感觉这个地方其实有点发挥的空间。不过嘛估计也是一些歪门邪道了。就当看个乐子吧。