企业官网建设流程全解析

做UE5项目，最怕的不是功能实现不了，而是所有功能都做完了，一进大场景运行起来帧率跟幻灯片似的，那种感觉真的很劝退。这篇是《虚幻5》系列的第五部分，前面几篇我们把环境搭建、场景搭建、角色控制、基础玩法都捋了一遍，这次专门解决“跑不顺”的问题：性能优化。内容整理自一个中小型开放世界Demo的优化过程，从原本平均只有二十几帧、CPU和GPU都满负荷运行的状态，一路调到稳定60fps。如果你项目也卡，这篇应该能帮上忙；哪怕你只是刚学UE5，先把优化思路建立起来，后面做东西会省非常多的时间。

1. 优化思路：先诊断，再动刀

优化这件事，第一原则就是：不要凭感觉乱调项目设置。我见过太多人一卡就去关阴影、关后期、降分辨率，结果画面烂了，帧率还是不行。原因很简单，你连卡在哪一步都不知道，怎么可能调对？就像去医院看病，不能一上来就说“我头痛开个药吧”，先做检查，搞清楚病灶在哪个位置，再对症下药。

1.1 认清瓶颈：到底是CPU、GPU还是IO

UE5项目的帧率瓶颈一般来自四个方面，你要能区分出它们的特征：

• GPU瓶颈：最常见，显卡跑满了，渲染任务太重。表现是GPU占用率接近100%，但CPU线程可能还有余量。常见原因是网格体面数太多、阴影开销大、后处理堆太多、材质太复杂。
• 游戏线程瓶颈：CPU单核在跑游戏逻辑，比如蓝图Tick、物理、寻路等。表现是GPU占用率不高，但是游戏逻辑线程顶着上限跑。
• RHI线程瓶颈：渲染API提交指令的线程，如果场景里绘制调用太多、状态切换太频繁，RHI线程容易卡住。战国人多、物件多、材质数量多的时候特别容易遇到。
• IO/资源加载瓶颈：进入新区域时瞬间卡顿，过一会儿又恢复。这种不是帧率问题，而是关卡流送、贴图流送或者同步加载导致的卡顿，优化方式完全不同。

判断的方法是先打开控制台，输入stat unit，观察Frame、Game、Draw、GPU这四个时间。Frame是总帧时间；Game是游戏逻辑线程耗时；Draw是渲染线程耗时；GPU是显卡上的渲染耗时。如果Game很高，偏CPU；如果Draw很高，渲染线程压力大；如果GPU很高，那就是显卡负载出问题了。

1.2 先设定帧预算：16.6ms的账要会算

很多人优化了半天，目标都没有定清楚。这里先普及一个概念：60fps对应每帧16.6毫秒，30fps对应33.3毫秒。你要做稳定60fps的体验，就等于给每一个环节分配预算，总和绝对不能超过16.6ms。

我常用的参考预算分配是这样的：

• 游戏逻辑线程：3-4ms
• 渲染线程：3-4ms
• GPU渲染：8-10ms

当然这只是参考，不同平台、不同游戏类型会有差异。但有了这个预算表之后，你看stat unit的输出，就能直接找到超预算的项目，针对性优化。比如Game线程都跑到8ms了，你还去调画质，那纯属白忙活；反过来GPU已经12ms了，你还在蓝图里抠那0.1ms的Tick开销，也是舍本逐末。

优化不是把所有东西都降低到最低，而是把最大的那笔开销找出来砍掉。永远把时间花在最长的那根木板上。

2. 渲染优化：Lumen、Nanite和阴影的取舍

渲染是UE5最亮眼的特性所在，但也是最容易烧硬件的地方。很多开发者一进项目就把所有特效拉满，Open World、Lumen、Nanite全开，结果常规显卡根本撑不住。这一节聊聊我在实际项目中怎么在这些特性之间找平衡。

2.1 Nanite到底该不该全开

Nanite是UE5的核心卖点，能渲染上亿三角形，理论上静态网格体的面数不再是压力。但有个前提：Nanite对网格体有严格限制，必须是静态的、不能变形、不能有顶点动画、不能用于布料和蒙皮网格。也就是说，那些会飘动的旗帜、要弯折的树枝、会物理破裂的碎片，开了Nanite可能反而出问题，或者根本不支持。

我实际测试下来，大面积的山体、岩石、建筑墙面这类静态物件，非常适合Nanite，可以放心把高模导进去，不用手动减面。但对于小物件，比如桌椅板凳、电线杆这类东西，Nanite的帮助并没那么大，反而可能会增加内存占用。更要注意的是不要让成千上万个细小的网格体独立存在，能合并就合并，能利用HLOD（分层细节）就开。

有些开发者反馈打开Nanite后画面会偶尔闪烁或漏光，一个常见原因是启用了Nanite但不允许它生成正确的阴影。在项目设置里需要确保Shadows、Lumen相关选项的Nanite支持是打开的，同时把“Overrides”里的三角形阈值保持默认或适当调整，避免因网格体过小而自动退出Nanite渲染。

另一个细节是：Nanite在首次加载或编辑器里会有一段“构建数据”过程，表现为卡顿、掉帧明显。这不代表项目最终性能差，发布后Data Build完成后就正常了。如果调试时一直觉得“开了Nanite反而更卡”，先排除是不是在编辑器环境下的假象。

2.2 Lumen的性能代价与静态光照的回归

Lumen全局光照是UE5的另一个大卖点，动态光影、多反弹都让画面质感提升不少。但它不是免费的：Lumen默认使用软件光线追踪，配合一定的硬件光追能力；如果开了硬件光追，GPU负载会明显上涨。在主机和主流显卡上，要想跑稳60fps，Lumen经常需要配合一定程度的降级设置。

我个人的项目选择方法是：如果场景的光照变化很少，比如室内关卡、固定视角的商业展示，果断用烘焙光照贴图（Baked Lighting），关掉Lumen的动态全局光照。烘焙之后的光照效果极其稳定，开销还很小，哪怕低端硬件也能流畅跑。反过来，如果是开放世界、昼夜循环、动态天气，那就在性能预算内开Lumen，并采用“软件追踪”或者“Lumen质量”调整为性能档。

在这里有一个大家容易忽略的点：Lumen和Nanite是两套独立体系，开Lumen不一定非要开Nanite，开Nanite也不影响你用烘焙光照。很多项目的合理组合是：静态几何体用Nanite + 烘焙光照，动态角色和可交互物体走普通网格体加实时阴影。这样的搭配在视觉损失上是很小的，却能省出一大截性能。

2.3 阴影距离与后处理：性价比的攻坚点

渲染出问题经常不是出在大头，而是出在“这里是阴影、那里是泛光”的积少成多。阴影这块，我建议控制级联阴影贴图的数量和距离。以Directional Light为例，把Cascade Shadow Maps从默认4级减到3级，把“Dynamic Shadow Distance”从全图拉到100左右，远的物体没有实时阴影，用胶囊体阴影或干脆不加，一般能明显降低GPU时间。

后处理体积也是隐形杀手。Bloom、Ambient Occlusion、Screen Space Reflections、Depth of Field、Chromatic Aberration，每一个效果都有对应开销。我在优化时经常做的测试是：把后期体积先全部关掉，看帧率回升多少；然后依次打开，看哪个效果占的帧时间最多，再根据项目需求决定去留。

就我的经验来说，SSR（屏幕空间反射）是开销大户，如果项目里水体不多、地面不反光，直接关掉或降为较低质量是非常实用的。景深对于玩法和探索类项目也不是必备，适当弱化能省出不少渲染资源。

3. 游戏逻辑优化：Tick和异步调用的使用之道

渲染优化只能解决画面层面的瓶颈。很多时候帧数低，锅不在显卡，而在CPU上的游戏逻辑太笨重。这一部分分享我在蓝图和游戏代码优化中踩过的大坑。

3.1 一帧一查的Tick，能不去就不去

有个很经典的比喻：你让一个员工每一帧都把所有抽屉打开检查一遍，就算他什么也不干，光查抽屉就会忙死。蓝图里的Event Tick就是这个“员工”，只要组件里挂了个Tick节点，这个Actor每帧都会执行一次。场景里如果有100个Actor都在Tick，哪怕每个只做一次非常简单的查询，积累起来就是相当可观的CPU开销。

我在项目中遇到过的一个案例：一个角色身上的AI检测逻辑放在了Tick里，检查周围有没有玩家。单个Actor看起来耗时不长，但场景里几十个AI角色同时做这件事，再加上Tick内调用了查找类节点，帧率直接掉到20多。后来改成“事件驱动”的模式：敌人只有在进入某个触发范围或者收到事件时才执行检测，平时完全不跑这段逻辑，CPU占用立刻降了下来。

如果你确实需要每帧更新，也可以在C++中用开关控制：

void AMyActor::Tick(float DeltaSeconds) { if (bEnableExpensiveLogic) { // 只在需要时才执行每帧逻辑 UpdateSensitiveSystem(); } else { // 平时保持休眠 } }

蓝图里也可以用Timeline、Delay、定时器来替代Tick，或者在Tick之前加Branch节点判断当前是否有更新需求。把“每帧都跑”改成“有需要才跑”，是游戏逻辑优化里性价比最高的一条路。

3.2 资源加载别硬等，异步才是正解

很多卡顿不是渲染问题，而是同步加载资源导致的。蓝图中如果直接调用“Load Asset”或“Load Level”这类同步节点，遇到大体积资源时，游戏线程会卡住，画面定格，等加载完再继续。玩家感知到的就是“进入新区域时掉帧到个位数”。

正确做法是用异步加载：Async Load Asset、Async Load Level，或者在关卡流送（Level Streaming）里配置合适的距离和加载策略。异步加载的作用是让资源在后台慢慢读入，画面保持流畅，等加载完成后再替换或显示内容。

我平时会把大量资源拆到子关卡里，配合World Partition来做流送。这样玩家走到某片区域时，该区域的资源能被预先加载，而不是等玩家踩进来的那一刻才现读取。关于World Partition的细节下一节再展开，但核心思想就一句话：让加载这件事发生在你看向远处时，而不是你站在门口时。

3.3 碰撞与物理：能简化就简化，别让物理引擎做无用功

物理引擎的碰撞检测也很消耗CPU。容易犯的错误是给复杂网格体直接生成了细腻的碰撞体形状，导致物理求解的计算量巨大。实际上对于大多数静态物，一个简化胶囊体、长方体碰撞体就足够了；对于需要精确交互的物件，也尽量用凸包碰撞，而不是每个三角面都参与碰撞。每次物理计算都是在和时间赛跑，不需要物理模拟的物体，直接把Collision Enabled设为No Collision，或者把Simulate Physics关掉。

还有一类很不起眼的开销：移动组件在移动过程中会持续检测地面、墙壁。如果场景里这种组件特别多，同时碰撞设置又不合理，CPU会非常忙。对于视觉背景的物件，可以考虑禁用碰撞响应，让它们的物理成本归零。

4. 资产优化：省下显存和内存，让GPU喘口气

渲染层面省下来的帧时间，通常还要看资产本身吃多少显存和内存。模型面数、贴图尺寸、材质复杂度，每一项都在暗中压榨硬件。这一节算是最直接能“抄作业”的部分。

4.1 贴图尺寸不是越大越好，尺寸跟着相机走

很多美术习惯了出图就是4K，导致项目里全是4K纹理，显存爆炸不说，游戏加载也慢。事实上一个物体最终占用多少贴图精度，取决于玩家在屏幕上能看到的区域有多大。

我常用的参考分配是这样的：

• 全屏特写物件（重要道具、主角身上装备）：2048-4096
• 正常交互程度的中型物体（想表现的武器、柜子）：1024-2048
• 大面积环境材质（山体、地面、墙面）：1024-2048
• 远处填充物（远处树木、碎石）：512或以下

关键是不要让远景物体也扛着4096贴图，那是纯浪费。同时要打开纹理压缩设置，选择合适的数据格式，比如BC7、ASTC。很多开发者会在导入设置里选了“无压缩”，结果内存直接被吃掉，帧率当然上不去。这一点在默认导入设置里就要检查好，而不是等优化时一个一个地找。

4.2 World Partition与Level Streaming：让世界跟着玩家走

开放世界场景如果全部在一个Level里，无论怎么优化，硬件都没法一次性加载所有内容。UE5的World Partition机制会把世界切成若干网格单元，根据玩家位置动态加载或卸载，这个思路本质上就是“让世界跟着玩家走”。

在项目设置里开启World Partition后，我可以给不同资产设定不同的加载半径，比如建筑3000、植被1500、贴花500。配合HLOD（Hierarchical Level of Detail），远处的大片物体会自动合并成性能友好的简化网格，肉眼几乎看不出区别，但渲染开销能降一个量级。

如果你的项目不是完整开放世界，也可以单纯使用Level Streaming，把室内场景、地下城拆分到独立Level。千里之行始于足下，关键是“不在当前区域的资源，不要占用当前帧的预算”，这条思路在任何规模的项目里都成立。

4.3 材质复杂度：母材质实例是性能救星

材质编辑器里每添加一个节点，最后都会编译成shader指令，节点越多，指令越复杂，GPU执行就越慢。尤其是半透明材质、多个材质球相互叠加的情况，开销会急剧上升。

我比较推荐的做法是用“母材质+材质实例”的模式。在母材质里把所有需要变化的参数暴露出来，比如基础颜色、粗糙度、金属度、纹理坐标偏移，然后尽量少建独立的材质球，而是创建这个母材质的材质实例，只改参数。这样GPU在处理相似材质时可以复用state，降低RHI线程的编译和切换成本。

同时，如果某个材质里的Expensive节点（比如计算量大的噪声函数、世界位置偏移等）没有实际用途，就删掉，不要留着以后用。shader编译的指令数量和材质节点数并不一定成正比，但复杂节点的代价绝对超乎预期，尤其是计算密集的特效材质，稍微优化一下可能帧率就回升了。

5. 工具实操：如何用Unreal Insights和Stat命令定位瓶颈

有了前面的知识，接下来要解决“怎么找到具体卡点”的问题。UE5自带的性能分析工具非常完善，关键是要会用。这一部分我把自己经常用的一套调试流程整理出来。

5.1 最有用的控制台命令速查表

在编辑器或运行中的游戏里按~打开控制台，常用命令如下：

• stat unit：查看每帧总时间、游戏线程、渲染线程、GPU时间
• stat gpu：查看GPU渲染各阶段的耗时，比如PrePass、BasePass、Shadows、Translucency
• stat rhi：查看渲染API线程的开销和DrawCall数量
• stat scenerendering：查看场景渲染相关参数
• ProfileGPU：在GPU上做详细profile，会生成一份按渲染指令拆解的硬盘报告，是定位GPU瓶颈最重要的工具
• stat startfile/stat stopfile：配合Unreal Insights生成长期性能记录文件，适合分析内存、加载、网络等整体问题

用带stat前缀的命令看实时数据，用ProfileGPU深入看单帧细节。两者配合，基本能覆盖90%的渲染调试场景。

5.2 用数据定位瓶颈的一整个流程

我简单还原一次真实定位过程。在一个模拟项目X的测试场景里，发现帧率只能跑到30fps左右。打开stat unit，看到Game为4ms、Draw为6ms、GPU为15ms，总和明显超预算。首先排除CPU瓶颈，因为Game线程还有余量；接着打开stat gpu，看到Preshadow、Shadow Depths相关条目耗时高，其中Shadow占了6ms，BasePass占了4ms，Translucency占了2ms。这就说明优化方向应该放在阴影上。

到这一层基本已经水落石出，去动态光源阴影设置里调低级联数量、缩短动态阴影距离、同时把远处静态物件的阴影改用烘焙阴影或者胶囊体阴影，帧率马上回升到50fps以上。再根据stat gpu中剩余的耗时分布，去处理BasePass里过重的材质。这样一轮一轮调下来，最终把GPU降到9ms左右，稳定60fps就跑住了。

这段流程的关键点在于：每一层数据都指向一个明确的优化目标，而不是盲目地关这关那。建议你也按这个套路走：先看整帧，再看系统，再往下钻细节。

5.3 优化前后对比表：数据不会说谎

优化前后，我一般会把关键指标记下来，方便确认每一步改动到底有没有效。写一个来自模拟项目X的示例对比表：

这个表不是固定答案，但能提醒你在优化的每一步都做一次对比。没有数据记录的优化，很容易出现“觉得快了但实际上瓶颈只是转移了”的情况。

6. 避坑清单：常见“优化完反而更卡”的坑

最后这一部分，我把在实际优化中踩过的一些坑整理成清单。不能说这些坑100%会在你身上复现，但都是真实项目里反复被问到或者自己遇到过的问题，提前知道能少走弯路。

6.1 Nanite开了反而更卡？先弄清楚是不是构建和兼容问题

有时候项目开了Nanite，反而出现明显的卡顿。除了之前说的非静态网格体不适合Nanite之外，还有一种情况是Nanite数据在编辑器里还在后台构建，或者首次进入场景时需要编译缓存。此时不要急着把Nanite关掉，先用一段时间让它把数据构建完成。如果发布后依然卡，检查平台支持的兼容性，个别硬件驱动版本也会导致Nanite渲染效率下降。可以在项目设置里尝试关闭“支持Nanite”或者调整网格体的重叠阈值，但千万别一刀切，会损失大量高品质细节。

6.2 Lumen噪点、闪烁和阴影跳动

Lumen的动态效果强，但偶尔会有噪点和阴影闪烁。很多人第一反应是把质量调低，但实际上应该检查屏幕百分比和后期处理。可以把r.ScreenPercentage设为100，同时把Lumen采样数适当提高，就能改善很多。另外，如果场景中有大量细小几何体或比较碎的植被，阴影闪烁经常是来自运动矢量或深度信息不稳定，这时候需要为那些植被开启更高质量的运动模糊向量，或者调整Nanite植被的阴影配置。改善噪点与闪烁的核心是让采样信息稳定，而不是一味地降质量。

6.3 GPU占用率低但帧率却很低

这种情况比较反直觉：明明GPU没满负荷，显卡利用率也不高，但帧率就是上不去。如果stat unit显示Draw或RHI线程时间很高，问题通常出在渲染线程的调用开销，比如材质切换频繁、Shader复杂度高、状态变化多。优化方向不是降画质，而是减少材质数量、控制阴影级联、降低Overdraw。还有一种可能是驱动把功耗或频率限制住了，笔记本平台要检查电源策略是否开启高性能模式，桌面平台要看是不是显卡被锁在了节能档。这种情况不属于引擎类别，但真的很容易混淆。

6.4 加载瞬间卡顿：流送和异步加载没配合好

帧率整体正常，但每到切换区域、进入新场景的瞬间就会卡，多半是IO同步加载造成的。优化重点是做好Level Streaming和异步加载。比如在进入某个区域前，设置一个触发区，提前250米开始异步加载该区域的Level和资源；不要等到玩家踩进门那一刻才加载。同时检查贴图流送池（Texture Streaming Pool）是否被设成了过小的值，流送池满了会导致贴图不断被挤出和重新加载，产生周期性掉帧。把r.Streaming.PoolSize适当调大，或者让贴图分辨率更合理，卡顿就会消失。

优化这个动作，说穿了就是把钱花在刀刃上。我自己比较推荐的顺序是：先做数据测量，找到最大的那笔开销；然后做逻辑减负，去掉没必要的Tick；再做渲染减负，处理阴影和后处理；最后才做资产和内存的精细优化。每次改动都记录一下数据，不要做没有验证的调整。

根据我个人的经验，真正让人崩溃的往往不是优化本身，而是不知道从哪里开始。先把stat unit开起来，跑一圈场景，看一下谁是最贵的，然后从最贵的那项下手。等使用一段时间后，你再回头看项目，会发现自己对整个引擎的渲染资源分布有了清晰很多的认识。这个内容后续还可以往更多方向扩展，比如控制台变量调优、移动端性能专项、内存泄漏排查这些，都是很现实的需求，咱们后面有机会可以继续聊。