做FPS优化的人都有一个共同的噩梦打开测试地图拉出二十个敌人帧数直接从120掉到45鼠标一甩就是一阵阵的屏幕撕裂。多敌人场景之所以难搞不是某一个系统出了大问题而是动画、AI、渲染、物理全挤在同一个屋子里开会每个人都在抢CPU和GPU的时间片。这篇文章我想用一次实际项目中的优化经历完整拆一遍“多敌人FPS场景”的性能瓶颈怎么定位、怎么拆解、怎么一步步压回目标帧率。内容会覆盖从Unreal Insights的帧数据分析到渲染侧的DrawCall削减、逻辑侧AI更新频率的调整、动画LOD和物理碰撞的精简最后落到用性能预算表和1% low帧校验结果。整个过程是纯实战经验涉及具体命令和配置参数。最适合正在被多敌人场景卡到怀疑人生的UE开发者或者想把引擎优化从“玄学”变成“工程”的团队。1. 场景分析与瓶颈定位先别急着砍找出真正的凶手多敌人场景的性能问题最忌讳一上来就猜。有人看一眼掉帧就条件反射去关阴影有人马上调低屏幕百分比结果帧数没涨多少画面糊成一片。我一开始也这么干过后来才发现与其瞎猜不如用引擎自带的工具把一分钟时长的帧数据录下来让数据告诉你瓶颈在哪。1.1 多敌人场景到底压垮了什么先明确一下概念。UE里一帧的时间是被多个线程瓜分的主线程GameThread负责游戏逻辑、AI决策、动画更新、物理模拟的准备渲染线程RenderThread负责场景图遍历、剔除、DrawCall提交RHI线程负责和显卡驱动打交道把渲染命令真正送进去。你在帧数面板里看到的Frame、Game、Draw、GPU就是这几条线程各自的花费。多敌人场景下最典型的伤害是同步发生的每个敌人都有自己的动画蓝图和AnimInstance格斗或射击动作一多GameThread上动画更新会随着人数线性增长每个敌人都有自己的AI控制器感知、寻路、行为树在运转每个敌人都是一个Actor有碰撞盒和可见性检测到了渲染端每个常规网格体至少产生1~2个DrawCall20个敌人加上枪口火花、弹壳、血雾特效DrawCall轻松破千。问题就出在这里四条线程哪一条先到极限你的帧数瓶颈就在哪一条。我先用一个生活化类比帮自己理清思路。主线程像是一个餐厅的点单服务员所有客人的需求都经过他处理渲染线程像是后厨的备餐台把所有菜按顺序摆好GPU是炒锅真正开火出菜。如果服务员太慢客人等得久这就是GameThread瓶颈如果备餐台堆满菜传不过去这是RenderThread瓶颈如果炒锅火力不够这是GPU瓶颈。餐厅要提升翻台率光买更好的锅没用你得先看出排队到底卡在哪个环节。1.2 用工具说话Unreal Insights和Stat命令的正确用法定位瓶颈首选Unreal Insights它可以在引擎里启动录制也可以运行时按快捷键捕获。我用的是启动时加-tracing参数的方式只录60秒覆盖进战斗开火和刷出理想状态的二十个敌人然后把数据拖到Unreal Insights里分析。界面上最直观的是帧时间线四条颜色的横条分别代表GameThread、RenderThread、RHI线程和GPU Busy时间哪条压到顶部红线那就是首要瓶颈。除了录帧我还会用一套固定的Stat命令来快速看关键计数器命令如下stat unit stat game stat render stat rhi stat anim stat engine这套命令在编辑器模式就可以跑。stat unit能看到Frame、Game、Draw、GPU的总耗时stat anim能看到动画更新的具体耗时stat engine能看到Actor、Tick、Collision相关的开销。第一次测多敌人场景时我在控制台敲了stat unit屏幕显示GameThread在35秒时已经吃了22msRenderThread只有12msGPU只有8ms。事实证明瓶颈在主线程不在渲染那我后续的优化重点就往动画和AI逻辑上砸而不是去折腾材质和阴影。2. 渲染侧优化让GPU和DrawCall一起瘦身虽然我这次定位到主线程瓶颈但多敌人场景的渲染压力同样不容忽视——尤其是当你把敌人数量堆到50甚至80DrawCall数高得会让任何一个手机GPU直接罢工。这部分我把渲染侧的优化策略整理出来即使你的瓶颈在主线程先把DrawCall压低也能给后续的GPU峰值留出喘息空间。2.1 绘制调用过载先看剔除和实例化多敌人场景里最常见的绘制调用浪费是玩家后面站着一群敌人玩家看不到他们但引擎依然逐帧提交它们的骨骼网格体、武器、附属部件。UE的默认视锥剔除能干掉屏幕外的物体但藏在背后的物体视锥可能仍然正向就需要靠遮挡剔除或距离剔除兜底。我用的是分层策略近战范围内0~10米保持完整的骨骼网格、LOD0、完整材质和阴影。中距离10~25米切换到LOD1关闭动态阴影使用简化材质。远距离25米以上切换到LOD2或直接用Imposter模块生成一张公告板纹理绘制成本几乎为零。关键参数在骨骼网格体上设置MinimumLOD和LODDistanceScreenSize同时打开Use True Velocity让LOD切换更平滑。实测在中距离关闭阴影后DrawCall直接砍掉一半。如果敌人是同一批模型我强烈建议把远处的敌人换成实例化静态网格体Instanced Static Mesh或HISMHierarchical Instanced Static Mesh。HISM最大的优势是自动把几十个敌人的网格体合并成一个DrawCall配合剔除系统单独管理每一实例的可见性。当玩家视角转向敌群时HISM可以只渲染屏幕中心附近的实例甚至能把一个80敌人场景的DrawCall压到十几个。2.2 Shader与材质优化的成本账材质是GPU耗电大户多敌人场景中尤其容易踩坑的是overdraw。角色的皮肤、盔甲、枪械各自带了一套复杂的PBR材质贴上法线、粗糙度、AO、各向异性贴图每一次BasePass都把这些计算结果跑一遍。敌人一多GPU的像素填充率就会被彻底吞掉。我采用的做法是为敌人角色做材质质量级别分级编辑器模式下保留PBR细节打包后或战斗状态下切换成简化版本。做法是在材质里开启Quality Level节点针对低质量的级别关闭细节纹理甚至替换一个无光照版本。这种方案在移动端优化里非常常见UE项目也直接支持。还有一个经验是材质中少用全局函数和复杂表达式尽量将纹理采样限制在BaseColor、Roughness、Metallic三个关键通道。我拿引擎自带的Lyra演示项目做过测试它的角色材质已经是很标准的优化版本但依然能通过降低鲁棒性获得20%的GPU时间盈余。2.3 光照与阴影多敌人时最容易忽略的大坑动态阴影是帧率杀手。敌人多意味着每个敌人为了投射阴影都要进入shadow map渲染一遍自己的网格体这会让阴影Pass的DrawCall瞬间翻倍。测试时五个敌人还能稳60帧拉到二十个时GPU总线直接烧红问题多半就出在阴影上。控制阴影成本有几招限制阴影距离将级联阴影贴图Cascaded Shadow Maps的MaxDistance控制在30米以内远处的敌人直接不投阴影最多依靠环境光遮蔽模拟效果。减少阴影级联数默认3~4级如果场景不是大开阔地2级完全够用每少一级都能省下一大截shadow map面积。非重要角色关闭投影在距离超过一定阈值后把敌人网格体上的Cast Shadow关掉用一张预烘焙的AO贴图在材质里模拟接触阴影。我记得当时把阴影距离从50米缩到25米GPU时间直接掉了30%画面观感并没有明显衰减。多敌人场景的光照优化性价比最高的永远是先动阴影而不是去把屏幕百分比从100%拉到50%。3. 逻辑与AI侧优化别让每帧做重复劳动把渲染侧清了一遍把帧率从45拉回60发现依然有波动再接上Unreal Insights看GameThread的时间又开始往上冒。这一轮我决定对AI和游戏逻辑动刀。3.1 AI感知与更新频率牺牲一点“聪明劲”换流畅UE的AI感知系统非常强大可以监听视觉、听觉、触碰但它默认会每帧去轮询所有感知通道。多敌人场景下二十个敌人同时开着视觉感知去扫描玩家位置主线程瞬间爆炸。这时候的正当优化思路是降低感知更新频率让AI“偶尔看一眼”而不是每帧都全功率工作。具体做法是在AIPerception组件里找到UpdateInterval把默认值从0改到0.3秒甚至0.5秒。0.5秒的感知延迟对普通射击游戏完全够用玩家从掩体后面露头AI在0.5秒内作出反应肉眼几乎察觉不到延迟。反而它省下了大量CPU时间因为在0.5秒的时间窗内AI不用重新执行GenerationalSensing。同样在AIController的TickInterval里我把角色Tick也从60Hz改到30Hz。多敌人场景里AI不需要每帧都决策行为树会有一些Waiting任务可以隔帧跑。2026年FPS游戏都在拼低延迟和1% low帧流畅度很少人关心AI的更新频率这块省出来的时间往往比渲染优化还要可观。3.2 导航与寻路NavMesh不是越多越好多敌人AI离不开寻路但UE的NavMesh在没有改变时也是每帧计算同样的路径。当二十个敌人走到一个路口由于他们同时抢占路径寻路组件会频繁重新计算路径产生大量A*搜索。我在项目里做了几件事将NavMesh生成网格的自动重新生成改为手动重build除非有墙体破坏或关卡更新否则不重算。为大型敌群共享路径寻路不能让二十个敌人走完全不同的路径而是让同一个小队共用一个FollowingComponent或Path Corridor只让Leader寻路其余跟随。使用UNavigationSystemV1::GetPathCost缓存结果避免每帧重复查询。路径搜索开销主要靠查表解决。地图稍微复杂点时A*搜索在CPU上偶尔会有几十毫秒的暴击这个暴击就是1% low帧出现的原因之一。换成Leader寻路后暴击概率会大幅下降1% low帧的数据也变得平滑。3.3 Gameplay代码的并发与缓存很多多敌人优化多半栽在“每帧全局扫描”这类写法上。比如某个玩家技能要检测范围内所有敌人有人就在Tick里写GetAllActorsOfClass然后遍历所有敌人。这种函数会触遍整个关卡的所有Actor串联查询巨耗性能。我的经验是使用UE的Detection Volume或UNiagaraSystem事件记录进入半径的Actor只在进出时更新列表不在Tick里遍历。将伤害检测从Tick改成定时器或事件驱动例如开枪时只对射线单一检查。用Actor属性缓存来避免重复操作尤其是Animation Related状态和时间戳它们本就是高频访问点。优化前我调试时看stat engine里Tick开销高达9ms。优化后把那种每帧检查敌人距离的逻辑全部改成事件驱动Tick开销直接降到2ms以下。多敌人场景不缺性能缺的是正确的数据结构。4. 动画与物理优化把CPU时间花在刀刃上动画和物理是多敌人场景主线程的第二大债权人。一个敌人跑动时它的骨骼动画系统每帧都在更新骨骼变换物理子系统又在处理胶囊体碰撞和射击反弹两者叠加开销惊人。4.1 骨骼动画LOD远处敌人不需要那么精细UE的骨骼网格体默认坚持全LOD动画计算骨骼数量越多动画更新开销越大。多敌人场景中根本不需要远处的敌人去跑骨骼蒙皮甚至布娃娃物理此时必须使用动画预算分配器。在项目设置里启用Animation Budget Allocator后可以用预算规定所有动画动画实例的总耗时比如10ms。预算分配器会优先保证靠近镜头的敌人动画质量把远离镜头的敌人动画的更新频率降到30Hz甚至15Hz代价是远处的敌人播放动作可能不够丝滑但玩家根本看不到那么远。我还给每个敌人设置了基于距离的骨骼LOD在CameraDistance的ScreenSize超过一定阈值后其陷阱骨骼网格体的更新被截断改成Using LODData或者只更新Root Motion。这一招能让动画系统的CPU占用率下降一半。动画LOD不是玄学它来源于一个简单的道理GPU在渲染远处物体时可以偷懒CPU在计算远处骨骼时同样应该偷懒。4.2 物理碰撞不要让子弹和敌人互相折磨物理系统在多敌人场景中最容易被滥用。敌人本身的碰撞胶囊体枪械弹道的Block通道场景的StaticMesh碰撞每个碰撞体只要活性参与物理模拟就会产生CPU开销。我做的第一件事是检查碰撞通道设置把敌人身体的物理模拟设为Fixed只保留碰撞查询响应关闭物理模拟也就是让它像一座活着的“静态雕像”而不是随时会受力弹跳。子弹的物理模拟极其浪费改用射线检测LineTrace不需要真正的子弹物理体就可以瞬间判定命中。还有一点是从Flash Flashbolt视角给敌人的碰撞体只开胶囊体不管发射的枪口烟雾特效。特效面片不要参与碰撞通道否则每个特效碎片都会和世界碰撞体交互画面没变好CPU已经爆炸。4.3 粒子特效的合并与限制多人的战场总躲不开火花、血雾、死亡爆炸。Niagara系统可以把大量粒子合并到一个GPU渲染容器里尤其是火焰和烟雾。我做了一个粒子池预设最多2000颗粒子超过上限的旧粒子被杀掉。这样一来敌人被击杀时爆出的一百个粒子瞬间被分发到粒子池而不是每个击杀新建一个组件、创建一批新粒子、再销毁变量避开了垃圾回收。实测粒子特效的GC峰值降了約40%1% low帧中的尖刺少了很多。5. 数据驱动的调优闭环用Profiler和统计验证一切前面讲了很多具体优化但优化的过程不是做完一条就能算数必须有个闭环。这个闭环的核心是建立性能预算表用工具测量每次改动前后的数据再靠1% low帧校验是否真的流畅。5.1 建立性能预算表在优化开始前我第一件事是定好目标帧率和各线程预算。举例目标60FPS一帧可用时间是16.6msGameThread预算6msRenderThread预算5msGPU Busy预算5msRHI线程预算3ms额外余量2ms这是一个比较健康的分配方式。实际项目里如果主线程偏重可以适当把GameThread调到7msRenderThread压到4ms。关键是把预算数字写成Excel表每次修改后往回填数据这样一眼就能看出哪里达标哪里超支。我用一张测试表现状举例线程/资源优化前耗时优化后耗时预算GameThread22ms7ms6msRenderThread12ms6ms5msGPU Busy8ms4ms5msRHI Thread5ms3ms3ms看着这份表格我就知道下一步必须继续优化GameThread里的动画和AI直到把22ms压到6ms以内。预算表最重要的作用是防止你学了十几个优化技巧后到处乱用而是在数字化约束下按优先级出牌。5.2 基于数据的迭代流程我自己的优化顺序基本固定为三条线第一轮先把渲染侧的阴影和实例化处理掉因为它们对帧率影响最直观改也最快。第二轮把AI的更新频率和路径缓存处理好降低GameThread峰值。第三轮再把动画预算分配和骨骼LOD调完看数字余量还有多少。每一轮结束我都会重录一次Unreal Insights更新预算表。很多人优化只做一轮就觉得够了但往往余额只有一点点未来加了新功能又会马上崩。我的习惯是直到预算表每行都比目标值低15%以上才算真正“完成”。5.3 1% low帧与流畅度的关系平均帧率是骗人的战斗中真正的体验是掉帧尖刺的多少。1% low帧的定义是把所有帧的渲染时间排序取最慢的1%帧的的平均帧时间再换算成FPS。如果平均帧是60 FPS但1% low只有20 FPS说明游戏中频繁出现卡顿体验很糟。普遍共识是1% low帧至少要保证大于45才能算得上“流畅”。多敌人场景中最容易出现1% low暴跌的原因是资源加载突刺比如敌人在远处首次出现在视线中它的骨骼网格体和材质纹理瞬间被送进内存导致主线程或GPU等待资源加载。我处理资源加载的方法是将敌人资产放进AssetManager的PrimaryAsset列表并在关卡开始前执行异步预加载Load Primary Asset。如果不想提前预加载太多至少将Mip Load Wait Time调低一点并开启Async Loading让纹理流送不阻塞主线程。6. 常见问题与排查实录多敌人优化是修不完的仔细走了一遍总会有几个陷阱。我把项目里踩过的坑结合现实经验摘几个典型做成一个速查表方便读者反复参考。6.1 优化后还是卡这几件事最容易遗漏现象可能原因解决方向帧数波动但Thread不超内存碎片或GC峰值使用对象池、分帧销毁多人同时爆特效后卡顿粒子导致DrawCall突增粒子池化、GPU粒子、限流平移视角时掉帧资源流送阻塞Async Loading、预加载资产AI同时开火时掉帧Audio或动画通知大量触发合并音效触发、降低AnimationNotify间距远处敌群跳动LOD切换过快影响观感调整LODDistanceScreenSize和LodTransitionDuration比如对象池是我反复强调的招数。敌人死亡后不要立刻Destroy Actor而是放进对象池等待下次刷怪时复用。这时你不再需要频繁创建Actor的资源分配也能大幅度减少GC的卡顿尖峰直接改善1% low帧。还有一个隐蔽问题是大量的低成本动画通知在同一帧触发。例如二十个敌人同时播放开火音效每个音效都创建了一个SoundWave实例瞬时占据内存撞击音效系统会引起内存峰。解决办法用SoundMix限流音频文件或限制同时播放的VoiceCount。6.2 一个真实的0.1% Low问题排查过程我印象最深的是一次加载了一个竞技场地图平时稳75 FPS但只要两个小兵上墙极限贴脸镜头快速转动的那一瞬间帧数就会瞬间跌到40以下肉眼可见地顿一下。Unreal Insights里记录的时间线显示第1200帧处用一条非常长的Delay出现在GameThread上几乎占据了整个时间线。顺着时间线往下看很快定位到是一条动画通知Animation Notify触发了角色身上一个特效的血雾生成而这个特效的Niagara资产当时并没有被预加载。动画播放带了资源加载加载需要读取磁盘磁盘I/O在那一帧挂起。最终我手动在Niagara资源设置了WarmUpTime并把它添加进预加载清单重新测试后0.1% low帧提升了80%从肉眼可感知的顿挫变成不可感知的微波动。这是典型的“性能问题不在代码逻辑而在资源加载时机”的案例。做FPS多敌人优化越到后面越要留一只眼睛盯住资源系统和IO调度而不只是旧式思维里的DrawCall和Tick。我个人在实际操作中的体会是多敌人场景的优化从来不是一次冲锋就能搞定的它更像一个持续迭代的工程。每次你很好的压低那一层就又会发现新一层瓶颈浮出来。但只要坚持用Unreal Insights记录、维护性能预算表并重视1% low数据你就能把这种看似玄学的过程慢慢变成一条条肉眼可见的绿色数据条。 多敌人FPS场景性能优化实战：从瓶颈定位到帧率提升
做FPS优化的人都有一个共同的噩梦打开测试地图拉出二十个敌人帧数直接从120掉到45鼠标一甩就是一阵阵的屏幕撕裂。多敌人场景之所以难搞不是某一个系统出了大问题而是动画、AI、渲染、物理全挤在同一个屋子里开会每个人都在抢CPU和GPU的时间片。这篇文章我想用一次实际项目中的优化经历完整拆一遍“多敌人FPS场景”的性能瓶颈怎么定位、怎么拆解、怎么一步步压回目标帧率。内容会覆盖从Unreal Insights的帧数据分析到渲染侧的DrawCall削减、逻辑侧AI更新频率的调整、动画LOD和物理碰撞的精简最后落到用性能预算表和1% low帧校验结果。整个过程是纯实战经验涉及具体命令和配置参数。最适合正在被多敌人场景卡到怀疑人生的UE开发者或者想把引擎优化从“玄学”变成“工程”的团队。1. 场景分析与瓶颈定位先别急着砍找出真正的凶手多敌人场景的性能问题最忌讳一上来就猜。有人看一眼掉帧就条件反射去关阴影有人马上调低屏幕百分比结果帧数没涨多少画面糊成一片。我一开始也这么干过后来才发现与其瞎猜不如用引擎自带的工具把一分钟时长的帧数据录下来让数据告诉你瓶颈在哪。1.1 多敌人场景到底压垮了什么先明确一下概念。UE里一帧的时间是被多个线程瓜分的主线程GameThread负责游戏逻辑、AI决策、动画更新、物理模拟的准备渲染线程RenderThread负责场景图遍历、剔除、DrawCall提交RHI线程负责和显卡驱动打交道把渲染命令真正送进去。你在帧数面板里看到的Frame、Game、Draw、GPU就是这几条线程各自的花费。多敌人场景下最典型的伤害是同步发生的每个敌人都有自己的动画蓝图和AnimInstance格斗或射击动作一多GameThread上动画更新会随着人数线性增长每个敌人都有自己的AI控制器感知、寻路、行为树在运转每个敌人都是一个Actor有碰撞盒和可见性检测到了渲染端每个常规网格体至少产生1~2个DrawCall20个敌人加上枪口火花、弹壳、血雾特效DrawCall轻松破千。问题就出在这里四条线程哪一条先到极限你的帧数瓶颈就在哪一条。我先用一个生活化类比帮自己理清思路。主线程像是一个餐厅的点单服务员所有客人的需求都经过他处理渲染线程像是后厨的备餐台把所有菜按顺序摆好GPU是炒锅真正开火出菜。如果服务员太慢客人等得久这就是GameThread瓶颈如果备餐台堆满菜传不过去这是RenderThread瓶颈如果炒锅火力不够这是GPU瓶颈。餐厅要提升翻台率光买更好的锅没用你得先看出排队到底卡在哪个环节。1.2 用工具说话Unreal Insights和Stat命令的正确用法定位瓶颈首选Unreal Insights它可以在引擎里启动录制也可以运行时按快捷键捕获。我用的是启动时加-tracing参数的方式只录60秒覆盖进战斗开火和刷出理想状态的二十个敌人然后把数据拖到Unreal Insights里分析。界面上最直观的是帧时间线四条颜色的横条分别代表GameThread、RenderThread、RHI线程和GPU Busy时间哪条压到顶部红线那就是首要瓶颈。除了录帧我还会用一套固定的Stat命令来快速看关键计数器命令如下stat unit stat game stat render stat rhi stat anim stat engine这套命令在编辑器模式就可以跑。stat unit能看到Frame、Game、Draw、GPU的总耗时stat anim能看到动画更新的具体耗时stat engine能看到Actor、Tick、Collision相关的开销。第一次测多敌人场景时我在控制台敲了stat unit屏幕显示GameThread在35秒时已经吃了22msRenderThread只有12msGPU只有8ms。事实证明瓶颈在主线程不在渲染那我后续的优化重点就往动画和AI逻辑上砸而不是去折腾材质和阴影。2. 渲染侧优化让GPU和DrawCall一起瘦身虽然我这次定位到主线程瓶颈但多敌人场景的渲染压力同样不容忽视——尤其是当你把敌人数量堆到50甚至80DrawCall数高得会让任何一个手机GPU直接罢工。这部分我把渲染侧的优化策略整理出来即使你的瓶颈在主线程先把DrawCall压低也能给后续的GPU峰值留出喘息空间。2.1 绘制调用过载先看剔除和实例化多敌人场景里最常见的绘制调用浪费是玩家后面站着一群敌人玩家看不到他们但引擎依然逐帧提交它们的骨骼网格体、武器、附属部件。UE的默认视锥剔除能干掉屏幕外的物体但藏在背后的物体视锥可能仍然正向就需要靠遮挡剔除或距离剔除兜底。我用的是分层策略近战范围内0~10米保持完整的骨骼网格、LOD0、完整材质和阴影。中距离10~25米切换到LOD1关闭动态阴影使用简化材质。远距离25米以上切换到LOD2或直接用Imposter模块生成一张公告板纹理绘制成本几乎为零。关键参数在骨骼网格体上设置MinimumLOD和LODDistanceScreenSize同时打开Use True Velocity让LOD切换更平滑。实测在中距离关闭阴影后DrawCall直接砍掉一半。如果敌人是同一批模型我强烈建议把远处的敌人换成实例化静态网格体Instanced Static Mesh或HISMHierarchical Instanced Static Mesh。HISM最大的优势是自动把几十个敌人的网格体合并成一个DrawCall配合剔除系统单独管理每一实例的可见性。当玩家视角转向敌群时HISM可以只渲染屏幕中心附近的实例甚至能把一个80敌人场景的DrawCall压到十几个。2.2 Shader与材质优化的成本账材质是GPU耗电大户多敌人场景中尤其容易踩坑的是overdraw。角色的皮肤、盔甲、枪械各自带了一套复杂的PBR材质贴上法线、粗糙度、AO、各向异性贴图每一次BasePass都把这些计算结果跑一遍。敌人一多GPU的像素填充率就会被彻底吞掉。我采用的做法是为敌人角色做材质质量级别分级编辑器模式下保留PBR细节打包后或战斗状态下切换成简化版本。做法是在材质里开启Quality Level节点针对低质量的级别关闭细节纹理甚至替换一个无光照版本。这种方案在移动端优化里非常常见UE项目也直接支持。还有一个经验是材质中少用全局函数和复杂表达式尽量将纹理采样限制在BaseColor、Roughness、Metallic三个关键通道。我拿引擎自带的Lyra演示项目做过测试它的角色材质已经是很标准的优化版本但依然能通过降低鲁棒性获得20%的GPU时间盈余。2.3 光照与阴影多敌人时最容易忽略的大坑动态阴影是帧率杀手。敌人多意味着每个敌人为了投射阴影都要进入shadow map渲染一遍自己的网格体这会让阴影Pass的DrawCall瞬间翻倍。测试时五个敌人还能稳60帧拉到二十个时GPU总线直接烧红问题多半就出在阴影上。控制阴影成本有几招限制阴影距离将级联阴影贴图Cascaded Shadow Maps的MaxDistance控制在30米以内远处的敌人直接不投阴影最多依靠环境光遮蔽模拟效果。减少阴影级联数默认3~4级如果场景不是大开阔地2级完全够用每少一级都能省下一大截shadow map面积。非重要角色关闭投影在距离超过一定阈值后把敌人网格体上的Cast Shadow关掉用一张预烘焙的AO贴图在材质里模拟接触阴影。我记得当时把阴影距离从50米缩到25米GPU时间直接掉了30%画面观感并没有明显衰减。多敌人场景的光照优化性价比最高的永远是先动阴影而不是去把屏幕百分比从100%拉到50%。3. 逻辑与AI侧优化别让每帧做重复劳动把渲染侧清了一遍把帧率从45拉回60发现依然有波动再接上Unreal Insights看GameThread的时间又开始往上冒。这一轮我决定对AI和游戏逻辑动刀。3.1 AI感知与更新频率牺牲一点“聪明劲”换流畅UE的AI感知系统非常强大可以监听视觉、听觉、触碰但它默认会每帧去轮询所有感知通道。多敌人场景下二十个敌人同时开着视觉感知去扫描玩家位置主线程瞬间爆炸。这时候的正当优化思路是降低感知更新频率让AI“偶尔看一眼”而不是每帧都全功率工作。具体做法是在AIPerception组件里找到UpdateInterval把默认值从0改到0.3秒甚至0.5秒。0.5秒的感知延迟对普通射击游戏完全够用玩家从掩体后面露头AI在0.5秒内作出反应肉眼几乎察觉不到延迟。反而它省下了大量CPU时间因为在0.5秒的时间窗内AI不用重新执行GenerationalSensing。同样在AIController的TickInterval里我把角色Tick也从60Hz改到30Hz。多敌人场景里AI不需要每帧都决策行为树会有一些Waiting任务可以隔帧跑。2026年FPS游戏都在拼低延迟和1% low帧流畅度很少人关心AI的更新频率这块省出来的时间往往比渲染优化还要可观。3.2 导航与寻路NavMesh不是越多越好多敌人AI离不开寻路但UE的NavMesh在没有改变时也是每帧计算同样的路径。当二十个敌人走到一个路口由于他们同时抢占路径寻路组件会频繁重新计算路径产生大量A*搜索。我在项目里做了几件事将NavMesh生成网格的自动重新生成改为手动重build除非有墙体破坏或关卡更新否则不重算。为大型敌群共享路径寻路不能让二十个敌人走完全不同的路径而是让同一个小队共用一个FollowingComponent或Path Corridor只让Leader寻路其余跟随。使用UNavigationSystemV1::GetPathCost缓存结果避免每帧重复查询。路径搜索开销主要靠查表解决。地图稍微复杂点时A*搜索在CPU上偶尔会有几十毫秒的暴击这个暴击就是1% low帧出现的原因之一。换成Leader寻路后暴击概率会大幅下降1% low帧的数据也变得平滑。3.3 Gameplay代码的并发与缓存很多多敌人优化多半栽在“每帧全局扫描”这类写法上。比如某个玩家技能要检测范围内所有敌人有人就在Tick里写GetAllActorsOfClass然后遍历所有敌人。这种函数会触遍整个关卡的所有Actor串联查询巨耗性能。我的经验是使用UE的Detection Volume或UNiagaraSystem事件记录进入半径的Actor只在进出时更新列表不在Tick里遍历。将伤害检测从Tick改成定时器或事件驱动例如开枪时只对射线单一检查。用Actor属性缓存来避免重复操作尤其是Animation Related状态和时间戳它们本就是高频访问点。优化前我调试时看stat engine里Tick开销高达9ms。优化后把那种每帧检查敌人距离的逻辑全部改成事件驱动Tick开销直接降到2ms以下。多敌人场景不缺性能缺的是正确的数据结构。4. 动画与物理优化把CPU时间花在刀刃上动画和物理是多敌人场景主线程的第二大债权人。一个敌人跑动时它的骨骼动画系统每帧都在更新骨骼变换物理子系统又在处理胶囊体碰撞和射击反弹两者叠加开销惊人。4.1 骨骼动画LOD远处敌人不需要那么精细UE的骨骼网格体默认坚持全LOD动画计算骨骼数量越多动画更新开销越大。多敌人场景中根本不需要远处的敌人去跑骨骼蒙皮甚至布娃娃物理此时必须使用动画预算分配器。在项目设置里启用Animation Budget Allocator后可以用预算规定所有动画动画实例的总耗时比如10ms。预算分配器会优先保证靠近镜头的敌人动画质量把远离镜头的敌人动画的更新频率降到30Hz甚至15Hz代价是远处的敌人播放动作可能不够丝滑但玩家根本看不到那么远。我还给每个敌人设置了基于距离的骨骼LOD在CameraDistance的ScreenSize超过一定阈值后其陷阱骨骼网格体的更新被截断改成Using LODData或者只更新Root Motion。这一招能让动画系统的CPU占用率下降一半。动画LOD不是玄学它来源于一个简单的道理GPU在渲染远处物体时可以偷懒CPU在计算远处骨骼时同样应该偷懒。4.2 物理碰撞不要让子弹和敌人互相折磨物理系统在多敌人场景中最容易被滥用。敌人本身的碰撞胶囊体枪械弹道的Block通道场景的StaticMesh碰撞每个碰撞体只要活性参与物理模拟就会产生CPU开销。我做的第一件事是检查碰撞通道设置把敌人身体的物理模拟设为Fixed只保留碰撞查询响应关闭物理模拟也就是让它像一座活着的“静态雕像”而不是随时会受力弹跳。子弹的物理模拟极其浪费改用射线检测LineTrace不需要真正的子弹物理体就可以瞬间判定命中。还有一点是从Flash Flashbolt视角给敌人的碰撞体只开胶囊体不管发射的枪口烟雾特效。特效面片不要参与碰撞通道否则每个特效碎片都会和世界碰撞体交互画面没变好CPU已经爆炸。4.3 粒子特效的合并与限制多人的战场总躲不开火花、血雾、死亡爆炸。Niagara系统可以把大量粒子合并到一个GPU渲染容器里尤其是火焰和烟雾。我做了一个粒子池预设最多2000颗粒子超过上限的旧粒子被杀掉。这样一来敌人被击杀时爆出的一百个粒子瞬间被分发到粒子池而不是每个击杀新建一个组件、创建一批新粒子、再销毁变量避开了垃圾回收。实测粒子特效的GC峰值降了約40%1% low帧中的尖刺少了很多。5. 数据驱动的调优闭环用Profiler和统计验证一切前面讲了很多具体优化但优化的过程不是做完一条就能算数必须有个闭环。这个闭环的核心是建立性能预算表用工具测量每次改动前后的数据再靠1% low帧校验是否真的流畅。5.1 建立性能预算表在优化开始前我第一件事是定好目标帧率和各线程预算。举例目标60FPS一帧可用时间是16.6msGameThread预算6msRenderThread预算5msGPU Busy预算5msRHI线程预算3ms额外余量2ms这是一个比较健康的分配方式。实际项目里如果主线程偏重可以适当把GameThread调到7msRenderThread压到4ms。关键是把预算数字写成Excel表每次修改后往回填数据这样一眼就能看出哪里达标哪里超支。我用一张测试表现状举例线程/资源优化前耗时优化后耗时预算GameThread22ms7ms6msRenderThread12ms6ms5msGPU Busy8ms4ms5msRHI Thread5ms3ms3ms看着这份表格我就知道下一步必须继续优化GameThread里的动画和AI直到把22ms压到6ms以内。预算表最重要的作用是防止你学了十几个优化技巧后到处乱用而是在数字化约束下按优先级出牌。5.2 基于数据的迭代流程我自己的优化顺序基本固定为三条线第一轮先把渲染侧的阴影和实例化处理掉因为它们对帧率影响最直观改也最快。第二轮把AI的更新频率和路径缓存处理好降低GameThread峰值。第三轮再把动画预算分配和骨骼LOD调完看数字余量还有多少。每一轮结束我都会重录一次Unreal Insights更新预算表。很多人优化只做一轮就觉得够了但往往余额只有一点点未来加了新功能又会马上崩。我的习惯是直到预算表每行都比目标值低15%以上才算真正“完成”。5.3 1% low帧与流畅度的关系平均帧率是骗人的战斗中真正的体验是掉帧尖刺的多少。1% low帧的定义是把所有帧的渲染时间排序取最慢的1%帧的的平均帧时间再换算成FPS。如果平均帧是60 FPS但1% low只有20 FPS说明游戏中频繁出现卡顿体验很糟。普遍共识是1% low帧至少要保证大于45才能算得上“流畅”。多敌人场景中最容易出现1% low暴跌的原因是资源加载突刺比如敌人在远处首次出现在视线中它的骨骼网格体和材质纹理瞬间被送进内存导致主线程或GPU等待资源加载。我处理资源加载的方法是将敌人资产放进AssetManager的PrimaryAsset列表并在关卡开始前执行异步预加载Load Primary Asset。如果不想提前预加载太多至少将Mip Load Wait Time调低一点并开启Async Loading让纹理流送不阻塞主线程。6. 常见问题与排查实录多敌人优化是修不完的仔细走了一遍总会有几个陷阱。我把项目里踩过的坑结合现实经验摘几个典型做成一个速查表方便读者反复参考。6.1 优化后还是卡这几件事最容易遗漏现象可能原因解决方向帧数波动但Thread不超内存碎片或GC峰值使用对象池、分帧销毁多人同时爆特效后卡顿粒子导致DrawCall突增粒子池化、GPU粒子、限流平移视角时掉帧资源流送阻塞Async Loading、预加载资产AI同时开火时掉帧Audio或动画通知大量触发合并音效触发、降低AnimationNotify间距远处敌群跳动LOD切换过快影响观感调整LODDistanceScreenSize和LodTransitionDuration比如对象池是我反复强调的招数。敌人死亡后不要立刻Destroy Actor而是放进对象池等待下次刷怪时复用。这时你不再需要频繁创建Actor的资源分配也能大幅度减少GC的卡顿尖峰直接改善1% low帧。还有一个隐蔽问题是大量的低成本动画通知在同一帧触发。例如二十个敌人同时播放开火音效每个音效都创建了一个SoundWave实例瞬时占据内存撞击音效系统会引起内存峰。解决办法用SoundMix限流音频文件或限制同时播放的VoiceCount。6.2 一个真实的0.1% Low问题排查过程我印象最深的是一次加载了一个竞技场地图平时稳75 FPS但只要两个小兵上墙极限贴脸镜头快速转动的那一瞬间帧数就会瞬间跌到40以下肉眼可见地顿一下。Unreal Insights里记录的时间线显示第1200帧处用一条非常长的Delay出现在GameThread上几乎占据了整个时间线。顺着时间线往下看很快定位到是一条动画通知Animation Notify触发了角色身上一个特效的血雾生成而这个特效的Niagara资产当时并没有被预加载。动画播放带了资源加载加载需要读取磁盘磁盘I/O在那一帧挂起。最终我手动在Niagara资源设置了WarmUpTime并把它添加进预加载清单重新测试后0.1% low帧提升了80%从肉眼可感知的顿挫变成不可感知的微波动。这是典型的“性能问题不在代码逻辑而在资源加载时机”的案例。做FPS多敌人优化越到后面越要留一只眼睛盯住资源系统和IO调度而不只是旧式思维里的DrawCall和Tick。我个人在实际操作中的体会是多敌人场景的优化从来不是一次冲锋就能搞定的它更像一个持续迭代的工程。每次你很好的压低那一层就又会发现新一层瓶颈浮出来。但只要坚持用Unreal Insights记录、维护性能预算表并重视1% low数据你就能把这种看似玄学的过程慢慢变成一条条肉眼可见的绿色数据条。