如果你是一个有经验的游戏开发者，那么你知道在目标平台上进行性能优化是贯穿整个开发周期的任务。也许你的游戏在高端PC上运行得很好，但在低端移动平台上，帧率是不是会慢很多，导致明显的卡顿？加载时间是不是过长，玩家每次走过门时，游戏就会卡住几秒钟？在这种情况下，不仅当前的游戏体验不尽如人意，游戏本身也因此被阻止添加更多功能：更多的环境细节和规模、游戏机制、角色和动作、视觉效果等。
问题的根源是什么？在许多项目中，问题出在渲染：Texture过大、Mesh过于复杂、Shader过于消耗资源，或者批处理、剔除和LOD的使用不当。
另一个常见的陷阱是过度使用复杂的mesh collider，这会大大增加物理模拟成本。或者，你编写的C#代码可能占用了过多的CPU时间，导致游戏的现实模拟本身很慢。
那么，如何编写快速的，至少是不迟缓的代码？
在过去的几十年里，PC游戏开发者通常通过“静候时代到来”来解决这个问题。从20世纪70年代到21世纪，CPU的单线程性能近乎每几年翻一番（摩尔定律），因此一款PC游戏在生命周期内“自动”变得更快。然而，在过去的二十年里，CPU单线程性能的提升相对较为平缓。相反，CPU的核心数量不断增加，甚至像智能手机这样的便携设备也开始配备多核。
此外，高端与低端游戏设备之间的性能差距也在逐步加大，很多玩家使用的是已经几年没更新的硬件。等待更快的硬件似乎不再是一个可行的策略。
那么，问题应该是：“为什么我的代码在CPU上运行时会这么缓慢？”有几个常见的陷阱：
— GC引起的开销和明显停滞：这是因为垃圾回收器作为自动内存管理器，负责管理应用程序内存的分配和释放。垃圾回收不仅会导致CPU和内存的开销，还可能在执行过程中暂停代码的运行，通常暂停时间为几毫秒。用户可能会感受到GC引起的帧率波动或更为明显的卡顿。
— 编译器生成的机器码不优化：某些编译器生成的代码优化程度远低于其他编译器，且优化效果在不同平台上可能有所不同。
— CPU核心利用不充分：虽然现在最低端的设备也配有多核CPU，但许多游戏仍将大部分逻辑保持在主线程上，因为编写多线程代码通常很困难且容易出错。
— 数据不符合缓存友好性：从缓存中访问数据比从主存中获取数据要快得多。然而，从主存访问数据可能需要CPU等待数百个CPU周期，所以我们更希望CPU尽可能地从缓存中读写数据。
最简单的方式是按顺序读取和写入内存，因此，最符合缓存友好的方式是将数据存储在数组中。但是，如果数据在内存中是不连续的分散存储，那么访问它将会导致大量的缓存未命中，进而需要从更慢的主存中获取。
— 代码不符合缓存友好性：同上一条，当代码执行时，如果它尚未加载到缓存中，它必须从主存中加载。一种策略是尽量减少函数调用的次数，以减少从主存加载的频率。例如，与其在多个代码块调用某个函数，不如在一个代码块中调用它，这样代码每次执行最多只需要加载一次。
— 代码过于抽象：抽象通常会导致数据和代码复杂性增加，从而加剧上述问题：没有GC的内存管理变得更加困难；编译器可能无法进行有效优化；安全且高效的多线程编程变得更加困难，而且数据和代码也可能变得不太符合缓存友好性。除此之外，抽象往往会分散性能成本，使得整个代码运行更慢，导致没有明显的性能瓶颈可以优化。
以上所有问题在Unity项目中都很常见。让我们更具体地来看一下这些问题：
— 虽然C#允许手动分配不会被GC的对象，但大多数Unity项目中的C#代码是使用会被GC的类实例。 实际上，Unity开发者长期通过“对象池”（主要优点是高效地重复使用来自预分配池的对象，消除了频繁创建和销毁对象的需要）来缓解这个问题（尽管对象池的使用可以说违背了最初使用能自动垃圾回收的语言的目的）。
— 在Unity编辑器中，C#代码通常通过Mono编译器编译成机器码。 对于独立构建，你通常可以使用IL2CPP（将C#中间语言转编译为C++）获得更好的效果，但这也带来一些缺点，比如更长的构建时间、游戏更难支持mod修改。
— 通常，Unity项目会将所有代码都运行在主线程上，部分原因是这是Unity提供的最简单方式：
- Unity的部分事件函数，比如MonoBehaviour的Update()，都是在主线程中运行的。
- — 大多数Unity API只能在主线程中才能保证安全调用。
— 大部分Unity项目中的数据结构通常是将一堆随机对象分散在内存中，这导致缓存命中率非常低。 再次强调，这部分是因为Unity使得以下操作变得容易：GameObject及其组件都是单独分配的，因此它们往往会分散存储在内存的不同部分。
- 传统Unity项目中的代码往往不符合缓存友好性：
- 传统的C#和Unity的API鼓励使用面向对象的编程方式，这种风格倾向于产生大量小型方法和复杂的调用链。与数据导向的编程方式不同，这种方式并不十分符合硬件优化。
— 每个MonoBehaviour的事件函数是单独调用的，这些调用不一定会按MonoBehaviour类型进行分组。例如，如果你有1000个Monster MonoBehaviour，每个Monster会单独更新，并不一定会与其他Monster一起更新。
— 传统C#和许多Unity API的面向对象方式通常导致过多的抽象层。这种抽象层的代码通常会导致效率低下，且很难解耦和隔离。
)
)
