Unity单例封装

1.前言

本篇主要针对Unity单例模式，完成一个可以重复继承使用的抽象类，减少重复的工作与代码。同时，对存在的多种单例进行优劣分析。

2.Unity单例问题分析

2.1 单例原则

单例要满足以下两个原则：

2.1.1 单一原则

即不能存在两个单例对象，这看起来是一句废话，且在C#编程中不会出现，但在Unity中进行组件化编程的时候却会存在。因为unity继承自Monobehavior的类是一个组件可以通过挂载形成一个实例。不用手动new产生。这就容易违背此原则。

2.1.2 功能封装原则

单例是为了将特定功能且功能关联的方法，封装在一个模块能，方便处理各种问题。并且避免各种重复产生实例对象，所以单例一般都会隐藏public构造函数。

2.2 存在问题

2.2.1 单例原则违背

目前，网络充斥这大量单例模式，都或多或少存在各种问题，各种解决方案臃肿，没有必要进行如此处理。点击查看详细叙述。
本文最后也会对不推荐的单例写法进行分析。

2.2.2 单例滥用

采用unity进行开发时，不可避免的会涉及到ui的切换以及相互调用。在很多教程或者网络教学视频中，大量采用单例，笔者曾看过一个教程，大部分脚本都采用单例进行处理。好处是增加灵活性，方便调用与切换，坏处则时不易维护，增加开销，尤其是当用到下文不推荐的方式。所以一定不要为了方便不同脚本之间相互调用而采用单例。

3.简单单例模式

3.1 推荐方式

此方式最简单粗暴，有效。唯一缺陷是看着一点都不高端。

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public abstract class MonoSingleton<T> : MonoBehaviour where T : MonoSingleton<T>
{
   
   
    private static T instance;

    public static T Instance
    {
   
   
        get
        {
   
   
            return instance;
        }
    }

    protected virtual void Awake()
    {
   
   
        instance = (T)this;
    }
}

3.2 使用FindObjectOfType的单例

3.2.1 单例代码

代码如下所示，此方法看起来很完美，考虑周全，其实存在很多问题与隐患。

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public abstract class MonoSingleton<T> : MonoBehaviour <