一、Tick 的性能本质：为什么每帧执行是杀手

Event Tick 在 UE 引擎里的"成本"由三个维度构成：

1.1 调度成本（Scheduling Cost）

UE 每帧都要遍历所有"启用了 Tick"的 Actor，调用它们的 Tick 函数。N 个 Tick Actor 每帧多约 N × 0.001ms 的调度开销。1000 个 Tick Actor 每帧仅调度就吃掉 1ms，这是隐形但真实的成本。

1.2 执行成本（Execution Cost）

Tick 函数体里的节点执行成本。一个简单 Set 节点 ≈ 0.001ms，一个 Cast ≈ 0.005ms，一个 SpawnActor ≈ 0.5ms。50 个 Actor 各自 Tick 里做一次 Spawn，帧时间立刻爆炸。

1.3 GC 压力（Garbage Collection Pressure）

Tick 频繁 Spawn / Destroy Actor 会制造大量"待回收"对象，触发 GC 时帧时间会"卡一下"。对 60 FPS 游戏，30ms 的 GC 停顿就是掉 1–2 帧。

⚠️ 一个直观的性能账本：假设你的独立游戏有 100 个敌人 AI，每个敌人 Tick 里做一次"距离玩家检测 + 状态机更新"。1 帧的执行时间约 0.05ms × 100 = 5ms / 帧。对 60 FPS 目标（每帧 16.67ms），敌人 AI 就吃掉了 30% 的帧预算。这还没算物理、动画、渲染。

二、Tick 五大替代方案完整对比

幸运的是，大多数 Tick 行为都不需要真的每帧执行。以下五种替代方案覆盖 90% 的优化场景：

2.1 Timer 替代方案详解

把"每帧检测玩家距离"改为"每 0.5 秒检测一次玩家距离"。设置 Set Timer by Event 的 Time 为 0.5s、Looping 为 true。性能提升 30 倍（60FPS → 2 次/秒），玩家几乎感觉不到差异。

2.2 事件驱动方案详解

把"每帧检测血量"改为"血量变化时更新 UI"。用 RepNotify 或自定义事件触发更新。99% 的帧不做 UI 更新，性能差距达 50–100 倍。

2.3 Behavior Tree 方案详解

敌人 AI 决策本质是"思考 → 选择动作 → 执行"循环。UE 的 Behavior Tree 系统已经为 AI 优化过调度：用 Selector 节点 + Service 节点 + Decorator 节点构建决策流，比在 Tick 里手写状态机高效得多。

2.4 Async Task 方案详解

对于"复杂数学计算 / 文件 I/O / 网络请求"等需要跨多帧完成的任务，Async Task 是标准解。常见场景：

• 大文件加载（关卡、纹理、音频）。
• 网络请求（Steam API、HTTPS 接口）。
• 复杂计算（路径规划、噪声生成、AI 决策树）。

2.5 Tick 间隔方案详解

UE 提供 "Set Actor Tick Interval" 节点，让 Tick 不再是每帧执行，而是每 N 秒 / N 帧执行一次。最简单、最直接的优化手段，适合"我必须 Tick，但不需要每帧 Tick"的场景。

三、Actor Tick 分组：物理前/中/后的执行顺序

UE 把 Actor 的 Tick 划分为 4 个组（Tick Group），每组在一个明确的时间点执行：

3.1 为什么要分组

默认情况下所有 Actor 都在 TG_PrePhysics，可能造成：

• 角色移动 Tick 完成后，下游的相机 Tick 才能读最新位置，造成逻辑滞后。
• 物理模拟基于"半新不旧"的数据。

3.2 实战分组策略

• 输入 / AI / 移动：TG_PrePhysics。
• 物理交互对象：TG_PrePhysics（前置）或 TG_PostPhysics（后置响应）。
• 相机跟随、后期处理：TG_PostUpdateWork（确保读最新位置）。

四、对象池：Spawn 与 Destroy 的优化

频繁 Spawn / Destroy Actor 是 GC 压力的主要来源。对象池（Object Pool）模式是经典解决方案：

4.1 核心思想

不销毁对象，而是"停用"它（SetActorHiddenInGame、SetActorEnableCollision、SetActorTickEnabled 全部 false），需要时重新"激活"。

4.2 适用场景

• 子弹、特效、伤害飘字等高频短生命对象。
• 敌人 AI 的"小怪"（Boss 数量少可不用）。
• 音效、粒子系统的 Spawn 节点。

4.3 简易对象池蓝图实现

独立游戏常用的"伤害飘字对象池"：

1. 关卡开始时 Spawn 50 个 DamageNumber 蓝图，存到 Array。
2. 需要显示时从 Array 取一个未激活的，SetActorLocation + 触发"显示飘字"自定义事件。
3. 飘字动画结束后 SetActorHiddenInGame + 标记为"可用"。

4.4 性能收益

实测对比：每帧 Spawn 10 个飘字 vs 对象池复用，GC 触发频率从每 5 秒一次降到每 30 秒一次，帧时间方差降低 40%。

五、LOD 与距离剔除：空间激活管理

UE 提供多种"空间激活"机制，让远处或不可见的对象不消耗 Tick 成本：

5.1 Distance Culling（距离剔除）

在 Actor 蓝图里用 SetActorTickEnabled + 距离判断，实现"远距离停止 Tick"逻辑。常见做法：

• 玩家周围 50 米内：所有敌人 AI 完整 Tick。
• 50–200 米：AI 切换到 1 秒间隔 Tick 或完全停止。
• 200 米外：完全 Disable Tick。

5.2 Level Streaming（关卡流式加载）

把大型关卡拆分为多个 Sub-Level，根据玩家位置流式加载 / 卸载。未加载的 Sub-Level 中所有 Actor 不消耗任何 Tick 成本，这是开放世界游戏的标配。

5.3 Cull Distance Volume（剔除距离体）

UE 内置的体素级剔除控制。关卡设计师可以在关卡里放置 Cull Distance Volume，超过设定距离的同类 Actor 一次性剔除。常见做法：

• 小石头、草、装饰物：50 米剔除。
• 中距离敌人：200 米剔除。
• 大型敌人 / Boss：1000 米剔除。

5.4 LOD 与蓝图 Tick

Skeletal Mesh 自带 LOD 系统（详细、中等、低模）。蓝图 Tick 也可以"按 LOD 分级"：

• 高 LOD：完整 AI 决策 + 完整动画状态更新。
• 中 LOD：仅做关键动画更新，AI 简化为"巡逻 → 攻击"。
• 低 LOD：完全不 Tick，仅播放 Idle 动画。

六、Unreal Insights：性能诊断工具链

UE 5 之后，Unreal Insights 取代了旧的 stat 命令，成为官方推荐的蓝图性能分析工具。

6.1 Insights 能做什么

• 帧时间分析：每帧在 Game Thread / Render Thread / GPU 上的耗时分解。
• Tick 热点：列出每帧所有 Tick Actor 的耗时排序，快速定位"最贵的几个 Tick"。
• 资产加载分析：追踪纹理、网格、关卡的加载时机与卡顿。
• 网络包分析：多人游戏下追踪 RPC 与包大小。

6.2 性能分析工作流

1. 在编辑器里运行 "Trace" 模式（带 Insights 分析的启动）。
2. 复现掉帧场景。
3. 停止后用 Insights 打开 trace 文件，定位"哪几个 Actor 占用了最多帧时间"。
4. 针对性优化（关闭 Tick、降低频率、改事件驱动）。
5. 重新 Trace，对比优化效果。

6.3 蓝图级 Stat 命令

快速定位问题时可用控制台命令：

• stat game：显示游戏线程总帧时间。
• stat unit：综合显示 Game / Draw / GPU 时间。
• stat blueprint：列出当前 Tick 蓝图耗时排序。
• stat startfile / stat stopfile：手动录制一段性能数据。

七、案例：一个独立游戏场景的优化全流程

Xmohe 联合一款 2.5D 独立 ARPG 项目，做过一次完整的"100 敌人战斗场景"性能优化。优化前的数据：

7.1 优化前状态

• 100 个敌人 AI，每帧 Tick，帧时间 38ms（25 FPS）。
• GC 频繁触发，平均每 8 秒一次 50ms 停顿。
• 玩家体验：明显卡顿，移动操作不跟手。

7.2 优化步骤（按 ROI 排序）

1. 第一步：远距离 AI 关闭 Tick。50 米外敌人 Disable Tick。帧时间 38ms → 24ms。
2. 第二步：把"每帧距离检测"改为 Timer 0.3 秒。帧时间 24ms → 19ms。
3. 第三步：Behavior Tree 替换手写状态机。50 个 AI 共享 BT，调度成本下降。帧时间 19ms → 16ms。
4. 第四步：子弹 / 飘字改对象池。GC 触发频率从 8s 一次降到 40s 一次。
5. 第五步：装饰物用 Cull Distance Volume 剔除。50 米外的小石头、草完全不再渲染。

7.3 优化后状态

• 帧时间 38ms → 16ms（从 25 FPS 提升到 60 FPS）。
• GC 停顿 8s → 40s（卡顿感消失）。
• 玩家体验：从"明显卡顿"到"流畅战斗"。

核心经验：优化 100 个敌人 AI 的 成本不是"重写"或"换引擎"，而是"5 个简单调整"。这 5 个调整都不需要重写游戏逻辑，只需要切换实现方式。独立游戏性能优化的 80% 收益来自"模式选择"，20% 来自"代码优化"。

八、初级用户：性能优化 10 条铁律

1. 默认禁用 Tick。新建 Actor 蓝图时，把 Tick 关掉。需要时再打开。
2. 用 Set Tick Interval 而非默认 0。需要 Tick 时设置合理间隔（0.1–0.5 秒）。
3. 用 Timer 替代高频 Tick。需要周期性检测时，Timer 是首选。
4. 用事件驱动替代每帧检测。状态变化才更新，否则不调用。
5. SpawnActor 后立刻考虑对象池。同一类对象频繁 Spawn 时。
6. 关闭远处的 AI Tick。用距离判断 + SetActorTickEnabled。
7. 不要在 Tick 里调 Print String。调试完一定删除。
8. 不要在 Tick 里做 Get All Actors Of Class。缓存引用或订阅事件。
9. 装饰物用 Cull Distance Volume。别让远距离小石头白白消耗 Tick。
10. 每次发版前跑一次 Insights。建立性能基线，及早发现回退。

九、中级用户：性能预算与团队规范

对中型独立游戏（≥ 5 人团队），建议建立性能预算（Performance Budget） 制度：

9.1 帧时间预算分配模板（60 FPS 目标）

9.2 团队级性能规范模板

建议在项目早期就写下并维护这份规范：

• 新 Actor 默认 Tick Off。需要 Tick 时必须写注释说明原因。
• AI 决策频率 ≤ 0.3 秒。任何更频繁的 AI 决策需主程 review。
• SpawnActor 频率 ≤ 5 次 / 秒 / 系统。超额需使用对象池。
• 装饰物、远景必须有 Cull Distance。关卡设计师负责配置。
• 每次重大功能上线前跑 Insights。性能回退 ≥ 10% 需立即修复。
• Print String 必须带 Once / Duration 限制。调试代码不允许无限输出。

9.3 性能优化的"投入产出"原则

中级工程师面对性能问题时，第一反应应该是"改变实现模式"，而非"优化现有代码"。理由：

• 关闭 Tick 1 行代码的收益 = 优化 100 行 Tick 函数体。
• 用 Timer 替代 Tick 5 行代码的收益 = 重写整套状态机。
• 用对象池替代 Spawn 10 行代码的收益 = 调优 GC 配置。

性能优化最常见的误区是"在错误的层面优化"。架构选择 > 算法选择 > 代码细节。这是 Xmohe 反复在独立游戏项目里验证的经验。