Unreal 浅谈TWeakObjectPtr
- 作者:admin
- /
- 时间:5月24日
- /
- 浏览:1079 次
- /
- 分类:厚积薄发
【USparkle专栏】如果你深怀绝技,爱“搞点研究”,乐于分享也博采众长,我们期待你的加入,让智慧的火花碰撞交织,让知识的传递生生不息!
前言
在Unreal的开发过程中,正确的引用和管理UObject是十分重要的,尤其Unreal有着它自己的UObject的GC机制,这使得对UObject的有效引用和管理变得尤为关键。不正确的引用UObject将造成循环引用或者影响该UObject的生命周期,这都是不希望看到的。所以Unreal通过TWeakObjectPtr提供一种弱引用来解决这个问题,在本篇文章中将详细探讨TWeakObjectPtr的工作原理。
TWeakObjectPtr是什么?
TWeakObjectPtr是UE4中的一个C++模板类,用于存储对UObject以及其派生类的弱引用。在UE4中UObject是所有游戏对象的基类,包括角色、场景组件、蓝图等,并且UE提供了一套GC机制来管理UObject的生命周期。弱引用意味着TWeakObjectPtr不会阻止其引用的UObject被GC销毁。这在某些情况下是非常有用的,比如当你需要访问一个UObject时,但不希望因为你的对UObject引用而导致永远不会被销毁。
示例代码如下所示,这里引用一个AActor*指针并且使用UPROPERTY将其纳入到UE的GC机制,这种写法相当对该AActor就添加了一次引用,意味着该Actor将不会被GC。当然如果使用TWeakObjectPtr来包装对应AActor,这样可以使用该AActor,但是并不会阻止其GC。
UPROPERTY()
AActor* A;
TWeakObjectPtr<AActor> A;
A = GetXXXActor();
当然既然TWeakObjectPtr不会影响对应UObject的GC流程,那么使用时也需要注意其有效性。使用前当然需要检验当前UObjecct的可用性,TWeakObjectPtr提供了IsValid方法用于判断引用的UObject是否可用,Get方法则会返回一个UObject指针。具体代码如下所示:
AMyActor* Actor
TWeakObjectPtr<AMyActor> ActorReference = Actor;
.......
if (ActorReference.IsValid())
{
// 使用Get()方法获取对象指针
AMyActor* ValidActor = ActorReference.Get();
// 在有效的Actor上执行操作
ValidActor->SomeMethod();
}
else
{
// TWeakObjectPtr无效,可能是因为对象已被销毁
UE_LOG(LogTemp, Warning, TEXT("Actor reference is invalid!"));
}
TWeakObjectPtr实现
接下来看看TWeakObjectPtr的实现。TWeakObjectPtr的声明如下所示:
template<class T=UObject, class TWeakObjectPtrBase=FWeakObjectPtr>
struct TWeakObjectPtr;
template<class T, class TWeakObjectPtrBase>
struct TWeakObjectPtr : private TWeakObjectPtrBase
可以看出TWeakObjectPtr是一个模板类,它继承自TWeakObjectPtrBase(一般默认为FWeakObjectPtr)。TWeakObjectPtr的模板参数T表示要引用的UObject派生类的类型,而模板参数TWeakObjectPtrBase表示实际弱引用实现的类型,也就是说TWeakObjectPtr实际上是FWeakObjectPtr的模版化包装。在Unreal中有很多的例子,当你看到TXXX的模板类时,应该想到后面有一个FXXX类在默默支持它。首先来看看隐藏在幕后的FWeakObjectPtr吧!
需要注意的一点,Unreal的实现使用的是Private继承。可能平时开发中使用Private继承的场景相对较少,但是对于各种基础库中使用Private继承还是不少的。略微揣摩一下Unreal使用Private继承的意图所在,先列一下Private继承可能会发挥到的作用:
- Private继承表面是继承,其实本质是一种更加简便达到组合的方式,子类和父类并不是Is-a的关系。完全避免类型兼容原则(子类可被认为是父类),可显示阻止不合理的类型转化(编译期暴露问题)。
- 使用继承便可以利用上空基类优化(EBO)以减少内存占用。
- 不希望派生类的子类直接使用基类的任何变量和方法(可以用using改变可见性)。
- 派生类可以覆盖基类的虚函数,但是不将这些函数暴露给外部。
第1、2点应该是Unreal使用Private继承来实现的原因,首先是符合语义,本质上TWeakObjectPtr是FWeakObjectPtr的一层模板包装,这也就是一种组合的实践方式;其二就是能够享受空基类优化来减少内存占用。对于第3、4点来说,一是FWeakObjectPtr并没有虚函数,二是一般来说正常开发流程中不会再去继承TWeakObjectPtr了。所以在这里第3、4点效果并无体现。
接下来看看FWeakObjectPtr的具体实现。具体的文件路径:\Engine\Source\Runtime\CoreUObject\Public\UObject\WeakObjectPtr.h
先列出一些重要的代码,更多细节请看源码:
struct FWeakObjectPtr
{
public:
FORCEINLINE FWeakObjectPtr()
{
Reset();
}
FORCEINLINE void Reset()
{
ObjectIndex = INDEX_NONE;
ObjectSerialNumber = 0;
}
FWeakObjectPtr(const FWeakObjectPtr& Other) = default;
FWeakObjectPtr& operator=(const FWeakObjectPtr& Other) = default;
COREUOBJECT_API class UObject* Get(bool bEvenIfPendingKill) const;
COREUOBJECT_API class UObject* Get(/*bool bEvenIfPendingKill = false*/) const;
COREUOBJECT_API bool IsValid(bool bEvenIfPendingKill, bool bThreadsafeTest = false) const;
COREUOBJECT_API bool IsValid(/*bool bEvenIfPendingKill = false, bool bThreadsafeTest = false*/) const;
private:
FORCEINLINE FUObjectItem* Internal_GetObjectItem() const;
FORCEINLINE_DEBUGGABLE bool Internal_IsValid(bool bEvenIfPendingKill, bool bThreadsafeTest) const;
FORCEINLINE_DEBUGGABLE UObject* Internal_Get(bool bEvenIfPendingKill) const;
int32 ObjectIndex;
int32 ObjectSerialNumber;
}
Unreal的UObject管理
这里需要额外关注的就是ObjectIndex和ObjectSerialNumber字段,你可能会疑惑为什么只需要两个int32类型就可以了,甚至在FWeakObjectPtr中都不需要存储任何的UObject。这和Unreal对于UObject管理有关。首先在Unreal中所有的UObject对象都会放到FUObjectArray来管理,在UObjectBase构造时会调用AddObject,再将AddObject调用AllcateUObjectIndex函数的UObject放到一个FUObjectArray对象中,如下所示:
![](http://uwa-ducument-img.oss-cn-beijing.aliyuncs.com/Blog/USparkle_TWeakObjectPtr/1.png)
并且在AllocateUObjectIndex中会构造一个FUObjectItem对象并会将FUObjectItem和UObject两者一一对应,同时广播UObjectCreate事件,如下图所示:
![](http://uwa-ducument-img.oss-cn-beijing.aliyuncs.com/Blog/USparkle_TWeakObjectPtr/2.png)
FUObjectItem对象会保存指向对应UObject的指针,UObject持有InternalIndex以便后续直接拿到对应的FUObjectItem。因为FUObjectItem持有UObject的指针(双向奔赴了),所以在UObject销毁时广播UObjectDelete事件,调用FreeObjectIndex后对应的FUObjectItem也会被销毁。
![](http://uwa-ducument-img.oss-cn-beijing.aliyuncs.com/Blog/USparkle_TWeakObjectPtr/3.png)
看到这里就可以知道Unreal并不直接管理具体的UObject,而是通过FUObjectItem去获取对应的UObject,并且这个FUObjectItem相当的轻量,所以在FUObjectArray持有一个FChunkFixedUObjectArray来储存所有的FUObjectItem。它们之间的关系可以通过下面这张图来解释:
![](http://uwa-ducument-img.oss-cn-beijing.aliyuncs.com/Blog/USparkle_TWeakObjectPtr/4.png)
还有FUObjectHashTables也是管理全局UObject对象,但是它是维护UObject名字(Name)到对象指针的映射,父子(Outer)对象之间的映射等,方便对UObject进行查找等操作和FWeakObjectPtr实现关系不大,所以在这里就不展开了。
现在已经知道ObjectIndex是被用于获取指定的UObject,那么ObjectSerialNumber是用来干什么的呢?还得补充一个知识点,那就是ObjAvailableList其实在AllocateUObjectIndex的实现是有用到的。获取对应的Index时会优先从ObjAvailableList获取一个可用的索引,无需遍历寻找。如果ObjAvailableList没有,则FChunkFixedUObjectArray需要扩容。
![](http://uwa-ducument-img.oss-cn-beijing.aliyuncs.com/Blog/USparkle_TWeakObjectPtr/5.png)
当然在FreeObjectIndex调用时,会向ObjAvailableList放入新的索引。
![](http://uwa-ducument-img.oss-cn-beijing.aliyuncs.com/Blog/USparkle_TWeakObjectPtr/6.png)
这就代表InternalIndex是循环使用,这样索引缓存机制会带来一个问题,那就是Unreal只会保证在同一时刻的所有的UObject的InternalIndex是不同的,但是在不同的时间下,不同的UObject会持有相同的InternalIndex。这对于FWeakObjectPtr来说显然是有问题的,因为可能会有FWeakObjectPtr当前指向的UObject并不是当初的UObject,但是它们的InternalIndex还是相同的,所以在这里多加了一个ObjectSerialNumber来确保能找到唯一的UObject。
ObjectSerialNumber是一个递增的数字,每当通过UObject去创建一个FWeakObjectPtr时都会递增,也就是ObjectSerialNumber并不会重复(当然你可能会担心int32会不会爆掉,但是你得先创建21亿个FWeakObjectPtr,如果真出现这种问题,你应该优先考虑为什么会有21亿个FWeakObjectPtr,而不是担心它会爆掉),同时这里会对FUObjectItem中的SerialNumber做比较。具体代码如下所示:
![](http://uwa-ducument-img.oss-cn-beijing.aliyuncs.com/Blog/USparkle_TWeakObjectPtr/7.png)
也可以从FWeakObjectPtr的一些实现,看出ObjectSerialNumber的意义所在,比如==和!=的运算符重载函数,这里都对ObjectIndex和ObjectSerialNumber进行了双重验证,才能真正确认指向的UObject是当初哪个。
![](http://uwa-ducument-img.oss-cn-beijing.aliyuncs.com/Blog/USparkle_TWeakObjectPtr/8.png)
到这里ObjectIndex和ObjectSerialNumber字段的含义就解释完毕。
回到FWeakObjectPtr
可以继续看FWeakObjectPtr的一些重要的实现。首先来看一下针对UObject的赋值构造函数,这是通过FUObjectArray的ObjectToIndex函数获取到对应的Index,并且通过AllocateSerialNumber函数生成唯一的ObjectSerialNumber,最后还调用了SerialNumbersMatch函数以确保UObject唯一性。
FORCEINLINE_DEBUGGABLE bool SerialNumbersMatch() const
{
checkSlow(ObjectSerialNumber > FUObjectArray::START_SERIAL_NUMBER && ObjectIndex >= 0); // otherwise this is a corrupted weak pointer
int32 ActualSerialNumber = GUObjectArray.GetSerialNumber(ObjectIndex);
checkSlow(!ActualSerialNumber || ActualSerialNumber >= ObjectSerialNumber); // serial numbers should never shrink
return ActualSerialNumber == ObjectSerialNumber;
}
void FWeakObjectPtr::operator=(const class UObject *Object)
{
if (Object // && UObjectInitialized() we might need this at some point, but it is a speed hit we would prefer to avoid
)
{
ObjectIndex = GUObjectArray.ObjectToIndex((UObjectBase*)Object);
ObjectSerialNumber = GUObjectArray.AllocateSerialNumber(ObjectIndex);
checkSlow(SerialNumbersMatch());
}
else
{
Reset();
}
}
接下来就是FWeakObjectPtr的一些常用方法的实现,比如Get和IsVaild的实现都是通过以下函数实现的。主要就是通过ObjectIndex和ObjectSerialNumber判断当前的FWeakObjectPtr是否可用的操作。当调用Get,如果ObjectItem可用则直接返回UObject指针否则返回nullptr。
FORCEINLINE FUObjectItem* Internal_GetObjectItem() const
{
if (ObjectSerialNumber == 0)
{
checkSlow(ObjectIndex == 0 || ObjectIndex == -1); // otherwise this is a corrupted weak pointer
return nullptr;
}
if (ObjectIndex < 0)
{
return nullptr;
}
FUObjectItem* const ObjectItem = GUObjectArray.IndexToObject(ObjectIndex);
if (!ObjectItem)
{
return nullptr;
}
if (!SerialNumbersMatch(ObjectItem))
{
return nullptr;
}
return ObjectItem;
}
FORCEINLINE_DEBUGGABLE bool Internal_IsValid(bool bEvenIfPendingKill, bool bThreadsafeTest) const
{
FUObjectItem* const ObjectItem = Internal_GetObjectItem();
if (bThreadsafeTest)
{
return (ObjectItem != nullptr);
}
else
{
return (ObjectItem != nullptr) && GUObjectArray.IsValid(ObjectItem, bEvenIfPendingKill);
}
}
FORCEINLINE_DEBUGGABLE UObject* Internal_Get(bool bEvenIfPendingKill) const
{
FUObjectItem* const ObjectItem = Internal_GetObjectItem();
return ((ObjectItem != nullptr) && GUObjectArray.IsValid(ObjectItem, bEvenIfPendingKill)) ? (UObject*)ObjectItem->Object : nullptr;
}
FWeakObjectPtr的解读就到这里。
看向TWeakObjectPtr
现在来看看TWeakObjectPtr是如何做好一个模板包装器的作用的。Get和IsVaild函数基本都是使用FWeakObjectPtr的实现,这里就不重复提及了。来看看一些不一样的操作,比如是TWeakObjectPtr和拷贝构造和赋值构造,如下所示:
template <typename OtherT,typename = decltype(ImplicitConv<T*>((OtherT*)nullptr))>
FORCEINLINE TWeakObjectPtr(const TWeakObjectPtr<OtherT, TWeakObjectPtrBase>& Other) :
TWeakObjectPtrBase(*(TWeakObjectPtrBase*)&Other) // we do a C-style cast to private base here to avoid clang 3.6.0 compilation problems with friend declarations
{
}
template <typename OtherT,typename = decltype(ImplicitConv<T*>((OtherT*)nullptr))>
FORCEINLINE TWeakObjectPtr& operator=(const TWeakObjectPtr<OtherT, TWeakObjectPtrBase>& Other)
{
*(TWeakObjectPtrBase*)this = *(TWeakObjectPtrBase*)&Other; // we do a C-style cast to private base here to avoid clang 3.6.0 compilation problems with friend declarations
return *this;
}
这里使用decltype(ImplicitConv((OtherT*)nullptr))来做了一个是否能够隐式转换的检测,如果不可以隐式转换则直接在编译期报错。确保这里传入的类型都是兼容的,随后就是对TWeakObjectPtrBase初始化的操作。
接下来看到TWeakObjectPtr另外一个赋值构造函数,具体实现如下所示:
template<class U>
FORCEINLINE typename TEnableIf<!TLosesQualifiersFromTo<U, T>::Value, TWeakObjectPtr&>::Type operator=(U* Object)
{
T* TempObject = Object;
TWeakObjectPtrBase::operator=(TempObject);
return *this;
}
这里使用TEnableIf和TLosesQualifiersFromTo两个模板元类,TEnableIf实现如下所示,很简单就能理解其用途,TEnableIf的主要作用是根据给定的条件(模板参数Predicate)来启用或禁用某个类型。
template <bool Predicate, typename Result = void>
class TEnableIf;
template <typename Result>
class TEnableIf<true, Result>
{
public:
using type = Result;
using Type = Result;
};
template <typename Result>
class TEnableIf<false, Result>
{ };
但是TLosesQualifiersFromTo是由多个模板类组合而来,首先是TAreTypesEqual,如下所示,TAreTypesEqual用于比较两个类型是否相等。如果给定的两个类型相等,它的Value成员变量将被设置为true,否则为false。
template<typename A,typename B>
struct TAreTypesEqual;
template<typename,typename>
struct TAreTypesEqual
{
enum { Value = false };
};
template<typename A>
struct TAreTypesEqual<A,A>
{
enum { Value = true };
};
随后是TCopyQualifiersFromTo,它的作用就是将一个类型的const和volatile限定符复制到另一个类型上。
template <typename From, typename To> struct TCopyQualifiersFromTo { typedef To Type; };
template <typename From, typename To> struct TCopyQualifiersFromTo<const From, To> { typedef const To Type; };
template <typename From, typename To> struct TCopyQualifiersFromTo< volatile From, To> { typedef volatile To Type; };
template <typename From, typename To> struct TCopyQualifiersFromTo<const volatile From, To> { typedef const volatile To Type; };
最后TLosesQualifiersFromTo的实现如下所示,它的主要作用是判断从一个类型From复制限定符到另一个类型To时,是否会丢失任何限定符。
template <typename From, typename To>
struct TLosesQualifiersFromTo
{
enum { Value = !TAreTypesEqual<typename TCopyQualifiersFromTo<From, To>::Type, To>::Value };
};
那么重新回到TWeakObjectPtr的赋值构造函数,使用这些模板类的目的在于检查只有在U类型的限定符不会在赋值时丢失时,才可以进行赋值操作。关于TWeakObjectPtr中的其他的函数就不再赘述,若大家感兴趣可以翻翻源码!
总结
TWeakObjectPtr是一个平时在开发过程中出现频率很高的工具,通常对于一些不确定其生命周期的UObject对象都可以通过TWeakObjectPtr包装一层以避免循环引用问题,并且可以避免对其UObject生命周期有所影响,确保引用的对象在其生命周期内被正确管理。当然在搞清楚TWeakObjectPtr的实现中也学到了很多其他知识,比如UObject在Unreal中是怎么被管理,当然还有一些模板元编程的技巧。
References
WeakObjectPtr
这是侑虎科技第1598篇文章,感谢作者不知名书杯供稿。欢迎转发分享,未经作者授权请勿转载。如果您有任何独到的见解或者发现也欢迎联系我们,一起探讨。(QQ群:793972859)
作者主页:https://www.zhihu.com/people/lllzwj
再次感谢不知名书杯的分享,如果您有任何独到的见解或者发现也欢迎联系我们,一起探讨。(QQ群:793972859)