Uniy 组件式泛型单例模式

1. 我们知道,在Unity中,所有对象脚本都必须继承MonoBehavior脚本,才能使用Unity内置的脚本功能;
2. 通常我们可以用静态类来取代单例模式,但是静态类方法的缺点是，它们必须继承最底层的类----Object。这意味着静态类不能继承MonoBehaviour，因此，我们不能使用它的任何一个Unity的功能，包括所有重要事件的回调函数，包括协程。并且，因为没有对象可供选择，我们失去了在运行时通过Inspector面版检查对象的数据的能力。这些都是我们可以通过单例模式使用的功能。
3. 一个常见的解决办法是“单例作为组件”，让一个游戏对象包含自己。并提供静态方法以授予全局访问。需要注意，在这种情况下，我们必须用私有静态实例变量和一种全局访问的全局实例方法基本上实现典型的单例设计模式。
4. 作为全局访问,我们对该组件在场景中只需要永远存在唯一一个组件单例实例:无则生成,多则销毁剩一个,切换场景不销毁唯一实例,仅此而已

   using UnityEngine;
   
   public class SingletonComponent<T> : MonoBehaviour where T : SingletonComponent<T>
   {
       private static SingletonComponent<T> _instance;
   
       public static SingletonComponent<T> _Instance
       {
           get
           {
               if (_instance != null)
               {
                   T[] compoments = GameObject.FindObjectsOfType(typeof (T)) as T[];
   
                   if (compoments != null && compoments.Length == )
                   {
                       return compoments[];
                   }
                   else
                   {
                       for (int c = ; c < compoments.Length -; ++c)
                       {
                           DestroyImmediate(compoments[c].gameObject);
                       }
                       return compoments[compoments.Length -];
                   }
               }
   
               GameObject go = new GameObject(typeof(T).Name,typeof(T));
               _instance = go.GetComponent<T>();
               DontDestroyOnLoad(_instance.gameObject);
               return _instance;
           }
           set { _instance = value as T; }
       }
   }

5. 子类继承Unity单例组件类进行方法构造,就可以正常使用单例模式了:

   public class ResourcesManagerSingleton : SingletonComponent<ResourcesManagerSingleton>
       {
           public static ResourcesManagerSingleton  Instance
           {
               get { return _Instance as ResourcesManagerSingleton; }
               set { _Instance = value; }
           }
   }

6. 如果可能的话，我们不应该放SingletonAsComponent 的派生类到我们的场景面版。这是因为 DontDestroyOnLoad()方法从来没被调用过。这将使单例组件对象在下一个场景加载的时候不存在了。

因此，如果任何对象尝试在OnDestroy()中做任何与单例相关的事，那它就会调用单例属性。如果单例在这一刻已经被摧毁，该对象的销毁过程就会在应用程序关闭期间创建一个新的单例。这可能会损坏我们的场景文件，因为我们的单例组件被遗留在了场景之后。如果这样，Unity就会报出一个错误：

为什么某些对象会在销毁阶段调用单例模式是因为单例经常使用观察者模式。这种设计模式允许其他对象注册/注销他们特定的任务，类似于Unity如何锁住回调，但是用了一个不太自动化的方式。我们将在即将到来的部分中看到一个全局信息系统的例子。对象将在系统构建的时候注册，而在关闭的时候取消注册，要做到这一点的最方便的地方是它的ondestroy()方法内。因此，这样的对象可能会遇到上述问题，也就是单例模式在应用程序关闭期间出现问题的地方。

为了解决这个问题，我们需要做出三点改变。首先，我们需要添加一个附加标志给单例组件，用来跟踪它的活动状态，并在适当的时候禁用它。这包括了单例自己的毁灭，以及应用程序关闭（OnApplicationQuit()是另一个Unity在这段时间有用的回调）：

private bool _alive = true;
void OnDestroy() { _alive = false; }
void OnApplicationQuit() { _alive = false; }
Secondly, we should implement a way for external objects to verify the Singleton’s current
state:

然后，我们应该实现一种外部对象来验证单例的当前状态：

public static bool IsAlive {
    get {
        if (__Instance == null)
            return false;
        return __Instance._alive;
    }
}

最后，任何试图在自己OnDestroy()方法里调用单例的，必须先使用IsAlive属性来验证状态。举个例子：

public class SomeComponent : MonoBehaviour {
    void OnDestroy() {
        if (MySingletonComponent.IsAlive) {
            MySingletonComponent.Instance.SomeMethod();
        }
    }
}

这将确保没有人试图在销毁过程中访问实例。如果我们不遵守这个规则，我们就会因为返回到编辑模式下，由于单例还存在于场景中而运行报错。

比较讽刺的是单例组件的出现后，在我们访问单例的实例之前，我们用Find（）方法来确定单例组件是否在场景中存在。

幸运的是，这将只发生在单例组件的第一次被访问时。但是单例的初始化不一定发生在场景的初始化的时候，因此可能在这个对象被实例化和调用Find（）方法时给我们游戏的过程中造成一个很不好的表现。解决办法是一个最高的类通过简单的调用每一个实例在场景的初始化时确定单例的初始化。

这种方法的缺点是，如果我们之后决定存在多个管理类，我们希望把它的行为分离出来更为模块化，就会有很多的代码需要改变。

还有进一步的选择，我们可以探索，如利用Unity的内置的脚本代码和检查界面之间的接口。