企业官网建设流程全解析

1. 先回答“瓶颈在哪”：UE性能优化从入门到精通的底层逻辑

我接过一个UE4项目时，第一反应是这游戏在编辑器里跑得挺欢，为啥一打包到目标机器上就掉帧掉到没法玩？后来调了两个多月，才把帧率稳住。那段时间让我意识到一件事：Unreal Engine开发与性能优化听起来像两套东西，实际上是一套——性能预算，从立项第一天就该定下来，而不是等项目快上线了才开始“救火”。

很多入门者容易把性能优化理解成“哪里卡了就调哪里”，比如某个场景帧率低了，就去减少几个模型面数、关掉几个特效。这种思路不能说错，但效率极低，因为卡顿往往不是单一因素造成的，而是渲染压力、CPU逻辑、内存带宽、资源加载、DrawCall数量等多方面叠加的结果。如果不先搞清楚瓶颈到底在哪个子系统，你做的所有调整都相当于蒙着眼睛修车。

1.1 性能是一个预算问题，不是一个玄学问题

想做好UE项目的性能优化，得先把思维从“优化”转成“预算”。就像做家庭开支计划一样，你的收入（硬件性能）是固定的，每个月要花的钱（游戏逻辑、渲染开销、内存占用）不能超过收入，否则就会“透支”——表现就是掉帧、卡顿、发热、闪退。

所以第一步永远是“记账”：搞清楚你的目标硬件上有多少预算可以花。举个例子，如果你的目标是在移动端保持30帧，那一帧的时间预算就是33.3毫秒（1000ms/30fps）。这33.3毫秒要分给游戏线程、渲染线程、GPU各自一部分。通常移动端大致是这样的分配：

预算参考表（目标30帧，每帧总预算约33.3ms）

这几个数值不是死的，但核心原则是：先看哪一项超了，再针对性地去优化对应模块。如果GPU时间明明还有富余，你却在那儿拼命减模型面数，这属于南辕北辙。反过来，如果游戏线程已经跑到了12ms，你还执着于合并DrawCall，那也是白费功夫。

1.2 渲染管线选型决定性能天花板

UE从4.x到5.x，一直在不断演进渲染能力。新手比较容易忽视的一点是：你在项目初期选择的渲染管线，直接决定了后面性能优化的上限。

目前主流的可选方案是：

• Forward Shading（前向渲染）：对多光源支持有限，但回归了MSAA抗锯齿，在VR项目里效果很好。UE里可以在 Project Settings -> Rendering 里勾选 Forward Shading。它的好处是单pass一次输出，内存开销小，适合对延迟敏感的场景。
• Deferred Shading（延迟渲染）：默认的PC/主机渲染路径，很多光源和动态物体也能高效处理。代价是不支持MSAA（只能靠TAA、FXAA等后处理抗锯齿），而且G-Buffer内存占用偏高，移动端不太推荐。
• Mobile Renderer（移动渲染器）：专门为移动GPU设计的简化管线，牺牲了一部分画面细节去换帧率和功耗，是移动端项目的主力。

你可能会问，选哪个更好？答案取决于目标平台。PC和主机，选延迟渲染基本没错；移动端和VR，前向渲染或移动渲染器更靠谱。你要是硬在移动设备上用延迟渲染，性能开销会非常难看，光G-Buffer的带宽就把GPU吃掉了。

1.3 目标平台与保底帧率：没有基准就没有优化

我在接手项目时做的第一件事不是写代码，而是和团队确定一件事：**这个游戏到底要跑在什么机器上？保底的帧率是多少？**这些信息不明确，后面所有的“优化”都像无头苍蝇。

比如做PC项目，团队内部通常需要设一个“最低配置”概念——不是说显存4GB就能跑，而是测试机和上线配置要有代表性。用一台中低端笔记本作为基准测试机，比任何高配工作站上的“完美表现”都有参考价值。做移动端项目更麻烦，因为安卓机型碎片化严重，你至少得选几档不同芯片的测试机：一档高端（骁龙8系列级别），一档中端（骁龙7系列/天玑8000级别），一档低端（骁龙6系列或者更老的芯片）。针对每一档设定不同的画质等级和分辨率缩放系数，这是后面第5章会细说的分级策略。

一句话总结：性能优化始于“预算表”和“基准平台”，没有这两样东西，后面所有的调整都只是碰运气。

2. 用工具说话：stat、Profiling和Unreal Insights的正确用法

很多开发者对性能优化感到无从下手，是因为他们靠“感觉”来判断卡顿原因。实际上，UE自带的调试工具已经非常成熟，能帮我们把每一毫秒都拆分出来，看清楚到底花在哪儿了。这章我把最常用的几套工具讲透。

2.1 stat unit 三行数字，先定位是CPU还是GPU

在编辑器或打包后的运行时，按键盘的波浪号（~）打开控制台，输入stat unit，你会看到这样一组数据：

• Frame：整帧的耗时，它是上限。
• Game：游戏线程耗时，包括蓝图、C++、物理、动画等逻辑计算。
• Draw：渲染线程耗时，负责场景剔除和渲染命令收集。
• GPU：GPU实际执行时间。

这组数据的作用就是帮你做第一轮“二分法定位”。如果Game接近Frame，那么瓶颈在游戏逻辑；如果Draw很长，多半是场景里物体太多、材质太复杂；如果GPU接近Frame，那就是画面渲染本身太重了。

顺便说一句，stat unit在不同版本里显示的项目略有差异。UE5以后还会显示 RHI 线程耗时。通用做法是：先记录60秒内的平均值和峰值，而不是看一眼就下结论。因为有些卡顿是瞬时尖刺（比如加载资源、GC），平均值正常但峰值爆表，这种问题最常见于场景切换或大规模Actor生成瞬间。

2.2 Unreal Insights 把帧拆开看

stat unit能告诉你瓶颈在哪一层，但它看不到更细的内容：到底哪个函数耗时长？哪个Actor的Tick占了资源？这时候就要请出Unreal Insights。

Unreal Insights从UE5.0开始逐渐成为官方主推的性能分析工具，老版本里的stat startfile和stat stopfile记录出的.ueprof文件也可以用Session Frontend打开，但体验不如新工具。要开启Trace，在启动参数里加上-trace=default，或者在编辑器里通过Trace窗口手动开启记录。

进入Unreal Insights后，你能看到每条线程的时间轴——游戏线程、渲染线程、工作线程全都平铺开来。对于某个卡顿帧，可以对比哪个线程在那个时间点阻塞了，双击耗时长的区块还能跳到具体函数或资产上。这比你在代码里到处插耗时日志要高效得多。

2.3 给渲染线程做的体检：GPU Visualizer 与通道耗时

如果你已经确定GPU是瓶颈，下一步要查的就是“GPU时间都花在哪些pass上了”。在控制台输入ProfileGPU（或按Ctrl+Shift+,），编辑器会生成一份GPU通道占用报告，列出SceneColor、BasePass、Shadow Depth、Translucency、PostProcessing等各环节的耗时占比。

举个例子，我在一个样板房项目里发现，单单阴影深度pass就占了GPU总时长的32%。进一步排查发现场景里动态光源太多，而且阴影分辨率给到了2048，这在中端显卡上完全不划算。把主要光源的阴影分辨率降到1024，并把无关紧要的辅助灯改成不投射阴影，GPU占用直接掉了近20%。

工具是死的，思路是活的。优化的过程其实是“用工具层层深入、不断逼近根因”的过程：stat unit看到总分配，Unreal Insights看到线程分布，GPU Visualizer看到渲染通道分配，三种工具配合使用，才能把一个复杂问题压缩到可解的范围。

3. 渲染层优化：DrawCall、资源级联与Shader压力

渲染层是UE性能开销的大头，尤其是场景元素多的时候，优化空间也最大。这章不聊太偏门的黑科技，只讲每个项目都能用上的三件套：DrawCall控制、LOD策略、纹理和显存管理。

3.1 DrawCall 是怎么吃掉帧时间的

DrawCall可以理解成CPU向GPU下达“把这个网格画出来”的指令。指令本身很快，但量一多，CPU和GPU之间来回通信就要排队，帧率自然就掉下来了。在 UE 里，DrawCall 数可以直接通过控制台stat scenerendering查看，重点看Mesh Draw Calls这一项。

降低DrawCall的手段主要有：

• 网格实例化（Instanced Static Mesh / HISM）：把大量相同的物体（比如树木、石头、路灯）合并成同一批绘制。场景里几百棵相同的树，用单个Actor一棵一棵放，和用HISM一次摆几百棵，DrawCall差距是几百倍的。
• Actor合并（Merge Actors）：打开Window -> Developer Tools -> Merge Actors，把多个静态网格合并成一个，同时合并材质和贴图。适合那种不会动、也不会被单独操作的装饰物。
• 降材质复杂度：一个物体用了过多的材质要么“材质层数”多，要么材质里的采样节点多，都会摊高DrawCall或Shader编译负担。实际做法是能用Master Material + Material Instance的就别搞多个独立材质，能减少材质层的就减少。

3.2 LOD、HLOD、Nanite：用三级减载换稳定帧率

除了DrawCall，三角形数量同样是GPU的压力来源。千万不要小看距离概念：远处一个占屏幕3像素的石头，如果还用5000三角形的精度去渲染，这就是纯浪费。

UE的LOD系统可以在引擎设置里给网格自动生成多级减面版本。选中Static Mesh资产后，在LOD Settings里勾选Auto Generate LOD，设置级数和屏幕尺寸阈值，引擎会根据距离自动切换高模、中模、低模。

到了UE5时代，Nanite虚拟化几何体更是把“三角形预算”这个概念彻底改写了。Nanite会自动按屏幕大小生成细分级别的网格流送，你不用再手动做LOD，而且大量三角形由GPU直接处理，效率非常高。但要注意，Nanite对半透明材质、某些带顶点动画的角色骨骼网格支持有限，移动端目前也不推荐开启。项目里该用哪个方案，取决于平台和你渲染的内容，没有通解。

再说HLOD（Hierarchical LOD）。当你在场景里摆了大量家具、道具时，单靠每个Actor自己的LOD还不够——毕竟远处一百个Actor合在一起仍然要跑一百次。HLOD能把这些散落的Static Mesh在编辑器里预先合并成单一代理网格，远处显示一个“块”，近处再展开细节。World Settings里的HLOD System节点负责这个，World Partition下还有ISMC（Instanced Static Mesh Component）方案。它的作用不是减少GPU压力，而是减少CPU和DrawCall的压力，对开放世界项目尤其重要。

3.3 纹理流送与显存预算的配置细节

显存溢出会导致严重的卡顿甚至闪退，尤其在移动端和低显存PC上很常见。UE的纹理流送系统可以只加载当前需要的贴图Mip等级，而不是把所有贴图一次性压进显存。

控制台命令r.Streaming.PoolSize用来设置纹理池大小（单位MB），设得太小会让远处贴图永远糊掉，设得太大又容易污染显存。PC项目一般建议设置为显存大小的1/4到1/3，移动端则需要更保守。还可以用r.Streaming.MaxEffectiveScreenSize控制纹理流送的像素阈值，让贴图不需要用到最高分辨率时就不加载。

移动端有个更实用的技巧：打包时降低材质贴图的分辨率上限，或者用Texture Group把场景贴图分成Common、Character、UI等组，单独控制每组的最大尺寸。UI贴图用1024甚至512就够，别让它占着2048的高清内存。

4. 游戏逻辑层的CPU瘦身：三个常见的坑

渲染优化是一部分，但不少项目真正卡的是CPU侧的游戏逻辑。尤其是蓝图写多了以后，游戏线程的耗时常常莫名其妙就到了15ms以上。这种情况再拼命减DrawCall也没救了，得回到逻辑层来“还债”。

4.1 每个Actor都Tick？赶紧改掉

默认情况下，每个Actor都会开启Tick。如果你场景里有几千个Actor，每个Actor的Tick哪怕只执行几条空逻辑，累积起来也是一笔不小的开销。更糟糕的是，有些人习惯把“每隔一秒检查一次血量”这类逻辑写在Tick里，用累加计时器判断是否该执行，等于每秒执行几百次无意义的比较运算。

规范做法是：

• 完全不需要每帧更新的Actor，构造函数里写PrimaryActorTick.bCanEverTick = false;直接关掉Tick。
• 需要周期性更新的，用TimerManager里的SetTimer设定间隔，别用Tick做轮询。
• 必须在每帧运行的任务，先想一想能不能合并到帧尾统一处理，或者把计算量大的部分拆到异步线程。

举个例子，我曾经把一个城市场景里300多个带Tick的路灯Actor全部改成“灯光初始状态设置一次就结束”，游戏线程的耗时直接降了3ms多。这类优化没什么技术含量，但对CPU压力的缓解非常可观。

4.2 蓝图不是不能用，而是要看用在哪

蓝图这玩意儿，开发效率高，但运行时性能和C++比还是有不小差距，主要是变量访问、函数调用和垃圾回收的开销。我见过团队把所有数值计算、寻路、装备栏逻辑都盘在蓝图里，跑到后面一开背包就卡一下，这种体验真的很难受。

我的建议是分三层：

• 表现层逻辑（UI交互、技能释放特效、简单状态切换）留在蓝图里，开发效率高，性能影响不大。
• 高频调用逻辑（移动控制、物理检测、寻路计算）尽量用C++写，或者在C++里暴露接口给蓝图调用。
• 数据驱动内容（单位属性、掉落表、剧情对话）放到DataTable或JSON里，别做成蓝图数组硬编码。

UE里有个工具叫蓝图转C++，虽然没有一键自动转换那么智能，但核心逻辑用C++重写后，再用蓝图做上层调用，这种做法既保性能又保开发效率，是我们项目里最常用的姿势。

4.3 异步加载与多线程：让闲置核心跑起来

游戏卡顿很多时候不是单帧计算太重，而是“把本该分帧完成的东西一次性压到了一帧”。场景切换时一瞬间加载几百个资产，或者读取一个大文件，很容易造成几秒钟的卡顿。

UE的关卡流送（Level Streaming）和异步加载（Async Load Assets）就是解决这个问题的。把大世界拆成多个子关卡，玩家靠近时才开始异步加载，离开后再卸载，而不是进入地图时一股脑全加载。API层面，LoadStreamLevel配合FStreamLevelDelegate回调，C++里还能用FStreamableManager按需加载资产。

多线程方面，UE提供TaskGraph和FRunnable，能帮你把A*寻路、数据编解码这类计算密集型的任务放到工作线程池里执行，避免占用游戏线程。不过多线程编程是深水区，记得处理好数据竞争和线程安全，别为了性能优化，反而追出一堆崩溃Bug。

5. 移动端项目的专项优化：帧率、发热与包体的平衡

移动端是很多团队消耗精力的主战场。安卓机型和iOS设备的GPU架构差异很大，芯片性能悬殊，屏幕分辨率也不统一，确实需要一套专门策略来应对。这章内容对PC项目也许用不上，但做手游、VR一体机相关项目的读者，建议仔细看。

5.1 移动渲染管线的取舍逻辑

UE在移动端默认走Mobile Renderer，它会自动关闭一些PC上能用的特性，比如SSR、高质量反射、体积雾等。但即使这样，你还是可以进一步取舍。

• 保证主光源阴影，但限制阴影距离。移动端动态阴影非常贵，超出一定距离直接切到Lightmap烘焙阴影，在项目设置里可以通过 Cascaded Shadow Maps 的级联距离来控制。
• 限制动态光源数量。我通常把移动端每个可见物体受动态光源影响的个数限制在1个，其余靠静态光照（Lightmap）补足，这样能大幅减少shader指令和overdraw。
• 后处理项目能少则少。Bloom可以用低档，AO只在主相机上加一层，景深尽量别用高斯多pass，很多移动端项目干脆不做景深，或者用一次pass的简化版本。

这些取舍不是盲目降画质，而是把有限预算花在玩家肉眼最关注的地方：主角周围的清晰度、光感和场景氛围。远处的东西反正是背景，没必要烧GPU。

5.2 动态分辨率与画质分级

移动端最常用的性能保险手段是动态分辨率。当检测到当前帧耗时超过预算（比如30帧制下超过33ms）时，程序自动降低渲染分辨率（调低r.ScreenPercentage的值），等GPU压力缓解后再慢慢升回来。这个过程玩家感知很弱，但帧率能保住。

UE移动端的写法通常这么处理：

C++里调整屏幕百分比（示意）

// 在YourPlayerController或GameUserSettings里，根据帧率动态调整 float CurrentFrameTimeMs = GetWorld()->GetDeltaSeconds() * 1000.0f; float TargetFrameTimeMs = 33.3f; // 目标30帧 float CurrentScreenPercent = UKismetSystemLibrary::GetConsoleVariableFloatValue(TEXT("r.ScreenPercentage")); if (CurrentFrameTimeMs > TargetFrameTimeMs * 1.2f) { // 超时了，降渲染分辨率 float NewPercent = FMath::Clamp(CurrentScreenPercent - 10.0f, 50.0f, 100.0f); UKismetSystemLibrary::ExecuteConsoleCommand(this, FString::Printf(TEXT("r.ScreenPercentage %f"), NewPercent)); } else if (CurrentFrameTimeMs < TargetFrameTimeMs * 0.8f) { // 有余量，可以升回来 float NewPercent = FMath::Clamp(CurrentScreenPercent + 10.0f, 50.0f, 100.0f); UKismetSystemLibrary::ExecuteConsoleCommand(this, FString::Printf(TEXT("r.ScreenPercentage %f"), NewPercent)); }

配合DeviceProfile，你可以按照机型的芯片档位，预设不同的分辨率、阴影质量、特效等级。高配机开100%分辨率，中配开80%，低配开60%，运行时再靠动态分辨率微调。这种“设备分级+动态调节”的组合，是移动端项目保证体验下限的主流做法。

5.3 移动端特有的资源控制

移动端显存就是内存，GPU和CPU共享同一块物理内存，所以内存管理对移动端尤其重要。

• 贴图压缩格式：iOS建议ASTC，安卓主流是ASTC或ETC2。项目设置里Texture Group可以统一指定，别默认BC7还往安卓真机上装，那样内存直接爆炸。
• 音频资源流送：大体积音频文件选择Streaming加载而不是全量加载进内存。
• 避免Resident Assets：检查确认哪些资产被设置成“常驻”，常驻资产越多，内存基线越高，低端机就容易闪退。

6. AI与大量Actor场景的性能治理：从行为树到导航网格

“Agent开发”这个词在游戏领域里通常指游戏AI代理——NPC、敌人、友军单位。很多项目的卡顿并不仅来自渲染，AI更新逻辑同样能占掉大量游戏线程时间。同时，“场景里Actor数量太多”也是一个常被忽视的隐形杀手。

6.1 行为树的频率问题

UE的行为树（Behavior Tree）虽然好用，但它默认在每个Tick都会运行。场景里有30个AI角色，每个AI每帧都跑一遍完整行为树，游戏线程被吃光很正常。

优化办法有两个方向：一是调整行为树的TickInterval。在Behavior Tree资产里有TickInterval属性，把默认0改成0.1~0.5不等，让AI每隔几百毫秒决策一次，肉眼完全看不出区别，CPU压力却成倍下降。二是把高频反应（比如被击中、听到声音）从行为树里摘出来，用事件驱动的方式触发——向AI发一个消息或调用一个接口，而不是让AI每帧去“感知”。

6.2 导航与感知的常见开销

Navigation Mesh的计算量也不小。动态躲避（Detour Crowd）用的RVO避障算法，CPU开销跟参与避障的Agent数量成指数关系。能改成静态路径的，就尽量别开避障；必须开的，限制同类Agent同屏数量。

EQS（Environment Query System）也是一个容易翻车的地方。很多团队喜欢让AI每几秒做一次EQS来找“最远掩体”或“最近玩家位置”，但EQS对环境采样很吃计算。如果你认真测过，会发现枚举器遍历了几百个点、几十次射线检测，耗时可观。对只需“找掩体”这种场景，用简单的距离判断+射线检测，效果也差不多，性能却便宜得多。

6.3 大量Actor存在时的合并策略

开放世界项目动辄几百上千个NPC和可交互物，如果每个都是正常的Actor（有场景组件、有Tick、有物理），CPU和内存都受不了。

合并策略一般分两步走：

• 静态物件：用上面提过的HISM/ISM或者HLOD批量合并。
• 动态物件：尽可能把“可交互范围”缩小——玩家走到跟前才生成实体Actor，走远了就换成静态壳或直接卸载。这就是Entity系统、World Partition在UE5中要做的事。World Partition后，不同区域用流送方块独立管理Actor加载与卸载，能让编辑器和大世界同时保持流畅。

7. 开发环境里的隐形坑：注册表残留与多版本引擎管理

说完了性能优化本身，我再聊一个容易被忽略、却又经常在开发流程里坑人的问题：引擎安装与版本管理的混乱。

一个很常见的场景：公司项目用UE4，个人笔记本装了UE5，桌面还有一堆不同版本的引擎，结果有时候双击打开项目，弹出“引擎版本不匹配”，或者批处理打包时找不到引擎路径。这时候很多人的第一反应是卸载重装，但实际上问题很大概率出在注册表残留和路径配置上。

7.1 理解 HKEY_LOCAL_MACHINE\SOFTWARE\EpicGames\Unreal Engine\4.0

在Windows系统里，UE引擎安装时会在注册表HKEY_LOCAL_MACHINE\SOFTWARE\EpicGames\Unreal Engine\[版本号]下写入环境信息。以4.x为例，HKEY_LOCAL_MACHINE\SOFTWARE\EpicGames\Unreal Engine\4.0这个键下面，通常会保存当前引擎的安装路径（比如InstalledDirectory）和引擎分支信息。

它的作用很关键：很多第三方工具、构建脚本、甚至Epic Games Launcher自身，都是通过读这个注册表项来定位引擎位置的。你用UE的命令行工具打包时，如果没有通过-unrealexe显式指定引擎路径，系统默认就是去注册表里找。

7.2 多版本共存常见的路径错乱

如果机器上装过多个不同版本的UE，注册表里对应的键可能会残留下旧路径，或者被某个工具的安装过程改乱了。比如磁盘换过盘符，或者引擎文件夹从D盘挪到E盘，可注册表里还写着D盘的老路径，Epic启动器打开项目时就找不到引擎，报的错莫名其妙。

这类问题的排查链路通常是这样的：

1. 运行regedit，定位到HKEY_LOCAL_MACHINE\SOFTWARE\EpicGames\Unreal Engine\4.0（版本号按实际项目来）。
2. 看InstalledDirectory的路径是否真实存在。不存在，要么把引擎文件夹挪回去，要么手动把键值改成正确路径。
3. 检查HKEY_CURRENT_USER\SOFTWARE\Epic Games\Unreal Engine\Builds里记录的引擎构建路径，有没有对应版本。
4. 路径改完后，重启Epic Games Launcher或重新在引擎目录下运行GenerateProjectFiles.bat，重新刷新关联。

这种做法属于“非常规操作”，但确实能解决90%的“引擎找不着”型问题。注意改注册表前建议备份一下键值，避免手滑改坏。

7.3 自动化打包时如何正确取引擎路径

在CI/CD流水线或本地批处理打包时，脚本里经常需要定位引擎目录。与其依赖注册表（容易被环境影响），更稳妥的写法是显式传入：

@echo off set UE_EDITOR_EXE=E:\UE_Project\UE_4.27\Engine\Binaries\Win64\UE4Editor-Cmd.exe set UPROJECT_PATH=D:\MyProject\MyProject.uproject "%UE_EDITOR_EXE%" "%UPROJECT_PATH%" -run=Cook -targetplatform=Windows -build

这么做的好处是，脚本的可移植性更强，不依赖注册表当前状态。但如果你管理的机器很多，手动维护每台电脑的引擎路径也累，所以很多团队会选择写个“启动前自动检测注册表”的脚本，检测不到再fallback到环境变量UE_ENGINE_DIR，多一层保险。

注册表这个话题不是直接提升性能的“优化”，但它属于稳定开发环境、减少无效返工的一部分。性能优化做得再好，如果打包环节天天被环境问题卡住，团队效率照样上不去。

8. 一次完整优化项目复盘：从掉帧到稳定60帧的实测记录

最后拿一个实际项目收尾，把前面讲的工具和思路串起来。这是一个中等规模的PC端室内设计展示项目，场景里有大量家具、灯具、材质丰富的模型，最初在测试机上帧率只有38~42帧，远达不到60帧的目标。

8.1 项目症状与初次数据收集

第一轮我们先在测试机上用stat unit记录了5分钟数据，结论是：

• Game线程：约6ms，正常。
• Draw线程：约8ms，偏高。
• GPU时间：约22ms，是最大瓶颈。

也就是说，问题主要出在GPU渲染压力上。接着用 ProfileGPU 看占用分布，又发现阴影pass占了9ms，BasePass占了8ms，后处理占了3ms，其余零星开销2ms。阴影和BasePass明显是两大头。

8.2 每步优化做了哪些、前后数据对比

接下来按优先级逐项调整，每做一步就重新记录数据：

几轮操作下来，GPU时间从22ms降到14ms左右，加上Draw线程优化后也降了一点，整帧稳定在60帧（约16.6ms预算内）。最关键的是，玩家视角下画面几乎没打折，阴影稍微软了一点而已。

8.3 防止性能回退的常规操作

优化完成不代表一劳永逸。项目继续迭代，新需求一进来可能又把帧率拖回去。所以我们的团队后来定了几条规矩：

• 性能测试自动化：每次版本合入前，在固定测试机上跑一遍固定场景，自动记录stat unit和ProfileGPU数据，和上个版本对比。超出预设阈值就拦截合入。
• 性能预算写进需求文档：新功能上线前先估算它要吃多少预算，超过当前可用预算的，要么砍复杂度，要么找其他系统匀预算。
• 定期在低配机实测：高配机掩盖问题，低配机暴露问题。每周挑两台低端测试机跑一遍关键流程，心里才踏实。

这整套流程走下来，最大的收益不是“这版不卡了”，而是团队对性能有了共同认知：性能是预算管理，是流程控制，不是某个人临到上线前的“灵光一闪”。

我做UE开发这些年，最大的体会是：绝大多数性能问题都不是某个“黑魔法”能解决的，而是项目从立项到上线每一个环节都需要时刻绷紧的那根弦。只要你把预算表定好、工具用熟、流程卡严，Unreal Engine 开发与性能优化这两件事，其实可以变成一个良性循环，而不是互相拉扯的对抗。