目录
前言：性能不是“最后一步”，而是“每一步”
第一章：性能问题的三大表象
1.1 渲染开销失控
1.2 物理模拟成本飙升
1.3 游戏逻辑本身太慢
第二章：为何“等硬件升级”不再可行？
第三章：传统 Unity 代码变慢的六大根源
3.1 垃圾回收（GC）引发卡顿
3.2 编译器生成的代码不够优化
3.3 多核 CPU 未被充分利用
3.4 数据结构对缓存不友好（Cache Unfriendly Data）
3.5 代码执行对缓存不友好（Cache Unfriendly Code）
3.6 过度抽象导致性能弥散
第四章：Unity 项目中的典型反模式
前言：性能不是“最后一步”，而是“每一步”
在游戏开发中，一个残酷的现实是：你的游戏可能在高端 PC 上运行流畅，却在目标用户手中的低端手机上卡顿不堪。帧率骤降、加载漫长、穿门冻结……这些问题不仅毁掉玩家体验，更会直接扼杀你添加新功能的可能性——更多角色？更大场景？更复杂的物理？统统被性能红线挡在门外。
过去，开发者可以依赖“摩尔定律”坐等硬件进步。但今天，单核性能增长停滞、设备碎片化加剧、多核成为标配，传统的 Unity 开发模式已显疲态。
而DOTS（Data-Oriented Technology Stack） 正是 Unity 为应对这一挑战推出的全新高性能架构。但在深入 DOTS 之前，我们必须先理解：为什么我们熟悉的 C# + MonoBehaviour 模式会成为性能瓶颈？
本文作为 DOTS 系列教程的开篇，将系统剖析传统 Unity 项目的六大性能陷阱，为后续学习 DOTS 的解决方案打下坚实基础。
第一章：性能问题的三大表象
1.1 渲染开销失控
许多项目的性能问题首先暴露在渲染层面：
- 贴图分辨率过高；
- 网格顶点数量庞大；
- Shader 计算复杂；
- 批处理（Batching）、剔除（Culling）和 LOD 使用不当。
这些都会显著增加 GPU 和 CPU 负担，尤其在移动平台表现尤为严重。
1.2 物理模拟成本飙升
过度使用Mesh Collider（网格碰撞体） 是另一个常见错误。相比简单的盒形或球形碰撞体，Mesh Collider 会极大增加物理引擎的计算复杂度，导致每帧耗时激增。
1.3 游戏逻辑本身太慢
最隐蔽也最关键的瓶颈，往往藏在你引以为豪的 C# 代码中。那些定义了游戏独特玩法的核心逻辑，可能每帧都在消耗数十毫秒的 CPU 时间——这在 60 FPS（每帧约 16.7ms）的目标下是不可接受的。
第二章：为何“等硬件升级”不再可行？
从 1970 年代到 21 世纪初，CPU 单线程性能大约每 18～24 个月翻倍（即摩尔定律），游戏会“自动变快”。但近二十年来，单核性能提升已趋于平缓，取而代之的是多核化趋势：
- 如今即便是千元智能手机，也普遍配备 4～8 个 CPU 核心；
- 高低端设备性能差距持续拉大，大量玩家仍在使用 2～3 年前的旧设备。
因此，“等待更快硬件”已不再是可行策略。我们必须主动写出更高效、更贴近硬件的代码——而这正是 DOTS 的出发点。
第三章：传统 Unity 代码变慢的六大根源
3.1 垃圾回收（GC）引发卡顿
C# 的垃圾回收机制虽简化了内存管理，却在游戏循环中埋下隐患：
- 每次
new临时对象（如Vector3、字符串、List）都会增加 GC 压力； - GC 触发时可能暂停主线程数毫秒至数十毫秒，表现为画面卡顿或掉帧。
💡 虽然开发者常用“对象池”缓解此问题，但这本质上是在绕过语言设计初衷，治标不治本。
3.2 编译器生成的代码不够优化
Unity 编辑器默认使用Mono 编译器，其优化能力有限。虽然发布版本可启用IL2CPP（将 C# 中间语言转为 C++ 再编译）以获得更好性能，但代价是构建时间变长、Mod 支持困难。
3.3 多核 CPU 未被充分利用
尽管设备普遍具备多核，但 Unity 默认将几乎所有逻辑塞进主线程：
Update()、FixedUpdate()等 MonoBehaviour 生命周期方法仅在主线程执行；- 绝大多数 Unity API 不支持多线程调用。
结果？其他 CPU 核心闲置，无法横向扩展性能。
3.4 数据结构对缓存不友好（Cache Unfriendly Data）
现代 CPU 严重依赖高速缓存（Cache）。若数据在内存中分散存放，CPU 将频繁遭遇缓存未命中（Cache Miss），不得不等待数百个时钟周期从主存读取数据。
✅ 最缓存友好的方式：紧凑、连续的数组（如
float[]或NativeArray<T>），实现顺序访问。
3.5 代码执行对缓存不友好（Cache Unfriendly Code）
函数代码本身也需要从内存加载到指令缓存。如果某个函数在帧内被零散调用多次（如分散在不同系统的 Update 中），其机器码会被反复加载。
✅ 优化策略：集中批量调用。例如，统一更新所有怪物，而非逐个调用其
Update()。
3.6 过度抽象导致性能弥散
面向对象编程（OOP）鼓励封装与继承，但在高频更新场景下：
- 虚函数调用阻碍编译器内联优化；
- 抽象隐藏了数据访问模式；
- 性能损耗被“均匀分布”在整个代码库中，找不到清晰瓶颈。
第四章：Unity 项目中的典型反模式
上述问题在 Unity 项目中极为普遍，具体表现为：
- 默认使用 GC 对象：C#
class实例由垃圾回收管理，虽方便但代价高昂； - 主线程垄断一切：Unity 的设计让单线程开发极其简单，却阻碍了并行化；
- 内存高度碎片化：每个
GameObject及其Component独立分配，彼此相距甚远； - OOP 风格 vs 硬件本质：传统代码强调“对象行为”，而硬件更关心“数据布局与访问模式”。
📌 举例：当你有 1000 个
MonsterMonoBehaviour 时，Unity 会逐个调用它们的Update()，且这些对象在内存中随机分布——这是性能的双重灾难。
