最近一直在啃多敌人场景的 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 对应 60FPS33.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 OptimizationURO。启用 URO 后骨骼网格可以根据与相机的距离动态调整动画更新频率比如近处敌人每帧更新骨骼中距离每 2 帧更新一次远处每 4 帧更新一次。准确说它是“减少动画更新的频率”但可以手动开启并设置远近阈值。C 里对应UAnimInstance::UpdateRateOptimization蓝图里也有对应的优化设置不复杂但很多人没注意到。第三招是关掉没有必要的 IK 和物理模拟。比如双脚 IK放在 FPS 里只对玩家有意义敌人 NPC 全开着 IK 每帧解算纯粹是浪费。物理资产布娃娃在敌人活着的时候通常只参与射线检测不需要每帧做模拟没必要的物理约束全部断开。还有动画蓝图的图表本身也值得检查把每帧都在执行的节点尽量简化能用缓存就不要每帧重新读变量。调试动画性能可以用控制台命令a.AnimBP.Profiling或直接在动画蓝图里打开 Debug 面板看各节点耗时哪条连线跑了最多毫秒一目了然。2.4 用 UE Interface 代替大而全的 Actor 类型判断多敌人场景往往有不同类型的敌人近战、远程、精英、召唤物。很多人写逻辑的时候习惯用CastAEnemyType一层层判断Cast 本身在热路径上有开销而且类型维护起来非常痛苦敌人种类一多蓝图连线就乱成一团。UE Interface接口是更干净的做法。给敌人定义一套行为能力接口比如可受到伤害、可以被标记、可以被处决然后每个敌人蓝图里实现这套接口。调用方只需要GetInterfaceIDamageable有接口就处理没有就忽略。这样既避免大量的 Cast 消耗又让系统解耦新增敌人只需要实现接口不用去改每个被调用方。这个思路在 UE 官方示例项目 Lyra 里体现得很明显它用大量接口和组件把玩家、AI、武器切成很独立的模块。多敌人场景也完全可以抄这套设计我后来在项目里把“可被子弹击中”、“可被感知系统识别”、“可被音效系统监听”都做成了接口逻辑调用链路变短性能反而更好查了。3. 渲染侧优化把 DrawCall 和三角形压力打下来3.1 实例化渲染HISM 是群体渲染的本命谈到渲染侧的优化首先要面对的就是 DrawCall。多敌人场景里敌人本身的网格体如果都是一个个独立提交DrawCall 很容易超过 CPU 渲染线程的承受上限。不过有个尴尬的地方——带骨骼动画的敌人没法简单用 Instanced Static Mesh 来实例化。所以要把“敌人”和“场景里大量重复物”分开看。像草地、碎石、弹壳、掉落的武器、场景装饰这类不会动或者只会播放简单动画的物体全部用 Hierarchical Instanced Static MeshHISM或 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-10msDrawCall4000 左右平均 FPS351% low22经过对象池、Tick 间隔调整、感知系统周期更新、动画 URO 优化、阴影距离限制、部分物体 HISM 化、Niagara GPU 粒子替换之后游戏线程4-6ms渲染线程4-5msDrawCall1300 左右平均 FPS701% low55这个对比也印证了一个观点多敌人场景的优化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看一次数据通常会非常清楚地看到某一步把一个尖峰修掉了。多敌人场景的优化不是什么玄学说到底就是把不该花的每帧开销找出来并停掉把该花的花在玩家真正看得到、感觉得到的地方。 
长河君 · 2026/10/2 22:40:47 · 阅读 1.2k 多敌人场景UE FPS性能优化：从瓶颈定位到实战调优
最近一直在啃多敌人场景的 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 对应 60FPS33.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 OptimizationURO。启用 URO 后骨骼网格可以根据与相机的距离动态调整动画更新频率比如近处敌人每帧更新骨骼中距离每 2 帧更新一次远处每 4 帧更新一次。准确说它是“减少动画更新的频率”但可以手动开启并设置远近阈值。C 里对应UAnimInstance::UpdateRateOptimization蓝图里也有对应的优化设置不复杂但很多人没注意到。第三招是关掉没有必要的 IK 和物理模拟。比如双脚 IK放在 FPS 里只对玩家有意义敌人 NPC 全开着 IK 每帧解算纯粹是浪费。物理资产布娃娃在敌人活着的时候通常只参与射线检测不需要每帧做模拟没必要的物理约束全部断开。还有动画蓝图的图表本身也值得检查把每帧都在执行的节点尽量简化能用缓存就不要每帧重新读变量。调试动画性能可以用控制台命令a.AnimBP.Profiling或直接在动画蓝图里打开 Debug 面板看各节点耗时哪条连线跑了最多毫秒一目了然。2.4 用 UE Interface 代替大而全的 Actor 类型判断多敌人场景往往有不同类型的敌人近战、远程、精英、召唤物。很多人写逻辑的时候习惯用CastAEnemyType一层层判断Cast 本身在热路径上有开销而且类型维护起来非常痛苦敌人种类一多蓝图连线就乱成一团。UE Interface接口是更干净的做法。给敌人定义一套行为能力接口比如可受到伤害、可以被标记、可以被处决然后每个敌人蓝图里实现这套接口。调用方只需要GetInterfaceIDamageable有接口就处理没有就忽略。这样既避免大量的 Cast 消耗又让系统解耦新增敌人只需要实现接口不用去改每个被调用方。这个思路在 UE 官方示例项目 Lyra 里体现得很明显它用大量接口和组件把玩家、AI、武器切成很独立的模块。多敌人场景也完全可以抄这套设计我后来在项目里把“可被子弹击中”、“可被感知系统识别”、“可被音效系统监听”都做成了接口逻辑调用链路变短性能反而更好查了。3. 渲染侧优化把 DrawCall 和三角形压力打下来3.1 实例化渲染HISM 是群体渲染的本命谈到渲染侧的优化首先要面对的就是 DrawCall。多敌人场景里敌人本身的网格体如果都是一个个独立提交DrawCall 很容易超过 CPU 渲染线程的承受上限。不过有个尴尬的地方——带骨骼动画的敌人没法简单用 Instanced Static Mesh 来实例化。所以要把“敌人”和“场景里大量重复物”分开看。像草地、碎石、弹壳、掉落的武器、场景装饰这类不会动或者只会播放简单动画的物体全部用 Hierarchical Instanced Static MeshHISM或 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-10msDrawCall4000 左右平均 FPS351% low22经过对象池、Tick 间隔调整、感知系统周期更新、动画 URO 优化、阴影距离限制、部分物体 HISM 化、Niagara GPU 粒子替换之后游戏线程4-6ms渲染线程4-5msDrawCall1300 左右平均 FPS701% low55这个对比也印证了一个观点多敌人场景的优化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看一次数据通常会非常清楚地看到某一步把一个尖峰修掉了。多敌人场景的优化不是什么玄学说到底就是把不该花的每帧开销找出来并停掉把该花的花在玩家真正看得到、感觉得到的地方。