有多少原因导致性能问题，就有多少种不同的方式来优化代码。通常，强烈建议开发者在尝试应用 CPU 优化之前对其应用程序进行性能分析。不过，还是存在几种普遍适用的简易 CPU 优化方式。
Unity 不使用字符串名称对 Animator、Material 和 Shader 属性进行内部寻址。为了加快速度，所有属性名称都经过哈希处理为属性 ID，实际上正是这些 ID 用于寻址属性。
因此，每当在 Animator、Material 或 Shader 上使用 Set 或 Get 方法时，请使用整数值方法而非字符串值方法。字符串方法只执行字符串哈希处理，然后将经过哈希处理的 ID 转发给整数值方法。
从字符串哈希创建的属性 ID 在单次运行过程中是不变的。它们最简单的用法是为每个属性名称声明一个静态只读整数变量，然后使用整数变量代替字符串。启动期间将自动进行初始化，无需其他初始化代码。
Animator.StringToHash 是用于 Animator 属性名称的对应 API，Shader.PropertyToID 是用于 Material 和 Shader 属性名称的对应 API。
在 Unity 5.3 及更高版本中，引入了所有物理查询 API 的非分配版本。将 RaycastAll 调用替换为 RaycastNonAlloc，将 SphereCastAll 调用替换为 SphereCastNonAlloc，以此类推。对于 2D 应用程序，也存在所有 Physics2D 查询 API 的非分配版本。
Whenever a Transform’s position or rotation is changed, an OnTransformChanged message is dispatched to all components on the same GameObject as the Transform, as well as all child GameObjects. For this reason, it is best practice to attempt to alter a Transform’s position and rotation as few times as possible during a given frame. Instead, batch all possible changes that need to be applied to the Transform, and apply them once. This minimizes the number of OnTransformChanged messages that must propagate through the Transform hierarchy, and is especially important when moving deep/large Transform hierarchies, such as animated characters.
对于位于紧凑循环中的矢量和四元数运算，请记住整数数学比浮点数学更快，而浮点数学比矢量、矩阵或四元数运算更快。
因此，每当交换或关联算术允许时，请尝试最小化单个数学运算的成本：
Vector3 x;
int a, b;
// 效率较低：产生两次矢量乘法
Vector3 slow = a * x * b;
// 效率较高：一次整数乘法、一次矢量乘法
Vector3 fast = a * b * x;
对于必须在 HTML 格式的颜色字符串 (#RRGGBBAA) 与 Unity 的原生 Color 及 Color32 格式之间进行转换的应用程序来说，使用来自 Unify Community 的脚本是很常见的做法。由于需要进行字符串操作，此脚本不但速度很慢，而且会导致大量内存分配。
从 Unity 5 开始，有一个内置 ColorUtility API 可以有效执行此类转换。应优先使用内置 API。
一般来说，最好完全避免在生产代码中使用 Object.Find 和 Object.FindObjectOfType。由于此类 API 要求 Unity 遍历内存中的所有游戏对象和组件，因此它们会随着项目规模的扩大而产生性能问题。
在单例对象的访问器对上述规则来说是个例外。全局管理器对象往往会暴露“instance”属性，并且通常在 getter 中存在 FindObjectOfType 调用以便检测单例预先存在的实例：
class SomeSingleton {
private SomeSingleton _instance;
public SomeSingleton Instance {
get {
if(_instance == null) {
_instance =
FindObjectOfType<SomeSingleton>();
}
if(_instnace == null) {
_instance = CreateSomeSingleton();
}
return _instance;
}
}
}
虽然这种模式通常是可以接受的，但必须注意检查代码并确保调用访问器时场景中不存在单例对象。如果 getter 没有自动创建缺失单例的实例，那么寻找单例的代码经常会重复调用 FindObjectOfType（通常每帧多次发生）并且会对性能产生不良影响。
在内部，Unity 的 Camera.main 属性会调用 Object.FindObjectWithTag（这是 Object.FindObject 的一个专用变体）。访问此属性并不比调用 Object.FindObjectOfType 更高效。如果代码必须寻址主摄像机，强烈建议您执行以下两项操作之一：
访问 Start 或 OnEnable 回调中的 Camera.main，并缓存所产生的引用。
构造一个可提供或添加活动摄像机引用的 Camera Manager 类。
The UnityEngine.Debug logging APIs are not stripped from non-development builds, and do write to log files if called. As most developers do not intend to write debug information in non-development builds, it is recommended to wrap development-only logging calls in custom methods, like so:
public static class Logger {
[Conditional("ENABLE_LOGS")]
public void Debug(string logMsg) {
Debug.Log(logMsg);
}
}
通过使用 [Conditional] 属性来修饰这些方法，Conditional 属性所使用的一个或多个定义将决定被修饰的方法是否包含在已编译的源代码中。
如果传递给 Conditional 属性的任何定义均未被定义，则会被修饰的方法以及对被修饰方法的所有调用都会在编译中剔除。实际效果与包裹在 #if … #endif 预处理器代码块中的方法以及对该方法的所有调用的处理情况相同。
有关 Conditional 属性的更多信息，请参阅 MSDN 网站：msdn.microsoft.com。