虚幻4随笔6 Object和序列化

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

诚如之前所说，虚幻4主要的一些特性都是由UObject穿针引线在一起的，想把虚幻玩到比较深的程度，UObject是迟早要面对、回避不得的问题，所以，准备在其它主题之前，先把UObject好好弄一下。UObject主要完成了哪些工作呢？私以为：

反射系统

UObject体系构建了整个虚幻反射系统的核心，每个UObject都来自于一个UClass，这个Class可以是Unreal Header Tool（以后统一遵循官网命名：UHT）生成的，也可以是来自于Blueprint生成的（UBlueprintGeneratedClass）。反射可以说是现在主流引擎的构建基础，对国内多数人而言，可能更熟悉的是Unity透过Mono构建出来的反射，它的重要性不言而喻。

反射很大一坨的东西，具体就不说了，它最大的作用，相当于在运行时动态生成代码，可以省掉很多手写代码的工作量。否则像UE这样复杂的界面，全部Hardcode，100人是绝对不够的，改一次所需的时间也是无法接受的。有了反射之后，剩下的很多就是很好理解的一条路就顺下来了：属性编辑器自动生成、自动消息包收发、自动序列化、自动生成BP节点、BP和C++的自动接口交互、自动浅拷贝深拷贝、甚至按照设定规则来进行拷贝……不胜枚举。

共通性都是一样：Get Class，Get Property，或者Get Function，分析Property和Function的属性，然后，设值、获取值、Invoke函数……

垃圾回收和生命期管理

UObject构建了虚幻的垃圾回收（GC）系统。GC这东西众说纷纭，但博主本人持乐观态度。最近的公司业务就遇到这么个事儿：脚本里需要发动态包，于是就需要在脚本里手动生成一个动态包，并挂接在包上面。为了完成这个目的，我就必须在脚本中制作一个生成动态包的节点，然后问题来了，我们必须还得要一个回收动态包的节点，否则这个动态包就无法回收……于是最后放弃了，回到了包里加各种Reserved的老路上去……有了GC，多数情况下都不用管这事儿……你让一个策划去理解回收这种事情，就是在给他们添麻烦，那本不是他们业务内的范畴。

GC的存在价值，并非是让事情变得简单这么简单，更多时候它能让你节省下很多编程心力，把精力花在真正该关注的地方。真GC出问题时去查错所带来的成本，未必比忘写delete带来的成本要大，说不定反而更小。

虚幻的垃圾回收系统，基本上就是从Root开始，不断遍历所有的Property，标记其为使用中。最后再遍历一遍，确认哪些Object没有标使用中就给它删掉。基本上，你不需要管这个过程，因为反射的作用，所以相关的信息都是UE自动就帮我们处理好的。有几个要注意的：

"Singleton"，需要一直存在的，直接AddToRoot。

F类本身是不走垃圾回收的，但是F 类内部又有U类，这种情况下你需要注意AddReferencedObjects。把F类内部的U类给加入到GC树上。

Classes里的类，标UPROPERTY的UObject属性会被自动加入到当前类的GC列表里，但不标的会不会，没有具体跟，反正习惯随手写个就行了。

TArray和TMap里面的UObject会被自动加入GC列表，但是如果写的是std::vector和std::map，则应该是不会的，需要手动用AddReferencedObjects加进去。

资源管理

UObject最后一个作用是构建了虚幻的资源管理体系。包括资源的搜索、资源之间的引用管理，下面详细展开。

首先要先说一下虚幻的Object命名，由于资源也都是UObject，所以其命名与UObject是同一个标准。按照现在的要求，是[类名']路径名/路径名/Asset名.[包内路径.]Object本名：[属性名][']（一般是Object所在类名+一个数字后缀）。比如：

Brush'/Script/Engine.Default__Brush'

BillboardComponent'/Script/Engine.Default__TextRenderActor:Sprite'

/Engine/TemplateResources/MI_Template_BaseGray_03_Metal.MI_Template_BaseGray_03_Metal

这个名称解析跟UE3和UDK略有不同，UE3由于基于upk来对包进行管理，而又限制Content文件夹下的Upk包不能重名，所以不需要前面的路径名。UE4基于Asset，Content不同子目录下可以有同名UAsset，所以路径名就是不可或缺的了。除此之外，Asset跟UPK没有太多不同，我们后面说包，也是指的UAsset，虽然看起来这个不像包。

理论上，所有的UObject都可以交由StaticLoadObject来加载（事实上也确实是这么做的），但是很多类是有基于LoadObject的特殊实现的，比如UClass（Blueprint Class），就必须用StaticLoadClass，而地图必须使用LoadMap，LevelStreaming这样地图相关的加载流程。这些变种的主要区别是会针对相应的情况做一些特殊的处理和操作。但是核心都绕不开StaticLoadObject。所以搞明白这个StaticLoadObject，实际上就搞明白了虚幻主要的资源组织结构。

主要的流程如下：

解析路径，找到对应包（UAsset或者UPK），如果还没加载则加载包。

判断Object是否已经加载，如果已经加载则直接返回。

对资源包的加载，会把整个资源包的所有Object全部预加载的（创建并调用PreLoad，对于资源等需要PostLoad的调用PostLoad）。同时，加载包时创建ULinkerLoad，这个LinkerLoad会自动分析每个包与其他包之间的关联，通过Imports来记录本包对其它包的引用，通过Exports记录本包内的Object。

加载后，看看目标对象是不是个Redirector，如果是Redirector，则说明"曾经有个包在这里，但是被移动到新地方去了"，就重定位到必要的地方。

说了这么多，其实你明白原理就很简单：虚幻所有对象都是按照一个包含了路径、包内路径、对象类名的唯一名称来命名的。而虚幻所有的包都是会记录对其它包的引用的。

所以一旦一个包的路径、对象的包内路径、以及对象类名本身发生变化，都可能会导致旧有资源的丢失和重定向。

当然，相关也都有一些机制可以帮助你事后修正（比如Redirector，Engine.ini里的Redirector config），但是，那都是补救措施，不能100%保证成功补救。好的情况，重新定位一下资源引用什么的就可以解决，但是最糟糕的情况下，有可能会导致数据丢失（其中最容易发生的就是因为BP类名修改，导致子BP类无法找到父BP类而导致子类无法正常使用只能删了重来……）

所以，在做UE4的包路径转移、资源名修改之前，一定要做好备份工作。最好是把所有原型迭代完毕后，统一进行类似操作，并经常存档或发SVN、GIT。