做FPS项目的人，几乎都会遇到同一个尴尬阶段：单测一个敌人、几个敌人时帧数很漂亮，一旦场景里铺开三四十个敌人，UE FPS 性能优化的警报就响了——帧率从一百多直接掉到四十，近战混战瞬间甚至能感觉到单帧顿卡。这套优化笔记是我自己在项目里反复调出来的实践方向，重点讲多敌人场景下如何系统性定位瓶颈，以及按收益排序去优化渲染、动画、AI和物理。如果你也在用虚幻引擎做多人战斗场景，不管是小规模遭遇战还是大规模刷怪，这篇文章的目标是让你拿到一套可以直接上手的排查路径和优化手段。

内容会覆盖从工具使用到具体配置的完整链路：如何用stat命令和Unreal Insights把瓶颈定位到线程级别、如何用LOD和剔除压低渲染成本、如何用动画预算分配器控制多角色的动画开销、如何让AI感知和寻路不再成为游戏线程的拖累，最后配上实测前后的数据对比。无论你用的是UE5还是UE4，大部分方案都能直接落地。

1. 多敌人FPS的瓶颈分布：先搞清楚卡在哪根神经上

先抛个结论：在多敌人FPS里，"感觉卡"绝大多数不是单一原因，而是渲染、动画、AI、物理四块开销在同一个帧里叠加。单看某一个模块时每个都不至于崩，一旦四五十个敌人同时进场，你的游戏线程、渲染线程和GPU可能同时接近满载，这时候任何一次突发的资源加载、一次GC暂停、一个敌人的瞬时动画开销，都会把帧时间顶到十几二十毫秒以上，反映到玩家脸上就是"开火瞬间掉帧"。

还有一个容易误判的点：FPS框架下的帧率有平均帧和"1% Low帧"两个维度。平均帧看着有八十多帧，但1% Low帧只有二十多帧，玩家的实际感受就是"卡但不至于完全玩不了"——这种忽高忽低的抖动感，在多人敌人混战里尤其明显。所以性能优化的目标不只是把平均帧拉高，还要把最差的那1%帧时间压住，让战斗过程保持稳定的输出节奏。

1.1 三个线程+GPU的常规判断套路

UE引擎在编辑器中按下~键，输入stat unit，会看到一个经典的帧头统计，它把一帧拆成几个主要区域：Frame、Game、Draw、GPU。多看几行数字，你就知道当前帧是被谁拖死的：

• Game线程高：游戏逻辑、AI、寻路、物理同步、动画更新最终都会落到游戏线程，表现为持续偏高或频繁Hitch。
• Draw线程高：渲染线程负责收集可见对象、生成绘制指令、驱动骨骼蒙皮任务、提交GPU状态，Draw过高常伴随大量骨骼网格体或过多的静态网格实例。
• GPU高：GPU一侧的负载主要来自着色器复杂度、overdraw、阴影和后处理，比如大范围烟雾、多个实时阴影光源、全屏特效堆叠。
• Frame高但Game/Draw/GPU都不高：这就很反常了，多半是等待事件、网络同步、内存分配或GC导致的阻塞，需要用Unreal Insights进一步查。

实际跑法：在敌人数量固定的一局里，先用stat unit看整体水位，再打开第二层统计。比如stat scenerendering看可绘制体数量、stat animation看骨骼动画更新耗时、stat ai看AI控制器与感知开销、stat navigation看导航路径查询和运行时导航生成的负载。一层层往下拆，优化的方向就不会跑偏。

1.2 多敌人场景的典型开销组成

以我的经验，一个四十名敌人的遭遇战场景，典型的帧时间开销分布大概是：游戏线程里AI感知和BehaviorTree决策占3到5毫秒，动画更新占2到4毫秒，物理与命中查询占1到2毫秒；渲染线程因为骨骼蒙皮和绘制指令生成占2到4毫秒；GPU端阴影与shader复杂度占2到5毫秒。这些都是经验区间的估计，不同项目差异很大，但有一个共性：没有任何一块是绝对的大头，往往是几块一起涨。所以对通用性能优化流程来说，你要做的第一步永远是确认当前瓶颈，而不是凭感觉去关阴影或删特效。否则你关了半天的阴影，最后发现瓶颈在动画更新线程，那就白折腾了。

2. 用统计工具把"感觉卡"变成"数据卡"

性能分析环节很多人会跳过去直接改代码，我觉得这是最亏的。工具本身不复杂，难的是养成"先数据、后动手"的习惯。下面这套流程是我每次优化多敌人场景都会走一遍的固定套路。

2.1 stat unit 与 stat 类别的组合用法

建议把常用命令整理成一个清单，开发过程中随时调出：

stat unit stat scenerendering stat animation stat ai stat navigation stat rhi stat startfile stat stopfile

stat startfile配合stat stopfile可以在本地生成一份trace文件，之后用Unreal Insights打开，能按线程维度看到每一帧里各个函数的真实耗时。相比纯粹看stat unit，trace文件能定位到具体函数和调用链，比如到底是AActor::Tick里的哪个任务耗时，还是骨骼更新接口消耗大。正式优化前的几天，我会开着stat startfile把战斗过程录几分钟，然后回放查看，比边玩边盯数字更容易发现细节。

对于肉眼观察，我习惯在战斗中切几个角度记录帧时间：敌人在视野内少量、大量聚堆、面向或背向玩家、开火瞬间，这些不同状态下瓶颈常常不一样。你可能发现大量敌人聚集时GPU阴影压力爆炸，但在空旷地带时游戏线程反而最高。录数据时尽量把固定相机和自由录屏都做一遍。

2.2 Unreal Insights的Trace链路与耗时采样

UE的Unreal Insights在统计大量AI和骨骼更新时非常有用。操作方法不复杂：控制台输入stat startfile，进入战斗后输入stat stopfile，在编辑器里用Unreal Insights打开生成的.utrace文件。此时可以重点查看：

• GameThread Timeline：找每一帧游戏线程里的最宽块，确认AI、物理、动画的分布。
• RenderThread Timeline：看骨骼网格体更新、Primitive组件收集的耗时。
• 帧与帧之间的间隔：如果有明显的无逻辑空洞，可能是等待GPU或线程同步。

在大量敌人场景里，GameThread上的AIPerception、BTService、AnimInstance的耗时块会非常醒目。一旦你能在Timeline上看到这些块，也就知道先优化谁了。

2.3 帧曲线与瓶颈切换的判断方法

一个常见误区是只盯Frame时间。比如你优化了AI后，Frame从19ms降到12ms，以为就够了；再跑一场发现GPU从5ms涨到10ms，帧又卡到16ms。这不是优化失效，而是瓶颈从游戏线程转移到了GPU或渲染线程。性能优化是个搬迁过程：把一边降下去，另一边的水位就会显出来。所以我通常在优化每个环节后重新跑一次完整的统计，记录Frame/Game/Draw/GPU四项的变化，同时关注1% Low帧。用表格或Excel记录每次改动前后的数据，比嘴上说"感觉流畅了"可靠得多。

3. 渲染侧优化：让"看得见"的敌人更便宜

进入渲染部分。多敌人场景里，渲染线程和GPU的开销主要来自：每个敌人角色的骨骼网格体绘制、阴影绘制、材质与着色器复杂度、动态光源的影响范围，以及远处一堆敌人依然在完整渲染。这里的优化原则很简单：让屏幕上排不上号的敌人，以最低的精度绘制。

3.1 Mesh LOD与骨骼LOD的阶梯化设置

静态网格体的LOD大家比较熟，在Mesh属性里自动生成几档距离LOD即可。但敌人是骨骼网格体，除了静态网格LOD，还有骨骼网格体特有的LOD机制：同一套模型可以按骨骼层拆成不同精度的LOD。例如全身完整骨骼的LOD0，去掉手指骨骼、只保留主骨骼的LOD1，再进一步去掉部分身体骨骼的LOD2。这样远处敌人不仅模型面数少，骨骼更新和蒙皮计算的成本也随之下降，而不是像传统LOD只降面数、骨骼计算还白费。

设置时要注意：编辑骨骼网格的LOD，需要在Skeleton或SkeletalMesh的LODSettings里按骨骼名称对应的LOD分组，把"低优先级骨骼"（如手指、饰品）放进低LOD组。这个操作有学习成本，但收益非常直接，特别是同时渲染几十个敌人时，骨骼LOD带来的性能节省比单纯压顶点数明显得多。

3.2 阴影与动态光消耗控制

阴影往往是多敌人场景里最容易被忽视的GPU杀手。一个敌人角色在镜头前投射的动态阴影，会成倍增加渲染开销，阴影距离稍远就大量消耗。常用的手段：

• 对远处敌人关闭Cast Shadow，或使用Shadow LOD：例如距离玩家超过一定范围的敌人只对主光源投射阴影，不参与次要灯光阴影。
• 场景主光源用可移动光源时，阴影地图分辨率不要整体拉太高，用距离衰减让近处清晰、远处模糊。
• 非必要的点光源/聚光灯如果会照亮多个敌人，会强制它们重新参与阴影计算；能烘焙的静态光源尽量烘焙，动态光源数量控制在个位数。
• 使用UE5的Virtual Shadow Maps时，给每个动态网格设置合理的阴影距离和缓存策略，避免每帧重建大量阴影图块。

实战里我习惯打开Lit视图下的Shading Model或直接查看阴影渲染耗时，然后一个光源一个光源地关掉看帧时间变化，保留"视觉上还能接受"的那部分。

3.3 剔除策略：距离、遮挡与视锥的配合

剔除是性价比最高的一类优化。首先保证视锥剔除默认开启，然后布置Cull Distance Volume：距离摄像机超过一定距离的物体直接不渲染，适合敌人模型、杂物、装饰物。注意敌人这种"会活动且可能与玩家互动"的物体，不能无脑远距离剔除，可以先在距离阈值外禁用渲染但保留AI，或者用"淡出+关闭渲染"来避免突兀。

遮挡剔除在多敌人场景中也很关键。室内巷道大量敌人堵门时，如果引擎能正确识别前后遮挡，可以省下很多Draw Call。默认的遮挡查询使用GPU Occlusion，前提是必须有足够大的遮挡物（例如墙体）以及合理的可视化设置。如果发现敌人之间互挡导致绘制量暴增，可以检查渲染设置里的遮挡查询阈值，并利用阻挡体积让引擎理解哪些是"遮挡主力"。

对于完全静止的装饰性网格（柱子、路障、掩体），用Hierarchical Instanced Static Mesh（HISM）或Instanced Static Mesh（ISM）合并实例。这样可以大幅压减Draw Call，把节省出来的渲染线程预算留给真正的敌人骨骼网格体。

4. 动画与骨骼：50个敌人同时跳舞的CPU代价

多敌人场景的CPU瓶颈，很多时候最先爆掉的是动画更新。每个骨骼网格体组件每帧都要做一次骨骼姿态计算，包括读取动画资产、加权骨骼变换、生成最终蒙皮矩阵。你想象一下，原本一个玩家角色做这件事不痛不痒，当有40个敌人同时刷新时，这个"每人一份"的开销瞬间就变得极其显眼。

4.1 动画更新管线在何处吃掉CPU

敌人动画从资源到屏幕大致经过这几个环节：加载动画序列、动画蓝图更新状态机、姿势计算（Locomotion、IK等）、骨骼网格体Finalize、蒙皮提交。其中动画蓝图的状态机如果每帧都做大量蓝图节点计算，开销会被放大几十倍。我见过一个项目里，敌人动画蓝图为了做随机空闲效果，每帧会调用多个随机数生成和计时器检测，单个敌人多了之后Game线程直接顶上十几毫秒。

所以优化动画时优先级大概是这样：先关掉不必要的IK——Full Body IK或CCD IK非常贵，多角色时能不用就不用，或者只在近处少数敌人上启用；再用Animation Budget Allocator统一管理多角色动画更新；最后才考虑是否把动画蓝图重构成C++ AnimInstance。IK这玩意单人演示很惊艳，但在几十个敌人同屏时，基本属于"性能黑洞"，该关就要关。

4.2 Animation Budget Allocator 配置实践

UE的Animation Budget Allocator是一个专门为多角色动画设计的分配器插件。开启方式：Project Settings里搜索Animation Budget打开插件，然后在项目设置里启用它。分配器会根据你设定的每帧动画预算，动态决定哪些角色升级动画更新频率、哪些角色降级，甚至跳过某些角色的动画更新只保留最后一帧姿势。

我常用的配置思路：

• 先把Average Frame Rate设为目标帧率的一半左右，例如目标60fps就设30到40，给其他模块留余量。
• AnimQualityOption选择按LOD自动降级；近处玩家前方的角色走完整动画，远处的直接降到低频率更新。
• 分配器支持把不同角色的Budget权重调高/调低，让玩家关注的"重要敌人"保持流畅，普通杂兵尽量节省。
• 同时开启骨骼网格体上的Update Rate Optimization（URO）选项，让远处的敌人降低动画更新频率，从60fps更新降到20甚至10fps更新。直观看去会有微小跳帧，但在混战里非常不容易被察觉。

实际踩过的坑：如果不设置的角色在Animation Budget Allocator下被强制降级，可能出现在战斗中被击倒后依然播放站立动画的诡异情况。解决办法是给关键状态（死亡、受击停滞、处决动作）预留更高的Significance，或强制该角色升级回完整动画。所以这个功能适合"大量杂兵+少数Boss"的结构，不适合所有敌人都想要精细动作的设计。

4.3 动画曲线与状态机的瘦身

除分配器外，动画序列和状态机本身也要瘦身。动画资产的压缩和Retarget其实影响加载与读取速度；最重要的是剔除无用的动画曲线（Curve）。动画曲线会随着动画更新而计算，如果每个敌人动画都携带大量用不到的自定义曲线，CPU开销会凭空增加很多。建议在动画资产的曲线面板里，删除项目中完全不会被AnimGraph引用的曲线。

状态机方面，多敌人场景尽量用简单的Locomotion状态机+条件变量驱动，减少嵌套状态机和大量Transition。UE5项目如果要频繁做复杂角色过渡，可以直接用Inertialization功能——它用惯性融合来处理状态切换，本质上通过混合上一个状态的姿势惯性来避免触发复杂Transition骨骼处理。默认在动画蓝图的状态机里启用后，过渡开销会明显下降，多敌人时差距会被放大。

5. AI、导航与物理：游戏线程的"隐形重担"

很多人在渲染和动画上花了很多精力，打开统计却发现游戏线程还是高居不下，往下一看，全是AI和导航的账单。这一节我把多敌人场景里最容易超预算的三个系统单独拉出来讲。

5.1 敌人AI的高频横跳与感知冷却

AIPerception是AI开销大户之一。默认视觉感知会定期执行视线检测，每次检测都要做射线和碰撞查询。当几十个敌人同时存在，如果感知更新间隔为0.1秒，每一帧就有好几个甚至十几个感知检测在进行，射线查询量快速上升。所以我把每个敌人的感知更新间隔调成0.3到0.5秒，甚至根据难度设定在玩家进入战斗后才提高频率；创建感知时常按"可见性变化"定时刷新，而不是每帧持续检测。

然后是BehaviorTree的Tick。BehaviorTree本身是低频驱动的，但如果你在BTService里每帧去执行路径跟踪或更新黑板键，仍然会累加。我的做法是：把高频循环从BTService里拆出去，比如移动速度更新、距离计算这种逻辑改成按距离LOD触发；BT节点之间用Wait和更长的间隔来控制决策频率。这也呼应了前面说的Blueprint性能原则：频繁的逻辑放在更底层的C++里，蓝图负责低频表达。

远距离敌人还有一个很划算的策略：进入"休眠"状态。当玩家距离某个敌人超过阈值时，直接停止该敌人的BehaviorTree和Perception，甚至把它的Tick关闭或拉大Tick间隔，只保留一个简单动画或干脆暂停动画。玩家靠近时再唤醒。这相当于给AI加了个"距离开关"，比任何局部优化都省。

5.2 导航网格与路径查询的预算控制

大量敌人同时做路径请求时，stat navigation会显示明显的路径生成开销。常见问题包括：动态障碍物导致网格频繁重建、导航体量大（大范围多层关卡）、大量Agent在同一区域同时执行MoveTo。处理手段：

• 限制同时进行计算寻路的AI数量：对远处的敌人不做实时寻路，只在被玩家感知到后，才在回合外计算一次粗路径。
• 避免频繁请求MoveTo：很多AI因为每帧更新目的地而反复发起路径查询，实际上只要终点变化不大，一个Wait或定时重算即可。
• 动态障碍影响：如果敌人之间的碰撞只用于彼此避让，尽量用轻量的避让逻辑代替实时Rebuild导航网格；除非必要，别让区域内高频变化物件影响导航网格。
• 导航网格分块：把导航网格按关卡区域拆分，让AI只在所在区块内寻路，不要跨区，减少路径搜索空间。

5.3 碰撞检测的按需拆解

物理开销在大量敌人时主要来自两点：每帧持续更新的碰撞查询，以及敌人之间互相穿透导致的求解。命中检测如果每个子弹都做一个独立的射线，子弹一多，碰撞查询的数量就会指数级增加。多敌人FPS里更优的做法是：把命中检测放在一个统一的批量查询函数中，比如用MultiSphereTrace一次扫出一串潜在目标，再逐个做有效性判断；或者把子弹的命中查询延迟合并到低频更新。

敌人自身的碰撞体尽量精简：多数敌人用胶囊体做查询、球形做检测，不需要精确的身体碰撞。想让子弹有"打中装甲/肢体不同部位"的效果时，再针对关键敌人启用更细分的多碰撞体，但普通杂兵保持简单。还要注意关闭不必要的Simulate Physics——很多敌人的武器、挂件如果开了物理模拟，战斗时会被爆炸波及，瞬间几十个动态物体在互相推撞，物理引擎会花大量时间求解，而这些效果玩家根本注意不到。

6. 多目标实测：以40个敌人场景的优化复盘

理论讲完，上一段实测数据。这个案例是我优化过的一个体验关卡：室内巷战，敌人总数40个左右，长期保持25到35个同屏，主角是手枪+随机刷怪点。开发期就一堆掉帧，编辑器和Packaged Build都有感知。基线配置是1080p、中低画质，目标是想稳住60fps以上。

6.1 基线数据采集方法

先保持画面设置不变，按之前说的方式录制三分钟的遭遇战trace，每隔几秒在固定点位让敌人持续靠近。统计结果如表：

可以看到优化前的瓶颈明显在Game线程，且1% Low很难看。按上面的顺序，我先优化AI（感知间隔、休眠）、动画（URO + 动画预算分配器），再做渲染侧削减，最后处理物理查询。

6.2 分阶段优化清单与结果

第一阶段：AI感知0.3秒间隔，远距离敌人休眠，移除BTService里每帧的路径重请求。Game线程从11ms降到7ms，1% Low从24fps提升到32fps。

第二阶段：启用Animation Budget Allocator并开启URO，把近战敌人动画更新频率降到30fps、远处降到15fps，同时剔除动画资产无用曲线。Game线程再降到5ms，动画更新产生的Blocks明显消失，帧时间变得更稳定。

第三阶段：渲染侧下重手。把距离玩家较远以外的敌人强制LOD2并关闭动态阴影；场景静态杂物改用HISM合并；动态点光源保留两盏，其余都改范围缩小或直接删除。Draw线程和GPU各降1-2ms。

第四阶段：物理与碰撞。敌人统一用胶囊体查询，命中检测改用一次性范围扫掠而不是逐发子弹全屏射线；关闭敌人武器小道具的物理模拟。Game线程进一步降到4ms以内，物理Hitch消失。

最终数据：

这个案例里的数据仅代表我的项目环境，但优化路径是可以复制的。如果你的项目基线不同，数据比例会有差异，但 "AI→动画→渲染→物理" 这个优先序在多敌人场景里几乎不会错。

6.3 值得注意的取舍与踩过的坑

最后总结几个过程中实际踩到的坑。

第一，动画预算分配器会把一些"看起来近但其实在优先区域外"的敌人也降级，导致玩家面前某个敌人卡成一帧一帧动。解决办法是使用分配器的Significance接口，或者干脆在玩家周围一定半径内禁用分配器对特定角色的调度。

第二，远距离敌人休眠的判定不能只看距离，还要参考玩家的朝向。如果一个敌人呆在玩家身后几米处，但因为距离阈值太大没休眠，反而不如干脆关闭渲染。更合理的方案是"距离+可见性"双条件组合：既不在镜头前、又不在感知范围内的敌人才休眠，否则会出现身后偷袭的敌人完全消失的尴尬。

第三，命中检测的批量扫掠要注意碰撞通道的层级。如果所有敌人都只有一个胶囊体和同一个碰撞通道，一次性扫掠确实很快；但如果想区分爆头、肢体伤害，就得额外维护一套"组件命中映射"，这部分的代码成本和调试成本也要纳入预期。为了纯粹的帧数把玩法做糙，那就本末倒置了。

最后，任何优化在多人联机项目里都要多做一步验证：因为服务器和客户端逻辑分离，客户端侧的动画和AI预算再低，也不能影响服务器上的行为判定。我个人的习惯是，每当一个大优化做完，至少跑一遍服务器逻辑测试，确认远距离休眠和动画降级没有破坏玩家的战斗反馈。

多敌人FPS性能优化的本质是做预算管理，把有限的帧时间优先分配给玩家正在关注的内容。先诊断瓶颈再动手，从AI感知、动画预算、碰撞查询这些CPU大头切起，再从LOD、阴影和剔除上抠GPU与渲染线程。我自己的项目走到现在，最深的体会是：性能优化不是一个一次性的任务，而是要跟着关卡、玩法、美术迭代反复测量的长期活。希望这套流程能给你省下一些走弯路的时间。