ue4渲染速度太慢_[UE4]性能优化指南(程序向)

封面来源：A Cold Stop(Mixer 制作材质、UE4渲染 )

[UE4]性能优化指南(美术向)玄冬Wong：[UE4]性能优化指南(美术向)​zhuanlan.zhihu.com

内容都是处理项目问题的相关笔记，留给自己做备忘录，也分享出来让别人少走弯路。

零散记录GPUProfile来统计性能消耗的时候，在editor模式下不是很准，因为编辑器的消耗也算进去了，如果要用，最好以Game模式来查看。

UE4不支持640X480的分辨率，如果在这个分辨率下运行程序，会导致程序崩溃(4.4版本，不知最新版本是否仍有此问题)。

如果角色身上有很多Component需要Attach，尽量在使用时Attach，不要一加载就全部attach，否则当场景中角色很多时，会有严重性能问题。

比如：场景中有几百个角色，但不是每个角色都需要摄像机和弹簧臂，那么在构造函数中就不要创建摄像机和弹簧臂组件。

面数对UE4来说不敏感，即使在移动端。ipad 4上，50万的三角面，也能够以30fps帧率稳定运行，移动端主要对贴图大小、材质复杂度较为敏感。

代码编译优化C++ 比 蓝图快100到1000倍

[Test] Blueprint vs C++ Performance vs Nativized BP

https://www.reddit.com/r/unrealengine/comments/6qtxy3/test_blueprint_vs_c_performance_vs_nativized_bp/

感谢知乎网友金木研指正：以上结果是在编辑器模式下的测试结果(没有native蓝图)，如果打包并将蓝图转换为native code，那么蓝图和C++的性能差距不超过两倍。

使用C++进行向量变换时，尽量使用FTransform::TransformXXX()和FTransform::InverseTransformXXX，而不是FQuat::RotateVector和FQuat::UnrotateVector，因为前者使用了更多的当前硬件支持的矢量汇编指令，榨干了硬件性能，而后者是为了跨平台，老老实实使用C++代码来执行计算公式，虽然也调用了硬件汇编指令，但数量相对较少。

UE4做了优化，当你使用FTransform::TransformXXX()时，如果当前硬件支持(intel 2008年之后的CPU、AMD 2011年之后的CPU)，就走硬件指令，如果不支持，则走FQuat::RotateVector。

VS2019针对C++代码编译速度、以及CPUAVX/AVX2指令集下的矢量计算进行了更深入的优化，并且微软Xbox ATG团队使用UE4的demo工程Infiltrator对优化后的效果进行了基准测试：

编译速度方面：完整编译速度，VS2019(16.2)是VS2017(15.9)的3.5倍，增量编译速度，VS2019(16.2)是VS2017(15.9)的1.6倍；

代码优化方面：以游戏帧率作为测试标准，VS 16.2相对16.0提升了2%到3%，而16.0相对15.9最大可以提升2.8%，也就是说使用VS2019编译代码，相比VS2017，可以让游戏运行时帧率提升5%左右。更多详情见微软C++团队博客：C++ Team Blog。

如何断点调试UE4中的内联函数：我们知道加了FORCEINLINE的函数无法断点调试，但是FORCEINLINE_DEBUGGABLE可以，这样保证函数既能在debug模式下调试，又能在shipping打包时让函数内联。

代码算法优化(仅限UE4 API相关)清空TArray时，如果该TArray对象还会继续使用，使用Reset()代替Empty()，因为前者不会销毁内存空间。

TArray移除元素时，如果对元素的顺序不关心，可以使用RemoveAtSwap()代替RemoveAt()，前者是用数组末尾的元素来填补内存空洞(移除元素后产生的无效内存空间)，而后者是对空洞后的所有元素平移。时间复杂度，前者为O(RemovedCount)，后者为O(ArrayNum)。

如果是单个生产者单个消费者(SPSC)的线程环境，可以使用TCircularQueue作为消息队列来保证数据安全，比使用FScopeLock消耗低，因为前者内部使用的是atomic，而非lock(虽然atomic也算一种轻量级lock)。

视距裁剪(剔除)开启Occlusion Culling (Project Settings -> Engine -> Renderi