1. 项目概述为什么要在Unity框架中思考命令模式如果你在Unity里做过几个项目尤其是那种功能越加越多、代码越写越乱的你大概率会和我有一样的感受脚本之间的调用关系像一团乱麻。一个UI按钮点击直接去调用Player的移动方法一个敌人的死亡事件又直接去修改GameManager的分数。这种“硬编码”的直接调用在项目初期确实快但到了中后期维护和扩展就成了噩梦。今天我想和你深入聊聊的就是在我们搭建Unity框架时一个绕不开的核心设计模式——命令模式Command Pattern。这不仅仅是“知道有这么个模式”而是真正理解它如何解决我们实际开发中的痛点以及如何在框架层面优雅地落地。命令模式的核心思想用大白话讲就是把一个“请求”或“操作”封装成一个独立的对象。这个对象里包含了执行这个操作所需的所有信息。这样做的好处是发出请求的对象比如一个按钮不需要知道具体谁来执行、怎么执行它只需要创建一个命令对象并“发送”出去就行了。这听起来有点抽象但在Unity游戏开发里这简直是解耦的神器。想象一下你的输入系统、UI系统、游戏逻辑系统之间不再直接纠缠而是通过一个个清晰的命令对象来通信代码的清晰度和可维护性会提升好几个档次。接下来我会结合从零开始搭建框架的实践拆解命令模式的几种典型应用场景、实现细节以及那些只有踩过坑才知道的注意事项。2. 命令模式的核心价值与Unity框架的契合点2.1 从“直接调用”到“命令封装”的思维转变在没接触命令模式之前我们最熟悉的代码可能是这样的public class StartButton : MonoBehaviour { public PlayerController player; void OnClick() { player.MoveToTarget(); // 直接调用 } }这段代码的问题显而易见StartButton紧紧依赖着PlayerController。如果我想把移动逻辑换到另一个类或者想在移动前后加一些日志、校验就必须来修改StartButton。这违反了设计原则中的“开闭原则”对扩展开放对修改关闭。引入命令模式后代码变成了这样public class StartButton : MonoBehaviour { void OnClick() { var command new MovePlayerCommand(targetPosition); CommandSystem.Execute(command); // 发送命令不关心谁执行 } }StartButton现在只负责创建和发出一个MovePlayerCommand命令对象。至于这个命令是谁执行的、怎么执行的按钮完全不关心。这个简单的转变带来了几个立竿见影的好处首先是解耦发送者和接收者之间没有了直接的引用关系其次是可扩展性我可以很容易地增加新的命令如JumpCommand,AttackCommand而无需修改现有的发送者代码最后是可复用性这个命令对象可以被序列化、记录、排队甚至实现撤销/重做功能。2.2 命令模式在游戏架构中的典型应用场景在Unity游戏框架中命令模式至少有以下几个非常适合的应用场景输入处理这是最经典的应用。键盘、鼠标、手柄的输入被映射成一个个具体的命令如MoveCommand,JumpCommand,FireCommand。输入管理器只负责生成命令并放入队列具体的执行逻辑由对应的命令对象处理。这样更改按键配置或支持新的输入设备会变得非常容易。UI系统每个UI按钮的点击事件都可以绑定到一个命令上。比如“开始游戏”、“打开设置”、“购买道具”。UI层只负责视觉交互和触发命令具体的业务逻辑加载场景、打开面板、扣款封装在命令内部。这保证了UI代码的纯粹性。网络同步在网络游戏中玩家的操作可以被封装成命令对象然后序列化后发送给服务器。服务器验证并执行后再将结果或命令广播给其他客户端。命令对象成为了客户端与服务器之间通信的协议单元。AI行为AI的决策逻辑可以产出命令序列。例如一个“攻击”决策可能产生ApproachEnemyCommand-AttackCommand-RetreatCommand这样一个命令链。这使得AI的行为模块化且易于调试。事务与撤销系统在编辑器工具或策略游戏中用户的每一步操作如放置建筑、移动单位都可以封装为命令。这些命令被保存在历史栈中轻松实现撤销(Undo)和重做(Redo)功能。理解这些场景能帮助我们在设计框架时不是生搬硬套模式而是有目的地将命令模式嵌入到架构的合适层级中。3. 命令模式的基础实现与框架集成3.1 定义命令接口与基础命令类任何模式落地首先要定义一套约定。在我们的框架中一个最基础的命令接口可能长这样public interface ICommand { void Execute(); }是的非常简单只有一个Execute方法。但这就是契约的核心任何可执行的操作都必须实现这个方法。然而在实际游戏中命令往往需要参数也需要知道执行的结果。因此一个更实用的基础命令抽象类可能是这样的public abstract class Command : ICommand { // 命令执行状态 public enum Status { Pending, Success, Failed } public Status CommandStatus { get; protected set; } Status.Pending; // 核心执行方法 public abstract void Execute(); // 可选用于撤销操作 public virtual void Undo() { } // 可选命令是否可执行的前置检查 public virtual bool CanExecute() { return true; } }这里我们引入了命令状态这对于需要异步执行或需要结果反馈的命令非常有用。CanExecute方法可以在执行前进行条件校验比如“玩家法力值是否足够释放这个技能”。接下来我们实现一个具体的命令。以“移动玩家”为例public class MovePlayerCommand : Command { private Vector3 _targetPosition; private PlayerController _player; // 依赖通常通过框架的IOC容器获取 public MovePlayerCommand(Vector3 targetPosition) { _targetPosition targetPosition; } public override void Execute() { if (!CanExecute()) { CommandStatus Status.Failed; return; } // 通过框架提供的服务定位器或IOC容器获取PlayerController实例 // 避免在命令构造函数中硬编码实现更好的解耦 _player ServiceLocator.GetPlayerController(); if (_player null) { CommandStatus Status.Failed; Debug.LogError(MovePlayerCommand: PlayerController not found!); return; } _player.MoveTo(_targetPosition); CommandStatus Status.Success; Debug.Log($Player moved to {_targetPosition}); } public override bool CanExecute() { // 检查玩家是否存活、目标点是否可达等 return true; // 简化示例 } }注意在这个实现中命令对象内部并没有在构造时直接持有PlayerController的引用而是在Execute方法中通过一个ServiceLocator服务定位器动态获取。这是框架集成中非常关键的一步它彻底切断了命令与具体执行者之间的编译时依赖使得命令类可以在任何上下文中被创建和序列化。3.2 构建命令的执行系统Command System有了命令对象我们需要一个中枢系统来调度和执行它们。这个CommandSystem是框架的核心组件之一。它的职责包括接收并缓存命令。管理命令队列用于实现命令排队执行。提供执行命令的入口。可能还需要管理命令历史用于撤销。一个简易但功能完整的CommandSystem实现如下public class CommandSystem : MonoBehaviour { private static CommandSystem _instance; public static CommandSystem Instance _instance; // 命令执行队列支持异步和顺序执行 private QueueCommand _commandQueue new QueueCommand(); // 命令历史栈用于撤销 private StackCommand _historyStack new StackCommand(); private void Awake() { if (_instance ! null _instance ! this) { Destroy(this.gameObject); return; } _instance this; DontDestroyOnLoad(this.gameObject); // 常驻跨场景 } private void Update() { // 每帧处理队列中的命令同步执行 ProcessCommandQueue(); } /// summary /// 立即执行一个命令 /// /summary public void ExecuteCommand(Command command) { if (command null || !command.CanExecute()) return; command.Execute(); _historyStack.Push(command); // 记录历史 // 可以根据命令状态进行事件通知例如 // EventSystem.Instance.Publish(new CommandExecutedEvent(command)); } /// summary /// 将命令加入队列等待执行 /// /summary public void EnqueueCommand(Command command) { if (command ! null command.CanExecute()) { _commandQueue.Enqueue(command); } } /// summary /// 处理命令队列 /// /summary private void ProcessCommandQueue() { while (_commandQueue.Count 0) { var cmd _commandQueue.Dequeue(); ExecuteCommand(cmd); } } /// summary /// 撤销上一步操作 /// /summary public void Undo() { if (_historyStack.Count 0) { var lastCommand _historyStack.Pop(); lastCommand.Undo(); } } // 清空队列和历史场景切换时可能需要 public void Clear() { _commandQueue.Clear(); _historyStack.Clear(); } }这个系统提供了两种执行方式ExecuteCommand立即执行和EnqueueCommand加入队列在Update中顺序执行。队列机制对于需要保证顺序性或避免在同一帧内执行过多逻辑的场景非常有用。历史栈则为实现撤销功能打下了基础。3.3 与框架其他模块的协作IOC容器与事件系统一个成熟的框架不会让CommandSystem孤立存在。它需要与框架的其他核心模块协同工作。1. 与IOC控制反转容器集成上面例子中MovePlayerCommand通过ServiceLocator.GetPlayerController()来获取执行者。在一个更完善的框架中我们通常会使用IOC容器进行依赖注入。我们可以改造命令的创建和执行方式public class MovePlayerCommand : Command { [Inject] // 依赖注入标记 private PlayerController _player; private Vector3 _targetPosition; public MovePlayerCommand(Vector3 targetPosition) { _targetPosition targetPosition; } public override void Execute() { // 注入的_player已由框架的IOC容器在命令执行前自动赋值 _player.MoveTo(_targetPosition); CommandStatus Status.Success; } } // 在CommandSystem中执行命令前先进行依赖注入 public void ExecuteCommand(Command command) { // 使用框架的IOC容器解析并注入命令的依赖 FrameworkContainer.Inject(command); command.Execute(); _historyStack.Push(command); }这样命令类本身不需要关心依赖从哪里来框架的IOC容器负责在运行时“注入”它所需的服务。这极大地提高了命令类的可测试性和可移植性。2. 与事件系统集成命令的执行往往伴随着状态改变其他系统可能需要对此做出反应。例如玩家移动后小地图需要更新任务系统可能需要检查是否到达了某个地点。我们可以通过事件系统来广播命令执行的结果而不是让命令直接去调用这些系统。public override void Execute() { _player.MoveTo(_targetPosition); CommandStatus Status.Success; // 发布一个事件而不是直接调用其他模块 EventSystem.Instance.Publish(new PlayerMovedEvent(_player.transform.position, _targetPosition)); }监听PlayerMovedEvent的系统如小地图系统、音效系统、成就系统会自行处理这个事件。这样命令系统与游戏的其他逻辑进一步解耦架构变得更加清晰和灵活。4. 进阶实践参数化命令、异步命令与撤销重做4.1 实现灵活的参数化命令基础命令只能执行固定操作。但在游戏中我们经常需要执行“对目标造成X点伤害”或“将物品A移动到位置B”这类带参数的操作。我们可以通过泛型来增强命令的灵活性。首先定义一个带参数的命令接口public interface ICommandT { void Execute(T parameter); }但更常见的做法是在基础Command类中增加一个泛型参数或者创建专门的参数化命令基类。一种实践是使用System.Action或Func委托来封装执行逻辑实现极度灵活的命令public class ActionCommand : Command { private Action _action; public ActionCommand(Action action) { _action action; } public override void Execute() { _action?.Invoke(); CommandStatus Status.Success; } } // 使用方式可以快速创建简单命令无需定义新类 var cmd new ActionCommand(() Debug.Log(Hello from Command!)); CommandSystem.Instance.ExecuteCommand(cmd);对于需要参数的情况可以定义ActionCommandTpublic class ActionCommandT : Command { private ActionT _action; private T _parameter; public ActionCommand(ActionT action, T parameter) { _action action; _parameter parameter; } public override void Execute() { _action?.Invoke(_parameter); CommandStatus Status.Success; } }这种方式的优点是极其灵活和快捷适合逻辑简单的命令。缺点是失去了强类型检查并且命令的逻辑分散在各处不利于复杂逻辑的封装和管理。在框架中我通常建议将核心的、可复用的业务命令定义为具体的类如BuyItemCommand,CastSkillCommand而将一些临时的、UI相关的简单操作用ActionCommand快速实现。4.2 处理异步操作命令游戏开发中充斥着异步操作加载场景、从服务器请求数据、播放一段动画并等待结束。传统的Execute()同步方法无法很好地处理这些情况。我们需要支持异步命令。一种常见的实现是引入ExecuteAsync方法并配合async/awaitpublic abstract class AsyncCommand : Command { public override void Execute() { // 对于异步命令同步Execute可能只是启动异步任务 ExecuteAsync().Forget(); // 注意需要处理Fire and forget的异常 } public abstract Task ExecuteAsync(); } public class LoadSceneCommand : AsyncCommand { private string _sceneName; public LoadSceneCommand(string sceneName) { _sceneName sceneName; } public override async Task ExecuteAsync() { CommandStatus Status.Pending; var asyncOp SceneManager.LoadSceneAsync(_sceneName); while (!asyncOp.isDone) { // 可以在这里更新加载进度条 await Task.Yield(); } CommandStatus Status.Success; } }在CommandSystem中我们需要妥善管理这些异步任务避免它们被意外取消或造成资源泄漏。可以维护一个正在进行的异步命令列表并在场景切换或游戏退出时妥善清理。实操心得异步命令的陷阱使用异步命令时最大的坑是生命周期管理。如果一个异步命令还在执行中但发出命令的对象如一个UI界面已经被销毁了就可能引发空引用异常。我的经验是在命令内部访问任何外部对象尤其是MonoBehaviour时都要进行空值检查或者使用CancellationToken来支持取消操作。另外Unity的协程Coroutine也是一种实现异步命令的常见方式可以与ICommand接口结合但需要注意协程不能直接在非MonoBehaviour对象中启动通常需要借助一个MonoBehaviour代理。4.3 实现撤销与重做功能撤销/重做是命令模式最迷人的特性之一尤其在编辑器工具或回合制策略游戏中。实现的基础在于命令不仅要执行还要知道如何撤销自己。我们需要增强我们的基础命令类public abstract class UndoableCommand : Command { // 记录执行前的状态用于撤销 public abstract void CaptureSnapshot(); // 执行命令 public override abstract void Execute(); // 撤销命令恢复到Snapshot的状态 public override abstract void Undo(); }以“移动游戏对象”命令为例public class MoveGameObjectCommand : UndoableCommand { private GameObject _target; private Vector3 _fromPosition; private Vector3 _toPosition; public MoveGameObjectCommand(GameObject target, Vector3 toPosition) { _target target; _toPosition toPosition; } public override void CaptureSnapshot() { _fromPosition _target.transform.position; } public override void Execute() { CaptureSnapshot(); // 执行前先捕获状态 _target.transform.position _toPosition; CommandStatus Status.Success; } public override void Undo() { _target.transform.position _fromPosition; CommandStatus Status.Pending; // 撤销后状态回退 } }在CommandSystem中我们需要维护两个栈_undoStack历史栈和_redoStack重做栈。public void ExecuteCommand(UndoableCommand command) { command.Execute(); _undoStack.Push(command); _redoStack.Clear(); // 执行新命令后重做栈清空 } public void Undo() { if (_undoStack.Count 0) { var cmd _undoStack.Pop(); cmd.Undo(); _redoStack.Push(cmd); // 被撤销的命令放入重做栈 } } public void Redo() { if (_redoStack.Count 0) { var cmd _redoStack.Pop(); cmd.Execute(); // 重做就是再次执行 _undoStack.Push(cmd); } }注意事项快照的深度与性能CaptureSnapshot的实现需要谨慎。对于简单的变换操作保存位置、旋转、缩放是可行的。但对于复杂的对象状态如一整个单位的属性、背包的所有物品进行深拷贝Deep Copy来保存快照可能会带来巨大的性能开销和内存压力。在实践中有几种优化策略1) 对于复杂对象实现增量快照只记录改变的部分2) 使用命令模式与备忘录模式Memento Pattern结合让对象自己提供创建和恢复快照的方法3) 限制撤销栈的深度只保留最近N步操作。5. 框架层面的命令模式优化与设计思考5.1 命令工厂与集中管理当项目中有成百上千个命令时直接在代码各处new命令对象会带来维护问题。我们可以引入一个简单的命令工厂来集中管理命令的创建。public static class CommandFactory { public static ICommand CreateMoveCommand(Vector3 target) { return new MovePlayerCommand(target); } public static ICommand CreateAttackCommand(Unit target) { return new AttackCommand(target); } // ... 其他命令 }使用工厂的好处是如果命令的创建逻辑需要改变例如需要注入额外的依赖只需要修改工厂方法即可。更进一步可以利用反射或IOC容器实现自动注册和发现命令实现更动态的命令管理。5.2 命令与查询职责分离在更清晰的架构中我们通常遵循命令查询职责分离原则。命令Command用于修改状态它不返回数据或只返回执行成功与否。查询Query用于获取数据而不产生副作用。在我们的框架中可以明确区分ICommand和IQuery接口。public interface IQueryTResult { TResult Execute(); }例如一个获取玩家分数的查询public class GetPlayerScoreQuery : IQueryint { [Inject] private PlayerDataModel _playerData; public int Execute() { return _playerData.Score; } }在架构中命令和查询可以通过同一个“处理器”或“总线”来发送但内部路由到不同的执行管道这有助于保持代码的清晰和可测试性。5.3 命令的日志、回放与测试由于命令是独立的对象它天然支持一些高级功能日志记录在CommandSystem.ExecuteCommand中可以很容易地将每个命令及其参数序列化后写入日志文件。这对于调试复杂的用户操作流程或线上问题排查至关重要。操作回放将一系列命令序列化存储下来就可以在任意时刻“回放”整个游戏过程。这对于制作游戏预告片、自动化测试或实现“观战”功能非常有价值。单元测试命令对象是纯逻辑的或者依赖可以被注入非常适合进行单元测试。你可以轻松地创建一个命令注入模拟的依赖然后验证命令执行后这些依赖的状态是否如预期般改变。6. 常见问题、踩坑实录与性能考量6.1 命令对象的生命周期与内存管理在C#中频繁创建和销毁大量的小型命令对象可能会触发垃圾回收导致游戏卡顿。对于每帧都可能产生大量命令的场景如实时输入处理需要考虑对象池优化。public class CommandPoolT where T : Command, new() { private StackT _pool new StackT(); public T Get() { if (_pool.Count 0) return _pool.Pop(); return new T(); } public void Release(T command) { command.Reset(); // 需要命令实现Reset方法清理内部状态 _pool.Push(command); } }对于MoveCommand这类简单命令使用对象池可以显著减少GC压力。但要注意如果命令内部持有对MonoBehaviour等Unity引擎对象的引用在释放回池时必须清空这些引用防止内存泄漏。6.2 命令执行顺序与依赖问题当多个命令被加入队列时它们的执行顺序是FIFO。但有些命令之间可能存在依赖关系。例如“打开宝箱”命令必须在“玩家走到宝箱前”命令执行成功后才能执行。一种解决方案是引入“复合命令”或“命令链”。public class SequentialCommand : Command { private ListCommand _subCommands new ListCommand(); private int _currentIndex 0; public void AddCommand(Command cmd) { _subCommands.Add(cmd); } public override void Execute() { ExecuteNext(); } private void ExecuteNext() { if (_currentIndex _subCommands.Count) { var cmd _subCommands[_currentIndex]; cmd.Execute(); // 假设命令是同步的简单顺序执行 // 如果是异步命令则需要更复杂的回调机制 _currentIndex; ExecuteNext(); } else { CommandStatus Status.Success; } } }更复杂的依赖关系可能需要引入有向无环图来管理命令的执行拓扑顺序。6.3 网络同步中的命令一致性在网络游戏中命令模式是同步玩家操作的重要手段。但这里有一个经典问题如何保证所有客户端在相同游戏状态下执行相同命令后得到相同的结果这要求命令必须是确定性的。命令的执行逻辑不能依赖于本地时间、随机数除非使用同步的随机种子或浮点数精度差异。通常服务器是权威的它验证并广播命令所有客户端根据广播的命令序列进行模拟。6.4 过度设计警告命令模式非常强大但切忌滥用。不是每一个函数调用都需要封装成命令。如果一段逻辑只在一个地方调用且没有解耦、撤销、日志等需求那么直接调用可能更简单明了。引入命令模式会增加代码的抽象层次和类的数量。我的经验法则是当发现多个发送者需要调用同一个操作或者一个操作需要在不同时间、以不同方式被调用或者你需要记录、撤销操作时命令模式就该登场了。7. 实战在框架中整合命令模式的完整流程让我们以一个具体的例子串联起命令模式在框架中的使用流程。假设我们要实现一个功能玩家点击UI按钮消耗金币购买一件道具。第一步定义命令public class PurchaseItemCommand : Command { [Inject] private IInventorySystem _inventorySystem; [Inject] private ICurrencySystem _currencySystem; public string ItemId { get; private set; } public PurchaseItemCommand(string itemId) { ItemId itemId; } public override bool CanExecute() { var itemPrice _inventorySystem.GetItemPrice(ItemId); return _currencySystem.HasEnoughCoins(itemPrice); } public override void Execute() { if (!CanExecute()) { CommandStatus Status.Failed; EventSystem.Instance.Publish(new PurchaseFailedEvent(金币不足)); return; } var itemPrice _inventorySystem.GetItemPrice(ItemId); _currencySystem.SpendCoins(itemPrice); _inventorySystem.AddItem(ItemId); CommandStatus Status.Success; EventSystem.Instance.Publish(new PurchaseSucceededEvent(ItemId)); } }第二步在UI中触发命令public class ShopItemUI : MonoBehaviour { public string itemId; public Button buyButton; void Start() { buyButton.onClick.AddListener(OnBuyButtonClicked); } void OnBuyButtonClicked() { // 不直接调用任何系统只创建并发送命令 var purchaseCommand new PurchaseItemCommand(itemId); // 通过框架提供的入口发送命令 Framework.GetCommandSystem().ExecuteCommand(purchaseCommand); } }第三步配置框架依赖在游戏启动时我们需要将IInventorySystem和ICurrencySystem的具体实现注册到框架的IOC容器中。void SetupFramework() { var container Framework.GetContainer(); container.RegisterIInventorySystem(new InventorySystem()); container.RegisterICurrencySystem(new CurrencySystem()); container.RegisterCommandSystem(new CommandSystem()); }这样当PurchaseItemCommand被执行时框架会自动将已注册的系统实例注入到命令中。第四步响应命令结果其他系统如UI更新、音效播放通过监听命令执行后发布的事件来做出反应而不是被命令直接调用。public class CoinUI : MonoBehaviour { void OnEnable() { EventSystem.Instance.SubscribePurchaseSucceededEvent(OnPurchaseSuccess); } void OnDisable() { EventSystem.Instance.UnsubscribePurchaseSucceededEvent(OnPurchaseSuccess); } void OnPurchaseSuccess(PurchaseSucceededEvent evt) { UpdateCoinDisplay(); // 更新金币显示 } }通过这样一个完整的流程我们可以看到命令模式成功地将UI交互、业务逻辑、数据更新和表现反馈清晰地分离开来。每个模块职责单一耦合度低无论是修改购买逻辑、增加新的付费方式还是测试购买流程都变得非常容易。命令模式远不止是一个“设计模式”当它融入框架的血液时它变成了一种架构思想一种组织代码和规范团队协作的强有力约束。它迫使开发者去思考操作的边界、依赖的方向和系统的响应方式。从最初的直接方法调用到引入命令接口再到与IOC容器、事件系统深度集成最后考虑性能、网络、撤销等高级特性这是一个框架从简陋走向健壮的典型路径。希望我对命令模式的这些思考和实战经验能为你自己的Unity框架搭建之路提供一些切实可行的参考。记住框架没有银弹最适合你项目规模和团队习惯的才是最好的。 Unity框架设计：命令模式解耦游戏逻辑与实现撤销重做
1. 项目概述为什么要在Unity框架中思考命令模式如果你在Unity里做过几个项目尤其是那种功能越加越多、代码越写越乱的你大概率会和我有一样的感受脚本之间的调用关系像一团乱麻。一个UI按钮点击直接去调用Player的移动方法一个敌人的死亡事件又直接去修改GameManager的分数。这种“硬编码”的直接调用在项目初期确实快但到了中后期维护和扩展就成了噩梦。今天我想和你深入聊聊的就是在我们搭建Unity框架时一个绕不开的核心设计模式——命令模式Command Pattern。这不仅仅是“知道有这么个模式”而是真正理解它如何解决我们实际开发中的痛点以及如何在框架层面优雅地落地。命令模式的核心思想用大白话讲就是把一个“请求”或“操作”封装成一个独立的对象。这个对象里包含了执行这个操作所需的所有信息。这样做的好处是发出请求的对象比如一个按钮不需要知道具体谁来执行、怎么执行它只需要创建一个命令对象并“发送”出去就行了。这听起来有点抽象但在Unity游戏开发里这简直是解耦的神器。想象一下你的输入系统、UI系统、游戏逻辑系统之间不再直接纠缠而是通过一个个清晰的命令对象来通信代码的清晰度和可维护性会提升好几个档次。接下来我会结合从零开始搭建框架的实践拆解命令模式的几种典型应用场景、实现细节以及那些只有踩过坑才知道的注意事项。2. 命令模式的核心价值与Unity框架的契合点2.1 从“直接调用”到“命令封装”的思维转变在没接触命令模式之前我们最熟悉的代码可能是这样的public class StartButton : MonoBehaviour { public PlayerController player; void OnClick() { player.MoveToTarget(); // 直接调用 } }这段代码的问题显而易见StartButton紧紧依赖着PlayerController。如果我想把移动逻辑换到另一个类或者想在移动前后加一些日志、校验就必须来修改StartButton。这违反了设计原则中的“开闭原则”对扩展开放对修改关闭。引入命令模式后代码变成了这样public class StartButton : MonoBehaviour { void OnClick() { var command new MovePlayerCommand(targetPosition); CommandSystem.Execute(command); // 发送命令不关心谁执行 } }StartButton现在只负责创建和发出一个MovePlayerCommand命令对象。至于这个命令是谁执行的、怎么执行的按钮完全不关心。这个简单的转变带来了几个立竿见影的好处首先是解耦发送者和接收者之间没有了直接的引用关系其次是可扩展性我可以很容易地增加新的命令如JumpCommand,AttackCommand而无需修改现有的发送者代码最后是可复用性这个命令对象可以被序列化、记录、排队甚至实现撤销/重做功能。2.2 命令模式在游戏架构中的典型应用场景在Unity游戏框架中命令模式至少有以下几个非常适合的应用场景输入处理这是最经典的应用。键盘、鼠标、手柄的输入被映射成一个个具体的命令如MoveCommand,JumpCommand,FireCommand。输入管理器只负责生成命令并放入队列具体的执行逻辑由对应的命令对象处理。这样更改按键配置或支持新的输入设备会变得非常容易。UI系统每个UI按钮的点击事件都可以绑定到一个命令上。比如“开始游戏”、“打开设置”、“购买道具”。UI层只负责视觉交互和触发命令具体的业务逻辑加载场景、打开面板、扣款封装在命令内部。这保证了UI代码的纯粹性。网络同步在网络游戏中玩家的操作可以被封装成命令对象然后序列化后发送给服务器。服务器验证并执行后再将结果或命令广播给其他客户端。命令对象成为了客户端与服务器之间通信的协议单元。AI行为AI的决策逻辑可以产出命令序列。例如一个“攻击”决策可能产生ApproachEnemyCommand-AttackCommand-RetreatCommand这样一个命令链。这使得AI的行为模块化且易于调试。事务与撤销系统在编辑器工具或策略游戏中用户的每一步操作如放置建筑、移动单位都可以封装为命令。这些命令被保存在历史栈中轻松实现撤销(Undo)和重做(Redo)功能。理解这些场景能帮助我们在设计框架时不是生搬硬套模式而是有目的地将命令模式嵌入到架构的合适层级中。3. 命令模式的基础实现与框架集成3.1 定义命令接口与基础命令类任何模式落地首先要定义一套约定。在我们的框架中一个最基础的命令接口可能长这样public interface ICommand { void Execute(); }是的非常简单只有一个Execute方法。但这就是契约的核心任何可执行的操作都必须实现这个方法。然而在实际游戏中命令往往需要参数也需要知道执行的结果。因此一个更实用的基础命令抽象类可能是这样的public abstract class Command : ICommand { // 命令执行状态 public enum Status { Pending, Success, Failed } public Status CommandStatus { get; protected set; } Status.Pending; // 核心执行方法 public abstract void Execute(); // 可选用于撤销操作 public virtual void Undo() { } // 可选命令是否可执行的前置检查 public virtual bool CanExecute() { return true; } }这里我们引入了命令状态这对于需要异步执行或需要结果反馈的命令非常有用。CanExecute方法可以在执行前进行条件校验比如“玩家法力值是否足够释放这个技能”。接下来我们实现一个具体的命令。以“移动玩家”为例public class MovePlayerCommand : Command { private Vector3 _targetPosition; private PlayerController _player; // 依赖通常通过框架的IOC容器获取 public MovePlayerCommand(Vector3 targetPosition) { _targetPosition targetPosition; } public override void Execute() { if (!CanExecute()) { CommandStatus Status.Failed; return; } // 通过框架提供的服务定位器或IOC容器获取PlayerController实例 // 避免在命令构造函数中硬编码实现更好的解耦 _player ServiceLocator.GetPlayerController(); if (_player null) { CommandStatus Status.Failed; Debug.LogError(MovePlayerCommand: PlayerController not found!); return; } _player.MoveTo(_targetPosition); CommandStatus Status.Success; Debug.Log($Player moved to {_targetPosition}); } public override bool CanExecute() { // 检查玩家是否存活、目标点是否可达等 return true; // 简化示例 } }注意在这个实现中命令对象内部并没有在构造时直接持有PlayerController的引用而是在Execute方法中通过一个ServiceLocator服务定位器动态获取。这是框架集成中非常关键的一步它彻底切断了命令与具体执行者之间的编译时依赖使得命令类可以在任何上下文中被创建和序列化。3.2 构建命令的执行系统Command System有了命令对象我们需要一个中枢系统来调度和执行它们。这个CommandSystem是框架的核心组件之一。它的职责包括接收并缓存命令。管理命令队列用于实现命令排队执行。提供执行命令的入口。可能还需要管理命令历史用于撤销。一个简易但功能完整的CommandSystem实现如下public class CommandSystem : MonoBehaviour { private static CommandSystem _instance; public static CommandSystem Instance _instance; // 命令执行队列支持异步和顺序执行 private QueueCommand _commandQueue new QueueCommand(); // 命令历史栈用于撤销 private StackCommand _historyStack new StackCommand(); private void Awake() { if (_instance ! null _instance ! this) { Destroy(this.gameObject); return; } _instance this; DontDestroyOnLoad(this.gameObject); // 常驻跨场景 } private void Update() { // 每帧处理队列中的命令同步执行 ProcessCommandQueue(); } /// summary /// 立即执行一个命令 /// /summary public void ExecuteCommand(Command command) { if (command null || !command.CanExecute()) return; command.Execute(); _historyStack.Push(command); // 记录历史 // 可以根据命令状态进行事件通知例如 // EventSystem.Instance.Publish(new CommandExecutedEvent(command)); } /// summary /// 将命令加入队列等待执行 /// /summary public void EnqueueCommand(Command command) { if (command ! null command.CanExecute()) { _commandQueue.Enqueue(command); } } /// summary /// 处理命令队列 /// /summary private void ProcessCommandQueue() { while (_commandQueue.Count 0) { var cmd _commandQueue.Dequeue(); ExecuteCommand(cmd); } } /// summary /// 撤销上一步操作 /// /summary public void Undo() { if (_historyStack.Count 0) { var lastCommand _historyStack.Pop(); lastCommand.Undo(); } } // 清空队列和历史场景切换时可能需要 public void Clear() { _commandQueue.Clear(); _historyStack.Clear(); } }这个系统提供了两种执行方式ExecuteCommand立即执行和EnqueueCommand加入队列在Update中顺序执行。队列机制对于需要保证顺序性或避免在同一帧内执行过多逻辑的场景非常有用。历史栈则为实现撤销功能打下了基础。3.3 与框架其他模块的协作IOC容器与事件系统一个成熟的框架不会让CommandSystem孤立存在。它需要与框架的其他核心模块协同工作。1. 与IOC控制反转容器集成上面例子中MovePlayerCommand通过ServiceLocator.GetPlayerController()来获取执行者。在一个更完善的框架中我们通常会使用IOC容器进行依赖注入。我们可以改造命令的创建和执行方式public class MovePlayerCommand : Command { [Inject] // 依赖注入标记 private PlayerController _player; private Vector3 _targetPosition; public MovePlayerCommand(Vector3 targetPosition) { _targetPosition targetPosition; } public override void Execute() { // 注入的_player已由框架的IOC容器在命令执行前自动赋值 _player.MoveTo(_targetPosition); CommandStatus Status.Success; } } // 在CommandSystem中执行命令前先进行依赖注入 public void ExecuteCommand(Command command) { // 使用框架的IOC容器解析并注入命令的依赖 FrameworkContainer.Inject(command); command.Execute(); _historyStack.Push(command); }这样命令类本身不需要关心依赖从哪里来框架的IOC容器负责在运行时“注入”它所需的服务。这极大地提高了命令类的可测试性和可移植性。2. 与事件系统集成命令的执行往往伴随着状态改变其他系统可能需要对此做出反应。例如玩家移动后小地图需要更新任务系统可能需要检查是否到达了某个地点。我们可以通过事件系统来广播命令执行的结果而不是让命令直接去调用这些系统。public override void Execute() { _player.MoveTo(_targetPosition); CommandStatus Status.Success; // 发布一个事件而不是直接调用其他模块 EventSystem.Instance.Publish(new PlayerMovedEvent(_player.transform.position, _targetPosition)); }监听PlayerMovedEvent的系统如小地图系统、音效系统、成就系统会自行处理这个事件。这样命令系统与游戏的其他逻辑进一步解耦架构变得更加清晰和灵活。4. 进阶实践参数化命令、异步命令与撤销重做4.1 实现灵活的参数化命令基础命令只能执行固定操作。但在游戏中我们经常需要执行“对目标造成X点伤害”或“将物品A移动到位置B”这类带参数的操作。我们可以通过泛型来增强命令的灵活性。首先定义一个带参数的命令接口public interface ICommandT { void Execute(T parameter); }但更常见的做法是在基础Command类中增加一个泛型参数或者创建专门的参数化命令基类。一种实践是使用System.Action或Func委托来封装执行逻辑实现极度灵活的命令public class ActionCommand : Command { private Action _action; public ActionCommand(Action action) { _action action; } public override void Execute() { _action?.Invoke(); CommandStatus Status.Success; } } // 使用方式可以快速创建简单命令无需定义新类 var cmd new ActionCommand(() Debug.Log(Hello from Command!)); CommandSystem.Instance.ExecuteCommand(cmd);对于需要参数的情况可以定义ActionCommandTpublic class ActionCommandT : Command { private ActionT _action; private T _parameter; public ActionCommand(ActionT action, T parameter) { _action action; _parameter parameter; } public override void Execute() { _action?.Invoke(_parameter); CommandStatus Status.Success; } }这种方式的优点是极其灵活和快捷适合逻辑简单的命令。缺点是失去了强类型检查并且命令的逻辑分散在各处不利于复杂逻辑的封装和管理。在框架中我通常建议将核心的、可复用的业务命令定义为具体的类如BuyItemCommand,CastSkillCommand而将一些临时的、UI相关的简单操作用ActionCommand快速实现。4.2 处理异步操作命令游戏开发中充斥着异步操作加载场景、从服务器请求数据、播放一段动画并等待结束。传统的Execute()同步方法无法很好地处理这些情况。我们需要支持异步命令。一种常见的实现是引入ExecuteAsync方法并配合async/awaitpublic abstract class AsyncCommand : Command { public override void Execute() { // 对于异步命令同步Execute可能只是启动异步任务 ExecuteAsync().Forget(); // 注意需要处理Fire and forget的异常 } public abstract Task ExecuteAsync(); } public class LoadSceneCommand : AsyncCommand { private string _sceneName; public LoadSceneCommand(string sceneName) { _sceneName sceneName; } public override async Task ExecuteAsync() { CommandStatus Status.Pending; var asyncOp SceneManager.LoadSceneAsync(_sceneName); while (!asyncOp.isDone) { // 可以在这里更新加载进度条 await Task.Yield(); } CommandStatus Status.Success; } }在CommandSystem中我们需要妥善管理这些异步任务避免它们被意外取消或造成资源泄漏。可以维护一个正在进行的异步命令列表并在场景切换或游戏退出时妥善清理。实操心得异步命令的陷阱使用异步命令时最大的坑是生命周期管理。如果一个异步命令还在执行中但发出命令的对象如一个UI界面已经被销毁了就可能引发空引用异常。我的经验是在命令内部访问任何外部对象尤其是MonoBehaviour时都要进行空值检查或者使用CancellationToken来支持取消操作。另外Unity的协程Coroutine也是一种实现异步命令的常见方式可以与ICommand接口结合但需要注意协程不能直接在非MonoBehaviour对象中启动通常需要借助一个MonoBehaviour代理。4.3 实现撤销与重做功能撤销/重做是命令模式最迷人的特性之一尤其在编辑器工具或回合制策略游戏中。实现的基础在于命令不仅要执行还要知道如何撤销自己。我们需要增强我们的基础命令类public abstract class UndoableCommand : Command { // 记录执行前的状态用于撤销 public abstract void CaptureSnapshot(); // 执行命令 public override abstract void Execute(); // 撤销命令恢复到Snapshot的状态 public override abstract void Undo(); }以“移动游戏对象”命令为例public class MoveGameObjectCommand : UndoableCommand { private GameObject _target; private Vector3 _fromPosition; private Vector3 _toPosition; public MoveGameObjectCommand(GameObject target, Vector3 toPosition) { _target target; _toPosition toPosition; } public override void CaptureSnapshot() { _fromPosition _target.transform.position; } public override void Execute() { CaptureSnapshot(); // 执行前先捕获状态 _target.transform.position _toPosition; CommandStatus Status.Success; } public override void Undo() { _target.transform.position _fromPosition; CommandStatus Status.Pending; // 撤销后状态回退 } }在CommandSystem中我们需要维护两个栈_undoStack历史栈和_redoStack重做栈。public void ExecuteCommand(UndoableCommand command) { command.Execute(); _undoStack.Push(command); _redoStack.Clear(); // 执行新命令后重做栈清空 } public void Undo() { if (_undoStack.Count 0) { var cmd _undoStack.Pop(); cmd.Undo(); _redoStack.Push(cmd); // 被撤销的命令放入重做栈 } } public void Redo() { if (_redoStack.Count 0) { var cmd _redoStack.Pop(); cmd.Execute(); // 重做就是再次执行 _undoStack.Push(cmd); } }注意事项快照的深度与性能CaptureSnapshot的实现需要谨慎。对于简单的变换操作保存位置、旋转、缩放是可行的。但对于复杂的对象状态如一整个单位的属性、背包的所有物品进行深拷贝Deep Copy来保存快照可能会带来巨大的性能开销和内存压力。在实践中有几种优化策略1) 对于复杂对象实现增量快照只记录改变的部分2) 使用命令模式与备忘录模式Memento Pattern结合让对象自己提供创建和恢复快照的方法3) 限制撤销栈的深度只保留最近N步操作。5. 框架层面的命令模式优化与设计思考5.1 命令工厂与集中管理当项目中有成百上千个命令时直接在代码各处new命令对象会带来维护问题。我们可以引入一个简单的命令工厂来集中管理命令的创建。public static class CommandFactory { public static ICommand CreateMoveCommand(Vector3 target) { return new MovePlayerCommand(target); } public static ICommand CreateAttackCommand(Unit target) { return new AttackCommand(target); } // ... 其他命令 }使用工厂的好处是如果命令的创建逻辑需要改变例如需要注入额外的依赖只需要修改工厂方法即可。更进一步可以利用反射或IOC容器实现自动注册和发现命令实现更动态的命令管理。5.2 命令与查询职责分离在更清晰的架构中我们通常遵循命令查询职责分离原则。命令Command用于修改状态它不返回数据或只返回执行成功与否。查询Query用于获取数据而不产生副作用。在我们的框架中可以明确区分ICommand和IQuery接口。public interface IQueryTResult { TResult Execute(); }例如一个获取玩家分数的查询public class GetPlayerScoreQuery : IQueryint { [Inject] private PlayerDataModel _playerData; public int Execute() { return _playerData.Score; } }在架构中命令和查询可以通过同一个“处理器”或“总线”来发送但内部路由到不同的执行管道这有助于保持代码的清晰和可测试性。5.3 命令的日志、回放与测试由于命令是独立的对象它天然支持一些高级功能日志记录在CommandSystem.ExecuteCommand中可以很容易地将每个命令及其参数序列化后写入日志文件。这对于调试复杂的用户操作流程或线上问题排查至关重要。操作回放将一系列命令序列化存储下来就可以在任意时刻“回放”整个游戏过程。这对于制作游戏预告片、自动化测试或实现“观战”功能非常有价值。单元测试命令对象是纯逻辑的或者依赖可以被注入非常适合进行单元测试。你可以轻松地创建一个命令注入模拟的依赖然后验证命令执行后这些依赖的状态是否如预期般改变。6. 常见问题、踩坑实录与性能考量6.1 命令对象的生命周期与内存管理在C#中频繁创建和销毁大量的小型命令对象可能会触发垃圾回收导致游戏卡顿。对于每帧都可能产生大量命令的场景如实时输入处理需要考虑对象池优化。public class CommandPoolT where T : Command, new() { private StackT _pool new StackT(); public T Get() { if (_pool.Count 0) return _pool.Pop(); return new T(); } public void Release(T command) { command.Reset(); // 需要命令实现Reset方法清理内部状态 _pool.Push(command); } }对于MoveCommand这类简单命令使用对象池可以显著减少GC压力。但要注意如果命令内部持有对MonoBehaviour等Unity引擎对象的引用在释放回池时必须清空这些引用防止内存泄漏。6.2 命令执行顺序与依赖问题当多个命令被加入队列时它们的执行顺序是FIFO。但有些命令之间可能存在依赖关系。例如“打开宝箱”命令必须在“玩家走到宝箱前”命令执行成功后才能执行。一种解决方案是引入“复合命令”或“命令链”。public class SequentialCommand : Command { private ListCommand _subCommands new ListCommand(); private int _currentIndex 0; public void AddCommand(Command cmd) { _subCommands.Add(cmd); } public override void Execute() { ExecuteNext(); } private void ExecuteNext() { if (_currentIndex _subCommands.Count) { var cmd _subCommands[_currentIndex]; cmd.Execute(); // 假设命令是同步的简单顺序执行 // 如果是异步命令则需要更复杂的回调机制 _currentIndex; ExecuteNext(); } else { CommandStatus Status.Success; } } }更复杂的依赖关系可能需要引入有向无环图来管理命令的执行拓扑顺序。6.3 网络同步中的命令一致性在网络游戏中命令模式是同步玩家操作的重要手段。但这里有一个经典问题如何保证所有客户端在相同游戏状态下执行相同命令后得到相同的结果这要求命令必须是确定性的。命令的执行逻辑不能依赖于本地时间、随机数除非使用同步的随机种子或浮点数精度差异。通常服务器是权威的它验证并广播命令所有客户端根据广播的命令序列进行模拟。6.4 过度设计警告命令模式非常强大但切忌滥用。不是每一个函数调用都需要封装成命令。如果一段逻辑只在一个地方调用且没有解耦、撤销、日志等需求那么直接调用可能更简单明了。引入命令模式会增加代码的抽象层次和类的数量。我的经验法则是当发现多个发送者需要调用同一个操作或者一个操作需要在不同时间、以不同方式被调用或者你需要记录、撤销操作时命令模式就该登场了。7. 实战在框架中整合命令模式的完整流程让我们以一个具体的例子串联起命令模式在框架中的使用流程。假设我们要实现一个功能玩家点击UI按钮消耗金币购买一件道具。第一步定义命令public class PurchaseItemCommand : Command { [Inject] private IInventorySystem _inventorySystem; [Inject] private ICurrencySystem _currencySystem; public string ItemId { get; private set; } public PurchaseItemCommand(string itemId) { ItemId itemId; } public override bool CanExecute() { var itemPrice _inventorySystem.GetItemPrice(ItemId); return _currencySystem.HasEnoughCoins(itemPrice); } public override void Execute() { if (!CanExecute()) { CommandStatus Status.Failed; EventSystem.Instance.Publish(new PurchaseFailedEvent(金币不足)); return; } var itemPrice _inventorySystem.GetItemPrice(ItemId); _currencySystem.SpendCoins(itemPrice); _inventorySystem.AddItem(ItemId); CommandStatus Status.Success; EventSystem.Instance.Publish(new PurchaseSucceededEvent(ItemId)); } }第二步在UI中触发命令public class ShopItemUI : MonoBehaviour { public string itemId; public Button buyButton; void Start() { buyButton.onClick.AddListener(OnBuyButtonClicked); } void OnBuyButtonClicked() { // 不直接调用任何系统只创建并发送命令 var purchaseCommand new PurchaseItemCommand(itemId); // 通过框架提供的入口发送命令 Framework.GetCommandSystem().ExecuteCommand(purchaseCommand); } }第三步配置框架依赖在游戏启动时我们需要将IInventorySystem和ICurrencySystem的具体实现注册到框架的IOC容器中。void SetupFramework() { var container Framework.GetContainer(); container.RegisterIInventorySystem(new InventorySystem()); container.RegisterICurrencySystem(new CurrencySystem()); container.RegisterCommandSystem(new CommandSystem()); }这样当PurchaseItemCommand被执行时框架会自动将已注册的系统实例注入到命令中。第四步响应命令结果其他系统如UI更新、音效播放通过监听命令执行后发布的事件来做出反应而不是被命令直接调用。public class CoinUI : MonoBehaviour { void OnEnable() { EventSystem.Instance.SubscribePurchaseSucceededEvent(OnPurchaseSuccess); } void OnDisable() { EventSystem.Instance.UnsubscribePurchaseSucceededEvent(OnPurchaseSuccess); } void OnPurchaseSuccess(PurchaseSucceededEvent evt) { UpdateCoinDisplay(); // 更新金币显示 } }通过这样一个完整的流程我们可以看到命令模式成功地将UI交互、业务逻辑、数据更新和表现反馈清晰地分离开来。每个模块职责单一耦合度低无论是修改购买逻辑、增加新的付费方式还是测试购买流程都变得非常容易。命令模式远不止是一个“设计模式”当它融入框架的血液时它变成了一种架构思想一种组织代码和规范团队协作的强有力约束。它迫使开发者去思考操作的边界、依赖的方向和系统的响应方式。从最初的直接方法调用到引入命令接口再到与IOC容器、事件系统深度集成最后考虑性能、网络、撤销等高级特性这是一个框架从简陋走向健壮的典型路径。希望我对命令模式的这些思考和实战经验能为你自己的Unity框架搭建之路提供一些切实可行的参考。记住框架没有银弹最适合你项目规模和团队习惯的才是最好的。