原文链接：hhttps://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity7.html

        由于性能问题的原因有很多，所以有很多不同的方式来优化代码。总的来说，强烈建议开发者在尝试进行CPU优化时仔细检查他们的应用程序。然而，有一些CPU优化时普遍适用的。

通过ID来定位属性

        Unity内部不通过字符串名字来定位Animator,Material和Shader属性。从速度角度讲，所有的属性被算成哈希值被存入属性ID容器中，这些ID事实上用于定位属性。

        因此，在Animator, Material或Shader中无论何时使用Set或Get函数，建议使用整数型函数来代替字符串型函数。字符串类型的函数在执行时只是简单的算出字符串的哈希值，然后将哈希值ID传递到整数类型函数中。

        在单次运行过程中，属性ID从字符串哈希值中创造是确定的。最简单的方法是为每个属性名字创建一个静态只读的整数类型变量，然后使用整数变量来代替字符串。在开始运行时这些是自动初始化的，并且并且不需要进一步的初始化代码。

        这些适当的API是应用于Animator属性名字的Animator.StringToHash，和对于Material & Shader属性名字的Shader.PropertyToID。

使用没有内存分配的物理API

        在Unity5.3或是更新的版本，引入了所有物理查询API的所有无内存分配版本。使用RaycastNonAlloc来代替RaycastAll，使用SphereCastNonAlloc来代替SphereCastAll等等。对于2D应用程序来说，也有2D物理API的无内存分配版本。

与UnityEngine.Objec进行空值比较

        Mono和IL2CPP运行时对待继承于UnityEngine.Objec类的实例有一种特殊的处理方式。执行实例中的函数事实上调用了引擎代码，其必须进行查找和验证才能使脚本引用转换到本机引用。虽然很小，将这种类型的变量与null的比较花费远远比纯C#类的消耗要高。因为这个原因，避免在在紧凑的循环中或是每帧执行的代码中进行空值比较。

向量和四元数计算和排序操作

        对于向量和四元数在紧凑循环中的计算，整数运算比浮点运算快，并且浮点运算比向量、矩阵、四元数运算要快。

        因此，如果当交替或者组合的算法允许时，尝试最小化单独数学操作的花费：

Vector3 x;

int a, b;

// Less efficient: results in two vector multiplications

Vector3 slow = a * x * b;

// More efficient: one integer mult, one vector mult

Vector3 fast = a * b * x;

内置的颜色工具

        对于那些必须要在HTML格式的颜色字符串(#RRGGBBAA)和Unity原生Color和Color32结构体之间转换的应用程序来说使用一个来自Unify Community的脚本是非常普遍的。这个脚本因为字符串操作非常慢并且有过多的内存分配。

        在Unity5中，有一个内置的ColorUtility API来有效率的进行这些转换工作。应该优先使用这个内置API。

Find和FindObjectOfType

        在产品代码中最好的实践是消除所有Object.Find和Object.FindObjectOfType的使用。因为这些API要求Unity去迭代所有内存中的 GameObject和Component，随着项目规模的扩大，其会迅速变成低性能的。

        上述规则的一个例外是其可以用于单例对象的存取器。一个全局管理器对象通常暴露一个“instance”属性，并且通常在get方法中有一个FindObjectOfType调用来预先检测单例的instance是否存在：

class SomeSingleton {

    private SomeSingleton _instance;

    public SomeSingleton Instance {

        get {

            if(_instance == null) {

                _instance =

                    FindObjectOfType<SomeSingleton>();

            }

            if(_instnace == null) {

                _instance = CreateSomeSingleton();

            }

            return _instance;

        }

    }

}

        虽然这种模式是可以接受的，但是检查代码确保在单例对象不存在时在场景中调用存取器是重要的。如果get方法不为丢失的单例创造一个实例，非常常见的会发现代码在寻找单例的过程中重复调用FindObjectOfType（通常是每帧多次），并且创造了一个不期望的性能消耗。

摄像机定位器

        内部来说，Unity的Camera.main属性调用了Object.FindObjectWithTag，这是Object.FindObject一个特殊的变体。如果代码必须定位主摄像机，那么强烈建议做下面两件事中的一件：

        ·在Start或OnEnable回调中访问Camera.main，并且缓存结果引用

        ·构建一个Camera Manager类，可以提供或是注入激活的摄像机的引用

调试代码&[条件]特性

        UnityEngine.Debug日志API并没有从非开发构建模式中剥离，并且在调用它的时候也会写入日志文件。对于大多数开发者来说，并不期望在非开发构建模式中写入调试信息，所以强烈建议在自定义函数中包装只用于开发模式的输出，像这样：

  public static class Logger {

        [Conditional("ENABLE_LOGS")]

        public static void Debug(string logMsg) {

            UnityEngine.Debug.Log(logMsg);

        }

    }

        通过使用[条件]特性修饰这些函数，用于条件特性的定义决定了被装饰的函数是否包含在被编译的源代码中。

        如果被定义的条件特性没有传递任何定义，那么被修饰的函数和所有调用调用此被修饰的函数的函数被编译出来。这个效果与此函数及调用被包裹在#if … #endif预处理程序块中一样。

        对于Conditional特性的更多信息，请看MSDN网站：https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/4xssyw96(v=vs.90)