第8章 性能优化

考点： 瓶颈定位方法、stat unit、渲染基础

参考答案：

1. 用 stat unit 查看 Frame/Game/Draw/GPU/RHIT 时间：GPU≈Frame 说明 GPU 瓶颈；Game 或 Draw≈Frame 说明 CPU 瓶颈；两者都远小于 Frame 则可能卡在 VSync/锁帧。
2. 交叉验证：r.ScreenPercentage 50 帧率明显提升→GPU（像素/着色器受限）；pause 帧率明显提升→CPU Game Thread 过重；stat rhi 确认 DrawCall 是否过多。
3. CPU 常见瓶颈与对策：Tick 过多（stat game 定位→禁用/降频）、物理（简化碰撞体）、动画（LOD/URO）、GC（对象池、控制触发）、寻路（减少动态障碍、降查询频率）。
4. GPU 常见瓶颈与对策：Overdraw（viewmode shadercomplexity/quadoverdraw）、DrawCall 过多（合批/HISM）、Shader 复杂度、分辨率过高（动态分辨率）、阴影开销（减少级联/距离）。
5. 快速定位流程：

stat unit
 ├─ GPU ≈ Frame → GPU瓶颈（分辨率/DC/材质/阴影逐项验证）
 ├─ Game ≈ Frame → Game Thread瓶颈（stat game 定位系统）
 └─ Draw ≈ Frame → Render Thread瓶颈（stat rhi 看 DC 数量）

考点： 性能分析工具熟练度

参考答案：

1. 总览类：stat unit（Frame/Game/Draw/GPU/RHIT 时间，最重要）、stat fps（帧率）、stat unitgraph（帧时间趋势图）。
2. CPU 分析：stat game（Tick/BlueprintTime/SpawnActor 等 Game Thread 统计）、stat scenerendering（InitViews/DynamicShadows）、stat slow -ms=0.5（显示超过阈值毫秒的函数）。
3. GPU 分析：stat gpu（PrePass/BasePass/ShadowDepths/Lights/Translucency/PostProcessing 各 Pass 耗时）、stat rhi（DrawPrimitive Calls/Triangles/Render Target 内存）。
4. 内存分析：stat memory、stat memoryplatform、stat streaming。
5. 特定系统：stat particles、stat anim、stat physics、stat ai、stat audio、stat foliage、stat nanite、stat lumen、stat net、stat rep。
6. 补充：stat startfile/stopfile 录制到文件；CSV Profiler 适合自动化回归；ProfileGPU 打开 GPU Visualizer。

考点： 现代性能分析工具、数据驱动优化

参考答案：

1. 功能：帧分析（CPU/GPU 时间线）、调用栈、内存分配追踪、网络、加载时间，支持本地/远程分析与自定义 TRACE 标记。
2. 使用流程：命令行 -trace=cpu,gpu,frame,bookmark,memory -tracefile=xx.utrace 或控制台 trace.start/stop，用 Engine/Binaries/Win64/UnrealInsights.exe 打开分析。
3. 代码中加标记：

#include "ProfilingDebugging/CpuProfilerTrace.h"
TRACE_CPUPROFILER_EVENT_SCOPE(MyActor_ExpensiveFunction);
TRACE_BOOKMARK(TEXT("Event"));
TRACE_MEMORY_MARKER(TEXT("BeforeLoadLevel"));

4. 与传统 stat 对比：Insights 可保存回放、有完整跨线程调用树与过滤搜索、支持远程与自定义标记、可做详细内存分配追踪；stat 适合实时快速查看。两者配合：日常 stat unit 快速检查，深挖用 Insights，CI 自动化 trace 做回归。
5. 最佳实践：CPU/GPU trace 同时开启，先看最长线程再逐层下钻到具体函数或 Pass。

考点： GPU 各 Pass 分析

参考答案：

1. 控制台输入 ProfileGPU 捕获一帧，按 Pass 查看耗时分布（BasePass/Lighting/Shadow/Translucency/PostProcess）。
2. 判读：BasePass 高→网格复杂度/DrawCall 过多；Lighting 高→光源数量或需光照贴图；Shadow 高→阴影光源/阴影质量；PostProcess 高→后处理链过重。
3. 用功能开关与分辨率变化验证因果（关掉某 Pass 或降分辨率看帧率是否变化），确认根因后再针对性优化。
4. 配合 stat gpu 交叉验证：stat gpu 显示各 Pass 毫秒级耗时，ProfileGPU 则提供层级视图，两者互补可快速定位最长 Pass。
5. 常用验证手段：Show → Visualize → Shader Complexity 查看像素着色器开销分布；Show → Visualize → Light Complexity 定位光源热点；FreezeRendering 冻结场景逐 Pass 对比。
6. 易错点：ProfileGPU 只捕获单帧，需多次捕取取中位数避免偶然性；合并后的 Mesh 包围盒过大会导致 Shadow Pass 膨胀。
7. 面试点评：考察对 GPU 渲染管线各 Pass 职责的理解，能否快速定位到具体瓶颈环节。

考点： 多线程与 IO 卡顿定位、trace 交叉印证

参考答案：

1. 不能只看 stat unit；需多工具交叉印证：Insights Timing（各线程耗时与等待）、GPU capture（各 Pass）、IO trace、对象/GC trace、stat slow。
2. GameThread 卡：函数级下钻，找 Tick/蓝图/物理/GC 调用点；Render Thread 卡：InitViews、场景代理、提交命令；RHI 卡：命令缓冲与资源分配；GPU 卡：看 Pass 与占用率；IO 卡：stat streaming/IO Insights 看加载阻塞与等待锁；GC 卡：stat gc/GC trace 看触发点与耗时。
3. 典型特征：线程时间线出现空白/等待常指向 IO、锁、资源加载；GPU 满载而 CPU 空闲→GPU 瓶颈；多线程都忙→考虑并行化与负载均衡。
4. GC 卡顿专项：stat gc 查看 GC 耗时与频率；Insights Memory 面板看 GC 触发时的分配潮汐；短命对象过多→对象池；引用泄漏→obj list 排查保活根；在加载界面主动调用 ForceGarbageCollection() 避免战斗中触发。
5. IO 卡顿专项：stat asyncio 查看异步 IO 队列深度；Insights IO 面板看文件读取延迟与阻塞；大文件未分块→拆分资源；同步加载（LoadSynchronous）阻塞主线程→改异步。
6. 易错点：只关注 GPU/CPU 而忽略 Render Thread 的 InitViews 开销；GC 卡顿被误判为 IO 卡顿；未区分 Game Thread 和 Render Thread 的职责边界。
7. 面试点评：考察多线程渲染架构的理解深度，能否用交叉印证方法精准定位卡顿来源。

考点： Tick 优化、事件驱动设计、Significance Manager

参考答案：

1. 代价：N 个 Actor×60fps 的 Tick 是最大 CPU 开销来源之一；先在 stat game 的 TickTime 确认是否热点。
2. 完全禁用：PrimaryActorTick.bCanEverTick = false;，运行时用 SetActorTickEnabled(false);。
3. 定时器替代轮询：

GetWorldTimerManager().SetTimer(CheckTimer, this, &AMyActor::PeriodicCheck, 0.5f, true);

4. 事件驱动：状态变化时才触发，而不是每帧检测。例如 SetHealth 中只有血量跨过 0 才调用 Die()，用 OnHealthChanged.Broadcast() 通知 UI 绑定更新。
5. 降频：PrimaryActorTick.TickInterval = 0.1f;（10Hz）或 SetActorTickInterval(0.2f)。
6. Significance Manager：按距离/重要性返回 0~1，据此选择完整/简化/最小更新，重要度为零则禁用 Tick。
7. 完整决策流程：先量化热点→再选降频/事件驱动/并行化；保证更新依赖、线程安全与最坏帧预算。效果对比：1000 AI 全 60Hz 约 6 万次/秒；定时器 0.5s 降约 97%；Significance 近密远疏约降 87%。

考点： 蓝图 vs C++、热路径

参考答案：

1. 蓝图比 C++ 慢约 10~20 倍，Tick 中的蓝图逻辑开销更大。
2. 核心原则：热路径（Tick、高频调用）移入 C++，蓝图只负责配置；用事件驱动替代轮询。
3. 减少 Cast：在 BeginPlay 缓存引用，避免每帧 Cast<>；避免每帧 GetAllActorsOfClass（改为维护注册列表）；减少循环与复杂数学；用宏/函数复用节点。
4. 调试：stat game 的 BlueprintTime、Unreal Insights 蓝图调用栈、蓝图 Profile 节点；必要时使用蓝图 Nativization。

考点： 空间分区、ParallelFor、线程安全边界

参考答案：

1. 空间查询：避免遍历全量 Actor 找最近目标；用 OverlapMultiByChannel/SweepMultiByChannel（球形/盒形查询）或空间分区（Grid/四叉树）缩小搜索集。
2. 并行计算：

ParallelFor(Enemies.Num(), [&](int32 Index)
{
    ProcessEnemy(Enemies[Index]); // 无共享状态的纯数据计算才可并行
});

3. 线程安全边界：后台线程不能随意访问 UObject/World/RHI 及其渲染资源；后台只做纯数据计算，结果经安全队列回 Game/Render 线程处理。
4. 其他 CPU 手段：禁用不必要 Tick、缓存引用与中间结果、避免热路径字符串构造、对象池复用、stat slow 定位超阈值函数。

考点： 生成尖峰、对象池、实例化渲染

参考答案：

1. 分帧注册/销毁：把一次大量 Spawn 拆到多帧分批执行（定时器/分帧队列），限制单帧生成峰值。
2. 对象池：预生成并复用高频对象（取出时启用、归还时隐藏并禁用碰撞与 Tick），池要有上限并预热，避免无限增长。
3. 静态同类批量用 ISM/HISM：

UInstancedStaticMeshComponent* ISM = CreateDefaultSubobject<UInstancedStaticMeshComponent>(TEXT("ISM"));
for (int32 i = 0; i < 1000; i++)
{
    ISM->AddInstance(FTransform(...)); // 千棵树 1 个 DrawCall
}

HISM 额外自带 LOD 与遮挡剔除。 4. 与 GC 配合：减少短命 UObject 创建，避免瞬时对象推高 GC 峰值；池化对象不进入 GC 循环。

考点： 渲染优化、剔除、LOD、Shader

参考答案：

1. 减少 DrawCall：合并 Mesh（Merge Actors）、ISM/HISM 实例化、材质实例共享、纹理图集减少状态切换（详见 6.1）。
2. LOD：多级 LOD 按屏幕空间自动切换；高面数静态模型可用 Nanite。
3. 剔除：距离剔除 SetCullDistance；视锥剔除与遮挡剔除由引擎自动完成（注意合并后的包围盒对遮挡剔除的影响）。
4. Shader 复杂度：减少指令数与纹理采样（目标：移动端<64~100 指令、PC 视预算）；材质 LOD/Quality Switch；避免像素着色器中的 pow/exp/sin/cos，改用近似或 LUT。
5. 渲染管线：降低分辨率/动态分辨率、简化后处理链、控制阴影级联与分辨率、控制半透明 Overdraw。
6. 用 ProfileGPU/stat gpu 先定位最长 Pass，再针对性下手，避免盲目优化。

考点： 烘焙光照、动态光源、阴影技术

参考答案：

1. 光照：静态场景烘焙光照贴图；控制动态光源数量与作用范围（光照通道、光源重要性）；用距离/重要性剔除不必要光源。
2. 阴影：只给重要光源开阴影；CSM（级联阴影）控制级联数与阴影距离；限制动态阴影投射体数量；远景可降低阴影分辨率。
3. Lumen（见 3.4）：调整质量/采样数、限制追踪距离、场景用 SDF 加速、硬件 RT 在预算允许时开启。
4. 用 stat lighting/stat scenerendering 验证各阶段开销。

考点： VSM、页池、显存管理

参考答案：

1. 收益：VSM 大幅减少传统阴影图的分辨率/级联管理限制，与 Nanite 配合高效，阴影观感更稳定。
2. 风险：消耗页池与显存，场景复杂或远景大时页表分配可能抖动、显存溢出。
3. 降级策略：按距离裁剪阴影投影体、控制阴影分辨率与质量分级、非关键区域用烘焙或低分辨率阴影；监控页池使用，设显存预算并分级降档。
4. 页池配置：r.Shadow.Virtual.CacheSizeMB 控制页池上限（默认约 50% 显存），按平台设不同预算；r.Shadow.Virtual.Nanite.Mode 可降级为传统阴影回退。
5. 显存监控：stat rhi 查看 Virtual Shadow 内存占用；memreport -full 输出各 Pass 显存分布；峰值超过 80% 预算时触发降级。
6. 远景降级实践：CVar r.Shadow.Virtual.MaxPhysicalPages 限制物理页数量；非关键物体关闭 VSM 投射（bCastVirtualShadowMap=false）；远景用烘焙阴影替代。
7. 易错点：未设页池上限导致显存溢出；VSM 与 Nanite 混用时未统一 LOD 策略导致阴影闪烁。
8. 面试点评：考察对 UE5 新阴影系统的理解，能否在画质与显存预算间做合理权衡。

考点： Lumen 选型、平台预算

参考答案：

1. 硬件 RT 质量强但成本高（需相应 GPU）；软件路径（SDF 追踪）兼容面广、成本可控。
2. 选型：室内/近景重视 GI 质量可开硬件 RT；开放世界/低端 PC/主机优先软件路径并降档。
3. 降级：调整质量档、采样数、追踪距离；静态区域烘焙+动态区域 Lumen 混合；准备多档画质回退并逐平台验证。
4. 关键 CVar 配置：r.Lumen.Reflections.MaxRayIntensity 控制反射开销；r.Lumen.TraceMeshSDFs 降为 0 可禁用 SDF 追踪回退到屏幕空间；r.Lumen.HardwareRayTracing 控制硬件 RT 开关。
5. 平台策略示例：PS5/Xbox Series X 中画质→软件 Lumen+中等采样；PS4/Xbox One→软件 Lumen+低采样+限追踪距离；高端 PC→硬件 Lumen+高采样+远追踪距离。
6. 易错点：硬件 RT 未检测 GPU 能力导致崩溃；开放世界全开硬件 Lumen 显存不足；SDF 场景覆盖不全导致 GI 闪烁。
7. 面试点评：考察对 Lumen 两种路径特性的理解，能否按平台和场景类型做合理选型。

考点： Overdraw、透明排序、粒子优化

参考答案：

1. 控制屏幕覆盖面积与叠加层数（多层半透明叠加过度绘制严重）；用 viewmode quadoverdraw/GPU trace 验证。
2. 材质指令数与纹理采样数控制，避免半透明物体上挂多个动态光源。
3. 粒子：减少粒子数与发射率、合并同材质粒子、必要时用简化半透明材质。
4. 排序与深度：减少深度写入、控制排序消耗；层数/覆盖/粒子数设预算并分平台验证。

考点： 超分辨率、动态分辨率、帧预算

参考答案：

1. TSR（UE 内置时间超分）、DLSS/FSR（厂商超分）在低渲染分辨率下重建高画质，能显著降低 GPU 像素负载。
2. 动态分辨率以帧时间预算为输入自动调；超分以固定/档位输入；两者配合时需以帧预算调输入并评估运动画质、UI 清晰度与延迟。
3. 不能只看平均 FPS：运动重影/闪烁、UI 模糊、输入延迟（超分开销）、平台支持都需要评估；用 P95/1% low 而非平均帧验证。
4. 动态分辨率配置：r.DynamicRes.OperationMode=2（自动模式）+ r.DynamicRes.MinScreenPercentage/MaxScreenPercentage 设上下限；r.DynamicRes.FrameTimeBudget 设目标帧时间（如 60fps→16.6ms）。
5. 超分配合：TSR 启用 r.TSR.Quality 档位；DLSS 需安装 NVIDIA 插件并设 r.NGX.DLSS.Quality；FSR 通过 r.FidelityFX.FSR.Enabled 开启。动态分辨率输出作为超分输入，两者联动调参。
6. 评估方法：P95 帧时间确保无尖峰；录屏检查运动重影/闪烁；UI 截图检查清晰度；stat unit 对比渲染分辨率与输出分辨率的差距。
7. 易错点：动态分辨率下限设太低导致画质突变；超分运动估计失败导致鬼影；只调 Screen Percentage 忽略超分自身的 GPU 开销。
8. 面试点评：考察对现代渲染管线中超分与动态分辨率协作机制的理解。

考点： 移动渲染管线、带宽、Shader

参考答案：

1. DrawCall 预算：iOS 约 300500、Android 约 200400；合批、ISM/HISM、减少材质种类是最有效手段。
2. Shader：像素指令约 <64 条；材质 LOD/Quality Switch 分档；避免复杂数学与多采样，用通道打包；平台宏分支（#if PLATFORM_ANDROID || PLATFORM_IOS）区分版本。
3. 纹理：iOS 主推 ASTC（6x6 均衡），Android 按设备用 ETC2/ASTC/BC7（Vulkan）；尺寸上限 2048；3D 纹理开 Mip、UI 纹理关 Mip 省约 33% 内存；纹理图集减少切换。
4. 内存：顶点总预算（移动约 <100K 顶点/帧）、至少 3 级 LOD、动画压缩/URO、音频 ADPCM/Vorbis、限并发音效（<16）、GC 在加载界面主动触发。
5. 渲染管线：r.MobileHDR=0、关闭后处理（Bloom/AA 等）、减少 CSM 级联与阴影分辨率、动态分辨率（r.DynamicRes.OperationMode=2）；移动端默认 Forward 渲染，Deferred 开销大不推荐。

考点： 内存管理、资源优化、对象池

参考答案：

1. 纹理：压缩格式（BC7/ASTC/ETC2）、纹理 Streaming/Mip、降低非必要分辨率、UI 与 3D 分开设定。
2. 资源引用：软引用+异步加载替代硬引用级联（详见 5.1/5.2）；常用小资源保留硬引用。
3. 对象池：预分配复用高频对象，减少创建/销毁与 GC 压力。
4. LOD/HLOD、Virtual Texture 降低常驻内存；监控用 stat memory、memreport、Unreal Insights Memory。
5. 预算与监控：PC/主机/移动分别定内存上限，峰值与持续占用分开统计，超限告警。

考点： GC 引用、循环引用、资源清理

参考答案：

1. 常见原因：动态分配未释放、循环引用导致对象无法被 GC 回收、委托/事件未注销、Timer 与粒子系统未清理。
2. 检测：Unreal Insights Memory（分配调用栈）、stat memory、obj list 类筛选、memleakcheck；长时间运行观察内存只增不减。
3. 避免：指针用 UPROPERTY 交给 GC 管理；TWeakObjectPtr 打破循环引用（尤其 Actor↔Component、对象↔委托）；正确清理 MyDelegate.RemoveAll(this)、GetWorldTimerManager().ClearTimer(...)；在 EndPlay/BeginDestroy 中释放资源。
4. 检测工具链：obj list class=Texture2D 按类型筛选已加载资源；memreport -full 生成完整内存报告；Unreal Insights Memory 面板按分配调用栈聚类，定位泄漏热点；长时间挂机跑 30 分钟后对比内存快照。
5. 循环引用典型场景：Actor 持有 Component 强引用 → Component 持有 Actor 弱引用未断 → 双向引用导致 GC 不可达；委托绑定未解绑导致目标对象被隐式持有。
6. 易错点：TSoftObjectPtr 未调用 LoadSynchronous 或异步加载后未释放 Handle，导致资源常驻；蓝图中 Bind Event 未在 EndPlay 中 Unbind。
7. 面试点评：考察对 UE GC 机制和引用管理的理解，能否系统性排查内存泄漏。

考点： 峰值分析、时间序列、快照

参考答案：

1. 用时间序列与快照区分"峰值"与"泄漏"：峰值是短暂涨落，泄漏是单调增长。
2. 排查顺序：加载重叠（多个大关卡/资源同时加载）→ 缓存策略（未及时淘汰）→ 分配碎片（大量小块分配）→ 资源未释放（引用未断）。
3. 手段：内存 trace 打点前后对照（TRACE_MEMORY_MARKER）、按类别统计对象计数、引用链分析定位保活根。
4. 加载重叠排查：检查关卡切换时是否有多个 Level Streaming Volume 同时触发；用 stat streaming 确认并发加载资源数量；stat asyncio 查 IO 队列深度是否打满。
5. 缓存排查：纹理 Streaming Pool 是否过大（r.Streaming.PoolSize）；VT 页池是否未设上限；对象池是否无限增长。
6. 碎片排查：memreport -full 查看 Small Block/Large Block 分配比例；大量小块分配→合并为大块或使用对象池；长期运行后碎片积累可通过主动 GC 回收。
7. 易错点：将峰值误判为泄漏导致过度优化；忽略关卡切换时的资源重叠加载；碎片问题被误认为是真正内存增长。
8. 面试点评：考察对内存峰值成因的分析能力，能否区分暂时性峰值与持续性泄漏。

考点： 对象统计、引用链、GC

参考答案：

1. 对象统计找类型：obj list class=xxx/obj count/stat memory 看哪类对象数量异常。
2. 引用链找保活根：Reference Viewer/引用分析定位是谁持强引用导致对象无法回收。
3. GC trace 看耗时与触发频率：区分是短命对象过多还是引用泄漏。
4. 修复方向：短命对象用对象池；错误强引用改弱引用；异步加载 Handle 未释放、委托持有 target 也是常见 UObject 保活来源。

考点： 资源引用机制、级联加载、内存管理

参考答案：

1. 硬引用：加载拥有者时把被引用的资源一并加载（UObject*/TSubclassOf）；引用链可能很长，加载一个小对象触发海量资源级联加载。
2. 软引用：只存路径不加载，TSoftObjectPtr/TSoftClassPtr；用时 LoadSynchronous()（阻塞，慎用）或 FStreamableManager::RequestAsyncLoad 异步加载。
3. 内存对比：100 种敌人硬引用全量加载约 2GB；软引用只按需加载遇到的 5 种约 100MB（省约 95%）。
4. 排查：右键资源→Reference Viewer 看引用链；控制台 obj list class=Texture2D 等查看已加载资源。

考点： 加载系统原理、资源管理策略

参考答案：

1. 概念区别：流式加载是引擎自动按需加载/卸载（基于距离/优先级），资源在内存中来来去去（纹理 Streaming、World Streaming）；异步加载是在后台线程加载不阻塞主线程，完成后回调，通常加载后常驻。
2. 纹理流式：r.Streaming.PoolSize、stat streaming、r.Streaming.FullyLoadUsedTextures 1；关卡流式：Level Streaming Volume 或 World Partition（UE5）。
3. 异步加载：FStreamableManager::RequestAsyncLoad（单/多资源），持有 TSharedPtr<FStreamableHandle> 做引用计数，Handle Reset 后资源可被 GC。
4. 选型表：地形纹理→流式；大世界关卡→World Partition；UI/音效/敌人→异步+软引用；常用小资源（粒子等）→硬引用。
5. 注意：LoadSynchronous 同步阻塞主线程；GC 可能与异步加载并发，注意线程安全。

考点： Asset Manager、可加载单元

参考答案：

1. 按可加载单元定义 Primary Asset Type（例如每关、每套角色资源组合）。
2. 用 Bundle 把资产组织成组（必备/可选），配合 PrimaryAssetId 统一管理与引用。
3. 预加载时机：进入场景/玩法前显式预加载当前所需资源并持有 Handle，离开时释放；避免首次运行时同步加载造成卡顿。
4. 配合软引用与流送，避免硬依赖把无关资产带进加载链。

考点： 加载时机、同步加载审计

参考答案：

1. 审计所有同步加载调用（LoadSynchronous/LoadObject 及蓝图加载节点），战斗路径不允许首次加载大资产。
2. 改为前置异步加载（进入区域前预加载）+ 占位表现；加载完成前用低模/占位显示。
3. 用加载时间 trace（assetloadtime）确认首次引用点，收紧 Bundle 与软引用，并预热常用战斗资产。
4. 审计方法：全局搜索 LoadSynchronous 和 LoadObject 调用点；蓝图中搜索 Load Asset/Load Class 节点；控制台 stat assetloadtime 查看各资源首次加载耗时。
5. 预加载实践：在进入战斗区域前 5~10 秒用 FStreamableManager::RequestAsyncLoad 预加载角色/武器/特效资源；持有 TSharedPtr<FStreamableHandle> 直到战斗结束才释放。
6. 占位表现：加载完成前显示低模/轮廓/占位粒子；用 OnAsyncLoadComplete 回调切换到高模；避免玩家看到资源弹出。
7. 易错点：LoadSynchronous 在蓝图中不易发现（隐藏在 Load Asset 节点中）；预加载时机太晚导致进入战斗仍有卡顿；Handle 提前释放导致资源被 GC 回收。
8. 面试点评：考察对异步加载机制和资源生命周期管理的实战能力。

考点： 加载链路、构建管线

参考答案：

1. DDC（Derived Data Cache）：影响派生资源（Shader、纹理烘焙等）的编译缓存，决定构建/编辑器是否重复编译。
2. Cook 缓存：影响构建产物生成，缓存命中可加速出包。
3. IO Store / Zen Loader：影响运行时从包内读取数据的链路（加载速度与包体组织）。
4. 分链路测量：构建时间看 DDC/Cook，运行加载看 IO；共享/预热 DDC 减少重复编译，加载链路单独测。

考点： Cook 依赖、包体瘦身

参考答案：

1. 依赖闭包：资源被加载/被 Cook 时会连带其所有间接依赖；看似未直接使用的大资源可能经某条引用链被带进包体。
2. 手段：Cook report / Asset Audit 分析依赖闭包与 chunk 归属，定位被间接 Cook 的大资源。
3. 修复：清理无用硬引用、纠正目录与打包规则、去重、压缩贴图音频；包体异常增大按依赖闭包逐层分析裁剪。

考点： 合批、实例化渲染、材质合并

参考答案：

1. 原理：每个 DrawCall 有 CPU 提交开销，过多造成 CPU Render Thread 瓶颈；PC 一般控制在 1000~2000 以内（移动端更严）。
2. 合并网格：Merge Actors 把多个小网格合并为一个（注意合并后包围盒会削弱遮挡剔除）。
3. 实例化渲染：ISM/HISM（HISM 自带 LOD 与遮挡剔除）对大量相同物体最优：

UInstancedStaticMeshComponent* ISM = CreateDefaultSubobject<UInstancedStaticMeshComponent>(TEXT("ISM"));
for (int32 i = 0; i < 1000; i++)
{
    ISM->AddInstance(FTransform(...)); // 千棵树 1 个 DrawCall
}

4. 材质合并：共享材质实例/材质参数集合、纹理图集减少材质与状态切换次数。
5. 查看：stat rhi（DrawPrimitive Calls）、ProfileGPU；远景用 HLOD 合并。

考点： LOD 配置、切换距离

参考答案：

1. LOD 依据屏幕空间大小自动切换远近精度的模型，减少远处顶点与填充开销。
2. 配置：Static Mesh Editor 自动生成多级 LOD，设 Screen Size 切换距离；LOD 0 用原始模型，1~3 逐步简化。
3. 最佳实践：所有静态网格体都设 LOD；小物体（植被、石头）用 HLOD 合并；stat lod 查看生效情况。
4. 动画可用 URO（Update Rate Optimization）降低远处角色更新频率，原理与 LOD 一致。

考点： Nanite 限制条件、适用场景判断

参考答案：

1. 原理：虚拟化几何体，逐 Cluster 选择 LOD，只渲染屏幕上可见的 Cluster，三角形量≈屏幕像素量而非模型复杂度。
2. 不支持的场景：半透明材质、WPO（风吹草动等顶点偏移）、粒子系统、Landscape（5.1+ 有限支持）、骨骼网格（5.4+ 实验性且不支持 Morph Target/Cloth）、移动端（需 SM6/DX12 Ultimate）、自定义渲染 Pass、VR 多视图（有限支持）。
3. 注意事项：小物体（<1000 三角/屏幕 <10 像素）传统渲染更快；Cluster 结构使内存 +20~50%，但 LOD 切换平滑无 Pop；GPU Driven 渲染下 stat rhi 的 DC 数不准确，用 stat nanite/stat nanitegeometry 看统计。
4. 适用判断：适合高面数静态（建筑、岩石、雕像、扫描数据）；角色/半透明/低模保持传统 LOD；静态环境用 Nanite+传统混合。
5. 平台约束：受目标平台影响，需保留传统 LOD/HLOD 回退方案。

考点： 指令数、纹理采样、材质变体

参考答案：

1. 指标：材质指令数（Instruction Count）、纹理采样次数、材质复杂度（材质编辑器可查看）。
2. 减少采样：合并纹理/通道打包、纹理数组；简化计算：用近似/LUT 替代昂贵函数。
3. 避免动态分支，用 lerp 代替 if：

// 不好：if 动态分支
// 好：
Result = lerp(B, A, step(0.5, Parameter));

4. 用材质实例共享基础 Shader；材质 LOD/Quality Switch 远端降级；控制 Static Switch 数量（见 7.3）。
5. 查看：材质编辑器 Instruction Count、viewmode shadercomplexity、ProfileGPU。

考点： Shader 编译管线、PSO 缓存机制

参考答案：

1. Shader 编译：材质节点→HLSL→平台字节码；Permutation 组合爆炸（若干功能组合成 2^N 变体），大型项目首次编译可能数十万变体、耗时数十分钟，编辑器中表现为"Compiling Shaders"阻塞。
2. 治理：收敛母材质功能、限制 Static Switch 与质量层、材质实例化共享；启用并共享 DDC 避免重复编译；Cook 只编目标平台；增加并行编译线程；r.Shaders.AsyncCompile=1。
3. PSO：图形 API（Vulkan/DX12/Metal）的 Pipeline State Object，包含 Shader+渲染状态+顶点格式+混合状态，首次创建很昂贵（毫秒级）；游戏中遇到新组合就触发 Hitch/卡顿。
4. PSO 方案：预缓存（r.ShaderPipelineCache.Enabled 1）、运行期收集记录（CollectedPSOs）供下次启动预热、加载屏预编译并显示进度；[ShaderPipelineCache] 配置 BatchSize/BatchTime/PrecompileBatchSize。
5. 治理分工：Shader 编译靠 DDC/预编译，PSO 靠运行采集+预热；两者都需在 Shipping 路径验证。

考点： Shader 变体、静态开关组合

参考答案：

1. 静态开关在编译期展开为不同 Permutation，开关数量组合乘法增长（几个开关即上百变体），导致编译时间、Shader 内存与首次 PSO 创建全部上升。
2. 控制：收敛母材质功能，删除低价值开关；开关只用于真正跨材质差异大的点；质量差异用 Quality Switch 分层而非每材质叠加开关。
3. 必要时拆成多个母材质按用途组织；用 Shader 变体统计审计，设定变体预算并在 CI 上阻断超标。

考点： VT 页池、反馈、流送

参考答案：

1. 收益：按需加载贴图页，避免大纹理（地形、巨型 UI、大面积重复贴图）常驻内存。
2. 成本/限制：需要反馈缓冲区与页池；可能出现请求延迟、页抖动或闪烁；部分材质功能（某些 UV 变换、世界对齐）受限；调试与构建链路更复杂。
3. 使用：地形等大场景收益明显；按场景验证收益与画质，设页池预算并监控抖动，必要时降级为普通纹理。

考点： RT 开销、复用池

参考答案：

1. RT 的正确使用场景：小地图（实时渲染地形俯视图）、后处理（Bloom/DOF 的多 Pass 中间结果）、镜面反射（Scene Capture 2D 捕获）、UI 动态元素（如实时渲染的 3D 头像/技能预览）。
2. 常见滥用案例：每帧新建大尺寸 RT（如 1920×1080）用于小地图、MSAA 4x 应用于不需要的场景、多个 RT 同时高分辨率常驻（如 Bloom 3 个 Pass 各一个 1080p RT）、后处理链过长导致 RT 级联。
3. 性能影响：每创建一个 RT 即分配 GPU 显存，高分辨率 RT 的带宽消耗极大；MSAA 4x 使 RT 内存翻 4 倍；频繁创建/销毁导致显存碎片与分配卡顿。
4. 优化建议：
   • 建立 RT 复用池：预分配一批常用尺寸 RT，用完归还而非销毁：

     // 伪代码：RT Pool 使用
     UTextureRenderTarget2D* RT = RTPool->Acquire(FVector2D(512, 512), PF_R8G8B8A8);
     // ... 使用 RT ...
     RTPool->Release(RT);

   • 小地图用半尺寸或 1/4 尺寸 RT，隔帧更新（30fps 足够）；
   • 关闭不必要的 MSAA（后处理中间 RT 通常不需要 MSAA）；
   • 后处理 Bloom 可用分层降采样（1/2 → 1/4 → 1/8），避免全分辨率；
   • 镜面反射按需开启，远处/次要物体可禁用。
5. 调试工具：stat rhi 查看 Render Target 内存占用，ProfileGPU 查看各 Pass 的 RT 读写开销，FreezeRendering 可固定场景便于对比。
6. 易错点：忘记在不需要时释放 RT Handle，导致 RT 常驻；Scene Capture 2D 的 TextureTarget 未设置合适的分辨率，造成不必要的全屏捕获。
7. 面试点评：考察对 GPU 显存管理和渲染管线中间产物的理解，能否在画质与性能间找到平衡。

考点： UE5 大世界系统、LOD 策略

参考答案：

1. World Partition：把世界划分为均匀 Grid Cell，按玩家位置自动加载/卸载，使用一个持久关卡；默认 Cell 约 256 米（25600 单位），Cell 大小权衡管理开销与内存/加载速度；支持 Data Layers 逻辑分层、编辑器只加载编辑区、多人协作分 Cell 减少冲突。
2. HLOD：把远处同一 Cell 的多个 Actor 合并为简化 Mesh+材质（合并 DrawCall、简化三角形、材质图集、简化碰撞）；近处用原始 Actor，中远距离用合并层，更远用极简层。
3. 收益量化示例：5000 建筑全量约 5000 DC/5000 万三角/4GB → WP+HLOD 后约 206 DC/200 万三角/1.5GB（DC 与三角降约 96%、内存降约 62%）。
4. 配置与调试：r.HLOD.DistanceScale、r.HLOD.MaximumLevel；Show→Visualize→HLOD 查看生效区域。

考点： Runtime Grid、Streaming Source、Data Layer

参考答案：

1. 查 Streaming Source 覆盖范围与 Grid 大小是否匹配移动速度与加载范围（Source 过小或移动过快会频繁换 Cell）。
2. 查 Data Layer 状态（意外加载/卸载）、硬依赖把远处资源提前拉入、Cell 之间的依赖链。
3. 用高速移动路线复现，看峰值 IO/创建/PSO；配合资源加载 trace 与 stat streaming 交叉印证；调预加载、Grid 大小与加载优先级。
4. Runtime Grid 配置：World Partition Runtime Grid 中设置 Cell 大小（开放世界建议 128~256m）；Loading Range 需覆盖玩家最大移动速度×预加载时间；Priority 按距离与重要性分级。
5. Streaming Source 调优：Streaming Source 的 Target State 控制加载/卸载行为；World Partition Streaming Policy 可设为 Always Loaded（小关卡）或 Dynamic（大世界）。
6. 硬依赖排查：右键资源 → Reference Viewer 查看依赖链；stat asyncio 查 IO 队列是否被大文件阻塞；用 Cook Report 检查 Cell 间依赖。
7. 易错点：Grid 太小导致频繁换 Cell 引发抖动；Grid 太大导致内存占用过高；未考虑玩家快速移动（坐骑/传送）时的预加载不足。
8. 面试点评：考察对 World Partition 流式加载机制的理解，能否系统性排查流送抖动问题。

考点： 综合排查、IO/创建/VT/PSO

参考答案：

1. 先 trace 区分卡顿来源：IO（读取）→ 创建（Spawn/Component 初始化）→ VT（纹理页请求）→ PSO（新渲染状态编译）。
2. 再按定位调：streaming source/grid 大小、预加载范围、VT 页池、PSO 预热、加载优先级。
3. 按固定路线复测 P95/1% low 确认修复并防回归；贴图模糊常因 VT/纹理池不足或 LOD 过度，需在内存与画质间平衡。
4. IO 卡顿修复：拆分大资源为多块（单文件 <10MB）；提高 IO 优先级（FStreamableManager 的 Priority 参数）；预加载范围扩大到玩家前方 2~3 秒移动距离。
5. 创建卡顿修复：分帧 Spawn（每帧限制生成数量）；组件延迟初始化（SetTickGroup(TG_PostPhysics)）；池化复用高频 Spawn/Destroy 对象。
6. VT 卡顿修复：增大 VT 页池（r.VirtualTexture.PoolSize）；降低非关键物体 VT 分辨率；监控 stat virtualtexture 查看页请求与驱逐频率。
7. 易错点：只优化 IO 忽略 PSO 首次编译卡顿；VT 页池设太大挤占其他显存；贴图模糊与流送卡顿是两个不同问题需分别处理。
8. 面试点评：考察开放世界大场景下的综合性能排查能力，能否建立从证据到修复的完整链路。

考点： 性能基线、可复现场景、分场景预算

参考答案：

1. 目标机 + 固定路线/场景复现；采集 P50/P95 帧耗、内存峰值、CPU/GPU trace，并记录版本留档。
2. 分场景（战斗/大世界/UI/加载）分别设预算，形成可重复基线与对比口径。
3. 自动化采集（CSV/Insights trace）保证后续每次改动可比对，防止性能回归。
4. 基线建立步骤：确定测试硬件（目标机而非开发机）→ 固定路线（玩家高频路径）→ 固定场景状态（敌人数量/特效状态一致）→ 跑 10 次取中位数→ 记录 Frame/Game/Draw/GPU 四项耗时。
5. 分场景预算示例：战斗场景 Frame <16.6ms（60fps）、Game <8ms、GPU <12ms；大世界探索 Frame <33ms（30fps）；加载界面 <5s。
6. 版本留档：每次优化前后在同一基线场景跑测试，结果存入 Excel/Git；用 stat startfile 录制到 .ue4stats 文件便于后续对比。
7. 易错点：基线场景与真实玩家行为不一致（如测试场景无战斗）；开发机性能远超目标机导致基线无参考价值；未控制测试环境（后台进程、分辨率不一致）。
8. 面试点评：考察性能优化的工程化起点，能否建立可量化、可复现的基线体系。

考点： 帧同步、VSync、Present、证据链

参考答案：

1. 先确认显示同步/锁帧与 Present 节奏：Frame 由 Present 队列与 VSync 决定，不一定等于 Game+Draw 或 GPU。
2. GPU 27ms 接近瓶颈但不唯一，还可能与 CPU 提交（Draw/RHIT）负载、帧队列深度相关。
3. 按证据定位：GPU capture 看 Pass、Insights 看线程等待，确认真正瓶颈后再动手；只优化材质可能未命中根因。
4. 帧时间分解：Frame = max(Game, Draw) + RHIT 提交 + Present 等待；GPU 27ms 但 Frame 33ms → 可能是 VSync 对齐导致额外等待 6ms。
5. 排查方法：stat unit 中 RHIT 时间是否异常高（>2ms 说明 RHI 命令提交瓶颈）；stat gpu 看具体是哪个 Pass 占用 27ms；Insights 查 Game/Draw 线程是否有阻塞等待。
6. 优先级判断：GPU 27ms（81% 帧预算）→ 先优化 GPU；Game 9ms + Draw 7ms = 16ms（48%）→ CPU 还有空间但非当前瓶颈。
7. 易错点：看到 GPU 高就只优化材质，未检查是否是 Shadow/PostProcess Pass 占用；忽略 RHIT 线程提交开销；VSync 导致的额外等待被误判为 GPU 瓶颈。
8. 面试点评：考察对帧时间分解和多线程提交机制的理解，能否避免"头痛医头"的片面优化。

考点： 需求量化、验收标准

参考答案：

1. 写明：场景/路线、目标硬件与画质档、P95/1% low、内存上限、加载时间。
2. 以基线差值验收（优化后-基线达标），并声明不可退化指标（内存不升、画质不降、无新增 hitch）。
3. 用自动化回归固定测量口径，避免"20%"无统一度量基准。
4. 需求文档模板：优化目标（如 PS5 60fps P95 <16.6ms）→ 测试场景（具体关卡+路线）→ 测试硬件（型号+驱动版本）→ 验收指标（帧率/内存/加载时间具体数值）→ 不可退化项（画质/功能/内存）。
5. 量化示例：基线 P95 = 22ms → 优化目标 P95 <18ms（提升约 18%）；内存峰值 4GB → 不超过 4GB；加载时间 8s → <5s。
6. 回归机制：CI 集成自动化性能测试，每次提交自动跑基线场景；超阈值自动报警并阻断合并。
7. 易错点："优化20%"无明确基准（基线是多少？）；只验收平均帧忽略 P95；未声明不可退化项导致优化引入新问题。
8. 面试点评：考察将模糊需求转化为可量化验收标准的能力，体现工程化思维。

考点： 统计口径、卡顿量化

参考答案：

1. 平均帧率会掩盖尖峰：偶发大卡顿被平均抹平，体验主要受最差帧影响。
2. 用 1% low / 0.1% low（最差 1% 帧的平均值）与帧时间曲线看尖峰频率与幅度。
3. hitch 分析：帧时间曲线上的突变即卡顿，结合 trace 定位来源（IO/GC/PSO/加载），以 P95 与最差帧为验收口径。
4. 统计指标详解：平均帧=所有帧的平均值（易被高帧拉高）；P95=95%帧优于此值（排除最差5%）；1% Low=最差1%帧的平均值（反映最差体验）；0.1% Low=最差0.1%帧的平均值（极端卡顿）。
5. 帧时间曲线分析：用 stat unitgraph 或 Insights Timing 面板查看；平滑曲线=稳定体验；尖峰=卡顿；周期性波动=GC/定时器触发。
6. hitch 定位：stat slow -ms=5 显示超过 5ms 的函数；Insights 搜索帧时间 >33ms 的帧，展开调用栈定位根因；常见 hitch 来源：GC（stat gc）、IO 阻塞（stat asyncio）、PSO 首次编译。
7. 易错点：只看平均 60fps 就认为流畅；忽略 1% Low 只看 P95；帧时间曲线上的小波动不关注（累积影响体验）。
8. 面试点评：考察对性能统计指标的正确理解，能否用多维度指标全面评估体验。

考点： 分系统预算

参考答案：

1. 按类别（角色/地图/特效）在目标机上定预算：三角面、骨骼数、材质指令与采样、纹理分辨率、Tick 数量与频率。
2. 用资产审计（Asset Audit）扫描超预算资产，配合自动路线持续测量。
3. 预算要落到具体数字并做成门禁（超标告警），随场景迭代维护，优化收益以预算差值验收。
4. 分系统预算示例：角色三角面 <50K/个、骨骼 <200 根、材质指令 <100、纹理 2K；场景三角面 <500 万/屏、DrawCall <1500；特效粒子 <5000/帧、半透明层数 <4。
5. 审计工具：Asset Audit 窗口按类型扫描超预算资产；stat rhi 查实时 DrawCall/三角形数；stat scenerendering 查场景组件数量；CI 集成自动扫描脚本。
6. 门禁机制：在 CI 流水线中加入预算检查步骤；超标时自动阻断合并并通知负责人；预算表随版本迭代更新（随内容增长适度放宽）。
7. 易错点：预算数字脱离目标硬件（如用 PC 预算考核移动平台）；只设上限不设下限（如三角面下限无意义）；预算未随项目阶段调整导致形同虚设。
8. 面试点评：考察对性能预算管理的工程化实践，能否将预算落地为可执行的门禁机制。

考点： 视觉/玩法回归

参考答案：

1. 回归测试流程：
   • 建立视觉基线：固定相机位置/角度截图，与优化前基线做像素级对比（PSNR/SSIM 阈值判定）；
   • 玩法回归：自动化测试关键路径（如战斗连招、NPC 交互、物理模拟），断言关键状态一致；
   • 帧率回归：同一场景同一路线，P95/1% low 不低于基线，同时帧时间曲线无新增毛刺。
2. 自动化检测方法：
   • CI 集成截图对比工具（如 ImageMagick compare、Unreal 自带的自动化测试框架）；
   • 用 Automation Testing 蓝图节点录制固定路线回放，自动触发截图与状态断言；
   • 性能数据用 CSV Profiler 自动采集，超阈值自动报警。
3. 视觉对比工具：
   • Show → Visualize → Shader Complexity 验证材质改动是否引入 Overdraw 变化；
   • FreezeRendering 固定场景逐 Pass 对比；
   • 截图差异热力图：突出闪烁/抖动区域。
4. 质量门禁：优化提交必须同时通过性能（帧率提升）+ 视觉（无闪烁/色差）+ 玩法（无行为变化）三重验证，任一不通过则打回。
5. 易错点：只对比平均帧而忽略帧时间波动；截图对比未固定相机导致误报；玩法差异被"画质降档"掩盖。
6. 面试点评：考察是否具备工程化质量意识，能否在性能优化与画质/玩法稳定性间建立系统性保障。

考点： 系统性优化方法论、工程化思维

参考答案：

1. 流程：设定目标→度量基线→定位瓶颈→制定方案→实施优化→验证效果→回归测试。
2. 目标量化：如 PS5 60fps（16.6ms），CPU 预算 Game 5ms+Draw 3ms，GPU 12ms，内存/加载时间上限；基线用 stat unit/Insights 记录。
3. 定位：stat game/stat slow/stat gpu/stat rhi 找到 Top 问题，Insights 下钻具体函数；方案按优先级（先最大瓶颈），一次改一处再测，避免无法归因。
4. 验证：优化前后同一场景对比数据；回归：功能回归+自动化性能测试（固定场景记录平均帧/最差帧/内存峰值，超阈值报警）+极端场景测试。
5. 用性能预算跟踪表管理各系统毫秒预算与状态（✅/⚠️/❌），持续迭代。
6. 完整流程步骤详解：
   • Step 1 — 设定目标：明确平台（PC/主机/移动）、画质档、帧率目标（60/30fps）、内存/加载上限；
   • Step 2 — 度量基线：在目标机上用固定路线跑 10 次，采集 P50/P95/1% low 帧耗、内存峰值、CPU/GPU trace，存档留基线；
   • Step 3 — 定位瓶颈：stat unit 判 CPU/GPU → stat game/stat gpu 找 Top Pass → Insights 下钻到函数级；
   • Step 4 — 制定方案：按 ROI 排序（高收益+低难度先做），一次改一处，记录改动内容；
   • Step 5 — 实施优化：代码/资源/配置改动，提交时附性能测试结果；
   • Step 6 — 验证效果：同一场景对比基线，P95 帧耗是否达标，内存是否未超标；
   • Step 7 — 回归测试：自动化 CI 跑固定场景性能测试，超阈值报警；功能回归确保无行为变化。
7. 工具链：stat unit（实时）、Unreal Insights（深度分析）、CSV Profiler（自动化回归）、Git Bisect（定位回归提交）、性能预算表（Excel/Notion 跟踪）。
8. 易错点：跳过基线直接优化导致无法量化收益；同时改多处无法归因；只看平均帧忽略 P95/1% low。
9. 面试点评：考察系统性工程思维，能否将性能优化从"凭感觉"升级为"可量化、可复现、可自动化"的流程。

考点： 优化方法论、系统性思维

参考答案：

1. 四步法：度量（Profiler 定位 CPU/GPU 瓶颈，记录基线）→ 分析（Top 3 耗时函数/DrawCall，根因是算法、数据量还是架构）→ 优化（优先最大的瓶颈，选合适手段）→ 验证（重新 Profile 确认效果且无新问题）。
2. CPU/GPU 判定：if (GPU > Game + Draw) GPU 瓶颈 else CPU 瓶颈，再用具体命令细分。
3. 优先级矩阵：高收益+低难度（禁 Tick、合并 DrawCall、LOD）先做；高收益+高难度（蓝图转 C++、架构重构、多线程化）认真规划；低收益+低难度（代码微优化）随手做；低收益+高难度（重写系统）放弃。

考点： 性能意识、常见错误识别

参考答案：

1. Tick 滥用 → 事件驱动/定时器/触发器；
2. Tick 中频繁 Cast → BeginPlay 缓存引用；
3. 每帧 GetAllActorsOfClass → 维护注册列表（子系统）；
4. 蓝图热路径 → C++ 实现；
5. 热路径字符串构造/日志 → 条件编译（#if !UE_BUILD_SHIPPING）并降低频率；
6. 频繁创建 UObject → 对象池复用；
7. 复杂碰撞（UseComplexAsSimple 逐三角形）→ 简化碰撞体+剔除距离；
8. 每帧射线检测 → 定时检测/事件触发；
9. 硬引用级联加载 → 软引用+异步加载；
10. 半透明 Overdraw → 减少半透明层数与覆盖面积。
11. 具体案例与避免方法：
    • Tick 中做射线检测：100 个 Actor 每帧射线 = 6000 次/秒，改用定时器 0.1s 降 90%；
    • 蓝图 Tick 中 Cast + 循环：蓝图比 C++ 慢 10~20 倍，热路径必须移入 C++；
    • 硬引用级联：一个蓝图硬引用 10 个纹理，100 个敌人 = 1000 纹理常驻，改用软引用按需加载；
    • UseComplexAsSimple：复杂模型逐三角形碰撞，改用简化碰撞体（Box/Sphere/Capsule）；
    • 每帧 GetAllActorsOfClass：遍历全量 Actor 找目标，改为子系统维护注册列表，增删时自动更新。
12. 反模式检测方法：
    • stat game 的 TickTime 看 Tick 总开销；
    • stat slow -ms=0.5 定位超过 0.5ms 的函数；
    • Insights 查看每帧高频调用函数；
    • stat rhi 的 DrawPrimitive Calls 看 DrawCall 是否过多。
13. 易错点：认为"功能正确即可"忽视性能；优化时只关注 GPU 而忽略 CPU 热路径；蓝图热路径是最大隐患。
14. 面试点评：考察日常开发中的性能敏感度，能否识别并避免常见陷阱。

考点： AI 降载、网络复制、Dormancy

参考答案：

1. 用距离/可见性/重要度分档：近处全量 AI+复制；中处降频（Tick 间隔、寻路频率、复制频率）；远处休眠（禁用 Tick、停止动画更新与移动同步）。
2. 状态聚合：同类敌人共享计算/批量更新；AI 决策只在服务端计算，客户端只做表现层。
3. 网络：复制降频（NetUpdateFrequency/NetPriority）、Dormancy 自动唤醒、Iris/Replication Graph 控制复制可见性集合。
4. 服务器保留权威核心（血量、位置权威），客户端做预测表现，保证安全性前提下减少同步量。

考点： 显存治理、分级降级

参考答案：

1. 先分析各页池与 Pass 占用：Nanite 流送/Cluster 内存、Lumen 探针与追踪缓冲、VSM 页池。
2. 逐层降级而非全关：先降 Lumen 采样/追踪距离 → VSM 分辨率/投影体裁剪 → 降渲染分辨率/开超分 → 几何质量（Nanite 分级）；设多档画质档位。
3. 按平台与场景监控显存峰值，保留回退路径并复测 P95/1% low。

考点： 包体分析、资源管线

参考答案：

1. 用 Cook report / Asset Audit 按 chunk 与依赖闭包定位新增 8GB 的构成（哪些资源被间接 Cook）。
2. 逐项处理：贴图压缩/分辨率/是否可流送、音频编码（Vorbis/ADPCM）、冗余与重复资产、错误目录/Cook 规则、可选内容拆分为 Chunk/DLC。
3. 砍依赖闭包（无用硬引用、间接 Cook 大资源），设包体预算并在 CI 上监控，防止再次增长。
4. 具体分析工具与方法：
   • 依赖分析：右键资源 → Reference Viewer 可视化引用链；Asset Audit 窗口查看每个资源的大小与依赖数量；命令行 ue4editor-cmd.exe -run=AssetAudit 批量审计。
   • Cook 报告：Cook 时加 -cookreport 参数，输出每个 chunk 的资源清单与大小；检查 Saved/Cooked/ 目录下各平台资源大小分布。
   • 贴图格式检查：obj list class=Texture2D 查看已加载纹理，检查 Compression Settings 是否合理（移动端用 ASTC/ETC2，PC 用 BC7）；stat streaming 确认纹理是否需要流送。
   • 音频编码：检查音频资源的 Compression Quality 与格式（Vorbis 质量 4~6 即可，过高质量浪费空间）。
5. Cook 优化策略：
   • 设置 NeverCook 标记排除测试/调试资源；
   • 用 Asset Manager 的 Primary Asset Rules 控制哪些资源进哪个 chunk；
   • 可选内容（DLC、地图包）拆分为独立 Chunk，按需下载；
   • 检查目录规则：确保测试资源目录在 Cook 排除列表中。
6. 重复/冗余检测：Asset Validation 工具扫描重复内容（相同哈希的资源合并）；检查蓝图中硬引用了不该加载的资产。
7. 易错点：只看总包体而不分 chunk 定位；忽略间接依赖导致的"幽灵资源"；Cook 规则配置错误导致调试资源混入发行包。
8. 面试点评：考察对 UE 资源管线全链路的理解，能否系统性定位和治理包体膨胀。

考点： 复盘、置信区间、实验日志

参考答案：

1. 固定路线重复测量多次，看均值与置信范围排除测量噪声；核对是否真的命中了瓶颈（可能优化了非瓶颈环节）。
2. 检查改动是否引入回归（功能/画质变化、新增开销），确认目标场景是否代表真实负载。
3. 保留实验日志与对比基线，用同一统计口径复测；必要时回退部分改动做 A/B 对比定位。
4. 诊断流程：
   • Step 1：排除测量噪声 — 同一路线跑 10+ 次，计算均值/标准差/置信区间；若标准差 >5%，说明场景不稳定，需控制变量（关闭后台进程、固定分辨率等）。
   • Step 2：确认瓶颈定位 — 优化前是否用 stat unit/Insights 确认了瓶颈？如果 GPU 27ms 而你优化了 CPU，自然无收益；重新 profile 确认。
   • Step 3：检查引入的开销 — 新增的代码/资源是否带来了额外成本？如对象池初始化开销、新材质 Shader 编译、额外的 Tick/定时器。
   • Step 4：验证目标场景 — 测试场景是否代表真实玩家行为？如只测了空旷平原而玩家常在密集战斗场景。
5. 常见陷阱：
   • 优化了"显眼但非瓶颈"的环节（如花时间优化一个只占 1% 的函数）；
   • 并行化引入锁竞争反而更慢；
   • 降采样/降分辨率后 GPU 负载下降但 CPU 提交开销未变，总帧率不变；
   • PSO 缓存未预热导致首次运行比优化前更慢。
6. A/B 对比法：保留优化前/后两个分支，在相同条件下分别跑 10 次取中位数对比；用 Git Bisect 或 Feature Flag 切换。
7. 实验日志模板：日期、优化内容、目标瓶颈、测量环境、基线数据、结果数据、结论、是否回退。
8. 易错点：只跑一次就下结论；未控制测试环境导致噪声；优化后忘记重新 profile 确认实际收益。
9. 面试点评：考察科学的实验方法论和严谨的工程态度，能否系统性地分析"优化无效"的根因。

考点： 网络复制扩展性、迁移评估

参考答案：

1. 解决的问题：大规模对象复制时全量遍历/序列化成本高；Replication Graph 按可见性/兴趣网格裁剪复制集，Iris 重构复制对象模型提升序列化效率与确定性，适合大规模同屏/多人场景。
2. 收益：大规模场景下带宽与 CPU 显著下降；小规模项目收益有限，引入成本需权衡。
3. 迁移评估：压测带宽、兼容性（现有属性复制 API）、工具链（分析与调试）、线上观测（复制统计/延迟）；逐步灰度并保留回退方案。
4. 适用场景与规模判断：
   • Replication Graph 适合：MMO（数百同屏玩家）、大逃杀（100+ 玩家）、RTS（大量单位）；全量遍历成本 O(N²)，Graph 裁剪后降至 O(N×K)（K 为相关对象数）。
   • Iris 适合：需要确定性序列化的场景（如回放系统、竞技游戏）；序列化效率提升约 30~50%。
   • 小规模项目（<20 同屏）：收益有限，引入复杂度不划算。
5. 迁移步骤：
   • Step 1 — 评估现状：用 stat net/stat rep 基线当前复制 CPU/带宽开销；
   • Step 2 — 压测目标规模：在测试服模拟目标玩家数（如 200 人），记录复制开销；
   • Step 3 — 逐步迁移：先迁移低风险系统（如环境物体复制），验证稳定性；
   • Step 4 — 全量切换：高风险系统（角色、战斗）迁移，保留旧代码作为回退；
   • Step 5 — 线上观测：灰度发布，监控延迟/带宽/掉线率。
6. 风险评估清单：
   • 现有属性复制 API 是否兼容（GetLifetimeReplicatedProps 等）；
   • 调试工具是否就绪（NetLog、复制统计面板）；
   • 回放系统是否需要确定性（Iris 优势）；
   • 团队学习成本（新 API 的理解与排错能力）。
7. 易错点：只在小规模测试通过就上线上大规模；未保留回退方案导致线上问题无法快速恢复；忽略网络延迟与丢包对新系统的影响。
8. 面试点评：考察对大规模网络架构的理解，能否评估技术选型的风险与收益，具备工程化迁移思维。