最近一直在啃多敌人场景的 UE FPS 性能优化。做 UE 的人迟早都会遇到一个场景：地图里一刷新出几十上百只敌人，帧数就开始断裂，普通移动都开始发飘，更别提交火了。我这边有几个项目都踩过这个坑，从第三人称射击到开放地图的僵尸群都有。这篇就拿“多敌人场景”当主线，把我实际用过的优化思路、命令、参数和排查流程完整写一遍。适合正在做 UE FPS、动作射击、生存类或塔防项目的开发者参考，技术美术看到渲染侧的优化章节也能直接用。内容不搞 PPT 理论，全部是可以在你自己项目里复现的做法。
1. 先判断瓶颈，再动手优化：多敌人场景的问题拆解
1.1 敌人一多，到底慢在哪
多敌人场景的性能问题，本质上是 CPU 和 GPU 同时被塞爆。很多人一掉帧就认为是显卡不行，先砍画质，结果帧数没怎么回来。实际上在敌人数量暴涨的场景里，最先扛不住的是 CPU 的游戏线程和渲染线程，GPU 反而经常在等数据。
拆开看，多敌人场景的消耗集中在几个地方：
- 敌人 Actor 的 Tick 更新。每个敌人每一帧都在跑自己的逻辑、感知、动画蓝图、移动组件更新。50 个敌人就是 50 份全流程计算，200 个敌人就是 200 份。
- 骨骼网格体的动画更新和蒙皮计算。一个角色骨骼网格哪怕只有 30 根骨骼，每帧都要采样动画、更新骨骼、做蒙皮，这个开销是实打实的。
- DrawCall 数量暴涨。每个敌人都带自己的网格体、材质、阴影投射，如果没用实例化渲染，等于每个敌人都提交一批渲染指令，DrawCall 很快就能冲到几千。
- AI 逻辑和寻路。行为树、感知系统（视觉、听觉检测）、NavMesh 路径请求，这些逻辑在敌人数量多的时候会比想象中占 CPU。
- 粒子特效、物理碰撞、布娃娃。敌人死亡时如果每个都来一套物理模拟和粒子爆发，那帧数就不是掉一点的问题了。
你可能会想：不对啊，现在的 PC 都很强，几千个 DrawCall 不算啥。但 FPS 对帧延迟非常敏感，多敌人场景往往不是平均帧难看，而是 1% low 帧崩得厉害。平均帧 60，实际开枪的时候突然掉到 25，体感就是“卡一下”。所以优化的目标不只是抬高平均帧，而是把最低帧、1% low 帧稳住。
1.2 用命令和 Profiler 把瓶颈“钉死”
动手优化之前，我强烈建议你先跑一轮性能数据。没有数据支撑的优化都是瞎猜。UE 自带几套非常好用的工具，先把瓶颈定位清楚再动手。
最常用的是控制台命令stat unit。在游戏里按打开控制台，输入stat unit`，会看到帧时间、游戏线程（GameThread）、渲染线程（RenderThread）和 GPU 时间，单位是毫秒。判断方法很简单：
- GameThread 时间明显偏高，说明 CPU 游戏逻辑是瓶颈，重点看 Actor Tick、动画、AI、蓝图。
- RenderThread 时间偏高，说明 CPU 侧的渲染提交工作量大，重点看 DrawCall、阴影、场景复杂度。
- GPU 时间偏高，说明显卡在忙，重点看分辨率、阴影质量、光照、后处理、粒子、网格密度。
stat rhi可以看到 DrawCall 数量。ProfileGPU可以看 GPU 内部各渲染阶段的耗时占比。Unreal Insights 则是更完整的时间线分析工具，可以看每帧里各个任务落在哪个线程、花了多少毫秒，特别适合抓“每帧都在跑但看起来没什么用”的隐性消耗。
还有一个容易被忽略的概念叫 1% low 帧。它统计的是所有帧时间中最差的 1% 样本的平均值。举个例子，你统计 100 帧，平均帧 60，但这 100 帧里有 1 帧花了 100ms，那一次卡顿就足够让瞄准动作整个脱离节奏。所以优化时我会专门盯 1% low 帧，而不是只看 FPS 数字。
注意：
stat unit显示的是毫秒，不是 FPS。1 帧 16.6ms 对应 60FPS，33.3ms 对应 30FPS。看到 40ms 就要知道已经掉到 25 帧左右了。
2. 敌人 Actor 的瘦身：把每帧成本降下来
2.1 少 Tick：能低频更新就不每帧跑
多敌人场景里最不值得花的钱，就是让每个敌人每帧都跑一遍 Tick。绝大多数 AI 逻辑根本不需要每帧刷新。视觉感知可以在 0.1 秒到 0.2 秒查一次，行为树可以 0.25 秒评估一次，动画里的某些状态变量也不需要每帧去重新读。
具体做法分两步。第一步，把 AActor 的 Tick 间隔从默认的0.0（每帧）改成一个合理的值。在 C++ 里设置PrimaryActorTick.TickInterval = 0.1f;，蓝图里在类设置面板找 “Tick Interval (seconds)”。这样一改，100 个敌人每帧的 Tick 成本立刻变成每 10 帧才跑一次，游戏线程的负担降得非常明显。
第二步，不是所有逻辑都要靠着 Tick 才行。事件驱动更好：做一个“攻击标记”、“被玩家发现”、“弹药耗尽”之类的条件，让敌人自己在事件发生时主动切换状态，而不是每帧去轮询自己该干什么。这活儿听着简单，做起来需要重构，但多敌人场景下收益极高。
比如一个瞄准系统，每帧都去用射线检测玩家，50 个敌人就是 50 条物理射线每帧跑。改成 0.2 秒检测一次，或者只在敌人状态切换、听到声响时才刷新目标，游戏线程瞬间就松了。
注意：改变 Tick 间隔不影响物理碰撞的准确性。物理模拟是由 PhysX/Chaos 驱动，跟 Actor Tick 是两条线。
2.2 对象池与延迟生成：别在开火瞬间搞动态分配
多敌人场景还有一个很隐蔽的性能杀手：战斗中不断生成和销毁敌人。每次 SpawnActor 和 Destroy 都会造成内存分配、组件初始化、GC 压力，如果恰好在交火激烈的时候频繁生成，帧数会出现非常难看的尖刺。
我更推荐用对象池。场景加载时预生成一批敌人放在幕后，需要出场时移动到一个出生点、恢复血量、打开碰撞，不需要时清除状态、退出舞台而不是销毁。对敌人这种会被反复打死刷新的战斗单位，对象池几乎是标配。
需要注意几个细节：
- 对象池每次复活 Actor，要重置所有状态：动画蒙太奇要停掉、挂载的粒子要清掉、AI 控制器要重新初始化、广播事件要小心旧的状态还留着。
- 建议用一个 PoolManager 统一管理，而不是每个生成点自己搞一套，方便监控存活数量。
- 真要用异步加载或者延迟生成，也尽量避免在同一帧批量生成。把生成请求排队，每帧只处理两三个，能有效规避帧尖峰。
另外我个人的习惯是，在做生成或对象池逻辑时，先预把 Transform 分开缓存好，因为变换和组件注册在批量生成时也会形成瞬时峰值。
2.3 动画更新优化：不是每只敌人都需要全速率骨骼更新
动画更新在多敌人场景里非常吃 CPU。每个骨骼网格体角色，每帧都要走动画蓝图、采样动画、更新骨骼层级、做蒙皮，几步下来十几毫秒就没了。100 个敌人就是 100 份动画管线在跑，CPU 扛不住很正常。
第一招是使用骨骼网格体 LOD。UE 的骨骼网格支持设置多级 LOD，低 LOD 可以关闭动画蓝图、禁用物理资产、甚至用简化骨骼。设置合理的屏幕尺寸阈值后，远处敌人自动切到低精度，更新负担大幅下降。常见做法是 LOD0 正常动画，LOD1 降低动画采样率，LOD2 直接关闭骨骼动画几秒钟更新一次。你可以通过每个骨骼网格体的 LOD Settings 面板调整。
第二招是用 Update Rate Optimization（URO）。启用 URO 后，骨骼网格可以根据与相机的距离动态调整动画更新频率，比如近处敌人每帧更新骨骼，中距离每 2 帧更新一次，远处每 4 帧更新一次。准确说它是“减少动画更新的频率”，但可以手动开启并设置远近阈值。C++ 里对应UAnimInstance::UpdateRateOptimization，蓝图里也有对应的优化设置，不复杂，但很多人没注意到。
第三招是关掉没有必要的 IK 和物理模拟。比如双脚 IK，放在 FPS 里只对玩家有意义，敌人 NPC 全开着 IK 每帧解算纯粹是浪费。物理资产（布娃娃）在敌人活着的时候通常只参与射线检测，不需要每帧做模拟，没必要的物理约束全部断开。还有动画蓝图的图表本身也值得检查，把每帧都在执行的节点尽量简化，能用缓存就不要每帧重新读变量。
调试动画性能可以用控制台命令a.AnimBP.Profiling或直接在动画蓝图里打开 Debug 面板看各节点耗时，哪条连线跑了最多毫秒一目了然。
2.4 用 UE Interface 代替大而全的 Actor 类型判断
多敌人场景往往有不同类型的敌人：近战、远程、精英、召唤物。很多人写逻辑的时候习惯用Cast<AEnemyType>一层层判断，Cast 本身在热路径上有开销，而且类型维护起来非常痛苦，敌人种类一多，蓝图连线就乱成一团。
UE Interface（接口）是更干净的做法。给敌人定义一套行为能力接口，比如可受到伤害、可以被标记、可以被处决，然后每个敌人蓝图里实现这套接口。调用方只需要GetInterface<IDamageable>，有接口就处理，没有就忽略。这样既避免大量的 Cast 消耗，又让系统解耦，新增敌人只需要实现接口，不用去改每个被调用方。
这个思路在 UE 官方示例项目 Lyra 里体现得很明显，它用大量接口和组件把玩家、AI、武器切成很独立的模块。多敌人场景也完全可以抄这套设计，我后来在项目里把“可被子弹击中”、“可被感知系统识别”、“可被音效系统监听”都做成了接口，逻辑调用链路变短，性能反而更好查了。
3. 渲染侧优化：把 DrawCall 和三角形压力打下来
3.1 实例化渲染：HISM 是群体渲染的本命
谈到渲染侧的优化，首先要面对的就是 DrawCall。多敌人场景里，敌人本身的网格体如果都是一个个独立提交，DrawCall 很容易超过 CPU 渲染线程的承受上限。不过有个尴尬的地方——带骨骼动画的敌人没法简单用 Instanced Static Mesh 来实例化。所以要把“敌人”和“场景里大量重复物”分开看。
像草地、碎石、弹壳、掉落的武器、场景装饰这类不会动或者只会播放简单动画的物体，全部用 Hierarchical Instanced Static Mesh（HISM）或 Instanced Static Mesh 来做。HISM 会自动把大量同类网格合并成少量渲染调用，而且带层次结构，可以按区域分批剔除。移动端项目尤其吃这套，DrawCall 砍下去之后发热和耗电都明显好转。
对于真正有骨骼动画的敌群，如果游戏是 RTS 或者俯视角大规模战斗，可以考虑把多个敌人合并成同一个动画骨骼驱动的大网格体，本质是把 100 个敌人变成同一个渲染对象，这个做法在一些大世界项目里已经落地过，但对 FPS 这种近距离看角色细节的项目来说，实现成本高，容易破坏角色表现。
我的建议是务实一点：FPS 里玩家能同时看见并且能够发生战斗交互的敌人数量通常在 20 到 60 个。如果敌人数量上千，那走的是另外一个方向（群体渲染 + 极简动画），不适合普通射击游戏。先保证 60 个高质量敌人在近中距离不掉帧，让远处的敌人走 LOD 和简化逻辑，比强行做群体渲染靠谱得多。
实际优化时可以用r.DrawCallStats看当前的 DrawCall 总数，用ProfileGPU看渲染线程提交时间。如果 RenderThread 偏高，优先检查是不是场景里有大量独立网格体没有实例化。
3.2 阴影、光照和距离场的取舍
多敌人场景里，阴影是最容易被人忽视的渲染吞噬者。每个投射阴影的角色都要多画一次深度 pass，如果每个敌人都开着级联阴影，100 个敌人就有 100 份阴影工程量。加上动态光源，GPU 负载直接爆掉。
针对敌人集群场景，我常用的做法：
- 限制动态阴影的距离。级联阴影不需要覆盖整个关卡，设置一个合理的 Shadow Distance，比如 30 到 50 米，超过这个距离的敌人直接不投阴影，只保留环境光遮蔽的接触感。
- 远处的敌人用低分辨率阴影贴图，或者干脆只用一个简单的 blob 阴影暗示高度。
- 尽量避免在核心战斗区域摆多盏动态光源。用预计算光照或者充分利用 Lightmass 烘焙静态光照，让动态阴影只服务于玩家附近的小范围。
- Distance Field Shadow 在 UE 里可以做柔和阴影，但它的开销在某些平台上不算低，用之前先 Profile 一下，不是在所有项目里都能白嫖。
讲到“低延迟反射”这个热词，其实对应的是实时反射质量。多敌人场景里我不建议开 SSR（屏幕空间反射），因为它本身是大面积的逐像素计算，人群一密集，屏幕空间里全是角色，反射计算量会被成倍放大。用反射捕获静态场景，角色身上的高光直接走材质本身的 specular 信息，获得的性能收益非常可观。1% low 帧的稳定性和这个设置关系很大。
3.3 遮挡剔除和 LOD 策略
UE 的默认遮挡剔除大多是软件遮挡，靠场景中包围盒来判断。多敌人场景里，如果敌人藏在掩体后面，理论上不该渲染，但默认剔除可能因为判断不够细，导致大量不可见角色也在提交渲染。这时可以拿预计算遮挡体积（Precomputed Visibility）来做。它对静态场景效果很好，缺点是场景动态变化时会失效，适合地图相对固定的关卡。
关于 LOD，很多人只给静态网格做了 LOD，敌人骨骼网格却不做，或者做了但距离阈值设得太远。骨骼网格的 LOD 不只是降低网格面数，更重要的是可以在远处关闭动画更新。我习惯把敌人 LOD 的距离调成比较激进：近距离玩家能看到面部表情就保持正常，一旦出战斗范围立刻切低模。配合上一节提高的骨骼 LOD 和 URO，敌人数量稍微上来一点也不会把线程打满。
给网格模型做 LOD 的时候要注意：法线贴图和材质复杂度也要跟着降，单纯降低面数但材质仍然是全分辨率贴图，性能提升有限。材质里如果出现很重的自定义节点，比如复杂的噪声扰动、多次纹理采样，请考虑给远 LOD 换一套简化材质。
3.4 Niagara GPU 粒子替换 CPU 粒子
敌人死亡时喷血、爆炸、烟雾，这些特效如果是 CPU 粒子系统，每个粒子都占 CPU 开销，几十个敌人同时死亡，CPU 直接卡死。把所有粒子特效迁移到 Niagara 的 GPU 发射器，让粒子的模拟跑在 GPU 上，CPU 压力立刻就降下来了。
多敌人场景里特别容易犯的一个错是：为了“手感”，每个敌人都挂了一堆常驻粒子特效，比如火焰、毒气、电弧。这些永久性发射器就算没有可见粒子，也会持续产生 CPU 开销。我的原则是——粒子特效只在事件触发的瞬间出现，持续时间短、发射数量可控、结束后立刻禁用发射器。不要把持续性特效简单塞给几十个敌人。
4. AI 与逻辑层优化：让群体的“大脑”也降频
4.1 感知系统的周期更新
AI 感知系统（AIPerception）本身是个好东西，可默认配置下它每帧都会做感知更新，多敌人场景里每个敌人都有一份感知数据要算，CPU 开销非常线性。我见过一个项目，50 个敌人什么都不干，光感知系统就占了游戏线程 8 毫秒。
正确的做法是在感知系统配置里把更新间隔调大。比如视觉感知 0.2 秒更新一次，听觉感知 0.1 秒更新一次。对人的反应来说，敌人“发现玩家”的判定慢个 0.1 秒根本感知不出来，但 CPU 能省下一大块。
某些更复杂的感知逻辑，比如“玩家被遮挡后敌人是否还能知道玩家在哪”，也别每帧都跑射线。利用 UE 里已有的 LastStimulusLocation 缓存机制，让感知系统只记住最后看到玩家的位置，然后低频验证。这样敌人依然表现得“聪明”，但不会像以前一样每帧做几十次射线检测。
4.2 行为树和寻路的成本控制
行为树本身很轻，但如果每个敌人每帧都评估、每帧重新寻路、每帧互相同步路径，那多敌人场景肯定崩。行为树可以在配置里修改评估间隔，通常 0.1 到 0.25 秒评估一次完全足够。
寻路是大头。当 50 个敌人同时请求 A* 寻路，CPU 会非常难受。几个实用技巧：
- 不要每帧请求寻路，改成定时器触发，或只在状态变化、目标位置明显变化时才请求。
- 对大量单位前往同一目标的情况，可以引入 Flow Field（流场寻路）。预先计算一张目标方向的流场，所有角色只需要查询格子方向，避开逐个个体的 A* 计算，非常适合僵尸潮一类的场景。
- NavMesh 的 Agent Radius、Cell Height 不要设置得过小，网格精细度翻倍，构建时间和寻路开销都是几何级数增长。
- 动态障碍物数量要控制，不要把每个敌人都变成动态障碍物。动态障碍太多，NavMesh 每次更新都要重新切块，掉帧特别严重。
4.3 网络同步与移动同步优化
如果你的 FPS 是多人联机，服务器压力也会影响客户端帧率，尤其是在多敌人场景里。服务器如果同时要同步 50 个敌人的状态、每个敌人的动画播放状态、AI 行为树状态，带宽和 CPU 都会被逼到极限。
调优方向很明确：
- 根据玩家与敌人的距离调整
NetUpdateFrequency。远处的敌人不需要每秒 30 次同步，3 到 5 次完全够，靠近了再提高。 - 敌人移动默认走 CharacterMovementComponent 的全量同步，可以改为 Actor 的简单同步，或者使用 “IsReplicatedOnlyTick” 之类的设置来减少更新频率。
- 如果敌人本身对玩家交互只做本地模拟（比如尸体、断开连接后的残余怪物），可以考虑只同步一个位置和一个状态值，其他全留在客户端本地预测。
多人联机还有一个经验：把 AI 行为逻辑尽量放在服务器上跑，客户端只做表现和输入转发，虽然服务器 CPU 压力会大，但可以保证所有客户端看到的敌人状态一致，不容易出现怪在我这边被打死、在你那边还活着的尴尬场面。服务器优化做得好不好，直接影响 1% low 帧，毕竟服务器一旦长时间卡顿，客户端同步会连着掉帧。
5. 常见问题与排查技巧实录
5.1 常见问题速查表
我把多敌人场景里最常见的性能问题和排查方向整理成了一张表，直接对着看就行：
| 现象 | 可能原因 | 优先排查方案 |
|---|---|---|
| 敌人一多帧数立刻暴跌 | GameThread 被 AI/动画/蓝图逻辑占满 | stat unit看 GameThread 毫秒数，逐个关闭 AI 感知或 Tick 间隔做对比 |
| 视角转动时卡顿明显 | DrawCall 过高或阴影过重 | stat rhi看 DrawCall 总数，降低动态阴影距离，检查 LOD 阈值 |
| 开枪或怪物死亡瞬间掉帧 | 动态生成/销毁、粒子发射、物理模拟 | 使用对象池，特效改为 Niagara GPU 粒子，布娃娃只在近距离激活 |
| 平均帧还行但开枪时手感发飘 | 1% low 帧偏低 | ProfileGPU 和 Unreal Insights 抓尖峰，重点查反射、阴影、物理、异步加载 |
| 远处敌人没有细节但还在消耗 | LOD 和 URO 未生效 | 检查骨骼网格 LOD 距离阈值，确认 URO 已启用 |
| 场景空无一物却帧数低 | 不可见物体照样在渲染 | 开启遮挡剔除，检查是否误开了“完全渲染所有 Actor”之类调试选项 |
| 移动端一热就掉帧 | GPU 过载或内存带宽太高 | 降低阴影、粒子、后处理，开启 HISM，控制面数和贴图大小 |
表格里的优先级是我自己的排序，实测下来命中率很高。
5.2 优化前后的数据对比经验
这里拿我之前一个 FPS 幸存者类项目举例，场景是 50 个敌人同时在场。优化前的数据大概是：
- 游戏线程：17-19ms
- 渲染线程：8-10ms
- DrawCall：4000 左右
- 平均 FPS：35
- 1% low：22
经过对象池、Tick 间隔调整、感知系统周期更新、动画 URO 优化、阴影距离限制、部分物体 HISM 化、Niagara GPU 粒子替换之后：
- 游戏线程：4-6ms
- 渲染线程：4-5ms
- DrawCall：1300 左右
- 平均 FPS：70
- 1% low：55
这个对比也印证了一个观点：多敌人场景的优化，CPU 侧的收益往往比 GPU 更大。很多人一开始只会去调阴影和分辨率，结果就是 GPU 降了一点点，GameThread 还是爆的，问题根本没有根治。
建议你每做一项优化，就开控制台记录一次数据。别一口气改十项然后发现帧数好了但不知道是哪一项起效的，这个习惯会帮你后续迁移到新项目时有据可依。
5.3 我踩过的几个坑
最后分享几个我实际踩过的坑。
第一个坑：只看stat unit的 GameThread 高，就去砍动画，结果几小时白干。后来开 ProfileGPU 才发现真正的问题是后处理里开了高分辨率体积云，GPU 被吃满，渲染线程反馈到帧率上。先分清是哪个线程的锅再动手。
第二个坑：把 HISM 用在了会被频繁移除和添加组件的位置。HISM 按理说可以增删实例，但如果你每帧都在动态添加几百个实例，重建层次结构本身也会造成 CPU 尖峰。HISM 适合相对静态的重复物，不适合高频变动的物体集合。
第三个坑：敌人的 Tick 间隔设成 0.1 秒后，动画还是每帧跑，因为我忘了骨骼网格的动画更新跟 Actor Tick 是两回事。动画更新的优化要单独调 URO，或者从动画蓝图里彻底关掉不必要的节点。省了这一块，多敌人场景的动画开销依然很高。
第四个坑：做对象池时没有把敌人身上的特效和音效组件完全重置，导致敌人“复活”后还在播放上一次死亡的声音或粒子，既让人出戏，又白白增加 CPU 和 GPU 消耗。对象池“复活”函数里必须把该停的、该清的、该断开的全部处理干净。
我自己现在优化多敌人项目的顺序基本是：先stat unit看线程，再 Unreal Insights 看细节，然后按“逻辑 Tick 减负 → 对象池化 → 动画 URO → 渲染 LOD 和阴影 → AI 感知降频 → 网络同步降频”的顺序一路做下去。每做完一步就回到stat unit看一次数据，通常会非常清楚地看到某一步把一个尖峰修掉了。多敌人场景的优化不是什么玄学，说到底就是把不该花的每帧开销找出来并停掉，把该花的花在玩家真正看得到、感觉得到的地方。
