本文仅代表个人观点，与任何组织立场无关。

　　这是一篇引导性的文章，并不会涉及非常深度的解析，其目的并非全面否定这个引擎，而是在盲目跟风的潮流中让并不是很了解这个引擎的人率先了解这个巨大的引擎中存在的史诗级大坑(主要强调设计和架构上的)，以提前做出措施，避免搬石头砸了自己的脚。

　　UE4 是一个优秀的实时渲染器，一个半成品游戏，也是一个辣鸡引擎，如果你有能力只把他当作渲染器用(其余部分自己造)那他会是一个好工具。

　　引擎价格什么就不多说了，大家心里清楚。

　　UE4 的代码基本来源于 Epic 自己开发的游戏，这也是他半成品游戏的性质的来源，你能在这个引擎里见到不少奇怪的东西：内置的伤害逻辑，背包逻辑，更可气的是，这些逻辑还可能耦合了一部分引擎逻辑，导致无法去掉(比如破碎体)。 由此也引发了一个有趣的现象：除了一线厂商的 3A 大作，基于 UE4 开发的游戏都会有十足的即视感，其原因不光是独家的渲染错误，还有这个半成品游戏的性质，大部分的游戏只是在做一个补全，则同质化严重必定发生。

　　UE4 的开源固然有对行业的推进作用，但这里换个角度去思考你就会发现

　　这个引擎不开源，就根本没法用：难以置信的把 Gameplay 都放在了 Cpp 层，大量的功能根本不存在上层接口(也没有上层编程工具，别说蓝图)。把自己的问题甩锅出去，“源码都给你了你不会自己改吗”的言论随处可见，但是就算我自己改了，由于不存在 API，和官方修改的冲突概率也极大，合并的过程中更是容易产出巨量的 bug。掩饰文档缺失的问题，大量模块在长时间内基本没有文档描述(比如 GPA 模块)，没有源码拿头去用。实际引擎的工具部分并不是真正的开源，或者说“开源不开放”，用户并没有自由修改的权利。补一张图，见文章结尾。 人是人他妈生的，妖是妖他妈生的，只要你有一颗善良的心就不再是妖，是人妖？

　　这部分大多内容是继承自 UE3 的。

　　By Design 的内存泄漏，只要加载了资源就永不释放，包括不允许手动释放，导致项目达到一定规模的时候需要经常通过重启引擎来清理内存，而相应的，这种规模的项目重开引擎消耗的时间是巨量的(即便 UE4 拥有 On Demand 的加载，但是 Resource Registry 是需要初始化的)。

　　PackageName 直接是路径引用，没有中间层，导致移动文件位置就需要修复引用，然后造成的后果有：

　　需要加载引用的文件，进而触发内存泄漏，如果文件过多则会导致内存爆炸修复引用会修改此文件，在版本管理中会产生大量的文件更改，并且可能 Block 他人的工作如果错误的在外部移动了文件(包括项目之间复制文件的情况)引用会全部丢失，基本无法修复重定向器在版本管理中非常容易埋坑(没有上传重定向器)，所以基本需要立即修复，也就是这个特性基本没有存在的意义，那么他为什么还要存在呢？因为在版本控制中每个人可能有提交权限，如果有人修改了一个文件波及了整个项目，但自己又没法提交这些修改，就会造成大量的冲突，所以需要上传重定向器让每个人修复自己目录中的重定向器。

　　所有资源导入之后，会经过解析-生成 UObject-序列化 UObject 的过程，变成 UE4 自己的 uasset 文件，这导致 DCC 产出的文件和项目中的文件需要分别维护并且手动同步，而从其他项目(商城)获取的资源，则需要手动导出，修改再重新导入的流程，效率极其低下不说，还另自定义资源管线的搭建极其困难。举例来说，当需要批量处理资源的时候，基本没法利用外部的工具，甚至还很容易触发内存泄漏导致内存爆炸。 对于版本合并而言，这还会导致文本类资源无法进行版本管理的合并且非文本类资源的修改判断也会被 UE4 残缺的资源修改判断拖累(UE4 只判断修改，不判断值)，进一步说，这种做法没有拆分“资产”和“资源”，很多时候资产明明没有改动却会引起 uasset 的变动(比如由依赖链上游的变动引起)。

　　一些资源或者功能存在过度的资源捆绑，比如多边形碰撞捆绑在 Mesh 上面，或者 StaticMeshComponent 既有 RenderMesh 的功能也有 SimulationPhysics 的功能。

　　材质采用饥渴式的编译模式，每个材质会为每个 Vertex Factory 生成一份 Shader 并立即编译，这意味着一个小的改动就可能触发上千个 Shader 编译，而 Shader 的编译方式沿用了 UE3 的 ShaderCompileWorker 的多进程编译方式，管理完全交给了操作系统，这造成了性能和内存的双重损失，其资源占用这在中低端机上基本是不可承受的，磁盘占用量也十分巨大。

　　U++ 和 BP，不是……不要误会，我不是针对你，我是说在座各位，都是垃圾

　　U++ 由几大部分组成：C++，UBT，UHT&UObject、 首先是万恶之源 C++：

　　贫瘠的模块管理就算是 UBT 也没法救场，一个 #include 直接引入几万行代码的编译时间引擎代码里面元编程技巧一个不少，编译时间原地起飞，芜湖！热更新？不存在的，给爷关了编辑器再编译完全自己造了一套标准库，但标准库的糟粕也照搬不误没有沙箱环境，游戏代码崩溃引擎也一起崩

　　然后是亡羊补牢的 UBT：

　　为了减少编译时间，使用了联合编译(即合并文件),导致了很多问题导致有时编译错误不在真正错误的文件漏掉对头文件的导入也可能因为别的文件已经导入而错误的编译通过(并在某个时间突然报错)在不同 Cpp 定义的本地 Symbol 也可能因为合并出现重复定义对IDE智能提示很不友好，IDE 甚至会采取激进的扫描法尽可能的扫描多的头文件，这对于中低端机也是致命的(智能提示每5分钟刷新一次体验过吗？)

　　最后是天外来客 UHT/UObject：

　　UHT 基于手写的 Parser，基本没有复用性，代码生成阶段不可扩展，用户能添加的只有字符串形式的 runtime 的 meta 信息反射采用保守式的标记，必须手写 UPROPERTY 而不是 UNOREFLECTION，这意味着基本每行都要写上这玩意，代码很难看，且会导致漏写导致 GC 出问题的情况标记采用宏的形式，导致 IDE 的排版煞笔为了减少编译时间(存疑)，反射采用完全的运行时反射，没有编译期信息UObject 体量十分恐怖，甚至还有一层 UObjectBase引入了 GC 的问题，配合上粒子系统之类的超重 GC 的实现，不注意池化一样起飞反射的数据结构不支持直接嵌套，必须要手动加中间层绕过

　　首先蓝图的本质就是脚本语言(引擎也没有提供任何其他上层语言)，这带来了一个困境：

　　对于非(游戏)专业团队/和业余制作，蓝图用起来非常爽。业余进阶到专业会经历 BP 到 C++ 的直线式难度曲线，大概率暴毙。对于小的制作团队，等等，小的制作团队用个锤子 UE4。对于大的制作团队，分工明确，策划其实不会参与太多的逻辑编写，这意味着蓝图大部分时间都是程序在使用，程序都写 C++ 了还会写不来脚本？

　　从而蓝图存在的意义根本站不住脚：有用，但没那么有用，如果拿蓝图和传统的脚本比较的话，问题就太多了： 匮乏的语言 Feature，甚至远低于 Lua：

　　没有 First Class Function，委托是专门开的一个洞，也就意味着高阶函数根本不可能，连个排序函数都写不出来，这使得其代码繁琐程度甚至大于其他语言没有符号引用，而是硬引用，这使得其他语言常见的函数/变量替换成为不可能(这也是下面 C++ 改名爆炸的原因)。扩展能力极差，比如蓝图本身没有任何书写异步逻辑的能力，必须要在 C++ 层面以极其繁琐的方式扩展(因为垃圾 C++ 也没有协程)权限管理是完美的形式主义，设置为私有得变量其实也能被其他蓝图访问C++ 层没有任何方便的 API 来访问蓝图方的变量，且蓝图往 C++ 迁移也是非常费时费力的工作多层数据结构必须要多个文件，而不能像传统语言一样单文件写完入土的变量域支持，入土的临时变量支持，一条线能拉穿整个屏幕，也能开枝散叶热更新想都别想，不存在的信息密度极低，a2+b2+2ab 你觉得蓝图要连多少(滑稽)

　　贫乏的编辑器支持：

　　上下文搜索困难，信息密度极低，二流 ide 的水平不支持叠(Stack)节点，满屏白线十分难看且浪费空间本地化后搜索问题很大(比如用英文搜索汉化的节点)且中文搜索不支持拼音，还要我打开输入法打字？匮乏的传播渠道，各种截图看得揪心，你能把蓝图放github上预览？(不过有dalao做了网页版的蓝图作为中转)

　　贫乏的迭代支持：

　　C++ 中的重构(如重命名)会导致蓝图出现大量错误，且无法简单修复。修改结构类型导致大量错误，举例来说：1.修改变量A的类型从T1到T2 2.修改函数参数类型从T1到T2 这种操作在基于文本的脚本中很常见，但是在蓝图中会导致编译错误，需要手动刷新 pin

　　各种实现上的问题：

　　蓝图中只要用到了其他蓝图类型就会硬引用其他蓝图，包括 Cast，导致爆炸式加载蓝图存在惰性编译的现象，有时C++ 层改变后，导致了蓝图错误，不会有任何报错，直到手动点一下蓝图编译按钮，并且很多线会断掉BUG 奇多，各种默认值清零的现象(比如和父类重名了)， 甚至蓝图损坏后可能导致启用引擎直接崩溃，只能二分差错 你回火星吧，地球是很危险的

　　这玩意对比 MFC 有过之而无不及，是伟大的文艺复兴。

　　基于 C++ 的 Layout 和 Style 系统走到了现代兴起的 WYSIWYG 的反面极端，实现-预览的循环周期无限长奇葩的 Style，一部分名为 Style 实为图元，一部分针对控件毫无复用性基于 Slot 的零碎式排版设计友好至极，每种都有自己独特的 API 和排版实现界面反射器辣鸡至极，只能查看层级，连布局都没法查看，更不用说 Style。完全缺失的索引机制(为了类型安全？)，控件复用套娃困难完全的 Retain Mode 配合上 C++ 产生完美的回调地狱，代码美如画基于运算符重载的编排语法与 IDE 自动排版天生八字不合，混乱代码大赛Retain Mode 的写法却用着 Immediate Mode 的渲染机制，达成了鱼和熊掌兼得的成就，代码难写效率还低，真有你的 UE4

　　UMG 就更离谱了，内核就只是 Slate 的 UObject 包皮版本，配上了一个最差的编辑器

　　不存在 Template，自定义控件虽然能组合基本控件，但他就真的只是一个控件(子控件对外部不透明)相应的，列表之类的动态生成控件的场合需要手动初始化空间以及 Slot 而不能复制一个模板同样的，继承控件也无法看到其子控件没有命名约束，没有索引机制，完全基于委托的回调机制配合蓝图的委托特性可以说难用至极完全基于 2D 的渲染(继承自 Slate)，3D 元素混排十分困难裸体的输入接口，只能处理原始的输入信号，并不能使用输入映射机制(在非 UI Only 模式下可以使用 Listen for Input Action)概念残缺，没有页面之类的概念，全部需要用户自己造轮子无法预览 Navigation，只能启动测试，残废功能。更离谱的是，修改 Navigation 的设置，需要重启界面才能生效，否则是无效的。有意思的是，从 Slate 到 UMG 的传承，还把 Style 给传没了，导致所有设置都集中在了控件上，复用性为0

　　扩展 Editor 工具的门槛极其高且代码极其繁琐

　　大量控件和反射系统耦合，自定义面板很多时候会被逼使用 引入额外的复杂度，而且其内部实现逻辑混乱，不少引擎内部的类型却使用了 来实现，导致复用更加困难巨量的 API 放置在 Private 文件夹里，Public 文件夹的 API 也看心情添加 XXX_API 导出，有几乎一半的 Public API 没有导出纯手动模式，没有使用任何反射特性，所有的行为都要手动注册回调，代码写起来极其繁琐真正的 0 文档支持，需要花费大量时间在引擎代码里摸瞎，且不同模块的实现风格差异巨大且混乱，各种范式的影子都能看到(什么 MVVM，MVC)，但又一个都不是病态的 SharedPtr 使用，推荐删掉裸指针(滑稽 作为一个“开源引擎”推动者，却拥有着如此差劲的社区体验，也不失为一种行为艺术

　　Epic launcher 登陆不上，卡顿是习以为常的现象，账号邮箱丢失也没有直接换的方法官方文档丰富度远远不够，很多内容藏在了官方发布的直播里，但直播的信息密度往往很低，需要消耗大量时间去学习(本来想喷下wiki，但发现官方光速整改还是点个赞吧)官方论坛，文档网站在国内都很慢，翻译质量有限引擎的开发进度几乎不透明(因为内部项目不透明)，Roadmap 基本是摆设引擎充满了饭圈气氛，而不是技术崇拜。官方代码的复用程度极其的低，导致插件开发门槛很高，最近补充了基于 UMG 的编辑器工具支持，但作用没有想象中大API 没文档不说，还随心所欲的导出，见文章末尾图官方插件说是插件但基本没有插件的意义：直接内置到引擎核心组件，唯一的好处就是你可能可以自己复制出来修改。。。相应的引擎的模块化很不错，但模块大部分都没有插件化，也就是你无法隔离模块的修改：你必须下载并编译整个引擎而不是下载并编译某个插件并替换资源类型十分有限，基本以美术素材为主，工具和游戏性插件屈指可数搜索功能非常难用，关键字搜索和类型筛选组合使用很违反直觉(必须先搜索后类型)资源规范和预览做得很不到位，客户能看到的信息有限(包括销量之类的重要信息)只有库没有管理，只是一个简单列表没有任何筛选功能，拥有资源过多之后难以使用虚幻商城没有多页面预览，点开资源还有返回loading页面购物车就真的只是购物车，不能收藏一部分 购买一部分有些引擎插件依赖，没对应版本的引擎就下不到对应插件

　　UE4 的 Undo/Redo 栈是全局的而不是 per document 的，稍不注意就能把去年改的给推了

　　UE4：你想学啊，我教你啊

　　内存布局非常的零散，加上大量的虚函数导致 Update 性能堪忧使用的是 FTickFunction 回调来进行 Tick，可能导致不同类型的 UObject 交替更新，性能再下一阶梯导致一些基类上功能过多，比如光是放置很多空 Actor 就会有较明显的性能消耗，需要手动将各种功能关闭对象体量过大导致创建消耗特别大，生成一个空的 Actor 就会有 0.1ms 的消耗只要是涉及 UObject 对象，基本都很难多线程，但是大部分逻辑层都在 UObject 上

　　首先整个 Transform 系统(也就是场景层级)都建立在 Component 之上，逻辑上挺简洁，但是却为了 OOP 的继承硬生生插了个奇妙的 Actor 进来，很多逻辑都放在了 Actor 上面，显得非常的不伦不类。之后为了替换父类中的组件，又强行搞了一个 DefaultSubobject 和 ObjectInitializer 的概念来补洞。。。你看 Unity 的纯组合模式和 Prefab Variant 有这么多鸟事吗？

　　World，GameInstance，GameMode，GameState，PlayerState，Controller，AIController，PlayerController，Pawn，Character，LevelBlueprint 直接内置于引擎之内(而不是开发套件)，官方似乎热衷于教大家做游戏，甚至物体位置低于某个高度自动销毁的功能都帮你写了，真是十分贴心呢？但这一坨纯粹是一团烂泥(俺只想写一个贪吃蛇？)

　　将场景里的对象(或对象集合)保存为资源并在不同的场景之间复用(或在运行时复制)是其他引擎(包括 inhouse 引擎)的常见 Feature，且实现难度并不大，但 UE4 就是有自己的清高不去实现这个 Feature，而是靠特么的 BP 的 DefaultObject 来搞，然后提供了极其难用的合并 Actor 为单个 BP 的工具。 而蓝图 DefaultObject 拥有以下优点：

　　拥有难用的独立编辑器不支持解包合并限制大基本没有嵌套能力实例的修改无法反向同步

　　以上问题也有很大部分来源于奇妙的 Actor：层级建立在 Component 而不是 Actor 上。

　　因为引擎默认以变长步更新物理引擎，后期才添加了定长步更新，在 Gameplay 层可选的 TickGroup 并没有开放出 Fixed Tick 的选项。

　　大量 API 在编辑器内和游戏内行为不一致，在编写代码的时候需要熟练掌握编辑器行为学并保证经常打包测试。 编辑器代码和游戏代码相互影响，代码隔离需要额外注意(你猜猜我在第几层 World)。

　　龙不吟，虎不啸，小小硬盘可笑可笑

　　引擎默认自带了大量的插件和素材，一个发行版引擎核心组件就能有 15G 左右，带上调试符号 40G 左右，带上常见打包平台工具(Android，IOS)可以达到 50G。作为对比，Unity 核心组件只有 4G 左右，加上安卓打包套件也只有 8G 左右。源码版引擎编译一个 Debug 版本加上一个 Develop 版本就能直接上 100G，SSD 不要钱吗？上述提到的资源包皮问题，美术资源 DCC 版本和引擎版本需要存两份，双倍的磁盘占用上述提到的 Shader 管理问题也会导致磁盘占用膨胀最小的可用移动平台包体 70mb 左右，Unity 移动平台最小可用包体 10mb 左右纹理压缩选项较少，没有精度更低的选项，自行扩展也很麻烦打包过程可自定义程度非常的低 此段来自 @Maxwell 的投稿

　　虽然 UE4 渲染的表现力足够强，但其内部的架构却充满了历史包袱，不堪重负。

　　Shader 编译系统和加载系统的精分导致崩溃概率极高且毫无 Debug 手段。 在 DX API 上一般一个 Shader 从编译到进入渲染管线的流程大致为：编译并储存二进制码，读取二进制码，加载 Shader 对应的 Render State(是否透明，是否要被深度遮挡等)，使用 Shader 和 RenderState 以及其他数据生成 Pipeline State Object 并在渲染时使用。而上述的各个步骤在 Unreal 中不仅完全分裂，中间用各种虚接口连接到 一起，而且完全没有测试手段，这就意味着引擎崩溃时往往会提示 Create PSO Fail 也就是最后一步出错，而问题则可能出在上述的任何一个步骤里，这些步骤甚至也没有单独的 Debug 方法，只能手动断点或在源码里夹杂私货的方式 Debug，更不用说 Render State 还是通过元编程和宏定义的手段直接硬编码，每次改动意味着巨量重新编译的时间。可谓“一天崩一次，一次崩一天”一点都不夸张。 同样的问题在材质上也有发生，因为 Shader 编译和加载系统的精分，导致场景中尤其是地形常常出现这样的迷惑行为：地形用了很多个材质和Shader，而这些材质和 Shader 使用的光照模型，贴图混合算法完全一样，唯一的区别是贴图的引用不同，而每个材质则“独享”一份 Shader 实例，因此当自研引擎的 Shader 体积单位还是 K 的时候，UE 的 Shader 体积已经是 M 了。 而伟大的UE4则继续发挥哪里有洞补哪里拆了东墙补西墙的策略，对于 Shader 体积爆炸没法一次性加载进内存这个情况，果断将Shader的加载设计进 Streaming 系统，而矛盾的是，Shader 的加载往往耗时很长且会导致驱动层阻塞，所以即使是玩家也常常能感受到“UE 做的游戏经常会顿卡”，更不用说开发者们了。

　　UE4 中为了提高后处理效率，减少RT读写的消耗，在后处理阶段使用了 Uber Final Pass，这样的设计理念本没有错，然而错在 Uber Pass 的 Shader 代码和执行部分并没有做任何形式的解耦，即使这些解耦工作完全是开发周期的，代码重度耦合，资源传入系统重度耦合，想做任何形式的定制都会带来极大的人力开销。

　　UE一直在努力将引擎“现代化”并尝试支持更多 New Features，包括RTX等，然而其立命之本的 Deferred Rendering 却依然还是形似DX9时代的产物，在老旧的API上因为贴图格式的限制以及并没有被发明出来的 Compute Shader，需要将 Geometry 信息放到 Geometry Buffer 且每盏灯光需要一个单独的 Pass，现代 API 的技术升级早就已经不需要这种方法。而 UE 始终不升级这种老旧的设计的代价就是：加入新的 Feature 必须扩充已经十分臃肿的 GBuffer，这对于硬件性能尤其是带宽性能不够的平台，如 PS4，是十分不友好的，同时每盏灯都需要读取 GBuffer 并覆盖一遍计算结果的策略也会导致需要渲染大量光源性能直线下降。

　　不过由于我们内部项目对此需求不强烈

　　这一部分列举的主要是功能上的问题了，这些问题有可能在接下来的版本里解决，但根据 UE4 项目驱动的引擎的属性，可预测大量特性进入无限鸽置的半成品状态。

　　BUG奇多，轨道丢失的现象，会直接序列化保存 Actor 数据，导致一些不在定序器中修改的属性也保存了扩展非常麻烦，扩展一个空轨道就要几百行框架代码很难和外部环境交互，Sequencer 之间也很难交互 (做剧情分支困难)事件使用内置的蓝图实现，并没有 Signal 一类的机制，非常的难用，并且这个蓝图甚至很难找到地方访问(除非通过这个 Event Track，奇葩的是删掉 Event Track 之后蓝图依然存在)，编译错误也容易藏在里面同样是 UE3 留下来的时代的眼泪，维护力度非常低，基本处于放弃状态随机崩溃和子关卡并不兼容在很长一段时间内 Profiler 都非常的弱，没有火焰图，信息分析很弱，查看一个瓶颈需要展开几十个栈在 Unreal Insight 出现后(4.23)，情况得到了改善，但内存分析依旧和没有一样镜头动画的维护力度非常低，甚至处于放弃的状态镜头插值的方式匮乏，球面插值之类的都没有(因为缺少 LookAt 的信息)实现非常的繁杂，把大量的功能揉在了同一个类里，包括但不限于：RootMotion，Physics，Network(Client Prediction)，其中 RootMotion 在联机时有 BugGravity 的方向被写死Capsule Collision 被写死内置大量无用的 Movement Mode

　　引擎的 AI 模块基本是为 FPS 设计的，内容上缺失严重

　　引擎实现的寻路系统不完整，虽然师从 Recast 但是抄作业都抄出了个不及格，相对于原版 Recast 缺少自定义规避行为等，引擎实现的规避组件也和原版不一样，会跑出寻路网格，只能通过空气墙解决，导航网格也经常出现失效的问题AI控制器消耗较大，空置的控制器也会带来不小的消耗

　　ABP 动画是硬引用，和骨骼和动画绑定，无法开放成参数(类似于 Material 和 Material Instance 那种参数)，导致状态机复用困难。(重定向？) Rig Control 也存在同样的问题。

　　奇葩的事件流，事件可能在任何一个角落被 Block 掉(Actor，Controller，LevelBlueprint，Pawn)UMG 并不能使用 Mapping，只有 Hardware Input(因为基于 SlateUMG Navigation 键位设置位于 SlateApplication，意思是和编辑器共享同一个按键(继承 Slate禁用输入并不会刷新 Axis 的值，导致迷惑行为《最开放的平台》