1. 项目概述为什么Unity开发者必须啃透设计模式如果你在Unity项目里写过超过1000行代码大概率经历过这样的场景一个看似简单的功能随着需求迭代代码文件膨胀到几千行各种Manager、Controller、Handler类之间相互引用牵一发而动全身。想改个UI显示逻辑结果发现要动到数据层、网络层甚至影响到了场景加载。这其实就是典型的“面条式代码”而设计模式就是帮你把这些“面条”梳理成清晰、可维护的“电路板”的工程学方法。这次我们聚焦的“UnityCsReference”是Unity官方在GitHub上开源的C#运行时源码。它不仅是Unity引擎的心脏更是一座设计模式的“活体博物馆”。很多我们日常在Unity中习以为常的API比如GameObject.Find、Resources.Load其背后都蕴含着深刻的设计思想。直接阅读源码可能让人望而生畏但如果我们带着“设计模式”这副眼镜去审视很多复杂的设计会瞬间变得清晰易懂。更重要的是你能学到Unity官方团队是如何在大型、高性能的C#项目中应用这些模式的这是任何第三方教程都无法比拟的实战经验。本指南不会空谈理论我们将紧扣Unity开发中最核心、最高频的三种模式单例、工厂和观察者。我会结合UnityCsReference中的真实案例以及我过去在多个上线项目中踩过的坑为你拆解它们的设计意图、实现变体、适用场景以及最重要的——在Unity这个特殊环境下的“正确打开方式”。无论你是想优化自己的项目架构准备应对更高难度的技术面试还是单纯想提升代码设计能力这篇指南都将提供一条从“知道”到“会用”再到“用得精”的清晰路径。2. 核心设计模式深度解析与Unity适配2.1 单例模式全局访问的利刃与双刃剑单例模式恐怕是Unity开发者最熟悉也最被滥用的模式。它的核心目标是确保一个类只有一个实例并提供一个全局访问点。在Unity中像GameManager、AudioManager、UIManager这类需要贯穿游戏生命周期的管理器使用单例似乎顺理成章。2.1.1 UnityCsReference中的单例实践UnityEngine.Object的启示很多人自己实现单例时第一反应可能就是写个静态的Instance属性。但让我们看看UnityCsReference中更底层的设计。UnityEngine.Object是所有Unity游戏对象的基类它本身并不是一个传统意义上的单例类但它管理着一个全局的“实例ID到对象”的映射表。这个映射表本身就是一个需要全局唯一访问的核心资源管理器。Unity通过内部的Object.Internal_GetInstanceID等Native方法确保了这个映射表的唯一性和线程安全。这给我们的启示是单例的核心是“唯一实例”和“可控的全局访问”而不一定非得是一个我们肉眼可见的MonoBehaviour挂载在场景里。2.1.2 三种主流实现方案与陷阱分析经典懒汉式Lazy Initializationpublic class GameManager { private static GameManager _instance; public static GameManager Instance { get { if (_instance null) { _instance new GameManager(); } return _instance; } } private GameManager() { } }优点简单直观用到时才创建。陷阱非线程安全。在Unity的主线程中虽然问题不大但如果你涉及多线程数据加载如使用Task.Run就可能创建出多个实例。绝对不要在Unity的Awake或Start里用这种方式跨脚本访问因为脚本初始化顺序不确定可能导致空引用。MonoBehaviour挂载式public class AudioManager : MonoBehaviour { public static AudioManager Instance { get; private set; } void Awake() { if (Instance ! null Instance ! this) { Destroy(gameObject); // 关键销毁新创建的重复实例 return; } Instance this; DontDestroyOnLoad(gameObject); // 关键跨场景保持 } }优点能利用Unity生命周期Awake,OnDestroy方便挂载组件和协程。陷阱必须手动处理重复创建和销毁。DontDestroyOnLoad用不好会导致场景切换后残留多个管理器。强烈建议在Awake最开始就进行判空和销毁操作这是血的教训。.NET Lazy 式推荐public class ConfigManager { private static readonly LazyConfigManager _lazyInstance new LazyConfigManager(() new ConfigManager()); public static ConfigManager Instance _lazyInstance.Value; private ConfigManager() { // 初始化配置 } }优点线程安全延迟初始化代码简洁。这是纯C#类单例的最佳实践。注意它创建的是普通的C#对象不是GameObject。适合管理数据、配置等无需Unity生命周期的服务。重要心得不要为了用单例而用单例。单例本质上是“全局状态”它会增加代码的耦合度让单元测试变得困难。在架构设计时可以优先考虑依赖注入DI容器比如使用Zenject或VContainer将“单例服务”以接口形式注入这样既能保证唯一性又解耦了直接依赖便于测试和替换。2.2 工厂模式解耦对象创建的魔法工厂模式的核心是将对象的创建过程封装起来调用者无需关心具体的创建细节。在Unity中我们时刻都在“创建对象”实例化预制体、加载资源、生成敌人。直接用GameObject.Instantiate和Resources.Load不是不行但业务逻辑会和具体的资源路径、创建参数紧密耦合难以维护和扩展。2.2.1 UnityCsReference中的工厂思想ObjectFactory与Pooling在UnityCsReference中你找不到一个叫GameObjectFactory的类但工厂思想无处不在。例如对象池Object Pooling就是一种特殊的工厂它管理着对象的创建和回收。更底层的各种Native Object纹理、网格、材质的创建都是由引擎内部的工厂机制管理的它对上层提供了统一的接口隐藏了不同平台如DX、OpenGL、Metal下资源创建的复杂差异。这告诉我们工厂模式不仅是“new一个对象”更是对创建逻辑复杂性和差异性的封装。2.2.2 实战构建一个可扩展的敌人生成工厂假设我们有多种敌人近战兵、弓箭手、法师。最简单的做法是在SpawnPoint脚本里写一堆if-else。让我们用工厂模式重构定义产品接口public interface IEnemy { void Initialize(EnemyData data); void PerformAction(); }实现具体产品public class MeleeEnemy : MonoBehaviour, IEnemy { ... } public class ArcherEnemy : MonoBehaviour, IEnemy { ... } public class MageEnemy : MonoBehaviour, IEnemy { ... }创建抽象工厂public abstract class EnemyFactory : MonoBehaviour { public abstract IEnemy CreateEnemy(Vector3 position, Quaternion rotation); // 可以包含通用的预处理逻辑如播放生成特效、注册到管理器 }实现具体工厂[CreateAssetMenu(fileName MeleeEnemyFactory, menuName Factories/Enemy/Melee)] public class MeleeEnemyFactory : EnemyFactory { [SerializeField] private MeleeEnemy _prefab; // 在Inspector中拖拽赋值 [SerializeField] private EnemyData _defaultData; public override IEnemy CreateEnemy(Vector3 position, Quaternion rotation) { var enemyObj Instantiate(_prefab, position, rotation); var enemy enemyObj.GetComponentIEnemy(); enemy.Initialize(_defaultData); // 可以在这里注入依赖如设置AI、血量等 return enemy; } }这里用到了ScriptableObject作为工厂配置载体这是一个Unity特有的强大特性。它允许我们将工厂的配置预制体、数据作为资产保存在项目中无需硬编码也便于策划同学调整。使用工厂public class Spawner : MonoBehaviour { [SerializeField] private EnemyFactory _enemyFactory; // 拖入具体的工厂Asset public void Spawn() { var enemy _enemyFactory.CreateEnemy(transform.position, Quaternion.identity); // 无需关心创建的是哪种敌人 } }这样做的好处当要新增一个“飞行兵”类型时你只需要新建一个FlyingEnemy产品类和一个FlyingEnemyFactory工厂资产。Spawner脚本一行都不用改。这完全符合“开闭原则”对扩展开放对修改关闭。踩坑记录工厂模式容易过度设计。如果你的对象创建逻辑非常简单且未来几乎不可能变化直接Instantiate反而更清晰。工厂模式的价值在应对变化时才能最大化体现。另外结合对象池使用工厂是性能优化的标准操作工厂负责首次创建和复杂初始化对象池负责循环利用。2.3 观察者模式事件驱动的通信枢纽观察者模式定义了对象间一种一对多的依赖关系当一个对象主题状态改变时所有依赖它的对象观察者都会得到通知并自动更新。在Unity中Invoke和SendMessage是弱化的观察者模式而C#的event关键字则是其标准实现。但我们需要更强大、更解耦的方案。2.3.1 从Unity内置事件到自定义事件系统Unity自己的UIButton.onClick就是一个典型的观察者模式应用。但当我们业务复杂时需要自己定义事件。直接使用C#事件的问题在于订阅和取消订阅需要严格配对否则会导致内存泄漏持有引用无法释放且事件发送者和接收者依然存在编译时依赖。2.3.2 实现一个健壮、解耦的事件总线Event Bus事件总线是观察者模式的升级应用它作为一个全局的中介者彻底解耦了事件的发布者和订阅者。定义事件基类public abstract class GameEvent { } public class PlayerHealthChangedEvent : GameEvent { public int CurrentHealth; public int MaxHealth; } public class EnemyDefeatedEvent : GameEvent { public Vector3 Position; public int ScoreValue; }实现核心事件总线public class EventBus { private static readonly DictionaryType, System.ActionGameEvent _events new DictionaryType, System.ActionGameEvent(); private static readonly DictionarySystem.Delegate, System.ActionGameEvent _eventLookups new DictionarySystem.Delegate, System.ActionGameEvent(); // 订阅 public static void SubscribeT(System.ActionT handler) where T : GameEvent { if (!_events.ContainsKey(typeof(T))) _events[typeof(T)] null; // 包装处理器避免类型转换问题 System.ActionGameEvent wrappedHandler (e) handler((T)e); _eventLookups[handler] wrappedHandler; _events[typeof(T)] wrappedHandler; } // 取消订阅关键 public static void UnsubscribeT(System.ActionT handler) where T : GameEvent { if (_eventLookups.TryGetValue(handler, out var wrappedHandler)) { if (_events.TryGetValue(typeof(T), out var action)) { action - wrappedHandler; if (action null) _events.Remove(typeof(T)); else _events[typeof(T)] action; } _eventLookups.Remove(handler); } } // 发布 public static void PublishT(T gameEvent) where T : GameEvent { if (_events.TryGetValue(typeof(T), out var action)) { action?.Invoke(gameEvent); } } }这个实现包含了类型安全的订阅/发布和通过查找字典确保正确取消订阅这是避免内存泄漏的关键。在MonoBehaviour中使用public class UIPlayerHealthBar : MonoBehaviour { void OnEnable() { EventBus.SubscribePlayerHealthChangedEvent(OnHealthChanged); } void OnDisable() { EventBus.UnsubscribePlayerHealthChangedEvent(OnHealthChanged); // 必须成对出现 } private void OnHealthChanged(PlayerHealthChangedEvent e) { // 更新血条UI float fillAmount (float)e.CurrentHealth / e.MaxHealth; // ... } } public class Player : MonoBehaviour { public void TakeDamage(int damage) { CurrentHealth - damage; EventBus.Publish(new PlayerHealthChangedEvent { CurrentHealth CurrentHealth, MaxHealth MaxHealth }); } }优势Player类完全不知道谁关心它的血量变化。UIPlayerHealthBar也只关心事件本身。新增一个成就系统血量低于20%时解锁成就只需要新建一个类去订阅同一个事件无需修改Player或UIPlayerHealthBar的代码。血泪教训事件总线虽好但滥用会导致“事件蜘蛛网”难以追踪事件流。务必遵循以下原则1) 事件命名要清晰如PlayerHealthChangedEvent而非HealthEvent2) 避免在事件中传递过大的数据或对象引用以防意外持有3) 在OnEnable/OnDisable或Start/Destroy中严格配对订阅和取消订阅这是Unity生命周期管理下防止空引用和泄漏的生命线。对于非常高频的事件如每帧更新需考虑性能或使用观察者模式的变体如UnityEvent或UniRx这类响应式编程库。3. 模式融合实战构建一个简单的技能系统理论说再多不如一个综合案例。我们来设计一个迷你技能系统融合上述三种模式。需求玩家可以释放火球术技能。火球需要从资源池中创建飞行命中敌人后造成伤害并触发伤害数字UI显示、音效播放和屏幕震动。单例模式的应用服务定位器我们创建几个全局管理器作为服务。// 资源池管理器单例 public class ProjectilePool : MonoBehaviour { public static ProjectilePool Instance { get; private set; } private Dictionarystring, QueueGameObject _pool new Dictionarystring, QueueGameObject(); void Awake() { Instance this; } public GameObject Get(string prefabId) { /* 从池中取或实例化 */ } public void Release(GameObject obj, string prefabId) { /* 回收到池中 */ } } // 音效管理器单例 public class AudioManager : MonoBehaviour { /* 略 */ }工厂模式的应用技能效果工厂火球命中后产生的效果爆炸特效、伤害数字样式可能不同使用工厂创建。public interface ISkillEffect { void Play(Vector3 position); } [CreateAssetMenu] public class ExplosionEffectFactory : ScriptableObject { [SerializeField] private GameObject _fireExplosionPrefab; [SerializeField] private GameObject _iceExplosionPrefab; public ISkillEffect CreateEffect(ElementType element) { // 根据元素类型返回不同的特效处理器 return element ElementType.Fire ? new FireExplosionEffect(_fireExplosionPrefab) : new IceExplosionEffect(_iceExplosionPrefab); } }观察者模式的应用事件驱动响应火球命中敌人是整个系统的核心事件。public class ProjectileHitEvent : GameEvent { public Vector3 HitPoint; public float Damage; public ElementType Element; } // 火球脚本 public class Fireball : MonoBehaviour { void OnCollisionEnter(Collision other) { // 计算伤害... EventBus.Publish(new ProjectileHitEvent { HitPoint transform.position, Damage calculatedDamage, Element ElementType.Fire }); ProjectilePool.Instance.Release(gameObject, Fireball); } } // 多个观察者 public class DamagePopupController : MonoBehaviour { void OnEnable() { EventBus.SubscribeProjectileHitEvent(OnHit); } void OnDisable() { EventBus.UnsubscribeProjectileHitEvent(OnHit); } void OnHit(ProjectileHitEvent e) { /* 在命中点生成伤害数字UI */ } } public class CameraShake : MonoBehaviour { void OnEnable() { EventBus.SubscribeProjectileHitEvent(OnHit); } void OnDisable() { EventBus.UnsubscribeProjectileHitEvent(OnHit); } void OnHit(ProjectileHitEvent e) { if(e.Damage 10) Shake(); } } // 技能效果工厂的消费者也可以作为观察者 public class SkillEffectPlayer : MonoBehaviour { [SerializeField] private ExplosionEffectFactory _effectFactory; void OnEnable() { EventBus.SubscribeProjectileHitEvent(OnHit); } void OnDisable() { EventBus.UnsubscribeProjectileHitEvent(OnHit); } void OnHit(ProjectileHitEvent e) { var effect _effectFactory.CreateEffect(e.Element); effect.Play(e.HitPoint); } }在这个融合案例中三种模式各司其职单例提供了稳定的全局服务访问点对象池、音效工厂封装了复杂对象的创建逻辑技能特效便于扩展新元素观察者事件总线则将技能命中的核心事件与各种响应逻辑UI、相机、特效彻底解耦。添加一个新响应比如命中后触发敌人中毒状态变得极其简单只需要创建一个新的监听类即可实现了高度的可维护性和可扩展性。4. 进阶思考与避坑指南掌握了基本用法后我们需要思考更深层次的问题并避开那些常见的“坑”。4.1 单例模式的替代方案依赖注入框架对于大型项目遍地开花的Instance属性会让代码高度耦合难以进行单元测试。依赖注入DI容器是更优雅的解决方案。以VContainer为例你可以这样注册服务public class GameLifetimeScope : LifetimeScope { protected override void Configure(IContainerBuilder builder) { builder.RegisterIAudioService, AudioManager(Lifetime.Singleton); builder.RegisterIResourceService, AddressableResourceService(Lifetime.Singleton); } } // 在需要的地方通过构造函数注入 public class Player { private readonly IAudioService _audioService; public Player(IAudioService audioService) { _audioService audioService; // 容器自动注入单例实例 } }DI容器帮你管理了这些“单例”的生命周期并且通过接口抽象让Player类不依赖于具体的AudioManager只依赖于IAudioService接口这使得替换实现如换成FmodAudioManager和编写单元测试注入一个Mock对象变得轻而易举。4.2 工厂模式的变体利用Unity的Addressable Assets System当项目资源非常多时使用Resources.Load或直接引用预制体会导致启动加载缓慢。Unity的Addressable系统本质上是一个超级资源工厂。你可以这样使用public class AddressableEnemyFactory { public async UniTaskIEnemy CreateEnemyAsync(string enemyAddressableKey, Vector3 position) { // 异步加载资源Addressable系统内部会处理缓存、依赖和生命周期 var handle Addressables.LoadAssetAsyncGameObject(enemyAddressableKey); await handle.Task; var prefab handle.Result; var obj GameObject.Instantiate(prefab, position, Quaternion.identity); var enemy obj.GetComponentIEnemy(); // 关联句柄与实例便于后续释放 Addressables.Release(handle); // 注意释放时机 return enemy; } }它将资源的加载、实例化、内存管理都封装了起来是大型项目资源管理的工厂模式最佳实践。4.3 观察者模式的性能与调试陷阱性能如果某个事件每帧被发布成百上千次如PositionUpdateEvent使用带泛型字典查找的事件总线可能会有开销。此时可以考虑使用更轻量级的方案如C#原生事件如果订阅者固定且少或者针对高频事件使用专门优化的通道。调试事件流难以追踪是观察者模式的最大缺点。当游戏行为异常时你很难知道是哪个事件在何时被谁触发。解决方案为事件总线添加日志功能在开发阶段记录所有事件的发布和订阅。使用IDE的调试工具在事件发布处设置条件断点。保持事件处理函数的纯洁性避免在处理函数中触发新的事件导致链式反应甚至循环。4.4 模式不是银弹适用才是王道最后也是最重要的一点设计模式是工具箱里的好工具但不是所有问题都要用最复杂的工具去解决。如果你的Manager真的只有一个且全局都需要访问用简单的MonoBehaviour单例没什么问题。如果你的对象创建逻辑就是一次性的Instantiate没必要套一层工厂。如果两个脚本就在同一个GameObject上直接调用方法或使用UnityEvent在Inspector里连线比用事件总线更直观。判断是否使用某个模式的标准是代码的复杂度是否会因为未来的需求变化而显著增加如果答案是肯定的那么提前用模式进行抽象就是有远见的设计如果是否定的那么清晰的直白代码比过度设计的设计模式更有价值。从UnityCsReference中学习不仅是学习他们用了什么模式更是学习他们在何处、为何使用这些模式这才是提升架构设计能力的核心。
Unity设计模式实战：单例、工厂、观察者模式在游戏开发中的应用与源码解析
1. 项目概述为什么Unity开发者必须啃透设计模式如果你在Unity项目里写过超过1000行代码大概率经历过这样的场景一个看似简单的功能随着需求迭代代码文件膨胀到几千行各种Manager、Controller、Handler类之间相互引用牵一发而动全身。想改个UI显示逻辑结果发现要动到数据层、网络层甚至影响到了场景加载。这其实就是典型的“面条式代码”而设计模式就是帮你把这些“面条”梳理成清晰、可维护的“电路板”的工程学方法。这次我们聚焦的“UnityCsReference”是Unity官方在GitHub上开源的C#运行时源码。它不仅是Unity引擎的心脏更是一座设计模式的“活体博物馆”。很多我们日常在Unity中习以为常的API比如GameObject.Find、Resources.Load其背后都蕴含着深刻的设计思想。直接阅读源码可能让人望而生畏但如果我们带着“设计模式”这副眼镜去审视很多复杂的设计会瞬间变得清晰易懂。更重要的是你能学到Unity官方团队是如何在大型、高性能的C#项目中应用这些模式的这是任何第三方教程都无法比拟的实战经验。本指南不会空谈理论我们将紧扣Unity开发中最核心、最高频的三种模式单例、工厂和观察者。我会结合UnityCsReference中的真实案例以及我过去在多个上线项目中踩过的坑为你拆解它们的设计意图、实现变体、适用场景以及最重要的——在Unity这个特殊环境下的“正确打开方式”。无论你是想优化自己的项目架构准备应对更高难度的技术面试还是单纯想提升代码设计能力这篇指南都将提供一条从“知道”到“会用”再到“用得精”的清晰路径。2. 核心设计模式深度解析与Unity适配2.1 单例模式全局访问的利刃与双刃剑单例模式恐怕是Unity开发者最熟悉也最被滥用的模式。它的核心目标是确保一个类只有一个实例并提供一个全局访问点。在Unity中像GameManager、AudioManager、UIManager这类需要贯穿游戏生命周期的管理器使用单例似乎顺理成章。2.1.1 UnityCsReference中的单例实践UnityEngine.Object的启示很多人自己实现单例时第一反应可能就是写个静态的Instance属性。但让我们看看UnityCsReference中更底层的设计。UnityEngine.Object是所有Unity游戏对象的基类它本身并不是一个传统意义上的单例类但它管理着一个全局的“实例ID到对象”的映射表。这个映射表本身就是一个需要全局唯一访问的核心资源管理器。Unity通过内部的Object.Internal_GetInstanceID等Native方法确保了这个映射表的唯一性和线程安全。这给我们的启示是单例的核心是“唯一实例”和“可控的全局访问”而不一定非得是一个我们肉眼可见的MonoBehaviour挂载在场景里。2.1.2 三种主流实现方案与陷阱分析经典懒汉式Lazy Initializationpublic class GameManager { private static GameManager _instance; public static GameManager Instance { get { if (_instance null) { _instance new GameManager(); } return _instance; } } private GameManager() { } }优点简单直观用到时才创建。陷阱非线程安全。在Unity的主线程中虽然问题不大但如果你涉及多线程数据加载如使用Task.Run就可能创建出多个实例。绝对不要在Unity的Awake或Start里用这种方式跨脚本访问因为脚本初始化顺序不确定可能导致空引用。MonoBehaviour挂载式public class AudioManager : MonoBehaviour { public static AudioManager Instance { get; private set; } void Awake() { if (Instance ! null Instance ! this) { Destroy(gameObject); // 关键销毁新创建的重复实例 return; } Instance this; DontDestroyOnLoad(gameObject); // 关键跨场景保持 } }优点能利用Unity生命周期Awake,OnDestroy方便挂载组件和协程。陷阱必须手动处理重复创建和销毁。DontDestroyOnLoad用不好会导致场景切换后残留多个管理器。强烈建议在Awake最开始就进行判空和销毁操作这是血的教训。.NET Lazy 式推荐public class ConfigManager { private static readonly LazyConfigManager _lazyInstance new LazyConfigManager(() new ConfigManager()); public static ConfigManager Instance _lazyInstance.Value; private ConfigManager() { // 初始化配置 } }优点线程安全延迟初始化代码简洁。这是纯C#类单例的最佳实践。注意它创建的是普通的C#对象不是GameObject。适合管理数据、配置等无需Unity生命周期的服务。重要心得不要为了用单例而用单例。单例本质上是“全局状态”它会增加代码的耦合度让单元测试变得困难。在架构设计时可以优先考虑依赖注入DI容器比如使用Zenject或VContainer将“单例服务”以接口形式注入这样既能保证唯一性又解耦了直接依赖便于测试和替换。2.2 工厂模式解耦对象创建的魔法工厂模式的核心是将对象的创建过程封装起来调用者无需关心具体的创建细节。在Unity中我们时刻都在“创建对象”实例化预制体、加载资源、生成敌人。直接用GameObject.Instantiate和Resources.Load不是不行但业务逻辑会和具体的资源路径、创建参数紧密耦合难以维护和扩展。2.2.1 UnityCsReference中的工厂思想ObjectFactory与Pooling在UnityCsReference中你找不到一个叫GameObjectFactory的类但工厂思想无处不在。例如对象池Object Pooling就是一种特殊的工厂它管理着对象的创建和回收。更底层的各种Native Object纹理、网格、材质的创建都是由引擎内部的工厂机制管理的它对上层提供了统一的接口隐藏了不同平台如DX、OpenGL、Metal下资源创建的复杂差异。这告诉我们工厂模式不仅是“new一个对象”更是对创建逻辑复杂性和差异性的封装。2.2.2 实战构建一个可扩展的敌人生成工厂假设我们有多种敌人近战兵、弓箭手、法师。最简单的做法是在SpawnPoint脚本里写一堆if-else。让我们用工厂模式重构定义产品接口public interface IEnemy { void Initialize(EnemyData data); void PerformAction(); }实现具体产品public class MeleeEnemy : MonoBehaviour, IEnemy { ... } public class ArcherEnemy : MonoBehaviour, IEnemy { ... } public class MageEnemy : MonoBehaviour, IEnemy { ... }创建抽象工厂public abstract class EnemyFactory : MonoBehaviour { public abstract IEnemy CreateEnemy(Vector3 position, Quaternion rotation); // 可以包含通用的预处理逻辑如播放生成特效、注册到管理器 }实现具体工厂[CreateAssetMenu(fileName MeleeEnemyFactory, menuName Factories/Enemy/Melee)] public class MeleeEnemyFactory : EnemyFactory { [SerializeField] private MeleeEnemy _prefab; // 在Inspector中拖拽赋值 [SerializeField] private EnemyData _defaultData; public override IEnemy CreateEnemy(Vector3 position, Quaternion rotation) { var enemyObj Instantiate(_prefab, position, rotation); var enemy enemyObj.GetComponentIEnemy(); enemy.Initialize(_defaultData); // 可以在这里注入依赖如设置AI、血量等 return enemy; } }这里用到了ScriptableObject作为工厂配置载体这是一个Unity特有的强大特性。它允许我们将工厂的配置预制体、数据作为资产保存在项目中无需硬编码也便于策划同学调整。使用工厂public class Spawner : MonoBehaviour { [SerializeField] private EnemyFactory _enemyFactory; // 拖入具体的工厂Asset public void Spawn() { var enemy _enemyFactory.CreateEnemy(transform.position, Quaternion.identity); // 无需关心创建的是哪种敌人 } }这样做的好处当要新增一个“飞行兵”类型时你只需要新建一个FlyingEnemy产品类和一个FlyingEnemyFactory工厂资产。Spawner脚本一行都不用改。这完全符合“开闭原则”对扩展开放对修改关闭。踩坑记录工厂模式容易过度设计。如果你的对象创建逻辑非常简单且未来几乎不可能变化直接Instantiate反而更清晰。工厂模式的价值在应对变化时才能最大化体现。另外结合对象池使用工厂是性能优化的标准操作工厂负责首次创建和复杂初始化对象池负责循环利用。2.3 观察者模式事件驱动的通信枢纽观察者模式定义了对象间一种一对多的依赖关系当一个对象主题状态改变时所有依赖它的对象观察者都会得到通知并自动更新。在Unity中Invoke和SendMessage是弱化的观察者模式而C#的event关键字则是其标准实现。但我们需要更强大、更解耦的方案。2.3.1 从Unity内置事件到自定义事件系统Unity自己的UIButton.onClick就是一个典型的观察者模式应用。但当我们业务复杂时需要自己定义事件。直接使用C#事件的问题在于订阅和取消订阅需要严格配对否则会导致内存泄漏持有引用无法释放且事件发送者和接收者依然存在编译时依赖。2.3.2 实现一个健壮、解耦的事件总线Event Bus事件总线是观察者模式的升级应用它作为一个全局的中介者彻底解耦了事件的发布者和订阅者。定义事件基类public abstract class GameEvent { } public class PlayerHealthChangedEvent : GameEvent { public int CurrentHealth; public int MaxHealth; } public class EnemyDefeatedEvent : GameEvent { public Vector3 Position; public int ScoreValue; }实现核心事件总线public class EventBus { private static readonly DictionaryType, System.ActionGameEvent _events new DictionaryType, System.ActionGameEvent(); private static readonly DictionarySystem.Delegate, System.ActionGameEvent _eventLookups new DictionarySystem.Delegate, System.ActionGameEvent(); // 订阅 public static void SubscribeT(System.ActionT handler) where T : GameEvent { if (!_events.ContainsKey(typeof(T))) _events[typeof(T)] null; // 包装处理器避免类型转换问题 System.ActionGameEvent wrappedHandler (e) handler((T)e); _eventLookups[handler] wrappedHandler; _events[typeof(T)] wrappedHandler; } // 取消订阅关键 public static void UnsubscribeT(System.ActionT handler) where T : GameEvent { if (_eventLookups.TryGetValue(handler, out var wrappedHandler)) { if (_events.TryGetValue(typeof(T), out var action)) { action - wrappedHandler; if (action null) _events.Remove(typeof(T)); else _events[typeof(T)] action; } _eventLookups.Remove(handler); } } // 发布 public static void PublishT(T gameEvent) where T : GameEvent { if (_events.TryGetValue(typeof(T), out var action)) { action?.Invoke(gameEvent); } } }这个实现包含了类型安全的订阅/发布和通过查找字典确保正确取消订阅这是避免内存泄漏的关键。在MonoBehaviour中使用public class UIPlayerHealthBar : MonoBehaviour { void OnEnable() { EventBus.SubscribePlayerHealthChangedEvent(OnHealthChanged); } void OnDisable() { EventBus.UnsubscribePlayerHealthChangedEvent(OnHealthChanged); // 必须成对出现 } private void OnHealthChanged(PlayerHealthChangedEvent e) { // 更新血条UI float fillAmount (float)e.CurrentHealth / e.MaxHealth; // ... } } public class Player : MonoBehaviour { public void TakeDamage(int damage) { CurrentHealth - damage; EventBus.Publish(new PlayerHealthChangedEvent { CurrentHealth CurrentHealth, MaxHealth MaxHealth }); } }优势Player类完全不知道谁关心它的血量变化。UIPlayerHealthBar也只关心事件本身。新增一个成就系统血量低于20%时解锁成就只需要新建一个类去订阅同一个事件无需修改Player或UIPlayerHealthBar的代码。血泪教训事件总线虽好但滥用会导致“事件蜘蛛网”难以追踪事件流。务必遵循以下原则1) 事件命名要清晰如PlayerHealthChangedEvent而非HealthEvent2) 避免在事件中传递过大的数据或对象引用以防意外持有3) 在OnEnable/OnDisable或Start/Destroy中严格配对订阅和取消订阅这是Unity生命周期管理下防止空引用和泄漏的生命线。对于非常高频的事件如每帧更新需考虑性能或使用观察者模式的变体如UnityEvent或UniRx这类响应式编程库。3. 模式融合实战构建一个简单的技能系统理论说再多不如一个综合案例。我们来设计一个迷你技能系统融合上述三种模式。需求玩家可以释放火球术技能。火球需要从资源池中创建飞行命中敌人后造成伤害并触发伤害数字UI显示、音效播放和屏幕震动。单例模式的应用服务定位器我们创建几个全局管理器作为服务。// 资源池管理器单例 public class ProjectilePool : MonoBehaviour { public static ProjectilePool Instance { get; private set; } private Dictionarystring, QueueGameObject _pool new Dictionarystring, QueueGameObject(); void Awake() { Instance this; } public GameObject Get(string prefabId) { /* 从池中取或实例化 */ } public void Release(GameObject obj, string prefabId) { /* 回收到池中 */ } } // 音效管理器单例 public class AudioManager : MonoBehaviour { /* 略 */ }工厂模式的应用技能效果工厂火球命中后产生的效果爆炸特效、伤害数字样式可能不同使用工厂创建。public interface ISkillEffect { void Play(Vector3 position); } [CreateAssetMenu] public class ExplosionEffectFactory : ScriptableObject { [SerializeField] private GameObject _fireExplosionPrefab; [SerializeField] private GameObject _iceExplosionPrefab; public ISkillEffect CreateEffect(ElementType element) { // 根据元素类型返回不同的特效处理器 return element ElementType.Fire ? new FireExplosionEffect(_fireExplosionPrefab) : new IceExplosionEffect(_iceExplosionPrefab); } }观察者模式的应用事件驱动响应火球命中敌人是整个系统的核心事件。public class ProjectileHitEvent : GameEvent { public Vector3 HitPoint; public float Damage; public ElementType Element; } // 火球脚本 public class Fireball : MonoBehaviour { void OnCollisionEnter(Collision other) { // 计算伤害... EventBus.Publish(new ProjectileHitEvent { HitPoint transform.position, Damage calculatedDamage, Element ElementType.Fire }); ProjectilePool.Instance.Release(gameObject, Fireball); } } // 多个观察者 public class DamagePopupController : MonoBehaviour { void OnEnable() { EventBus.SubscribeProjectileHitEvent(OnHit); } void OnDisable() { EventBus.UnsubscribeProjectileHitEvent(OnHit); } void OnHit(ProjectileHitEvent e) { /* 在命中点生成伤害数字UI */ } } public class CameraShake : MonoBehaviour { void OnEnable() { EventBus.SubscribeProjectileHitEvent(OnHit); } void OnDisable() { EventBus.UnsubscribeProjectileHitEvent(OnHit); } void OnHit(ProjectileHitEvent e) { if(e.Damage 10) Shake(); } } // 技能效果工厂的消费者也可以作为观察者 public class SkillEffectPlayer : MonoBehaviour { [SerializeField] private ExplosionEffectFactory _effectFactory; void OnEnable() { EventBus.SubscribeProjectileHitEvent(OnHit); } void OnDisable() { EventBus.UnsubscribeProjectileHitEvent(OnHit); } void OnHit(ProjectileHitEvent e) { var effect _effectFactory.CreateEffect(e.Element); effect.Play(e.HitPoint); } }在这个融合案例中三种模式各司其职单例提供了稳定的全局服务访问点对象池、音效工厂封装了复杂对象的创建逻辑技能特效便于扩展新元素观察者事件总线则将技能命中的核心事件与各种响应逻辑UI、相机、特效彻底解耦。添加一个新响应比如命中后触发敌人中毒状态变得极其简单只需要创建一个新的监听类即可实现了高度的可维护性和可扩展性。4. 进阶思考与避坑指南掌握了基本用法后我们需要思考更深层次的问题并避开那些常见的“坑”。4.1 单例模式的替代方案依赖注入框架对于大型项目遍地开花的Instance属性会让代码高度耦合难以进行单元测试。依赖注入DI容器是更优雅的解决方案。以VContainer为例你可以这样注册服务public class GameLifetimeScope : LifetimeScope { protected override void Configure(IContainerBuilder builder) { builder.RegisterIAudioService, AudioManager(Lifetime.Singleton); builder.RegisterIResourceService, AddressableResourceService(Lifetime.Singleton); } } // 在需要的地方通过构造函数注入 public class Player { private readonly IAudioService _audioService; public Player(IAudioService audioService) { _audioService audioService; // 容器自动注入单例实例 } }DI容器帮你管理了这些“单例”的生命周期并且通过接口抽象让Player类不依赖于具体的AudioManager只依赖于IAudioService接口这使得替换实现如换成FmodAudioManager和编写单元测试注入一个Mock对象变得轻而易举。4.2 工厂模式的变体利用Unity的Addressable Assets System当项目资源非常多时使用Resources.Load或直接引用预制体会导致启动加载缓慢。Unity的Addressable系统本质上是一个超级资源工厂。你可以这样使用public class AddressableEnemyFactory { public async UniTaskIEnemy CreateEnemyAsync(string enemyAddressableKey, Vector3 position) { // 异步加载资源Addressable系统内部会处理缓存、依赖和生命周期 var handle Addressables.LoadAssetAsyncGameObject(enemyAddressableKey); await handle.Task; var prefab handle.Result; var obj GameObject.Instantiate(prefab, position, Quaternion.identity); var enemy obj.GetComponentIEnemy(); // 关联句柄与实例便于后续释放 Addressables.Release(handle); // 注意释放时机 return enemy; } }它将资源的加载、实例化、内存管理都封装了起来是大型项目资源管理的工厂模式最佳实践。4.3 观察者模式的性能与调试陷阱性能如果某个事件每帧被发布成百上千次如PositionUpdateEvent使用带泛型字典查找的事件总线可能会有开销。此时可以考虑使用更轻量级的方案如C#原生事件如果订阅者固定且少或者针对高频事件使用专门优化的通道。调试事件流难以追踪是观察者模式的最大缺点。当游戏行为异常时你很难知道是哪个事件在何时被谁触发。解决方案为事件总线添加日志功能在开发阶段记录所有事件的发布和订阅。使用IDE的调试工具在事件发布处设置条件断点。保持事件处理函数的纯洁性避免在处理函数中触发新的事件导致链式反应甚至循环。4.4 模式不是银弹适用才是王道最后也是最重要的一点设计模式是工具箱里的好工具但不是所有问题都要用最复杂的工具去解决。如果你的Manager真的只有一个且全局都需要访问用简单的MonoBehaviour单例没什么问题。如果你的对象创建逻辑就是一次性的Instantiate没必要套一层工厂。如果两个脚本就在同一个GameObject上直接调用方法或使用UnityEvent在Inspector里连线比用事件总线更直观。判断是否使用某个模式的标准是代码的复杂度是否会因为未来的需求变化而显著增加如果答案是肯定的那么提前用模式进行抽象就是有远见的设计如果是否定的那么清晰的直白代码比过度设计的设计模式更有价值。从UnityCsReference中学习不仅是学习他们用了什么模式更是学习他们在何处、为何使用这些模式这才是提升架构设计能力的核心。
