1. 多敌人场景下 UE FPS 性能优化的整体思路拆解1.1 为什么多敌人场景是性能的“照妖镜”单敌人或者空场景跑 120 帧一进多敌人混战就掉到 40 帧这种事我在项目里见得太多了。多敌人场景之所以难搞是因为它同时压榨了 CPU 的 Game Thread、Render Thread、RHI Thread还有 GPU 的 Base Pass、Shadow、透明粒子任何一个环节先扛不住帧率就崩。更麻烦的是这种崩溃往往不是线性的——10 个敌人还好20 个敌人突然掉一半因为某个环节触发了阈值比如 Draw Call 合并失效、动画更新从多线程回退到单线程、粒子系统开始爆内存。所以做多敌人场景优化第一步不是打开 Profiler 看哪个函数耗时高而是先建立一张“压力传导图”敌人数量增加会带来哪些维度的负载增长我通常把它拆成四层逻辑层Actor Tick、AI 行为树、感知系统、移动组件。动画层骨骼更新、动画蓝图求值、IK、Retarget。渲染层Draw Call、材质复杂度、阴影、粒子。内存与带宽层Actor 数量带来的 UObject 遍历、GC 压力、网络同步量。这四层里逻辑层和动画层主要吃 CPU渲染层吃 GPU 和 Render Thread内存层则是隐性的平时不显一到 GC 就卡顿。优化的核心思路就是把每一层的负载从“随敌人数量线性增长”变成“亚线性甚至常数”。听起来像废话但具体怎么做下面我按实操顺序拆开讲。1.2 先定预算再谈优化我见过太多人一上来就改代码改完发现帧率没变因为瓶颈根本不在他改的地方。所以我的习惯是先给每个线程定预算。以 60 帧为目标一帧 16.6ms通常这样分配线程预算ms说明Game Thread6-7逻辑、动画求值、物理Render Thread4-5可见性剔除、Draw Call 提交RHI Thread2-3命令转换GPU12-14实际渲染和 CPU 并行多敌人场景下Game Thread 和 Render Thread 是最容易超的。你可以用stat unit看整体用stat game、stat renderthread、stat gpu分别看各线程。如果 Game Thread 高就往 Actor Tick 和动画方向查如果 Render Thread 高就往 Draw Call 和材质方向查。这个判断顺序很重要方向错了后面全白做。1.3 优化优先级先砍数量再降单次成本我的经验是优化收益从大到小排序是这样的减少参与计算的 Actor 数量剔除、分帧、距离分级。降低单个 Actor 的更新频率Tick 间隔、动画更新率。降低单个 Actor 的单次计算成本LOD、简化动画蓝图。并行化多线程动画、异步物理。很多人喜欢直接从第 3 步开始调材质、降骨骼结果发现 20 个敌人里只有 5 个在屏幕内另外 15 个根本看不见还在跑完整逻辑。所以先把“看不见的”和“不重要的”处理掉收益立竿见影。2. 逻辑层优化让 Actor 少干活、巧干活2.1 Tick 管理不是所有敌人都需要每帧思考UE 默认每个 Actor 只要PrimaryActorTick.bCanEverTick true就会每帧 Tick。20 个敌人就是 20 次 Tick每个 Tick 里可能还有 AI 感知、移动、动画状态机更新。我通常做三件事第一按距离分级 Tick。屏幕内且距离近的敌人每帧 Tick屏幕内但距离远的每 2 帧 Tick 一次屏幕外的每 5-10 帧 Tick 一次甚至完全停掉逻辑 Tick只保留必要的移动插值。实现上可以用SetActorTickInterval也可以自己写一个管理器统一调度。第二用 Tick 分组。UE 有TickGroup的概念但更实用的是把敌人分成几组每帧只更新一组。比如 20 个敌人分 4 组每组 5 个轮流更新这样每帧只有 5 个敌人在跑完整逻辑。对于 FPS 来说敌人 AI 的反应延迟差几帧玩家基本感知不到但 CPU 负载直接降到四分之一。第三能不用 Tick 就不用。比如敌人的血量显示、UI 更新完全可以用事件驱动血量变了才更新而不是每帧去查。AI 感知也可以用定时器代替 Tick比如每 0.2 秒检测一次视野而不是每帧都做射线检测。注意停掉 Tick 后敌人的移动、动画可能会卡顿。我的做法是保留一个轻量的“表现层更新”比如用SetActorLocation的插值在 Tick 外做或者用 Timeline 驱动。逻辑停了表现不能停否则玩家一眼就看出来。2.2 AI 与感知系统的降载多敌人场景里AI 感知Perception是隐藏的 CPU 杀手。每个敌人如果都开视野检测、听觉检测20 个敌人就是 20 套射线和球体检测。优化手段共享感知同一阵营的敌人可以共享一个感知结果比如一个小队只让队长做完整感知其他成员复用。降低检测频率视野检测从每帧改成每 0.1-0.2 秒一次用定时器驱动。简化检测形状用球体检测代替复杂的多射线检测或者用角度加距离的数学判断代替物理射线。分帧检测20 个敌人的感知分散到 20 帧里每帧只让一个敌人做完整感知。行为树本身也有开销。如果敌人多可以考虑把行为树换成更轻量的状态机或者用UStateTree这种更高效的结构。行为树的Tick也可以降频比如每 0.1 秒 Tick 一次而不是每帧。2.3 移动组件的优化UCharacterMovementComponent功能全但开销也大。多敌人场景下如果敌人不需要复杂的移动比如不需要攀爬、游泳可以用更简单的移动组件或者直接关掉一些功能关掉bOrientRotationToMovement如果不需要。降低MaxSimulationTimeStep和MaxSimulationIteration。如果敌人是远程攻击为主移动简单甚至可以用UPawnMovementComponent自己写轻量移动。物理模拟能关就关布娃娃系统只在死亡时开启。我实测过20 个 Character 的移动组件如果全功能开启Game Thread 能占到 3-4ms简化后能降到 1ms 左右。这个收益在紧张预算里很关键。3. 动画层优化多敌人场景的重灾区3.1 动画更新率的取舍动画系统在多敌人场景里往往是 Game Thread 的最大头。每个敌人的骨骼更新、动画蓝图求值、IK 计算都是实打实的 CPU 开销。最直接的优化就是降低动画更新率。UE 里可以用UAnimInstance的SetUpdateAnimationInEditor或者自定义更新频率。常见做法屏幕内近处敌人每帧更新。屏幕内远处敌人每 2 帧更新一次。屏幕外敌人每 4-8 帧更新一次或者完全暂停动画更新只保留一个静态姿势。实现上可以在AnimInstance的NativeUpdateAnimation里根据距离判断是否跳过更新。注意跳过更新时动画不会推进所以要用Montage或者手动设置Position来保持表现。对于 FPS 来说远处敌人的动画稍微卡顿玩家基本注意不到。3.2 动画蓝图的精简动画蓝图里的逻辑越复杂求值越慢。多敌人场景下我通常做这些精简去掉不必要的 IK如果敌人不需要脚部 IK、手部 IK直接关掉。IK 的求值成本很高尤其是 Full Body IK。简化状态机状态机里的过渡条件越复杂求值越慢。能用简单布尔判断的不要用复杂的数学计算。用 Anim Node 的 LODUE 的动画节点支持 LOD可以设置距离阈值远处敌人自动跳过某些节点。避免每帧更新不必要的数据比如BlueprintUpdateAnimation里不要做复杂的射线检测、不要查表。实操心得我习惯在动画蓝图里加一个UpdateRate变量根据敌人距离动态设置。近处 0每帧中距离 1隔帧远处 2隔 3 帧。然后在NativeUpdateAnimation里用计数器控制实际更新。这个改动很小但收益很大。3.3 骨骼 LOD 与 Retarget 的坑UE 的骨骼 LOD 可以在远处降低骨骼更新频率甚至完全跳过。设置方法是在 Skeletal Mesh 的 LOD 设置里给每个 LOD 指定Bone Reduction和Update Rate。多敌人场景下我通常给远处敌人设置 LOD 2 或 3骨骼更新率降到 15-30Hz。Retarget 是另一个坑。如果敌人用了不同的骨骼Retarget 的开销会叠加。能统一骨骼就统一不能统一的话尽量在导入时就烘焙好不要在运行时做 Retarget。4. 渲染层优化Draw Call、材质与阴影4.1 Draw Call 合并与实例化多敌人场景下每个敌人可能有多个 Mesh身体、武器、配件20 个敌人就是 60-100 个 Draw Call。Render Thread 的压力主要来自这里。优化手段合并 Mesh把敌人的身体、武器、配件合并成一个 Skeletal Mesh减少组件数量。使用 Instanced Static Mesh如果敌人有大量相同的静态部件比如头盔、背包用 ISM 渲染。材质合并尽量让敌人共用少数几个材质减少材质切换。可以用 Material Instance 动态改参数而不是用不同材质。剔除确保屏幕外敌人被正确剔除。UE 的Cull Distance Volume和Per Actor Cull Distance都很好用。我实测过20 个敌人如果每个有 3 个 Mesh 组件Draw Call 大概 60合并成 1 个 Mesh 后降到 20 左右Render Thread 直接省 2-3ms。4.2 材质复杂度的控制材质越复杂GPU 和 Render Thread 的开销越大。多敌人场景下敌人材质要尽量简单用Unlit或者简单的Default Lit避免复杂的多层混合。减少纹理采样次数能用一张图解决的不要用三张。关掉不必要的材质特性比如Subsurface Scattering、Clear Coat。用Material Quality Level在低配下自动降级。如果敌人有特殊效果比如受伤闪红、隐身尽量用参数控制而不是用不同的材质实例。材质实例的切换也会带来开销。4.3 阴影与粒子的取舍阴影是 GPU 的大头。多敌人场景下每个敌人如果都投射动态阴影GPU 压力会很大。优化手段降低阴影分辨率远处敌人的阴影用低分辨率或者直接关掉。用 Capsule Shadow 代替如果敌人不需要精确阴影用胶囊体阴影代替骨骼阴影成本低很多。限制阴影距离只让近处敌人投射阴影远处敌人不投射。粒子降级敌人的特效粒子枪口火焰、血迹在远处用低 LOD或者直接不生成。注意关阴影和粒子要谨慎不能影响 gameplay。比如敌人隐身时阴影可能是玩家判断位置的重要线索这种就不能关。优化永远要服务于玩法。5. 多线程与异步把能并行的都并行5.1 动画多线程更新UE 的动画系统支持多线程更新bUseMultiThreadedAnimationUpdate。开启后动画求值会放到 Worker Thread 上减轻 Game Thread 压力。但要注意动画蓝图里的逻辑必须是线程安全的不能访问非线程安全的 UObject。有些节点不支持多线程比如某些 IK 节点需要检查。多线程动画的调试更麻烦出问题不好查。我通常会在项目设置里开启多线程动画然后逐个检查动画蓝图把不安全的节点替换掉。收益在敌人多的时候很明显Game Thread 能省 1-2ms。5.2 异步物理与移动物理模拟也可以异步。UE 的Async Physics可以把物理计算放到独立线程。但多敌人场景下如果敌人用的是 Character Movement 而不是物理模拟收益不大。如果敌人有布娃娃、物理约束可以考虑开启。移动组件的更新也可以分帧。比如 20 个敌人的移动更新分散到 4 帧里每帧只更新 5 个。这个需要自己写管理器但收益很直接。5.3 Render Thread 的并行Render Thread 本身已经是独立的但可以通过r.RHICmdBypass等命令调整 RHI 线程的行为。不过这些命令因平台而异移动端和 PC 端差别很大。我的建议是PC 端可以尝试开启 RHI 线程并行移动端则要谨慎因为移动端的 CPU 核心少线程多了反而抢资源。6. 常见问题与排查技巧实录6.1 帧率突然掉一半怎么查多敌人场景最常见的问题就是“突然掉帧”。我的排查顺序stat unit看是 Game 还是 Draw 还是 GPU 高。如果是 Game 高stat game看具体是哪个函数。如果是 Draw 高stat renderthread看是哪个阶段。如果是 GPU 高ProfileGPU看是哪个 Pass。用stat anim看动画开销stat particles看粒子开销。常见原因某个敌人的动画蓝图触发了复杂逻辑、粒子系统爆了、GC 触发、Draw Call 突然增加。我遇到过一次20 个敌人里有一个触发了特殊状态动画蓝图里做了一次全场景射线检测直接卡了 10ms。这种问题只能靠 Profiler 抓。6.2 优化后没效果可能是什么原因瓶颈不在你优化的地方比如你优化了 Game Thread但瓶颈在 GPU。优化被其他开销抵消比如你降了动画更新率但增加了距离检测的开销。测试场景不对在空场景测的没覆盖多敌人混战。平台差异PC 上有效移动端无效因为移动端瓶颈不同。我的建议是每次优化只改一个变量改完立刻测用数据说话。不要一次改一堆否则不知道哪个有效。6.3 常见问题速查表问题可能原因排查方法解决方向Game Thread 高Actor Tick 多、动画复杂stat game、stat anim降 Tick 频率、简化动画Render Thread 高Draw Call 多、材质复杂stat renderthread合并 Mesh、简化材质GPU 高阴影、粒子、分辨率ProfileGPU降阴影、减粒子帧率波动大GC、粒子爆发stat gc、stat particles优化 GC、粒子池移动端卡顿线程争抢、带宽平台 Profiler降线程数、降纹理6.4 独家避坑技巧不要过早优化先让功能跑起来再优化。我见过有人在原型阶段就抠性能结果玩法改了优化全白做。用数据说话每次优化前后都要有 Profiler 数据不要凭感觉。注意平台差异PC 和移动端的瓶颈完全不同优化方案要分开做。保留回退方案优化可能引入 Bug要能快速回退。测试要覆盖极端情况20 个敌人不够试试 50 个、100 个看什么时候崩。7. 一个完整的优化案例从 40 帧到 60 帧7.1 初始状态与瓶颈定位我之前做过一个 FPS 项目20 个敌人混战时帧率掉到 40。用stat unit看Game Thread 12msRender Thread 8msGPU 10ms。Game Thread 是主要瓶颈。进一步用stat game看动画占了 5msAI 占了 3ms移动占了 2ms。Render Thread 的 8ms 里Draw Call 占了 5ms。7.2 具体优化步骤第一步动画降频。近处敌人每帧更新中距离隔帧远处每 4 帧。动画开销从 5ms 降到 2.5ms。第二步AI 感知降频。从每帧检测改成每 0.2 秒检测AI 开销从 3ms 降到 1ms。第三步移动组件简化。关掉不需要的功能移动开销从 2ms 降到 1ms。第四步Mesh 合并。每个敌人从 3 个 Mesh 合并成 1 个Draw Call 从 60 降到 20Render Thread 从 8ms 降到 5ms。第五步阴影降级。远处敌人不投射阴影GPU 从 10ms 降到 8ms。最终Game Thread 降到 5msRender Thread 降到 5msGPU 降到 8ms帧率稳定在 60。7.3 优化后的效果与反思这个案例里最大的收益来自动画降频和 Mesh 合并。动画降频几乎没有视觉损失因为远处敌人的动画玩家根本看不清。Mesh 合并需要美术配合但一次性的工作长期收益很大。反思的话我觉得一开始就应该把动画更新率和距离挂钩而不是等出了问题再改。另外AI 感知的降频也要注意不能降得太狠否则敌人反应太慢影响玩法。8. 工具与调试让优化有据可依8.1 常用 Profiler 命令stat unit整体帧时间。stat gameGame Thread 细分。stat renderthreadRender Thread 细分。stat gpuGPU 各 Pass 耗时。stat anim动画开销。stat particles粒子开销。stat gcGC 开销。ProfileGPUGPU 详细抓取。UnrealInsights最强大的工具可以看时间线、线程、CPU 核心占用。8.2 自定义性能埋点UE 的SCOPE_CYCLE_COUNTER可以自定义埋点把关键逻辑的耗时统计出来。比如给 AI 感知、动画更新、移动更新都加上埋点然后在stat里看。这个在排查具体问题时非常有用。8.3 移动端注意事项移动端和 PC 端差别很大CPU 核心少线程多了反而慢。带宽有限纹理和 Mesh 要更省。GPU 是 Tile-Based过度绘制影响大。发热降频长时间跑要留余量。移动端优化要更激进动画更新率可以降到 15Hz阴影可以全关粒子要严格控制。9. 我个人在实际操作中的体会多敌人场景优化说到底就是一场“预算争夺战”。每个系统都想多占一点 CPU 和 GPU你要做的就是根据玩家实际能感知到的信息把预算分配给最重要的地方。远处敌人的动画、阴影、粒子玩家根本注意不到那就大胆砍。近处敌人的逻辑、动画、特效玩家盯着看那就保证质量。我踩过最大的坑是“一刀切”。比如把所有敌人的动画更新率都降到 15Hz结果近处敌人看起来像幻灯片。后来改成按距离分级近处 60Hz中距离 30Hz远处 15Hz效果好很多。所以优化一定要分级不能一刀切。另外优化不是一次性的工作。项目不同阶段瓶颈会变。原型阶段可能是 Game Thread上线前可能是 GPU。要定期跑 Profiler持续优化。最后再分享一个小技巧在游戏里加一个调试开关可以实时显示每个敌人的 Tick 频率、动画更新率、Draw Call 数量这样测试的时候一眼就能看出哪个敌人有问题。这个开关在开发期非常有用上线前记得关掉就行。
