1.UObject
众所周知UObject是虚幻基础的基类，干了很多事。
1）Garbage collection 垃圾回收
C++的内存管理是由程序员完成的。一个对象可能由多个对象引用。那么不需要这个对象的时候，该不该释放这个对象所在的内存区域呐？
释放：一旦有别的对象引用该对象，释放后就会产生野指针。当另一个对象来访问时会看到空空如也甚至是其他对象的内存区域。
不释放：这片内存区域永远无法被回收。
解决方案：
①继承自UObject类，同时指向UObject类实例对象的指针成员变量，使用UPROPERTY宏进行标记。虚幻引擎的UObject架构会自动的被UProperty标记的变量考虑到垃圾回收系统中，自动的进行对象的生命周期管理。
②采用智能指针。非Object类型才可以使用智能指针进行自动内存释放。
2）Reference updating 引用自动更新
3）Reflection 反射
4）Serialization 序列化
当你希望把一个类的对象保存到磁盘，同时希望下次可以完好无损的加载，那么同样需要继承自UObject类。
5）Automatic updating of default property changes 自动检测默认变量的更改
6）Automatic property initialization 自动变量初始化
7）Automatic editor integration 和虚幻引擎编译器的自动交互
虚幻引擎的Editor面板，希望能够编辑，则需要继承自UObject类。
8）Type information available at runtime 运行时类型识别
虚幻引擎打开了/GR-编编译器参数。意味着你无法使用C++标准的RTTI机制：dynamic_cast。如果你希望使用，请继承自UObject类，然后使用Cast<>函数完成。虚幻自己实现了一套自己的，更高效的运行时类型识别的方案。
9）Network replication 网络复制
当你再进行网络游戏开发(c/s架构)时，你一定希望能够有自动的处理变量的同步。而继承自UObject类，其被宏标记的变量能够自动的完成网络复制的功能。从服务器端复制变量到对应的客户端：
①构造函数并不是游戏运行的时候调用，同时即便你只有一个UObject对象存在于场景中，构造函数依然会被调用两次。
②构造函数被调用的时候UWorld不一定存在。
2.Actor
能够被挂在组件。
而坐标与旋转，只是一个SceneComponent组件。如果这个Actor不需要一个固定位置，就可以不给这个Actor挂SceneComponent。
希望Actor被渲染则挂一个静态网格组件。
希望Actor有骨骼动画，则挂一个骨架网格组件。
希望Actor移动，挂一个Movement组件。
3.Pawn
被“操作”的特性。它能够被Controller操作，这个Controller可以是玩家也可以是AI。
4.Character
Character继承自Pawn。Character提供了一个特殊的组件-CharacterMovement，这个组件提供了一个基础的，基于胶南体的角色移动功能，包括跳跃移动，如果需要，还可以扩展，蹲伏和爬行。
5.Controller
Controller是漂浮于Pawn/Character之上的灵魂。他操作着Pawn和Character的行为。Controller可以是AIController，你可以在这个类中使用虚幻优秀的行为树/EQS环境查询系统。也可以是玩家，PlayerController，可以在这个类中绑定输入，然后转换为对Pawn的指令。为何如此设计，Epic给出“不同的怪物也会共享同样的Controller，从而获得类似的行为”。既然是是灵魂，肉体就不唯一，灵魂可以通过Possess/Unpossess来控制。