UE多敌人AI性能优化：从GameThread瓶颈到行为树调度实战

前阵子做一个 UE FPS 玩法验证，我在场景里放了 40 个敌人 AI，一进场帧率直接从 120 掉到 35。当时第一反应是显卡吃不消，结果打开性能面板一看，GPU 占用还不到一半，卡死的是 CPU 的 GameThread。后来我花了两天把多敌人 AI 场景里的 CPU 开销捋了一遍，帧率拉回 70 以上。这篇就是把那两天的思路、工具、参数和经验整理出来，核心围绕多敌人 AI 场景下 UE FPS 的性能优化，给那些也被 AI 数量拖垮帧率的项目一个可落地的参考。

1. 多敌人 AI 一多就掉帧：先别怪显卡，瓶颈在 GameThread

1.1 40 个敌人同时上线，CPU 端到底在忙什么

先给一个直观算账。一个普通敌人 AI 的默认逻辑链路大概是：AAIController 的 Tick 驱动行为树刷新，行为树再去黑板读变量、跑装饰器和任务节点；与此同时 AIPerceptionSystem 在循环处理视野和听觉感知；如果需要移动，寻路组件会向导航系统发查询；碰到玩家或者其他单位，还会产生碰撞和 Overlap 事件。这一整套链路，单个敌人看不出什么问题，可一旦数量叠到 30、40，全部挤在同一帧执行，GameThread 就会迅速被打满。

我项目里的敌人还分层巡逻、锁定、掩护、开火几个状态，行为树分支特别多，每个分支下的装饰器检查都跟着 Tick 走。Bullet 这种东西本身也在高频移动，和一堆胶囊体做碰撞检测又是额外开销。所以那个 120 掉 35 的瞬间，显卡根本没到极限，瓶颈全在 GameThread。

1.2 用 stat unit 和 UnrealInsights 锁定瓶颈链路

遇到帧率问题，我第一件事永远是打开控制台跑stat unit。它会显示 Frame、Game、Draw/GPU 三行时间。那次实验 Frame 是 35ms，Game 行占了 30ms，Draw 行只剩 5ms，一眼就能断定是 CPU 侧的 GameThread 饿了，根本轮不到 GPU 背锅。

定性之后要定量。我是先执行stat startfile，让引擎跑一段 tracing，然后stat stopfile生成 trace 文件，再用引擎自带的 UnrealInsights 打开分析。在时间线的过滤框里直接搜BehaviorTree、PerceptionSystem、AIController这类关键字，很快就能看到各函数的具体耗时。那一版查出来的头号大户是UBehaviorTreeComponent::TickComponent，其次是一大堆感知更新和RequestMove造成的寻路等待。这个排查顺序很重要：先判断是 CPU 还是 GPU，再细分是 AI、导航、物理还是蓝图逻辑，最后才决定怎么砍，每一步都有数据支撑，而不是凭感觉乱优化。

1.3 一个反直觉的判断：AI 不需要每帧思考

很多团队在做 AI 的时候，下意识觉得“行为树跑得越快，敌人越聪明”。但从性能角度看，这完全是误区。真人玩家从看到目标到做出反应，怎么也要一两百毫秒。敌人 AI 每帧刷新一次决策，给人的观感并不会聪明多少，反而会显得神经质：敌人一边高速奔跑一边瞬间切换状态，看起来反而失真。

所以我的经验值是：活跃敌人超过 15~20 个，行为树和感知的更新频率必须从“每帧”降级为“定时”或者“分帧”。在 UE 里并不存在一个“调高就聪明、调低就笨”的绝对换算，只要状态切换延迟控制在 150ms 左右，玩家的体感基本不受影响，GameThread 却能省出一大块时间。

2. 从“每帧都在想”到“该想才想”：AI 思考频率的调度优化

2.1 把行为树的决策心跳从 Tick 改成 Timer

UE 的 AIController 默认走 Tick 驱动，想让行为树不跟 Tick 走，最简单的方式是绕开默认逻辑，用FTimerManager自己驱动更新。我当时的做法是在敌人控制器里加一个定时器，按固定间隔触发一次“思考”，再配合相位偏移把不同敌人的思考时间错开，避免同帧扎堆。

// AEnemyController.h UCLASS() class AEnemyController : public AAController { GENERATED_BODY() public: void StartDistributedThinking(float InInterval, float InPhaseOffset); void OnThinkTimer(); float ThinkInterval = 0.1f; FTimerHandle ThinkTimerHandle; }; // AEnemyController.cpp void AEnemyController::StartDistributedThinking(float InInterval, float InPhaseOffset) { ThinkInterval = InInterval; float FirstDelay = InInterval * InPhaseOffset; GetWorld()->GetTimerManager().SetTimer( ThinkTimerHandle, this, &AEnemyController::OnThinkTimer, ThinkInterval, true, FirstDelay ); }

这个FirstDelay是核心。每个敌人从场景管理器的敌人数组里拿到自己的Index和总数TotalCount，算出Phase = (Index % TotalCount) / (float)TotalCount，再乘上ThinkInterval，就能得到一个 0~1 秒之间的初始延迟。40 个敌人如果都延迟 1 秒，Spread 开以后，每一帧最多只有四五个敌人在同一帧里做决策，比原来的“40 个一起开动”舒服太多。

2.2 AIPerception 是全局单例，感知参数要按重要性分级

很多人不知道，UE 的感知系统UAIPerceptionSystem是全局单例，所有 AI 的感知更新都挂在同一个系统上。这个系统里任何一次“全体感知扫描”的代价都是所有 AI 叠加的。我在项目里把所有敌人的视觉感知默认范围从 6000 收窄到 4000，把感知系统的 Sense 更新间隔从默认拉到 0.2~0.3 秒，听觉感知只对近距离敌人保持开启，远距离敌人直接关掉听觉通道。这样改完，感知这块的 GameThread 耗时下降了肉眼可见的程度。

具体操作上，可以在项目的AIPerceptionSystem子类里重写相关 Tick 逻辑，也可以在敌人的感知组件上单独设置SetSenseEnabled。要点是别让视觉、听觉、伤害感知全部以相同频率运行，视觉是 FPS 里最常用的，其他感知按玩法需求降级。

2.3 按距离分级：距离玩家越远，AI 越“懒”

除了在时间上错峰，还可以在逻辑上分级。以玩家位置为圆心画几层半径：半径 1200 以内是“全火力模式”，行为树和感知保持 0.1 秒级更新；1200 到 3000 是“警惕模式”，更新频率降到 0.25 秒，感知半径缩减；3000 以外直接进入“纸片人模式”，行为树干脆不跑，只播放动画、做最低限度的转向和移动同步。

这个分级和 GPU 的 LOD 思路一模一样。离玩家近的敌人必须灵活、反应快，因为玩家能直接观察它；离得远的敌人，玩家根本没有精力去细看它的决策质量，强行跑高频 AI 只是白白烧 CPU。我当时这个分级帮 GameThread 省出了三成时间，和频率错峰叠加起来，效果非常夸张。

3. 被忽视的隐形成本：寻路队列、碰撞通道和调试残留

3.1 寻路请求要限流：别让 40 个敌人同时找路

打个比方：40 个敌人发现玩家之后，如果同一帧全部触发寻路请求，就好比 40 个人同时挤进一个收费站，后面的车全得排队。UE 的寻路本身是异步的，但大量同帧请求会拉高寻路线程的排队长度，反过来让 GameThread 在等待关键路径数据时被拖住。

我的做法是给寻路加一个冷却：每个 AI 发起一次RequestMove之后，短时间内不允许再发新请求，通常 0.5 秒起步；如果敌人有“追击玩家”这种持续需求，就在路径失效或者目标偏离一定距离时才重新寻路，而不是每帧都问导航系统。另外，几个敌人在同一方向上的目标点很接近时，可以让它们共用一条路径结果，只对终点做少量偏移，视觉上不会穿帮，寻路开销却直观下降。

3.2 NavMesh 动态障碍物的坑：少 Rebuild，多靠碰撞查询

做第一人称射击，场景里常常有爆破物、可破坏掩体这些动态障碍。动态障碍一多，有些团队会选择频繁更新 NavMesh，这是一个大坑。NavMesh 重建本身在 CPU 端的开销很大，尤其大场景局部重建的频率高了以后，帧率会出现周期性的断崖。

我的替代方案是把“导航不变的部分”和“动态避障的部分”拆开：静态场景吃 NavMesh，动态障碍物不参与寻路，而是让敌人的移动组件在靠近障碍时用碰撞查询做局部避让。这样 NavMesh 几乎不重建，动态避障成本也远低于反复烘焙导航数据。UE 自带的环境查询系统（EQS）也可以辅助做局部点选择，但要注意 EQS 的查询频率同样需要控制，不能变成新的性能黑洞。

3.3 碰撞通道收敛：从“全响应”改成“按需响应”

碰撞和 Overlap 是 FPS 里悄悄吃性能的另一个隐形大头。玩家朝 40 个敌人开枪时，子弹 Trace 要在每个胶囊体上做检测，如果每个敌人的碰撞通道是默认的 BlockAll，那每次 Trace 的成本都会被放大。我在项目里单独建了一个EnemyBody碰撞通道，只让它对子弹通道和玩家可见通道产生 Overlap 响应，对其他通道要么 Ignore，要么 Block 但不产生事件。

碰撞通道的设置不是越多越精细就越好。FPS 里真正需要高频响应的是“子弹 vs 敌人”“敌人 vs 玩家可见检测”这几种，其他大量无关的碰撞对，都该尽早用通道过滤掉。这一步做完以后，玩家朝天开枪、往地面打、场景物件飞来飞去这类高频交互，都不会再引发无意义的 Overlap 事件。

3.4 DrawDebug 和调试残留：发行包里的隐形吃帧

这个坑我踩得特别深。为了观察 AI 感知范围和行为树状态，我开了感知可视化、胶囊体轮廓绘制，还有一堆DrawDebugSphere。新版本引擎调试完，除了控制台指令关闭，还要检查项目里是不是有常驻的 Debug 绘制逻辑。我那次就是漏掉了一个感知调试绘制功能，打包发给测试时帧率掉了近两成，排查到最后才发现是绘制代码留在代码里，一直在空转。

所以我现在都会在项目的构建配置里做一道强制封锁：打包时#if UE_BUILD_SHIPPING包一层，把感知可视化、行为树 Debugger 的运行时绑定全部剔除。这种调试残留属于性价比最低的浪费，因为它不提供任何玩法价值，纯粹吃 CPU，而且特别隐蔽。

4. 查询方式的“反模式”与批量处理：别让蓝图遍历成为新瓶颈

4.1 不要在 Tick 里 GetALLActorsOfClass

这是很多蓝图项目的常见病。为了获得玩家位置，或者为了统计当前敌人数量，直接在某个 Actor 的 Tick 里调GetAllActorsOfClass。这个函数会在每次调用时生成一个临时数组，把所有同类型 Actor 遍历一遍。当场景里有 100 个敌人，而这个函数被多个 Actor 每帧调用时，复杂度就是 100 乘以调用次数，瞬间变成 CPU 杀手。

我自己的处理方式是用一个场景管理器（比如一个AEnemyDirectorActor），在敌人生成和消失的时候维护一份缓存数组。任何需要敌人列表的逻辑，都向管理器要缓存，而不是现场遍历。玩家位置这种高频访问的数据也一样，由管理器每帧更新一次，所有敌人共享同一个引用，不要再各自 Get。

4.2 世界空间查询的正确姿势：初筛后精筛

有的场景确实需要在运行时找“附近敌人”或“范围内目标”，免不了要做世界空间查询。UE 的OverlapMultiByChannel本身有空间加速，不像遍历数组那么粗暴，但它也有一个前提：碰撞通道要提前筛对。如果用一个会同时碰到地板、箱子、墙壁的通道做查询，那返回结果里大部分是垃圾数据，后续还得做二次过滤，反而比纯循环更亏。

正确的做法是“初筛 + 精筛”两步走：先用一个很大的球体范围做粗筛，拿到潜在目标后，再按角度、朝向、遮挡关系做精筛。很多 FPS 的视觉判定根本不需要每一帧都跑这套流程，把查询频率降到 0.1 秒一次，再叠加前面说的感知系统分级，效果足以满足玩法需求。

4.3 热点循环别留在蓝图里，下沉 C++ 封装一次

我在这儿说一句得罪人的话：纯蓝图里写复杂的循环和分支，遇到几十上百个 AI 的时候会特别吃亏。蓝图节点接线有额外开销，尤其是那种长循环里还要做大量数学运算和字符串比较的逻辑，运行时损耗比想象中高不少。

我并不是建议整个项目都推翻重写蓝图。更平衡的做法是把“高频且逻辑稳定”的部分下沉到 C++：比如“遍历敌人列表计算最近目标”“批量更新仇恨值”“统一处理伤害事件”这几种热点逻辑，用 C++ 封装成场景管理器的函数，然后蓝图只需要调用返回值。我自己是把敌人的“寻找目标”逻辑从蓝图搬到 C++ 之后，每一个 AI 单帧的决策时间都降了一个台阶。

float UEnemyLibrary::FindClosestEnemy(const FVector& Origin, const TArray<AActor*>& EnemyList, AActor*& OutTarget) { float BestDistanceSq = TNumericLimits<float>::Max(); OutTarget = nullptr; for (AActor* Enemy : EnemyList) { if (!Enemy) { continue; } float DistSq = FVector::DistSquared(Origin, Enemy->GetActorLocation()); if (DistSq < BestDistanceSq) { BestDistanceSq = DistSq; OutTarget = Enemy; } } return BestDistanceSq; }

这段代码没有任何花哨技巧，就是把“谁离我最近”这个循环从蓝图挪到了 C++。作用在于：同一个逻辑，C++ 的执行成本比蓝图低得多，而且更容易被引擎优化。

5. 落地参数表与实测效果：一套可以抄作业的配置

5.1 一组合适的起步参数

上面讲的方法最后要落到实处。下面是我那个 40 敌人 FPS 原型调整后的参数，可以当成一套起步配置。不同的项目手感不同，但沿着这套参数往上下浮动，基本能找到一个合理的平衡点。

5.2 实测效果与副作用：帧率回来了，但 AI 会“迟钝”

改完以后，同一场景、同一段 60 秒测试，帧率从 35fps 回到了 70fps 以上，GameThread 耗时占比从接近 30ms 降到 10ms 以内。数据上非常成功，但副作用也来了：感知频率降低以后，如果玩家操作特别快，比如瞬间从敌人视野里闪过去，敌人会有一瞬间的“没看见”感，体感上有点像 AI 反应迟钝。

这个问题的解法不是把感知频率调回去，而是给 AI 加一个“延迟追赶”机制：感知系统发现目标后，即使目标短暂脱离视野，AI 也会根据最近一次已知位置继续追 0.5 秒左右。玩家感觉是“敌人记住了我最后的位置”，实际上是从容的视觉欺骗。对 FPS 来说，这种短暂的目标记忆反而让敌人显得更聪明、更真实。

5.3 后续扩展与个人体会：这套思路能用到哪儿

多敌人 AI 性能优化的思路，和渲染层优化是相通的：工具栏先定位，再按“该想才想、该查才查、能不查就不查”的原则做减法，最后用视觉手法补足降频带来的体验损失。我现在遇到更大规模的敌人集群，比如 100 人以上的杂鱼，会引入群组模拟的思路，让一部分敌人走轻量状态机而不是全功能行为树；但战斗核心的精英敌人，仍然保留完整的行为树和感知能力。

折腾一圈下来，我的最大体感是：优化多敌人 AI 的关键不是把代码改得多炫，而是先承认“每个敌人的每一帧开销都是乘法”，然后用调度、降频、过滤这些基本功把乘法改成加法。能先把这一层做到位，再去碰 Mass 这类大数据框架，你会感觉顺很多。如果你项目里也有“AI 一多帧率就崩”的老毛病，我建议你从 stat unit 开始，一步一步照着这条链路往下查，多半会有意想不到的收获。