1
// ===== CPU Timing 视图：最常用的分析入口 =====
2
//
3
// 打开 .utrace 文件后，左侧选择 "Timing Insights" → CPU Timing 面板：
4
//
5
// ① 顶部时间线：缩略图——整个 trace 文件的时间跨度
6
// ② 主时间线区域：
7
//    每一行 = 一个 CPU 核心（物理线程）
8
//    每个色块 = 一个 Trace Event（函数调用或自定义作用域）
9
//    色块长度 = 函数耗时（越长越慢）
10
//    色块颜色 = Timer 分组（同组同色）
11
//
12
// ③ 下方聚合面板：
13
//    "Timers" 标签页 → 按函数聚合的总耗时排序
14
//    "Calls" 列   → 调用次数——判断"单次慢"还是"调用太多"
15
//    "Incl" 列    → Inclusive Time（含子函数）——函数总耗时
16
//    "Excl" 列    → Exclusive Time（不含子函数）——函数自身逻辑耗时
17
//
18
// 分析工作流：
19
//   1. 按 Exclusive Time 排序 → 找到自身最慢的函数
20
//   2. 按 Inclusive Time 排序 → 找到调用链中最"重"的函数
21
//   3. 点击色块 → 查看调用栈 → 定位到具体代码行
22
//
23
// 面试标准答案：
24
//   "找到瓶颈 → 按 Excl 找自身慢的函数，按 Incl 找调用子树重的函数。
25
//    Excl 高 = 这个函数内部逻辑慢——要优化算法。
26
//    Incl 高但 Excl 低 = 它调用的子函数慢——顺着调用链往下找。"
27

28
// ---------- 编辑器中的快速 Trace ----------
29
//
30
// 不需要启动 Insights.exe——编辑器内置了简化的 Trace 控制：
31
//
32
// 控制台命令：
33
//   trace.start  default     → 开始录制（CPU+GPU+Frame）
34
//   trace.start  cpu,gpu,memory → 指定通道
35
//   trace.stop               → 停止录制，自动打开 .utrace 文件
36
//   trace.file               → 查看当前录制文件路径
37
//
38
// 快捷键：编辑器右下角 "Trace" 按钮 → Start / Stop

1
// ===== stat unit：性能分析的第一条命令 =====
2
//
3
// 在控制台（~）输入 `stat unit`，屏幕右上角显示四栏：
4
//
5
// ┌─────────────────────────────────────────────────────────┐
6
// │ Frame: 16.67ms   Game: 8.2ms   Draw: 5.1ms   GPU: 12.3ms │
7
// └─────────────────────────────────────────────────────────┘
8
//
9
// Frame：上一帧的总耗时（目标：16.67ms = 60fps / 33.33ms = 30fps）
10
// Game ：GameThread 耗时——逻辑脚本/AI/物理/动画
11
// Draw ：RenderThread 耗时——剔除/合批/生成渲染命令
12
// GPU  ：GPU 实际执行渲染命令的耗时（异步于 CPU）
13
//
14
// 瓶颈判断法则：
15
//   Game > Draw+GPU  → CPU 瓶颈（GameThread 绑死）
16
//   Draw > Game+GPU  → RenderThread 瓶颈（DrawCall 太多）
17
//   GPU  > Game+Draw → GPU 瓶颈（Shader 太复杂/分辨率太高）
18
//
19
// 面试标准答案：
20
//   "stat unit 的四栏分别对应三个线程：GameThread（逻辑）、
21
//    RenderThread（生成渲染命令）、GPU（执行渲染）。
22
//    最大的一栏就是当前瓶颈——优化它才能提升帧率。"
23

24
// ---------- stat unit 的变体 ----------
25
// stat unitgraph → 显示更详细的历史曲线图——看帧率趋势

1
// ===== stat 命令族：每个子系统都有专属监控 =====
2
//
3
// ┌─────────────────────┬────────────────────────────────────────┐
4
// │ 命令                  │ 显示内容                                  │
5
// ├─────────────────────┼────────────────────────────────────────┤
6
// │ stat unit            │ Frame / Game / Draw / GPU 四栏总览         │
7
// │ stat game            │ GameThread 细分——Tick/动画/物理/脚本耗时     │
8
// │ stat scenerendering  │ RenderThread 细分——剔除/合批/阴影/RHI       │
9
// │ stat gpu             │ GPU 各 Pass 耗时——BasePass/Shadow/Lighting │
10
// │ stat memory          │ 内存总览——Physical/OS/Streaming Pool        │
11
// │ stat fps             │ 帧率计数器                                  │
12
// │ stat levels          │ 关卡流送——当前加载了哪些 Level                │
13
// │ stat streaming       │ 资源流送——纹理/网格加载状态                  │
14
// │ stat slate           │ Slate UI 性能——Invalidation/Widget 数量     │
15
// │ stat engine          │ 引擎循环——World Tick / Network Tick         │
16
// │ stat physics         │ 物理模拟——活跃刚体数量/Chaos 耗时            │
17
// │ stat anim            │ 动画系统——AnimInstance 更新耗时              │
18
// │ stat ai              │ AI 系统——行为树/EQS 执行耗时                 │
19
// │ stat particles       │ 粒子系统——活跃粒子数                         │
20
// │ stat startfile       │ 开始录制 stat 数据到 .csv 文件                │
21
// │ stat stopfile        │ 停止录制                                    │
22
// └─────────────────────┴────────────────────────────────────────┘
23
//
24
// 实战工作流：
25
//   ① stat unit → 确定瓶颈线程（Game / Draw / GPU）
26
//   ② 瓶颈在 Game → stat game → 看 Tick/Anim/Physics 谁占最多
27
//   ③ 瓶颈在 GPU → stat gpu → 看哪个 Pass 最重
28
//   ④ stat startfile → 录制数据 → 导入 Excel/脚本做量化分析
29

30
// ---------- 编辑器中的快捷性能面板 ----------
31
//
32
// Ctrl+Shift+,  → 打开/关闭 GPU 可视化（GPU Visualizer）
33
// Ctrl+Shift+H  → 打开/关闭 Stat FPS
34
// 编辑器顶部 "Performance" 菜单 → 各类 stat 快捷开关

1
// ===== 性能优化的四条铁律 =====
2
//
3
// 铁律 1：先测量，后优化
4
//   ✗ "这个函数看起来慢，优化一下" → 浪费时间去优化没有瓶颈的代码
5
//   ✓ Insights trace → 按 Exclusive Time 排序 → 只优化前 5 个
6
//   经验：80/20 法则——80% 的耗时由 20% 的代码产生
7
//
8
// 铁律 2：一次只改一个变量
9
//   ✗ "同时改了对象池 + 异步加载 + 减少 Tick" → 不知道哪个有效果
10
//   ✓ 只做一处修改 → 对比 trace → 记录变化 → 再改下一个
11
//
12
// 铁律 3：用数据说话，不用直觉
13
//   ✗ "我觉得 Tick 太慢了" → 可能 Tick 只占 5%
14
//   ✓ "stat game 显示 Tick_Actor 占 42%，Incl Time 8.3ms"
15
//
16
// 铁律 4：Dev 测准，Shipping 验证
17
//   ✗ 只在编辑器（PIE）中测性能——编辑器额外开销（Stats/Editor UI）误导结论
18
//   ✓ 最终验证必须在 Development 或 Test 构建中进行
19
//   ✓ Development 构建保留 stat 命令但去掉编辑器开销
20

21
// ---------- 基准测试代码模板 ----------
22
void BenchmarkOptimization()
23
{
24
    // ① 优化前——记录基线
25
    double BeforeTime = FPlatformTime::Seconds();
26

27
    // ... 需要测量的代码逻辑 ...
28

29
    double ElapsedMs = (FPlatformTime::Seconds() - BeforeTime) * 1000.0;
30
    UE_LOG(LogTemp, Log, TEXT("Elapsed: %.2f ms"), ElapsedMs);
31

32
    // ② 应用优化 → 重新运行 → 对比
33
    // ③ 用 Insights trace 确认不仅这段代码变快了，
34
    //    而且没有引入新的瓶颈（比如 GC 时间增加）
35
}

1
// ===== 60fps 性能预算（16.67ms/帧）=====
2
//
3
// 典型分配（AAA 游戏参考）：
4
//   GameThread  : ~8ms   (逻辑 / Tick / AI / 物理 / 动画)
5
//   RenderThread: ~5ms   (剔除 / 提交 DrawCall)
6
//   GPU         : ~12ms  (渲染执行——与 CPU 并行)
7
//   余量         : ~3ms   (应对突发——爆炸/场景切换)
8
//
9
// 30fps 性能预算（33.33ms/帧）：
10
//   同上比例 × 2——但通常 GPU 是主要瓶颈（光照/阴影/后处理）
11
//
12
// 关键认知：GameThread 和 RenderThread 是串行的——
13
//   Game 8ms + Draw 5ms = CPU 侧总耗时 13ms，留给 GPU 只有 3.67ms
14
//   但 GPU 渲染与 CPU 并行的——CPU 送命令到命令队列后继续下一帧
15
//   GPU 慢 → CPU 等（GPU 绑死）→ Frame 时间 = GPU 时间

1
// ===== 陷阱 #1：Tick 滥用 —— 最多的性能杀手 =====
2
//
3
// 症状：stat game 显示 Tick 占 40%+
4
// 根因：太多 Actor 每帧执行 Tick，但绝大多数帧什么都不需要做
5

6
// ✗ 坏模式——所有逻辑都在 Tick 里
7
class ABadTickActor : public AActor
8
{
9
    virtual void Tick(float DeltaTime) override
10
    {
11
        Super::Tick(DeltaTime);
12

13
        // 每帧检查——但距离 99.99% 的帧中玩家都在 1000 米外
14
        float Distance = FVector::Dist(GetActorLocation(), Player->GetActorLocation());
15
        if (Distance < 200.0f)
16
        {
17
            Activate();
18
        }
19
    }
20
};
21

22
// ✓ 好模式 1：用 Timer 替代高频 Tick
23
class AGoodTimerActor : public AActor
24
{
25
    virtual void BeginPlay() override
26
    {
27
        Super::BeginPlay();
28
        // 每 0.5 秒检查一次——而非每帧（60 次/秒 → 2 次/秒）
29
        GetWorldTimerManager().SetTimer(
30
            CheckTimer,
31
            this,
32
            &AGoodTimerActor::CheckDistance,
33
            0.5f,
34
            true   // 循环
35
        );
36
    }
37

38
    void CheckDistance()
39
    {
40
        // 和上面相同的逻辑——但调用频率降低了 30 倍
41
    }
42

43
    FTimerHandle CheckTimer;
44
};
45

46
// ✓ 好模式 2：用 Trigger 体积替代距离检测
47
// 不需要任何 Tick——引擎碰撞系统自动检测进入/离开。
48
// 在 BeginOverlap / EndOverlap 中处理逻辑。
49

50
// ✓ 好模式 3：完全禁用不必要 Tick 的组件
51
void DisableUnusedTicks()
52
{
53
    // 静态网格体——不需要 Tick
54
    StaticMeshComp->SetComponentTickEnabled(false);
55

56
    // 减少 Tick 频率——每 5 帧执行一次
57
    MovementComp->SetComponentTickInterval(5.0f / 60.0f);
58

59
    // Actor 级别禁用
60
    SetActorTickEnabled(false);
61
    // 需要时重新启用：SetActorTickEnabled(true);
62
}

1
// ===== 陷阱 #2：蓝图/C++ 边界 —— 跨 VM 调用的隐藏成本 =====
2
//
3
// 症状：stat game 中 Blueprint VM 占比异常高
4
// 根因：蓝图每帧调用 C++ 函数，或 C++ 每帧调用蓝图事件
5
// 开销：每次跨 VM 调用 ~0.001~0.01ms（参数编排 + 虚拟机栈操作）
6
//       单独看不严重——但 1000 次/帧 × 0.005ms = 5ms = 帧率从 60 → 46
7

8
// ✗ 坏模式——C++ 每帧调用蓝图函数
9
class ABadBoundary : public AActor
10
{
11
    virtual void Tick(float DeltaTime) override
12
    {
13
        // 每帧调用 BlueprintImplementableEvent——频繁跨 VM
14
        OnTick_BP();  // ★ 每次调用都在穿越蓝图虚拟机边界
15
    }
16

17
    UFUNCTION(BlueprintImplementableEvent)
18
    void OnTick_BP();  // 蓝图实现——C++ → 蓝图调用
19
};
20

21
// ✓ 好模式 1——把循环逻辑全部搬到 C++ 侧
22
class AGoodBoundary : public AActor
23
{
24
    virtual void Tick(float DeltaTime) override
25
    {
26
        // C++ 中做完所有计算
27
        CalculateTransform(DeltaTime);
28

29
        // 只在状态变化时通知蓝图——而非每帧
30
        if (bStateChanged)
31
        {
32
            OnStateChanged_BP();
33
            bStateChanged = false;
34
        }
35
    }
36

37
    void CalculateTransform(float DeltaTime)
38
    {
39
        // 纯 C++——零 VM 开销
40
    }
41
};
42

43
// ✓ 好模式 2——蓝图用 Event 驱动，不用 Tick
44
// 蓝图侧：用 Event Dispatcher / Custom Event 替代 Event Tick
45
// C++ 侧：只在必要时调用蓝图——见上面代码

1
// ===== 陷阱 #3：GC 抖动 —— UObject 高频创建/销毁 =====
2
//
3
// 症状：stat memory 中 UObject 数量剧烈波动，每几秒一次 GC 卡顿
4
// 根因：在 Tick / 循环中创建临时 UObject，GC 频繁触发清扫
5
// 开销：一次完整的 GC 清扫可能耗时 5~50ms——在 60fps 下就是 1~3 帧的卡顿
6

7
// ✗ 坏模式——每帧创建 UObject
8
class ABadGCActor : public AActor
9
{
10
    virtual void Tick(float DeltaTime) override
11
    {
12
        // 每帧创建新的 UObject → GC 压力爆炸
13
        UMyDataObject* TempData = NewObject<UMyDataObject>();
14
        TempData->Process();
15
        // TempData 离开作用域 → 成为垃圾 → 等 GC 回收
16
        // 1000 个这样的对象/帧 → GC 每 10 秒触发一次完整清扫
17
    }
18
};
19

20
// ✓ 好模式 1：用 F 结构体替代（值类型——无 GC）
21
struct FMyData  // ★ F 前缀——纯 C++ 结构体，不参与 GC
22
{
23
    int32 Value;
24
    float Time;
25

26
    void Process() const { /* ... */ }
27
};
28

29
class AGoodNoGC : public AActor
30
{
31
    virtual void Tick(float DeltaTime) override
32
    {
33
        FMyData TempData;  // 栈分配——零 GC 开销
34
        TempData.Process();
35
    }
36
};
37

38
// ✓ 好模式 2：对象池——复用 UObject
39
class UObjectPool
40
{
41
    TArray<UMyDataObject*> Pool;
42

43
    UMyDataObject* Acquire()
44
    {
45
        if (Pool.Num() > 0)
46
            return Pool.Pop();      // 复用已存在的对象
47
        return NewObject<UMyDataObject>();  // 池耗尽——才创建新的
48
    }
49

50
    void Release(UMyDataObject* Obj)
51
    {
52
        Obj->Reset();
53
        Pool.Add(Obj);  // 归还到池——不销毁
54
    }
55
};
56

57
// ✓ 好模式 3：用 TWeakObjectPtr + 定期清理——减少 GC 根集

1
// ===== 陷阱 #4：构造脚本（Construction Script）中做重操作 =====
2
// ✗ 在构造函数或 Construction Script 中同步加载资源
3
// → 编辑器每次移动 Actor 都会触发 Construction Script
4
// → 编辑器卡死
5
// ✓ Construction Script 应该极轻——只做参数计算的视觉效果更新
6

7
// ===== 陷阱 #5：同步加载——LoadObject 卡主线程 =====
8
// ✗ 在 Tick 或 BeginPlay 中同步加载
9
void BadSyncLoad()
10
{
11
    USkeletalMesh* Mesh = LoadObject<USkeletalMesh>(
12
        nullptr, TEXT("/Game/Characters/Boss.Boss"));
13
    // 这个 Mesh 的依赖链可能有数百个对象 → 卡住主线程 100~500ms
14
}
15
// ✓ 使用 FStreamableManager 异步加载
16
void GoodAsyncLoad()
17
{
18
    FStreamableManager& Streamable = UAssetManager::GetStreamableManager();
19
    Streamable.RequestAsyncLoad(
20
        FSoftObjectPath(TEXT("/Game/Characters/Boss.Boss")),
21
        FStreamableDelegate::CreateUObject(this, &AMyActor::OnMeshLoaded)
22
    );
23
    // 主线程不阻塞——加载完成后回调 OnMeshLoaded
24
}
25

26
// ===== 陷阱 #6：属性网络复制过载 =====
27
// ✗ 把所有属性标记为 Replicated，且没有条件过滤
28
// → 每帧网络带宽被无关属性变化占满
29
// ✓ 使用 DOREPLIFETIME_CONDITION(ClassName, Property, COND_OwnerOnly)
30
//   或自定义 Replication Condition
31

32
// ===== 陷阱 #7：每帧重建 Widget =====
33
// ✗ 在 Tick 中 AddToViewport / RemoveFromParent 或完全重建 UI
34
// → Slate 层每帧 Layout → Paint → 大量 Invalidation
35
// ✓ 用数据绑定更新现有 Widget 的属性——而非重建整个控件树

1
// ===== Slate 性能：理解 Invalidation 是核心 =====
2
//
3
// Slate 的渲染流程：
4
//   ① 每帧：比较新旧 Widget 状态 → 标记"脏"区域（Invalidation）
5
//   ② 只重绘脏区域——其余部分复用上一帧的缓存
6
//
7
// 性能问题的根源：
8
//   太多 Widget 每帧都在"变脏" → Invalidation 区域覆盖全屏 → 等同于全屏重绘
9
//
10
// 常见触发 Invalidation 的操作：
11
//   - 修改 Widget 的 Visibility
12
//   - 修改 Text 的值（即使没变化也触发）
13
//   - 改变 Brushes 的颜色
14
//   - AddToViewport / RemoveFromParent
15

16
// ---------- Slate 优化 checklist ----------
17
//
18
// ✓ 使用 SInvalidationPanel 包裹频繁更新的区域
19
//   SInvalidationPanel 将子控件缓存在单独的 RenderTarget 中
20
//   只有子控件真正变化时才重新绘制——其余帧直接复用缓存
21
//
22
// ✓ 使用事件驱动（Event-Driven）替代轮询——现代 UE UI 唯一正统规范
23
//   ★ 绝对禁止 .Text_Lambda() / .Text_UObject() 等动态绑定轮询！
24
//     原理：Lambda 绑定会在每帧强制 UI 线程执行表达式去嗅探数值是否改变，
25
//     几百个 Lambda = UI 线程卡死；更致命的是，动态绑定会彻底瘫痪
26
//     SInvalidationPanel 的缓存——引擎无法预测 Lambda 结果何时变化，
27
//     只能每帧将该区域判定为脏区 → 全屏重绘风暴（Invalidation Flood）。
28
//   ✓ 正确做法：控件始终保持静止（Volatile = false），
29
//     数据层在数值真正改变时派发事件 → 显式、主动调用一次 SetText() 精准刷新
30
//
31
// ✓ 批量修改属性——合并多次连续修改为一次
32
//   Widget->SetVisibility(...) → 每次调用触发一次 Invalidation
33
//   如果需要在同一帧中修改多个属性 → 批量修改并手动调用 Invalidate
34
//
35
// ✓ 避免在 ScrollBox 中创建大量子 Widget
36
//   使用 SListView / STreeView —— 它们虚拟化（只创建可见行的 Widget）
37
//
38
// ✓ 离线 Pre-Construct 复杂 Widget
39
//   在非关键帧构建 Widget 树——而非在玩家交互的瞬间

1
// ===== RenderDoc：GPU 逐帧剖析的工业级工具 =====
2
//
3
// 用途：捕获一帧的所有 GPU 命令——逐 DrawCall 查看
4
// 下载：https://renderdoc.org/（免费开源）
5
// 集成：UE 编辑器 → Plugins → RenderDoc → Enabled
6
//
7
// 基本工作流：
8
//   ① 启动编辑器 → RenderDoc 自动附加
9
//   ② 在 RenderDoc 界面点击 "Capture" → 回到编辑器 → 渲染一帧 → F12
10
//   ③ 回到 RenderDoc → 分析捕获的帧
11
//
12
// 关键分析面板：
13
//   Event Browser：列出所有 DrawCall + Dispatch（按提交顺序）
14
//   Texture Viewer：查看任何中间渲染目标的内容
15
//   Pipeline State：查看某个 DrawCall 的完整管线状态
16
//   Mesh Viewer：查看某个 DrawCall 的几何体
17
//
18
// GPU 耗时分析：
19
//   展开 Event Browser → 找一个耗时长的 DrawCall
20
//   → 查看用了哪个 Shader（Shader Complexity 高不高？）
21
//   → 查看 Render Target 是不是超大分辨率（全屏 Pass 还是小范围？）
22
//   → 查看 Mesh 是不是面数爆炸（一个 DrawCall 画了 100 万三角面？）
23

24
// ---------- RenderDoc 与 stat gpu 的配合 ----------
25
//
26
// stat gpu → 找到哪个 Pass 最重 → RenderDoc 中定位该 Pass
27
// stat scenerendering → 找到哪个 Mesh/材质 DrawCall 数量异常
28
// 结合 Insights CPU trace → 确认瓶颈在 GPU 而非 CPU 提交

1
// ===== 陷阱 #1：在没有性能数据的情况下"优化" =====
2
// ✗ "我觉得这里慢了" → 优化了一个只占 2% 帧时间的代码
3
// ✓ Insights trace → 按 Excl Time 排序 → 只碰前 5 个
4

5
// ===== 陷阱 #2：在 PIE（Play In Editor）中做性能结论 =====
6
// ✗ PIE 中有编辑器开销（Stats 面板/Editor UI/蓝图调试器）
7
//   → 实际 Shipping 包的帧率可能快 20~40%
8
// ✓ 用 Standalone Game 模式或 Development 构建做最终验证
9

10
// ===== 陷阱 #3：用 FPS 代替帧时间做性能指标 =====
11
// ✗ "优化后 FPS 从 60 涨到 65" → 看起来只提升了 8%
12
//   实际上：16.67ms → 15.38ms = 节省了 1.29ms——在 60fps 以下影响巨大
13
// ✓ 永远用帧时间（ms）做性能度量——不要用 FPS
14

15
// ===== 陷阱 #4：关闭了 Tick 但没关闭 Component Tick =====
16
// ✗ SetActorTickEnabled(false) —— 但子组件仍然在 Tick
17
//   → UActorComponent::TickComponent 每帧都在执行
18
// ✓ 逐组件检查：Comp->SetComponentTickEnabled(false)
19

20
// ===== 陷阱 #5：在 Shipping 中保留 stat 命令的调试代码 =====
21
// ✗ #if !UE_BUILD_SHIPPING 作用域外的性能统计代码
22
//   → 即使不显示 UI，代码仍在执行
23
// ✓ 所有 SCOPE_CYCLE_COUNTER / stat 相关代码放在条件编译中
24

25
// ===== 陷阱 #6：用 ensure 做高频路径的性能监控 =====
26
// ✗ 每帧调用 ensure() —— 即使不失败，表达式求值 + 条件分支也有开销
27
//   尤其是 ensureAlways——每次都记录日志
28
// ✓ 高频路径用计数器 + 定期上报——而非每次都走断言分支

1
Q: "游戏卡顿了，你怎么排查？完整的工作流是什么？"
2
A: ① stat unit → 确认瓶颈线程（Game/Draw/GPU 谁最大）。
3
   ② Insights trace → 录制关键场景的 utrace 文件 → 按 Excl Time 排序定位具体函数。
4
   ③ 如果 GPU 瓶颈 → stat gpu + RenderDoc 捕获一帧 → 找最重的 DrawCall/Pass。
5
   ④ 如果内存波动 → stat memory → 检查 UObject 数量是否持续增长（GC 抖动）。
6
   ⑤ 定位到具体代码 → 套用对应修复方案（Tick→Timer、对象池、异步加载…）。
7
   ⑥ 修复后重新 trace → 对比优化前后的 Exclusive Time → 确认有效。
8

9
Q: "Tick 太多了怎么办？有哪些替代方案？"
10
A: ① Timer：SetTimer 替代高频轮询——0.5s 检查一次而非每帧。
11
   ② Event 驱动：Trigger 体积 / 委托 / GameplayEvent——只在事件发生时响应。
12
   ③ 降频：SetComponentTickInterval(0.1f) → 每秒 10 次而非 60 次。
13
   ④ 禁用不活动的 Actor：SetActorTickEnabled(false) + 距离/可见性判断。
14
   ⑤ 蓝图→C++：关键路径上用 C++ 实现——避免蓝图虚拟机开销。
15
   ⑥ LOD：远处 Actor 完全禁用 Tick。
16

17
Q: "GC 卡顿怎么排查和优化？"
18
A: 排查：stat memory → 看 UObject 数量是否剧烈波动。
19
   根因：每帧创建/销毁大量 UObject → GC 频繁触发完整清扫。
20
   优化：① 用 F 前缀结构体替代临时 UObject（栈分配——零 GC）。
21
   ② 对象池（ObjectPool）——复用而非新建。
22
   ③ TWeakObjectPtr——不增加 GC 根集引用计数。
23
   ④ 减少 UPROPERTY 标记的引用——每个都增加 GC 扫描负担。
24
   ⑤ GC 参数调优——Project Settings → Engine → Garbage Collection 中的
25
    //   Maximum Number of Objects 等核心配置项（对应 ini 中的 gc.MaxObjects）；
26
    //   ⚠️ "gc.MaxObjectsInEditor" / "gc.MaxObjectsInGame" 是虚构的幻觉 CVar——不存在。
27
   // ★ gc. 是 GC 系统前缀——不是 r.（渲染器）或 s.（仿真系统）