先讲个场景。我之前在做一个 UE FPS 原型项目里面有一张靶场地图AI 敌人按波次进场最多同屏 20 个。最初跑起来帧率惨不忍睹开战前 144 帧上下第一波敌人一进场直接掉到 70交火激烈时甚至跌破 501% Low 帧能掉到 30 出头。这种“平时很顺、一打起来就卡”的体验在射击类项目里是最致命的因为玩家感知到的不是平均帧率而是帧时间是否平滑。那颗突然卡顿的瞬间可能就正好是敌人开枪、你拉枪线的那一帧。这篇就是拿这个多敌人场景做例子把 UE FPS 性能优化从定位到落地的完整思路拆开讲。如果你正在做 FPS、塔防、ARPG或者任何“同屏几十个单位”的项目应该能从中拿走一套可以直接套用的优化路径。1. 动刀之前先搞清楚多敌人场景到底卡在哪里优化这事最忌讳的就是“感觉卡然后瞎改”。我见过太多人一上来就关阴影、降分辨率、砍材质结果画面糊了帧率没怎么涨。因为多敌人场景的瓶颈往往不是渲染而是游戏线程和动画系统。所以第一步永远是定位而不是动刀。1.1 多敌人场景的“全栈”嫌疑对象一个敌人在场景里占用的资源远比你想象的多。它至少包含四个层次的成本渲染层骨骼网格体要提交到 GPU 才能画出来。每个敌人都有自己的三角面数、骨骼数量、材质、阴影投射同屏 20 个敌人就是 20 倍开销。动画层每个敌人身上有一个动画蓝图实例每帧要做状态机求值、骨骼采样、蒙皮计算这一串走完CPU 时间就烧掉了。AI 逻辑层AIController 里的行为树、感知系统、寻路组件全部都是每帧在跑的东西。20 个敌人同时思考本质上就是 20 棵行为树在 Work。碰撞与内存层每个敌人的胶囊体都要参与碰撞查询投射物、子弹检测都对着它们来加上 Spawn/Despawn 时的对象布局和垃圾回收都会变成帧时间上的毛刺。这个结构里最坑的是它们都在同一条帧时间链路里排队。你只优化其中一项帧率大概率没什么变化因为瓶颈会从一个环节转移到另一个环节。所以我会先跑一轮 Profile把各阶段的时间拆开看清每一刀到底该砍向哪里。1.2 先用工具定位瓶颈别让优化变成开盲盒UE 自带的性能工具链足够完成 90% 的定位工作关键是你要知道看什么、怎么看。第一件事对着运行中的游戏打开控制台数字键 1 左边那个反引号键底下是 输入stat unit这个命令会把一帧的时间拆成 Game Thread游戏线程、Draw Thread渲染线程、GPU显卡三部分单位是毫秒。这里有个经验判断哪一项数值最高瓶颈就大概率在哪一项。如果 Game Thread 在 10ms 以上而 GPU 只有 5ms那瓶颈在 CPU 侧的逻辑和动画你跑去调阴影参数是没有意义的。如果 Game Thread 很高继续输入stat game这个输出比较长但我重点看两个计数器StaticMeshComponent 附近的 Draw Call 相关值以及 Anim 相关的时间报告。别忘了同时打开一个Unreal Insights编辑器工具栏 Window → Developer Tools → Unreal Insights它能把 Game Thread 里的函数级耗时摊开比如某个动画蓝图的 Evaluate 花了 3ms某棵行为树的 Tick 花了 2ms这里面的数据是实打实的不会骗人。如果 GPU 时间明显偏高则用编辑器视口右上角的 Lit 下拉菜单切到Shader Complexity视图也就是材质复杂度模式。它会把屏幕上的像素上色绿色代表便宜越红越紫越贵。多敌人场景下如果敌人模型的轮廓和胸口细节都红得发亮那就不是 Draw Call 问题是材质和 Overdraw 的问题。先把这轮跑通后面所有优化才有依据。我自己的习惯是建一张表机器配置、场景人数、Game/Draw/GPU 各项耗时、1% Low 帧改之前记录一次改之后立刻记录一次。数据攒起来你才会知道哪些方案在自己的项目里真正有效。2. 渲染侧让画面从“画得太多”变成“画得聪明”拿到 Profile 数据后如果 GPU 时间确实偏高或者 Draw Call 数量异常大就进入渲染侧的优化。多敌人场景的渲染开销有个特点大量重复角色和重复的静态物件同时出现这给合批和实例化提供了空间也意味着每个不经意的阴影或材质设置都会被放大 20 倍。2.1 复用静态物件的网络开销ISMC 与材质合批先说一个很容易被误解的点骨骼网格体无法像静态网格那样直接用 Instanced Static Mesh 合并因为每个敌人的骨骼姿势都会不同不能共用同一份变换数据。所以敌人本体需要靠 LOD、动画预算、材质简化去压成本这在后面会说。但场景里的其他物体完全可以用 HISMHierarchical Instanced Static Mesh Component。靶场里大量重复的箱子、掩体、墙体装饰如果都是一个个静态网格体摆在场景里每个都会提交一次 Draw Call。把它们替换成 HISM 后引擎会按视距自动分批次距离远的还在一个 Instance 批次里Draw Call 数量瞬间降下来。材质合批也要顺手做。比如所有敌人用同一个材质实例而不是每个敌人单独复制一个材质资源能减少材质切换带来的状态变更开销。我当时把敌人身上的“受击闪白”“死亡溶解”全部做成同一个母材质下的动态参数用 Material Instance Dynamic 改参数值而不是每个敌人新开一份材质效果立竿见影。这里还有一个细节特效和贴花Decal的排序。弹孔贴花、血迹贴花一旦铺得多Overdraw 和排序成本会明显上涨。如果场景里有几十个敌人枪战一开打弹坑贴花几十个叠在一起GPU 的压力比想象的更高。我的做法是限制贴花数量并在敌人靠近时优先移除旧贴花再生成新贴花而不是无脑叠。2.2 阴影与光照多敌人场景里隐藏的显卡杀手阴影是多敌人场景里最阴间的开销之一。一个简单规律每个动态光源下每个投射阴影的物体都要多画一遍阴影通道。20 个敌人同时站在场景里如果都开启了投射动态阴影GPU 就要为每个敌人都跑一遍阴影深度渲染这个成本会均匀地反映到 GPU 时间上。我建议按距离分三档控制近距离0~10米保留完整阴影质量这是玩家注意力最集中的区域阴影穿帮最明显。中距离10~30米降低阴影分辨率甚至关闭次级阴影投射。远距离30米外关闭动态阴影改用烘焙阴影或者干脆无阴影。具体实现上可以使用 UE 的距离标量Distance Field和阴影级联参数。在控制台里调试时比较有价值的几个变量r.Shadow.MaxResolution控制最大阴影图分辨率r.Shadow.DistanceScale控制阴影有效距离r.Shadow.CSM.MaxCascades控制级联数。我通常会把级联数从默认的 4 降到 2把阴影距离压到合适范围尤其在 FPS 这种视野狭窄、注意力集中的游戏里远处敌人的阴影其实很难被注意到。特别提醒一点如果你用的是 UE5 的 Lumen不要照搬传统 CSM 参数。Lumen 的动态阴影走的是屏幕空间追踪和 SDF 追踪对多敌人场景的消耗主要来自屏幕上的像素覆盖面积而不是阴影图分辨率。我踩过的坑就是改了半天的r.Shadow.CSM.MaxDistance发现画面毫无变化最后才意识到 Lumen 已经接管了远距离阴影该调的是 Lumen 自己的质量档位。2.3 材质与 OverdrawGPU 上的隐形消耗材质优化在多敌人场景里常常被忽略因为单个敌人看起来没那么贵。但一个复杂的 PBR 材质如果包含多层贴图采样、复杂的节点连线、半透明混合20 个同屏立刻就会在材质复杂度视图里现出原形。我优化敌人材质时遵循一个优先级首先删掉不需要的功能性贴图比如绒毛、次表面、独立的高光贴图能省就省。其次检查半透明部分敌人的护目镜、能量核心这些部件如果使用半透明材质每个重叠像素都会做混合计算比不透明材质贵很多。能用不透明模拟的就换成不透明或者用 Masked 模式代替 Alpha Blend。最后注意着色器指令数用材质编辑器里左上角的 Stats 面板看指令数单材质超过 200 条指令就要想办法简化。多敌人场景的目标是每个角色材质控制在 80 到 120 条以内。还有一个前后台策略敌人进入屏幕外或者被障碍物遮挡时让它不参与主视图渲染。这听起来是废话但很多项目没有设置好组件级 Reactive 或者 Visibility 选项导致离屏的敌人还在正常绘制。骨骼网格体组件上有一个 Visibility Based Anim Tick Option可以设置为 Tick When Offscreen让离屏敌人跳过骨骼更新这个设置在远处有大量敌人的波次式关卡里特别值钱。3. 逻辑侧从“每帧全量驱动”到“按需调度”如果是 CPU 侧瓶颈也就是 stat unit 里 Game Thread 时间很高那么多半不是渲染问题而是动画、AI、寻路和碰撞在互相挤压。很多 FPS 项目用到 20 个敌人时CPU 瓶颈远大于 GPU 瓶颈因为你让 20 个 AI 每帧都在做全套决策和动画计算这本质上是用“每帧全量驱动”的思路在跑一个多智能体系统成本自然爆炸。3.1 动画更新用预算分配器替代全员每帧计算动画是多敌人场景里被低估的大户。一个标准 Skeletal Mesh 角色每帧要经历动画蓝图 Event Tick 求值 → 状态机转到对应状态 → 获取骨骼 Pose → 蒙皮混合 → 更新渲染数据。这一整套流程在单角色场景里毫秒级都不算事但 20 个角色加在一起游戏线程的动画开销常常能到 5ms 以上。UE 为此提供了一个叫Animation Budget Allocator的机制思路很简单它给整个项目的动画更新设定一个总预算比如 2ms然后让引擎自动决定哪些角色全速率更新、哪些角色降频更新、哪些角色跳过更新。优先级高的角色比如玩家当前锁定的目标保持高质量动画远处的、背对玩家的敌人可以降到每秒 15 帧更新或者干脆只播放根运动。打开方式是在 Project Settings 里搜 “Anim Budget”启用这个系统后编辑器里会出现对应的调试视图用不同颜色显示每个角色的动画预算状态。我第一次开启后Game Thread 时间从 6.2ms 降到 4.1ms画面观感几乎没有区别因为远处的敌人本来就不是玩家目光焦点。但这里要注意预算分配器不是万能药。如果你的敌人 20 个都在屏幕中央同时做特殊动作预算会均匀降频可能导致所有敌人动画都出现肉眼可见的卡顿。我的建议是配合骨骼 LOD 一起用给骨骼网格体生成 LOD近距离用完整骨骼比如 68 根骨骼中距离切到简化骨骼版48 根远距离再切到低模形态。屏幕空间占比越小越不值得花完整骨骼的更新成本。如果项目里出现“几十上百个同模角色”的极端需求还可以考虑更激进的方案Animation Sharing。这个插件允许多个 SkeletalMesh 共享同一个动画采样结果代价是所有共享者动作会同步不一致。它非常适合远处的杂兵、观众席人群、背景部队这类不需要独立动画状态的对象。塔防和战争题材项目里很常见。3.2 敌人AI拆开Tick把感知和寻路变成间歇任务AI 是另一个 CPU 大户。默认情况下每个 AIController 会在每帧调用一次 Tick而感知组件会以一定的频率更新周围环境行为树会不断执行任务节点。20 个敌人同时这样做游戏线程很快就会被打满。第一刀是拉开感知组件的更新间隔。AIPerceptionComponent 的感知更新并不需要和渲染帧率一致尤其是视觉感知人眼本身处理视觉信息也不是每帧都刷新。我通常把感知间隔从默认值调大比如 0.25 到 0.5 秒一次然后通过行为树里的冷却节点来打包处理感知结果。调完之后游戏手感不会明显变化但 CPU 占用会立刻降一截。第二刀是把敌人的 Tick 分散到不同帧。这是实际项目里很多新人想不到的20 个 AI 在第 1 帧、第 2 帧、第 3 帧…… 第 20 帧各唤醒一部分而不是全部挤在同一帧里决定要不要开火。最简单的实现是给每个 AIController 分配一个 Frame Offset通过当前帧号和自己的 ID 取模算出一个自定义 Tick 帧。这样每帧只有几个敌人做完整感知和决策视觉上里敌人还是“同时活着”但 CPU 负载被摊平了。第三刀是让非活跃敌人彻底停止思考。FPS 里玩家还没进入某个区域的敌人或者已经死了的敌人没必要继续跑行为树和感知。用圆形区域或者触发器把指挥权交给玩家玩家进入某个 TriggerVolume才激活附近一群敌人的 AIController玩家离开后这群敌人回到“休眠”状态行为树挂起。这对波次式 AI 进场特别有效我在靶场项目里把一半的敌人设置为“未激活”Game Thread 直接少了近 1ms。3.3 寻路与碰撞减少底层查询压力寻路在多敌人场景里是另一个容易被忽略的 CPU 消耗点而且出了问题往往表现为“某几帧突然卡一下”不是持续性的 CPU 占用。因为 AI 同时发起寻路请求时NavMesh 系统要在短时间内处理大量路径计算导致帧时间毛刺。第一件事不要每个敌人独立寻路到同一个目标点。20 个敌人一起对玩家位置发起 MoveTo 请求路径系统会把 20 条路径全部算一遍这是很蠢的开销。更合理的做法是选一个“领队敌人”计算路径其他敌人跟随领队的路径点再叠加上各自的编队偏移。这在 UE 里可以用“领队 队形位置”的方式实现敌人之间保持相对位置而不是各自找路。第二件事烘焙静态 NavMesh。如果场景里有大量动态变化比如墙被炸塌、门被打开能局部刷新就不要全图刷新NavMesh 的运行时重建开销很高。我试过在靶场里加了几个可破坏掩体每次掩体被炸后全图路径重新烘焙帧时间直接起飞。后来改成只在掩体周围做一个动态障碍物绕行标记禁止后半场的路径贴合压力立刻缓解。碰撞这边最常见的问题是给敌人模型开了复杂碰撞。骨骼网格体默认的物体碰撞如果直接用了精细的 Body Setup每个物理查询都会消耗更多 CPU。标准做法是只保留胶囊体作为主要碰撞通道子弹命中检测时用胶囊体粗测命中后再根据帧率决定是否细化到骨骼块。还有一个细节是碰撞 Channel 的设置敌人之间不应该互相产生大量的物理碰撞查询开火检测也只对玩家角色和敌人阵营响应避免把无关对象都卷进射线检测里。4. 实操复盘一个20人靶场场景的优化全过程纸上谈兵到这里我个人觉得最有价值的还是把一个真实场景从“卡到飞起”优化到“稳定爽快”的完整过程记录下来。下面是我做靶场场景时的实测数据机器是当时团队里最常见的 NVIDIA 显卡加中端 CPU目标是在 1080p 下稳定 60 帧以上。4.1 优化前数据画像把卡顿变成数字场景是 20 个 AI 敌人分四波进入一个长约 100 米的靶场。进入交火阶段后我用 stat unit 拿到了这样一组数据指标数值说明Game Thread6.2 ms动画 AI 逻辑为主Draw Thread5.1 ms提交渲染指令GPU8.3 ms阴影 材质 OverdrawFrame14.2 ms约 70 FPS最低到 45 FPS1% Low28 FPS战斗中频繁掉帧这个数据其实说明了两件事第一瓶颈比较分散每个环节都在拖后腿不是某一项特别离谱第二1% Low 帧和平均帧差距巨大说明存在明显的帧时间毛刺多半来自 GC 和 NP 的临时计算。我再打开 Unreal Insights 里的 Game Thread 时间线看到每个敌人的动画蓝图都占了大约 0.2ms 到 0.3ms行为树平均占 0.1ms感知占 0.15ms。20 个敌人的合计时间正好和 6.2ms 对上了。这个定位过程大概花了半小时但省下来的优化时间远远不止这些。4.2 逐项优化与实测结果一次改一处改了就看帧接下来我没有一次性把所有改动全部上马而是逐项改、逐项测。因为如果一次改好多处你永远不知道到底是哪一刀起了作用也无法判断哪个改动在该项目里带来了副作用。第一项是开启 Animation Budget Allocator。这个改动立刻把 Game Thread 时间从 6.2ms 压到 4.1ms帧率从 70 升到 83。20 个敌人的动画更新不再都是全速率靠近玩家和处于攻击状态的敌人保持高质量远处待机的敌人明显降频但因为目光很少看过去体验上没有异常。第二项是AI 感知间隔调整和帧分布。感知间隔从默认值拉到 0.3 秒同时给每个敌人配了不同的 FrameOffset。这次改了之后 Game Thread 从 4.1ms 降到 3.0ms帧率升到 96。敌人反应速度其实没怎么变因为感知间隔 0.3 秒对 FPS 而言完全够用人眼根本感知不到 0.1 秒的延迟。第三项是针对 GPU 的阴影与材质动作。我把中远距离敌人的阴影分辨率降档同时把敌人的材质从 200 条指令压缩到 120 条左右关掉了几处不必要的半透明效果。GPU 时间从 8.3ms 降到 6.1ms帧率突破 100。这里没有牺牲玩家近战时的画面质量因为近距离敌人的阴影和材质依然保留高质量。第四项是对象池和路径缓存。我原本用 SpawnActor 动态生成每一波敌人后来改成了预先生成 20 个敌人存入对象池进场时从池里取出死亡后沉底复用。同时给静态目标的寻路结果加了缓存同一个目标点在一定时间内的寻路结果直接复用不再重新计算。这两项改动把 1% Low 帧从 28 FPS 拉到了 53 FPS平均帧率倒没有涨太多但战斗中的卡顿感几乎消失了。整个优化过程结束后的数据是这样的指标优化前优化后Game Thread6.2 ms2.4 msGPU8.3 ms5.3 msFrame14.2 ms约 8 ms1% Low28 FPS53 FPS4.3 过程中踩过的坑与最终参数建议复盘一遍有几个坑是实打实踩过的写出来希望能帮你避开。第一个坑Animation Budget 开启后远处的敌人动画会周期性冻结。这个机制本身是正常的但如果你把预算设得太紧比如 1ms 甚至更低远处的敌人会直接停在某个 Pose 上不再更新一旦玩家拉近视角视觉穿帮非常明显。我的建议是把预算设得宽松一点比如 2.5ms并用骨骼 LOD 兜底而不是把动画预算压到极限。第二个坑感知间隔调大后敌人会在玩家贴脸时反应变慢。感知更新做得太稀疏敌人被子弹击中后可能需要 0.3 秒才能感知到并做出反应在 FPS 里这是致命的延迟。这要求你区分“低优先级感知”和“高优先级被击中反馈”感知环境用 0.3 秒间隔但受到伤害后立刻触发一次高优先级感知用事件驱动而不是纯粹靠轮询。第三个坑远程敌人和近战敌人不能共用一套优化参数。近战敌人不需要长视野但需要在近身时立刻转身远程敌人需要在远处发现玩家却不需要近距离精细动画。我的最终参数是分两层远程敌人拉大感知半径、压低动画刷新频率近战敌人保持动画高频率、缩短感知距离。这样两拨敌人在同一场战斗中都不会显得“傻”帧率也稳得住。最后再分享一个小技巧每次改完参数后不要只在编辑器 PIE 里测一定要打一个 Development 包到真机上测一遍。编辑器和打包后的性能表现有时差异巨大尤其在动画预算和 GC 策略上。我见过项目在编辑器里跑得飞起打包后在低配机器上卡顿依旧原因就是编辑器模式下 CPU 调度策略和真机不一样。数据以打包后的 Profile 为准宁可花十分钟多测一轮也不要对着白天在编辑器里看到的帧率盲目乐观。