1. 项目概述为什么Unity开发者绕不开单例模式在Unity项目里摸爬滚打几年你会发现一个有趣的现象无论项目大小从原型验证到大型商业游戏总有几个脚本的身影无处不在它们管理着全局的音效、控制着游戏的流程、或者保存着玩家的数据。这些脚本往往有一个共同的名字——单例Singleton。今天我们不谈那些教科书式的定义就从实际开发的角度聊聊在Unity里实现单例模式的那些门道、踩过的坑以及如何写出一个既好用又安全的单例基类。单例模式的核心诉求很简单确保一个类在程序的生命周期内只有一个实例并提供一个全局访问点。在Unity的语境下这通常意味着一个MonoBehaviour脚本在整个游戏运行期间只存在一个。听起来简单但新手常犯的错误就是直接在脚本里写个public static Instance然后满世界调用结果场景切换时实例没了或者异步加载时产生多个实例导致数据错乱、空引用异常频发。一个健壮的单例不仅要解决“唯一性”问题还要处理好Unity特有的生命周期、跨场景持久化、线程安全尽管Unity主线程单线程但某些接口或Task可能涉及以及资源初始化顺序。2. 单例模式的核心设计思路与Unity适配2.1 饿汉式 vs 懒汉式在Unity中的选择设计模式教科书里常提饿汉式和懒汉式。饿汉式在类加载时就创建实例简单粗暴懒汉式则在第一次被访问时才创建延迟初始化。在Unity里纯粹的C#类单例可以沿用这些思路但一旦涉及MonoBehaviour情况就复杂了。MonoBehaviour的实例必须挂载在游戏对象GameObject上由Unity引擎管理其Awake、Start等生命周期。因此Unity中单例的创建往往不是简单的new而是Instantiate一个预制体或者通过FindObjectOfType查找更常见的是在脚本自身的Awake方法中完成实例的赋值与唯一性校验。对于Unity单例我强烈推荐“懒汉式”与“自举式”结合。即不预先在场景中放置单例对象而是在代码首次访问时动态地创建所需的GameObject并挂载脚本。这样做的好处是按需加载避免在游戏启动时初始化所有管理器加快初始场景加载速度。减少场景依赖不需要手动在每个场景里拖入单例对象降低场景管理的复杂度。灵活性高可以在创建时动态加载不同的配置或预制体。2.2 线程安全考量Unity真的是单线程吗很多文章说Unity是单线程的所以不需要考虑线程安全。这说法不准确。Unity的主游戏逻辑如Update、物理模拟、渲染确实运行在主线程但一些异步操作如UnityWebRequest、async/await、某些第三方插件或平台接口可能会在后台线程中回调。如果你的单例属性Instance的get访问器实现不当在极端的多线程访问情况下仍有可能创建出多个实例。因此一个健壮的Unity单例基类尤其是非MonoBehaviour的纯C#单例应当考虑线程安全。最常用的方式是使用双重校验锁Double-Checked Locking。对于MonoBehaviour单例由于Instantiate必须在主线程调用我们通常依靠Unity的生命周期方法如Awake来保证初始化顺序但属性的get访问器内部仍需进行空值检查和同步控制。2.3 跨场景持久化DontDestroyOnLoad的正确姿势这是Unity单例最经典的需求之一。一个游戏管理器GameManager或音频管理器AudioManager通常希望从游戏开始到结束一直存在不随场景切换而被销毁。实现方法是在单例实例创建后立即调用DontDestroyOnLoad(this.gameObject)。关键点在于调用时机。必须在Awake方法中调用而不是Start。因为Awake在脚本初始化时立即调用而Start可能在下一帧才调用在场景切换的间隙对象可能已被错误销毁。此外一个常见的“坑”是如果你的单例对象在多个场景中都存在例如不小心在两个场景里都拖入了GameManager预制体那么Awake时后一个场景的对象会销毁自己但可能已经对静态的Instance变量造成了污染。因此在Awake中除了设置DontDestroyOnLoad更关键的是实现一个“先到先得”的实例竞争逻辑。3. 手撕一个通用的Unity单例MonoBehaviour基类理论说再多不如直接上代码。下面我将一步步拆解一个我项目中经过多年锤炼的泛型单例基类SingletonMonoT。它支持懒汉式初始化、跨场景持久化、自动处理重复实例并提供了简单的线程安全保护。3.1 基类代码实现与逐行解析using UnityEngine; /// summary /// 泛型Unity单例基类MonoBehaviour。 /// 继承此类的脚本将自动具备单例特性并默认跨场景不销毁。 /// /summary /// typeparam nameT单例类型/typeparam public abstract class SingletonMonoT : MonoBehaviour where T : SingletonMonoT { // 使用volatile关键字确保多线程环境下instance状态可见性 private static volatile T _instance; // 锁对象用于线程同步 private static readonly object _lock new object(); // 标识应用是否正在退出防止应用退出时再次创建实例。 private static bool _applicationIsQuitting false; /// summary /// 单例实例的全局访问点。 /// /summary public static T Instance { get { // 如果应用正在退出直接返回null避免在退出时创建新对象。 if (_applicationIsQuitting) { Debug.LogWarning($[{typeof(T)}] 实例已在应用退出时被销毁。不再返回实例。); return null; } // 第一重检查如果实例已存在直接返回避免不必要的锁开销。 if (_instance null) { // 加锁确保同一时间只有一个线程能进入创建逻辑。 lock (_lock) { // 第二重检查进入锁后再次检查防止等待锁期间实例已被其他线程创建。 if (_instance null) { // 尝试在场景中查找已存在的实例例如手动拖入场景的对象。 _instance FindObjectOfTypeT(); // 如果场景中不存在则自动创建一个新的GameObject并挂载脚本。 if (_instance null) { GameObject singletonObject new GameObject(${typeof(T).Name} (Singleton)); _instance singletonObject.AddComponentT(); Debug.Log($[{typeof(T)}] 场景中未找到现有实例已自动创建{singletonObject.name}); } else { Debug.Log($[{typeof(T)}] 使用场景中已存在的实例{_instance.gameObject.name}); } // 确保单例对象在加载新场景时不被销毁。 // 注意此调用应放在实例赋值之后且仅在实例为自己创建时调用一次。 // 对于Find找到的已有对象其DontDestroyOnLoad状态可能已被设置这里再次设置是安全的但非必需。 DontDestroyOnLoad(_instance.gameObject); } } } return _instance; } } /// summary /// Unity的Awake消息。在此进行实例的注册和唯一性保障。 /// 注意此方法在脚本初始化时调用早于Start也早于任何可能的Instance属性访问。 /// /summary protected virtual void Awake() { // 应用退出时不执行任何逻辑。 if (_applicationIsQuitting) return; // 如果静态实例为空则将当前对象赋值给它。 if (_instance null) { _instance this as T; // 建议在此处调用DontDestroyOnLoad确保即使是通过拖拽到场景的方式创建也能持久化。 DontDestroyOnLoad(gameObject); } // 如果静态实例已存在且不是当前对象说明存在重复实例则销毁当前对象。 else if (_instance ! this) { Debug.LogWarning($[{typeof(T)}] 检测到重复的单例实例即将销毁{gameObject.name}); Destroy(gameObject); // 注意这里不要销毁组件Destroy(this)而是销毁整个GameObject。 // 因为整个GameObject可能都是为这个重复的单例而存在的。 } // 可选的初始化代码可以放在这里或者放在一个独立的Init方法中由Instance属性首次访问时调用。 // 但更推荐将初始化逻辑放在一个单独的Init方法并由Instance的getter在创建后显式调用以获得更清晰的控制流。 } /// summary /// Unity的OnDestroy消息。在此处理应用退出时的清理。 /// /summary protected virtual void OnDestroy() { // 只有当被销毁的对象是真正的单例实例时才将静态引用置空。 // 这可以防止重复实例被销毁时错误地清空真正的实例引用。 if (_instance this) { _instance null; } } /// summary /// Unity的OnApplicationQuit消息。设置退出标志。 /// 这是为了防止在应用退出时其他脚本可能访问Instance导致在退出过程中创建新的GameObject。 /// /summary protected virtual void OnApplicationQuit() { _applicationIsQuitting true; // 也可以选择在这里将_instance显式置为null // _instance null; } }3.2 关键设计点解析与避坑指南双重校验锁Double-Checked Locking第一重检查if (_instance null)在锁外进行。绝大多数情况下实例已经存在这可以避免每次访问Instance都进行昂贵的加锁操作极大提升性能。锁对象_lock使用一个静态的只读对象作为锁。这是C#中线程同步的常见做法。第二重检查锁内再次if (_instance null)这是关键。考虑两个线程同时通过第一重检查一个线程获得锁并创建了实例释放锁后另一个线程进入锁内如果没有第二重检查它会再次创建一个实例破坏单例。volatile关键字修饰_instance字段。它告诉编译器和运行时这个字段可能被多个线程同时访问禁止对其进行一些激进的优化如指令重排确保线程读到的是最新的值。在现代C#内存模型下对于引用类型在某些场景下可能不是严格必需但加上它是一个良好的、显式的线程安全承诺。_applicationIsQuitting标志这是Unity单例特有的、至关重要的安全措施。当玩家退出游戏时Unity会开始销毁所有对象。如果在销毁过程中某个脚本的OnDestroy或别的回调里再次访问Instance的getter会导致框架尝试创建一个新的GameObject。但这个新对象创建于应用关闭过程中会立即被销毁并可能在控制台产生错误日志。设置此标志可以优雅地避免这种情况。Awake中的实例管理这个逻辑处理了“手动将单例预制体拖入场景”的情况。如果场景中已存在一个实例Awake会将它赋值给_instance。如果场景中存在第二个重复的Awake会销毁后者。这保证了无论通过代码动态创建还是场景中静态放置最终都只有一个实例存活。DontDestroyOnLoad的调用位置我们在两处调用了它Instance属性getter中创建新对象后。Awake方法中当当前对象被确认为唯一实例后。 这确保了无论是哪种方式创建的实例都会被标记为不销毁。在Awake中调用尤其重要因为它处理了场景中预先放置的对象。使用泛型T where T : SingletonMonoT这是所谓的“Curiously Recurring Template Pattern (CRTP)”。它让基类能够知道派生类的具体类型从而在静态字段_instance中存储正确的类型T而不是基类SingletonMono。这使得每个派生类都有自己独立的静态实例字段。4. 如何使用这个单例基类以AudioManager为例有了基类创建任何单例管理器都变得异常简单。下面我们创建一个音频管理器。using UnityEngine; using System.Collections.Generic; public class AudioManager : SingletonMonoAudioManager { [SerializeField] private AudioSource _bgmSource; // 背景音乐音源 [SerializeField] private AudioSource _sfxSourcePrefab; // 音效音源预制体 [SerializeField] private AudioClip _defaultBGM; // 默认背景音乐 private QueueAudioSource _sfxPool new QueueAudioSource(); // 音效对象池 private Transform _sfxPoolRoot; // 对象池根节点 protected override void Awake() { // 首先调用基类的Awake完成单例实例的注册和去重。 base.Awake(); // 基类Awake调用后如果this不是_instance说明它是重复实例会被销毁后续代码不会执行。 // 只有真正的单例实例才会执行下面的初始化代码。 if (_instance ! this) return; // --- 以下是AudioManager特有的初始化 --- if (_bgmSource null) { _bgmSource gameObject.AddComponentAudioSource(); _bgmSource.loop true; _bgmSource.playOnAwake false; } // 创建对象池根节点便于在Hierarchy中管理生成的音效对象。 _sfxPoolRoot new GameObject(SFX_Pool).transform; _sfxPoolRoot.SetParent(transform); DontDestroyOnLoad(_sfxPoolRoot.gameObject); // 对象池也需持久化 // 预初始化几个音效源 for (int i 0; i 5; i) { CreateNewSFXSourceInPool(); } // 播放默认背景音乐 PlayBGM(_defaultBGM); } private AudioSource CreateNewSFXSourceInPool() { AudioSource source; if (_sfxSourcePrefab ! null) { source Instantiate(_sfxSourcePrefab, _sfxPoolRoot); } else { GameObject go new GameObject(SFX_Source); go.transform.SetParent(_sfxPoolRoot); source go.AddComponentAudioSource(); source.playOnAwake false; } source.gameObject.SetActive(false); _sfxPool.Enqueue(source); return source; } public void PlayBGM(AudioClip clip, float volume 1.0f) { if (clip null || clip _bgmSource.clip) return; _bgmSource.clip clip; _bgmSource.volume volume; _bgmSource.Play(); } public void PlaySFX(AudioClip clip, float volume 1.0f, float pitch 1.0f) { if (clip null) return; AudioSource source; if (_sfxPool.Count 0) { source CreateNewSFXSourceInPool(); } else { source _sfxPool.Dequeue(); } source.gameObject.SetActive(true); source.clip clip; source.volume volume; source.pitch pitch; source.PlayOneShot(clip); // 使用PlayOneShot允许音效重叠播放 // 播放完毕后延迟放回对象池 StartCoroutine(ReturnSFXToPoolAfterPlay(source, clip.length)); } private System.Collections.IEnumerator ReturnSFXToPoolAfterPlay(AudioSource source, float delay) { yield return new WaitForSeconds(delay); source.gameObject.SetActive(false); source.clip null; _sfxPool.Enqueue(source); } // 其他方法停止BGM、设置全局音量等... }使用方式在任何其他脚本中要播放音效只需一行代码AudioManager.Instance.PlaySFX(clickSoundClip);无需关心AudioManager是否存在、在哪里。Instance属性会处理所有创建和查找逻辑。5. 进阶话题非MonoBehaviour单例与资源管理5.1 纯C#单例实现对于不需要挂载在GameObject上、不依赖Unity生命周期的管理器如配置管理器、网络协议解析器可以使用更简单的纯C#单例。public class ConfigManager { private static readonly LazyConfigManager _lazyInstance new LazyConfigManager(() new ConfigManager()); public static ConfigManager Instance _lazyInstance.Value; private ConfigManager() { // 私有构造函数防止外部实例化 LoadConfig(); } private void LoadConfig() { /* ... */ } }这里使用了LazyT类它是.NET Framework 4.0引入的专门用于延迟初始化并且默认是线程安全的。这是实现懒汉式单例最简洁、最推荐的方式。5.2 单例与Addressable/AssetBundle资源加载在现代Unity开发中我们常用Addressables系统管理资源。单例管理器经常需要加载资源。注意事项初始化顺序确保资源管理系统如Addressables初始化在单例管理器使用之前完成。通常可以在一个Bootstrapper场景或启动脚本中完成。异步加载单例的初始化方法如InitAsync可能需要是异步的。要处理好异步初始化完成前其他模块访问单例功能的情况。一种模式是提供IsInitialized属性或者使用Task/UniTask让调用方等待初始化完成。错误处理资源加载可能失败。单例管理器需要有容错机制例如加载失败时使用默认资源或提供友好的错误提示。5.3 单例模式的替代方案与反思单例虽好但不能滥用。过度使用单例会导致代码高度耦合难以测试。考虑以下替代方案依赖注入Dependency Injection, DI使用像Zenject现称Extenject、VContainer这样的DI框架。将管理器注册为“单例”生命周期框架会自动管理其创建和注入到需要它的类中。这解决了耦合问题更易于单元测试和模块替换。Service Locator模式提供一个全局的“服务定位器”用于查找服务。它比单例稍微灵活一点但依然存在全局状态的问题。ScriptableObject对于存储游戏配置、共享数据如玩家库存、游戏设置ScriptableObject是一个极佳的选择。它可以作为资产存在在编辑器中可视化配置并且多个对象可以引用同一份数据天然具备“单例”的数据共享特性同时又避免了静态类的缺点。我的经验法则对于纯粹的功能性管理器如音频播放、场景切换如果全局只有一个且生命周期与游戏一致可以使用单例。对于数据或配置优先考虑ScriptableObject。在中大型项目中强烈建议引入DI框架来管理这些“全局”服务即使初期学习成本稍高但对项目的长期维护性有巨大好处。6. 实战中遇到的典型问题与解决方案6.1 问题场景切换时单例对象上协程Coroutine中断现象单例对象上运行的协程比如一个延时任务或动画序列在切换场景后停止了。原因DontDestroyOnLoad的对象在场景切换时不会被销毁但默认情况下MonoBehaviour上启动的协程与它所在的Scene关联不大主要与MonoBehaviour实例本身是否被禁用或销毁有关。然而一些与场景对象相关的操作如WaitForSeconds虽然不受影响但yield return new WaitForEndOfFrame()在场景卸载和加载的间隙可能会出现问题。更常见的是协程中引用了旧场景中的对象这些对象在场景切换时被销毁了导致协程后续步骤出现空引用。解决方案在协程内部对所有来自场景的对象引用进行空值检查。如果协程必须在场景切换时继续运行并且其逻辑是全局性的如游戏倒计时确保它不依赖于任何场景特定对象。在单例的OnDestroy或一个自定义的OnSceneUnloading方法中主动停止StopCoroutine那些依赖于即将卸载场景的协程。6.2 问题编辑器模式下播放停止后单例静态变量未重置现象在Unity编辑器中运行游戏停止播放后单例类的静态变量_instance仍然持有引用指向一个已被标记为销毁的“僵尸”对象。再次点击播放Awake中判断_instance ! null可能会错误地销毁新创建的有效实例。原因Unity编辑器停止播放时会销毁运行时的游戏对象但不会自动清理C#静态字段。这些字段仍然引用着已经被销毁的UnityEngine.Object这就是所谓的“虚假的实例”fake null。_instance null检查会返回false但_instance实际上已经无效。解决方案这就是我们在基类中使用_applicationIsQuitting标志的原因。在编辑器模式下我们需要区分是播放停止还是真正的应用退出。// 修改基类的OnApplicationQuit和Awake protected virtual void OnApplicationQuit() { _applicationIsQuitting true; // 可以选择在这里将_instance置为null但更安全的做法是依靠标志。 // _instance null; } // 在Awake开始时增加对编辑器模式下“虚假实例”的检查 protected virtual void Awake() { #if UNITY_EDITOR // 在编辑器模式下如果应用未运行但_instance指向了一个被销毁的对象则将其置空。 if (!UnityEditor.EditorApplication.isPlayingOrWillChangePlaymode UnityEditor.EditorApplication.isPlaying) { // 这个条件判断比较复杂一个更通用的方法是检查_instance的“真伪” if (_instance ! null _instance null) // 这个写法不成立需要借助UnityEngine.Object重载的操作符 { // 正确的检查方式 if (_instance ! null _instance.gameObject null) { _instance null; } } } #endif // ... 原有的Awake逻辑 }实际上更健壮的做法是使用[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.SubsystemRegistration)]特性在每次运行时初始化前重置静态字段。但最简单有效的还是结合_applicationIsQuitting标志并在Instance的getter中对_instance进行“真实性”检查例如if (_instance null || _instance.gameObject null)。我们的基类已经通过_applicationIsQuitting处理了主要问题。6.3 问题单例的初始化顺序依赖现象GameManager单例在Awake中需要访问AudioManager.Instance但AudioManager可能还没有完成初始化它的Awake可能晚于GameManager的Awake被调用。原因Unity不保证不同GameObject上脚本Awake的调用顺序。虽然同一GameObject上的脚本顺序可以通过Script Execution Order设置但不同对象间的顺序是不确定的。解决方案懒初始化不要在所有单例的Awake中进行相互访问。改为在第一次需要使用时即在某个方法内部通过Instance属性访问此时属性getter会确保实例被创建和初始化。显式初始化顺序创建一个专门的Initializer脚本在某个最早的时刻如Start或通过[RuntimeInitializeOnLoadMethod]按顺序调用各个单例的Init()方法。使用依赖注入框架DI框架通常提供明确的绑定和初始化顺序配置。在我们的SingletonMono设计中由于实例创建是懒汉式的首次访问Instance时创建并且Awake中的初始化代码在实例创建后立即执行所以如果两个单例在各自的Awake中互相访问对方Instance可能会形成循环依赖或空引用。最佳实践是将单例的初始化逻辑从Awake中分离出来放入一个如Initialize()的方法中并由一个更高层的管理器如游戏状态机按需、按顺序调用。7. 性能优化与最佳实践总结谨慎使用FindObjectOfType我们基类在Instance的getter中使用了FindObjectOfTypeT()。这个方法在场景对象很多时会有性能开销。对于性能敏感的项目可以完全摒弃查找强制要求通过Instance属性动态创建。或者在编辑阶段通过预生成并注册的方式管理单例。避免在单例的Awake/Start中进行耗时操作这会影响游戏启动速度。将非紧急的初始化如加载大量配置放到协程或异步任务中。考虑将单例分为“持久单例”和“场景单例”不是所有单例都需要DontDestroyOnLoad。例如一个只管理当前关卡敌人的EnemyManager就应该随着关卡场景一起销毁。你可以创建两个基类PersistentSingletonMonoT和SceneSingletonMonoT。为单例提供显式的销毁方法除了依赖OnApplicationQuit在某些情况下如切换账号、重启游戏逻辑你可能需要手动重置单例状态。提供一个Cleanup()或Dispose()方法并确保能安全地重新初始化。日志输出在调试阶段保留基类中的Debug.Log输出有助于跟踪单例的创建和销毁。在发布版本中记得将它们注释掉或使用条件编译#if UNITY_EDITOR。最终单例模式是Unity开发中一把锋利的瑞士军刀用好了能极大提升开发效率用不好则会让代码库变得僵化难维护。理解其原理实现一个健壮的基类并清楚其适用场景与局限是每一位Unity开发者从入门到精通的必经之路。上面的SingletonMonoT基类以及围绕它展开的讨论希望能为你提供一个坚实可靠的起点。在实际项目中请根据具体需求灵活调整和扩展。