Unity3D 全局脚本

我们知道Unity3D在是可以创建游戏场景的，在每个游戏场景中又可以创建游戏对象，把每个场景的游戏对象融合在一起就是一款3D游戏。游戏场景之间属于同等级的关系，为了让游戏场景之前交互我们需要有一个凌驾所有场景之上的脚本，我称之为“全局脚本”。如下图所示，所有场景都能与这个唯一的全局脚本进行交互。当场景切换时可将临时逻辑数据写入全局脚本中，切换完毕后再去全局脚本中取之前保存的数据，从而实现交互。（当然还有别的办法也能实现这个效果，但是我觉得这样做会更好一些，数据会更安全一些）

例如：游戏战斗时你获得一定数量的金币，当你返回菜单界面时，你仍然能看见UI界面显示你的金币数量，这就是全局交互。

又或者，大部分游戏Loding时都只有一个Loading场景，A场景转到B时调用这个场景，B转到C也是调用这个Loading场景，

那么Loading场景要怎么知道接下来读取哪个场景？当然是通过你将全部场景的名字存到全局变量，然后读取的时候指定了。

接着我们就进入场景中，游戏场景是由若干游戏对象组成，下面我好好说一说游戏对象。游戏对象是需要绑定游戏脚本才能完成它的生命周期。那么脚本的使命就会尤其的重要。因为游戏对象比较多那么脚本必然会出现交互的情况，如下图所示，很多初期Unity3D的项目中的脚本会编写成这个样子。错综复杂相互交互，这样编写的脚本有可能你的游戏能做出来，可是你在维护的时候团队开发的时候你会发现你的脚本非常的混乱，别的同事想改都不知道怎么改。（显然这样的作法时完全错误的）

 

游戏中尽量避免这种高耦合的方法，比如由于某些变动，上面图片的脚本4需要修改或者删除，那么也必须更改脚本1,2,3,5与其的交互，不然会出错。

这种高耦合的方法显然非常累，而且还容易出错，比如你忘了更改脚本3与脚本4的交互，那么就出错。

 

我们想想为什么脚本之间要交互，原因很简单。是因为脚本中需要使用/调用另一条脚本或者另一条脚本对应的游戏对象某一项数据/方法，为了解决这个问题而导致最终的脚本非常混乱。为了避免这个问题，我在开发中会这么做，如下图所示，脚本之间切记不要做直接的相互交互，脚本之间只做间接的交互。每一个游戏场景都有一个凌驾所有游戏对象之上的单例脚本，在这条脚本中保存场景中所有脚本的公共数据。包括该场景的整体逻辑更新都是在这条单例脚本中完成。每条脚本都只与这个单例脚本做交互，和别的脚本一概不交互。（间接交互）

 

或者使用消息通知中心来实现解耦也可以：

（需要注意的是，Unity自带的消息中心很烂，效率不高，也没有订阅功能，需要自己扩展）

 

编写脚本时请注意，脚本只干属于自己最重要的事情，就跟代码中的函数一样，只干最重要的事情。切记和该条脚本无关的事情不要去管，不要在脚本中做过多的相互连带工作，让所有连带工作的话都放在全局单例脚本中来做。

第一种方式是使用静态类。适合存储一些全局的变量，如游戏当前关卡、玩家得分等。
实现方式和普通的C#静态类没有差别。注意使用静态类就没有必要继承MonoBehaviour了。

如果要实现复杂一些的全局控制，如切换游戏关卡等操作，更常用的方式是使用单例类。
单例类的实现又分为两种：

• 继承自MonoBehaviour的单例类
• 纯C#的单例类

前者的优点是：

• 可以在Inspector中显示，便于赋值和查看变量等；
• 可以利用MonoBehaviour的接口；
• 可以使用Coroutine。
• 等等。

缺点也很多，主流的观点是能不继承MonoBehaviour就不要继承。

纯C#的单例类

实现起来简洁，易于理解。

普通的写法，不考虑多线程

public class MyClass
{
    private static readonly MyClass _instance = new MyClass();
    public static Class Instance {
        get {
            return _instance;
        }
    }    

    private MyClass() {}
}

线程安全的写法

检查两次。C#中使用lock关键字。

public class MyClass
{
    private static volatile MyClass _instance;
    private static object _lock = new object();

    public static MyClass Instance
    {
        get
        {
            if (_instance == null)
            {
                lock(_lock)
                {
                    if (_instance == null)
                        _instance = new MyClass();
                }
            }
            return _instance;
        }
    }

    private MyClass() {}
}

基于MonoBehaviour的单例类
普通的写法

利用了Unity的运行机制，从Awake处获取Unity创建的对象作为单例。
注意在Unity中不要使用new来创建MonoBehaviour实例。

public class MyClass : MonoBehaviour
{
    static MyClass _instance;

    void Awake () {
        _instance = this;
    }

    public static MyClass Instance {
        get {
            // 不需要再检查变量是否为null
            return _instance;
        }
    }
}

持久化的写法

在多个场景中保存单例。又有两种方法。

第一种是使用DontDestroyOnLoad方法，告诉Unity不要销毁实例所在的对象，然后将脚本挂到某个GameObject上：

public class MyClass : MonoBehaviour
{
    static MyClass _instance;

    void Awake () {
        _instance = this;
        // 防止载入新场景时被销毁
        DontDestroyOnLoad(_instance.gameObject);    
    }

    public static MyClass Instance {
        get {
            return _instance;
        }
    }
}

上面这个方法有个弊端，必须要从挂载了这个单例的GameObject所在的场景启动，否则会找不到GameObject对象。但是开发和测试时我们经常会单独启动一个场景。

另一种方法会创建一个GameObject，然后将单例挂载到其上：

public class MyClass : MonoBehaviour {

    static MyClass _instance;

    static public MyClass Instance
    {
        get
        {
            if (_instance == null)
            {
                // 尝试寻找该类的实例。此处不能用GameObject.Find，因为MonoBehaviour继承自Component。
                _instance = Object.FindObjectOfType(typeof(MyClass)) as MyClass;

                if (_instance == null)  // 如果没有找到
                {                                       
                    GameObject go = new GameObject("_MyClass"); // 创建一个新的GameObject
                    DontDestroyOnLoad(go);  // 防止被销毁
                    _instance = go.AddComponent<MyClass>(); // 将实例挂载到GameObject上
                }
            }
            return _instance;
        }
    }
}