标签：style blog http io color os ar 使用 sp
诚如之前所说，虚幻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。
?
?
Redirector需要提醒一点，虚幻里进行资源文件从一个文件夹到另一个文件夹的移动，一定要在编辑器中进行。因为虚幻资源之间的引用关系是通过前面说的Object命名来保证的，而路径名又是Object的一部分，名称不对等很容易发生问题。而编辑器移动资源后，有时候会发现移动前所在的路径下多了一个1KB字节左右小尾巴，这个小尾巴就是Redirector，同样不要手动删除，而是要在资源查看器里，通过对Redirector（需要Filter开启）的Fix up命令来进行删除。
先把Redirector打开
然后Fixup，或者
右键直接文件夹，Fix up Redirectors in Folder。
?
由于包是"Link Load"的，加载过程中会分析引用，所以如果包比较碎，这里就会由于做了更多的文件访问而导致速度变慢。单如果单个包内数据量较大，则也会导致加载单个包时速度变慢的情况，归根到底，就是权衡啊权衡。（一般说来，10个1k > 1个10k）
?
Transient对象不会被存盘，Transient包（GetTransientPackage）是一个特殊的包，所有临时对象都应该创建在这个包里面。
?
异步实际并非真正异步。LoadObject加载过程中有一系列的全局变量，而且这些全局变量维护时没有任何锁，所以也无法真正做到异步加载。所以虽然您看到接口上有LoadPackageAsync，但那个的实现是在主线程每帧区分时间片来实现的。不过话说回来，多线程读包真的有必要吗？机械硬盘的访问速度本身是最大的限制因素，读包过程中的多线程，CPU其实帮不上任何忙。
?
真正大量磁盘或网络数据的异步加载可以参考Texture Streaming（为何只有Texture做了Streaming就是因为这玩意儿现在是游戏最吃资源的了，十个模型的资源量不见得比得上一张贴图啊），先把Object和少量基本信息当作占位符加载进来，Object的实际数据则放到其他线程里慢慢加载。如果您有类似需求，可以考虑这个方案。不过感觉是没必要，比如我们游戏常用的角色异步加载什么的，其实走主线程时间片完全够了。
?
编辑器中的资源会被标记为Standalone，在无引用时仍然存在，其它还有一系列不会被GC的情况，需要注意。
标签：style blog http io color os ar 使用 sp
原文地址：http://www.cnblogs.com/noslopforever/p/4058304.html
