Unity3D - 单例模式和静态类

Posted 2022-12-02 EZhex1991

Unity3D的API提供了很多的功能，但是很多流程还是会自己去封装一下去。当然现在网上也有很多的框架可以去下载使用，但是肯定不会比自己写的用起来顺手。

对于是否需要使用框架的问题上，本人是持肯定态度的，把一些常用方法进行封装，做成一个功能性的框架，可以很大程度上提高代码的效率，维护也方便。

对于网络上很多教程上使用的“游戏通用MVC框架”，现在看来并不符合MVC这种结构性框架的设计思想：要知道，MVC最初是被设计为Web应用的框架，而游戏中的很多事件并不是通过用户点击UI发生的，View和Controller在游戏逻辑中的占比一般都少的可怜，而且很多教程上把Model剥离出很多“Manager”模块，甚至有人把View和Controller合在一起写了UIManager——连MVC的结构都没了，为啥还要称之为MVC框架呢？
MVC: “人红是非多。。。。”

目前大部分的游戏框架——特别是小型项目的游戏框架——都是把一些数据的特定行为进行了一下封装：生成一个物件，播放一个特效，进行一次随机事件等。当然也会有一些结构性的设计或者资源管理设计如：UI的回退栈或者回退链，场景的载入记录和切换，下载队列的管理等。

在Unity的框架设计中，有一个词会经常见到：单例模式（singleton）。单例模式就是在整个游戏中只使用某个类的一个实例，核心的一句话就是public static T Instance;即在类中定义了一个静态的自身实例供外部使用，调用方法时就是：T.Instance.Function()。在本人最初接触这种设计方式时经常会与静态类弄混淆，T.Function()。中间差了一个静态Instance，很多时候好像区别不大。。。

在接近两周左右的时间里，我一直在纠结于自己正在写的框架到底应该写成单例模式的还是静态模式的，今天刚好对这个问题有了一个新的想法：静态可不可以理解为一种封闭性很强的单例？

首先回想一下静态的两个常识：

1. 静态类不能继承和被继承！（严格点说是只能继承System.Object）也就是说你的静态类不可能去继承MonoBehaviour，不能实现接口。
2. 静态方法不能使用非静态成员！如果你大量使用静态方法，而方法里又需要用到这个类的成员，那么你的成员得是静态成员。

第2点需要注意：如果你想在Unity的编辑器下调整某个参数，那么这个参数就不能是静态的（哪怕你自定义EditorWindow去修改这个值也没用），解决的办法是通过UnityEngine.ScriptableObject去存放配置（生成*.asset文件），然后在运行中通过LoadAsset去加载，然后再改变静态成员。至于原因，相信不难理解——你看到的所有Unity组件都是一个个实例，你要通过Unity的编辑器去配置，那么你就得有一个这样的可配置实例。

从面向对象上想一下：静态方法或者静态类，不需要依赖对象，类是唯一的；单例的静态实例，一般就是唯一的一个对象（当然也可以有多个）。差别嘛。。。好像也不大。。。

如果这样考虑没有错，那再回头比较一下两种方式：

1. 静态（静态方法或者静态类），代码编写上绊手绊脚，方法调用很方便，运行效率高一丢丢。逻辑面向过程，不能很好地控制加载和销毁。
2. 单例（类的静态实例），代码编写和其他类完全一样，继承抽象模版接口都可以，Unity里也很方便进行参数配置，不过使用麻烦有犯错的可能性（必须通过实例调用方法），效率不如静态（但是也不会有很大影响吧）。

如果这些说法太抽象，那我再给出一个常见的问题：如果你的框架有一个SoundManager能够管理所有的声音播放，那么你会怎么去实现？
（在刚接触Audiosource这个组件的时候，我想的是每一个声音都由一个AudioSource去播放。但是后来发现完全没必要，AudioSource有静态的PlayClipAtPoint方法去播放临时3D音效，同时有实例方法PlayOneShot去播放临时音效（2D和3D取决于当实例的SpatialBlend）。如果没有特殊的需求，那么一个AudioSource循环播放背景音乐，上述两种方法播放游戏中的特效音频，这对于大部分游戏已经足够了。）

那么问题来了：你的SoundManager播放声音的方法如果是静态的，那么AudioSource组件必须在代码中通过各种方式去获取（新建组件或者获取特定GameObject下的组件）——因为保存这个组件的变量必须是静态的，也就不能通过Unity的编辑器去赋值。如果不去阅读代码那么用户完全不知道这是一个什么样的组件获取流程，如果我破坏这个流程（同名物体，包含互斥组件等），那么这个Manager很有可能会出现不可预料的异常。
而继承MonoBehaviour并RequireComponent(typeof(AudioSource))，怎么看也比“为了静态而静态”的代码要方便健壮的多。

实际上到这里已经可以基本总结出何时需要使用单例了：

1. 只要你的类需要保存其他组件作为变量，那么就有必要使用单例；
2. 只要你有在Unity编辑器上进行参数配置的需求，那么就有必要使用单例；
3. 只要你的管理器需要进行加载的顺序控制，那么就有必要使用单例（比如热更新之后加载ResourcesManager）；

当然，这里都只是“有必要”，并不是“必须”。两者区别最大的地方，一个是方便写，一个是方便用。方便写的代价是每次调用加个instance，方便用的代价则是放弃了面向对象和Unity的“所见即所得”，孰轻孰重，自己抉择。

另一方面，和“为了静态而静态”一样，“为了单例而单例”同样是一个不合理的设计。这样的解释仍然是那么的模糊，那么，就给自己定义一个最简单的规则吧——如果你的单例类里没有任何需要保存状态的变量，那么这个类里的方法就可以全都是静态方法，这个类也可以是个静态类。