1. 項(xiàng)目概述Unity程序員為什么繞不開“模式”這個(gè)坎干了這么多年Unity開發(fā)我越來越覺得設(shè)計(jì)模式不是面試八股文而是商業(yè)項(xiàng)目里真刀真槍解決問題的工具箱。你接手一個(gè)項(xiàng)目Leader甩過來一句“用狀態(tài)機(jī)重構(gòu)一下BOSS戰(zhàn)斗邏輯”或者策劃滿嘴跑火車地要求“每種敵人都有三種攻擊形態(tài)后續(xù)還要加新種類”這時(shí)候如果你腦子里沒有一套成熟的“模式”體系代碼就會(huì)從第三天開始失控。標(biāo)題里說的“模式相關(guān)的開發(fā)需求”我理解下來大概分兩層。狹義上是指設(shè)計(jì)模式在Unity中的落地比如單例、狀態(tài)、觀察者、工廠、對(duì)象池、命令模式這些廣義上還包括Unity引擎自帶的“模式化”機(jī)制比如Animator的有限狀態(tài)機(jī)、協(xié)程和異步模型、腳本生命周期回調(diào)甚至Addressables的資源加載模式。這兩層你得融會(huì)貫通才能在商業(yè)項(xiàng)目里游刃有余。這篇文章不是教科書式的理論復(fù)述而是把我這些年從中小型團(tuán)隊(duì)、獨(dú)立Demo到線上運(yùn)營(yíng)項(xiàng)目的實(shí)踐總結(jié)一遍什么場(chǎng)景用哪個(gè)模式、為什么選它而不是另一個(gè)、核心代碼長(zhǎng)什么樣、以及我在真實(shí)項(xiàng)目中踩過哪些坑。無論你是剛轉(zhuǎn)Unity兩三個(gè)月的初級(jí)程序員還是在做中大型項(xiàng)目想梳理代碼架構(gòu)的資深開發(fā)這篇文章應(yīng)該都能給你一點(diǎn)可落地的參考。我始終有個(gè)觀點(diǎn)設(shè)計(jì)模式是為了解決特定問題而存在的不是為了炫耀技術(shù)。脫離業(yè)務(wù)場(chǎng)景談模式是耍流氓具體怎么理解下面拆開講。2. 需求拆解與方案選型模式不是越多越好而是越準(zhǔn)越好2.1 先看清“模式化需求”到底長(zhǎng)什么樣展開寫方案之前得先把需求看清楚。我總結(jié)了商業(yè)項(xiàng)目里最常見的幾類“模式相關(guān)需求”你對(duì)照一下基本不會(huì)跑偏第一類對(duì)象狀態(tài)切換類需求。典型的就是角色行為——待機(jī)、移動(dòng)、攻擊、受擊、死亡或者戰(zhàn)斗流程——回合開始、玩家行動(dòng)、敵方行動(dòng)、回合結(jié)束。這類需求的特點(diǎn)是狀態(tài)之間切換邏輯復(fù)雜條件判斷散落在各處用一堆if-else寫到最后連自己都改不動(dòng)。第二類對(duì)象創(chuàng)建與管理類需求。比如怪物波次生成、子彈發(fā)射、UI彈窗、飄字特效。這類需求的核心矛盾是對(duì)象數(shù)量動(dòng)態(tài)變化創(chuàng)建銷毀頻繁直接new和Destroy會(huì)導(dǎo)致性能抖動(dòng)和GC壓力同時(shí)不同種類對(duì)象的創(chuàng)建流程差異大代碼容易重復(fù)。第三類模塊間通信類需求。比如戰(zhàn)斗模塊打掉一個(gè)怪UI界面要刷新任務(wù)進(jìn)度音效模塊要播放擊殺音效成就系統(tǒng)要累計(jì)計(jì)數(shù)。如果每個(gè)模塊都直接互相引用耦合度會(huì)瞬間爆炸改一個(gè)功能牽扯一片。第四類流程控制與管理類需求。比如新手引導(dǎo)、副本流程、登錄流程這些流程有嚴(yán)格的先后順序且每一步都可能被突發(fā)事件打斷——玩家斷線、點(diǎn)擊跳過、強(qiáng)制退出。普通寫法是嵌套回調(diào)寫到最后就是傳說中的“回調(diào)地獄”。2.2 方案選型背后的取舍邏輯針對(duì)上面四類需求對(duì)應(yīng)的模式選型其實(shí)有相對(duì)成熟的組合。這里直接給結(jié)論附上我的理由需求類型推薦模式組合為什么不選其他方案狀態(tài)切換狀態(tài)模式State 有限狀態(tài)機(jī)FSM用EnumSwitch寫狀態(tài)切換新加一個(gè)狀態(tài)要改原方法違背開閉原則對(duì)象創(chuàng)建管理對(duì)象池Object Pool 工廠模式Factory直接Instantiate頻繁操作性能和內(nèi)存都不穩(wěn)工廠類把創(chuàng)建邏輯收斂配合池子批量管理模塊通信觀察者模式Observer/ 事件中心模塊之間互持引用整個(gè)項(xiàng)目變成蜘蛛網(wǎng)沒法做熱更和單元測(cè)試流程控制命令模式Command或異步狀態(tài)機(jī)嵌套回調(diào)邏輯不直觀出錯(cuò)后堆棧全亂而且中途打斷很難處理這個(gè)選型邏輯本質(zhì)上是在回答三個(gè)問題這個(gè)需求的變化點(diǎn)在哪里這段代碼的復(fù)用點(diǎn)是哪里改動(dòng)頻率最高的地方能不能被隔離2.3 為什么我建議“先做減法”我在早期帶項(xiàng)目的時(shí)候犯過一個(gè)典型錯(cuò)誤剛學(xué)完設(shè)計(jì)模式恨不得把二十三種模式全塞進(jìn)項(xiàng)目里。結(jié)果就是代碼抽象層級(jí)過多一個(gè)簡(jiǎn)單的攻擊邏輯繞了五六個(gè)類新來的同事根本看不懂調(diào)試起來想罵人。后來我學(xué)乖了。設(shè)計(jì)模式在項(xiàng)目里應(yīng)該按“成本收益比”來取舍。比如一個(gè)功能可能寫死不再改那直接用最簡(jiǎn)單的方式實(shí)現(xiàn)就好沒必要硬套模式。但如果需求文檔里明確寫了“后續(xù)會(huì)新增角色種類”、“可能有多種攻擊方式”那就值得花一天時(shí)間把模式設(shè)計(jì)好。記住一句話模式是應(yīng)對(duì)變化的手段沒有變化需求就蒸蒸日上不需要模式。這個(gè)行業(yè)很多項(xiàng)目的代碼腐爛不是因?yàn)槌绦騿T不懂設(shè)計(jì)模式恰恰是因?yàn)檫^度設(shè)計(jì)導(dǎo)致沒人敢改、沒人能懂。3. 核心技術(shù)點(diǎn)解析五個(gè)高頻Unity設(shè)計(jì)模式實(shí)戰(zhàn)詳解這五個(gè)模式是我從業(yè)以來使用頻率最高的幾乎每個(gè)商業(yè)項(xiàng)目都會(huì)用到。我分別從“它解決什么問題”、“核心原理長(zhǎng)什么樣”、“Unity環(huán)境下的實(shí)現(xiàn)細(xì)節(jié)”三個(gè)角度講透。3.1 單例模式服務(wù)管理器的利與弊單例大概是Unity開發(fā)者最早接觸的模式因?yàn)樗鉀Q了一個(gè)很現(xiàn)實(shí)的問題有一些對(duì)象全局唯一而且到處都要訪問——音頻管理器、UI管理器、網(wǎng)絡(luò)管理器、存檔管理器。每個(gè)地方都傳引用太麻煩不如搞個(gè)全局訪問點(diǎn)。C#里最典型的實(shí)現(xiàn)就是你經(jīng)常見到的public class AudioManager : MonoBehaviour { private static AudioManager _instance; public static AudioManager Instance { get { if (_instance null) { _instance FindObjectOfTypeAudioManager(); if (_instance null) { var go new GameObject(AudioManager); _instance go.AddComponentAudioManager(); DontDestroyOnLoad(go); } } return _instance; } } }這段代碼把幾個(gè)要點(diǎn)都覆蓋了懶加載、場(chǎng)景中自動(dòng)查找、沒有則自動(dòng)創(chuàng)建、跨場(chǎng)景不銷毀。很多初學(xué)者抄完就完了但有幾個(gè)坑你得注意。第一個(gè)坑是單例的銷毀時(shí)機(jī)。游戲退出時(shí)Unity會(huì)銷毀所有場(chǎng)景對(duì)象靜態(tài)字段不會(huì)自動(dòng)置空。如果此時(shí)有異步回調(diào)訪問單例會(huì)出現(xiàn)“對(duì)象已銷毀但靜態(tài)引用還在”的詭異錯(cuò)誤。我的習(xí)慣是重寫OnDestroy時(shí)把_instance置空并加一個(gè)_isQuitting標(biāo)志位在回調(diào)里判斷。第二個(gè)坑是單例的初始化順序。A單例在Awake里訪問B單例如果B還沒初始化結(jié)果就是空引用。我踩過這個(gè)坑之后項(xiàng)目里統(tǒng)一規(guī)定所有單例的初始化放在Start或者另一個(gè)管理器的Init流程里禁止在Awake里互相訪問。第三個(gè)坑也是最關(guān)鍵的認(rèn)知——單例不是萬能的。它在小型項(xiàng)目里好用但當(dāng)你有一堆單例像“音效管理”、“任務(wù)管理”、“背包管理”、“成就管理”它們內(nèi)部還在互相調(diào)用你就等于把全局耦合穿了一條線。所以現(xiàn)在業(yè)界更推薦用依賴注入或服務(wù)定位器來替代單例至少讓訪問關(guān)系顯式化。Unity新版本的Dependency Injection包就是干這個(gè)用的。注意如果項(xiàng)目里單例數(shù)量超過5個(gè)而且存在互相調(diào)用關(guān)系你就要考慮用服務(wù)定位模式或者DI容器重構(gòu)了。否則后期維護(hù)成本會(huì)指數(shù)級(jí)上升。3.2 狀態(tài)模式與有限狀態(tài)機(jī)角色AI和戰(zhàn)斗流程的最佳搭檔狀態(tài)模式在Unity里的應(yīng)用數(shù)量我敢說排第二沒人敢排第一。Animator Controller本質(zhì)就是一個(gè)可視化有限狀態(tài)機(jī)但代碼層面的狀態(tài)機(jī)依然不可或缺因?yàn)閺?fù)雜的戰(zhàn)斗邏輯、AI邏輯單靠動(dòng)畫層根本表達(dá)不了。我常用的狀態(tài)機(jī)基類設(shè)計(jì)長(zhǎng)這樣public abstract class StateBase { protected StateMachine machine; public StateBase(StateMachine machine) { this.machine machine; } public virtual void OnEnter() { } public virtual void OnUpdate() { } public virtual void OnExit() { } } public class StateMachine { private StateBase _currentState; private DictionarySystem.Type, StateBase _states new DictionarySystem.Type, StateBase(); public void AddState(StateBase state) { _states[state.GetType()] state; } public void ChangeStateT() where T : StateBase { var next _states[typeof(T)]; _currentState?.OnExit(); _currentState next; _currentState.OnEnter(); } public void Update() { _currentState?.OnUpdate(); } }這套設(shè)計(jì)的核心思路是每個(gè)狀態(tài)是一個(gè)獨(dú)立的類狀態(tài)之間的切換通過ChangeState觸發(fā)新加一個(gè)狀態(tài)不影響已有邏輯只需要AddState并調(diào)用切換即可。舉個(gè)例子一個(gè)普通的近戰(zhàn)單位AI一般就這幾個(gè)狀態(tài)待機(jī)、巡邏、追擊、攻擊、受擊、死亡。用狀態(tài)機(jī)的寫法每個(gè)狀態(tài)的自邏輯內(nèi)聚在一個(gè)類里邏輯邊界非常清晰。如果你需要新增一個(gè)“狂暴”狀態(tài)只需要寫一個(gè)RageState類然后在滿足條件的地方調(diào)用ChangeState ()完事。但這里有個(gè)實(shí)戰(zhàn)中非常重要的細(xì)節(jié)狀態(tài)機(jī)里的狀態(tài)切換條件不能散落在Update里到處判斷。我見過很多同學(xué)把切換條件寫在每個(gè)狀態(tài)的OnUpdate里結(jié)果狀態(tài)一多切換關(guān)系變成一張亂七八糟的網(wǎng)你根本理不清誰是誰的上級(jí)。我的做法是把切換條件的判斷集中在一個(gè)地方比如狀態(tài)機(jī)的“Update”里先收集外部事件再做統(tǒng)一裁決?；蛘哂脦А斑^渡條件”的狀態(tài)機(jī)框架每個(gè)狀態(tài)聲明自己能過渡到哪些狀態(tài)以及對(duì)應(yīng)的條件委托。另外如果你的需求只是動(dòng)畫切換不是復(fù)雜邏輯切換優(yōu)先用Animator Layer和動(dòng)畫參數(shù)不要用代碼狀態(tài)機(jī)重造輪子。只有邏輯復(fù)雜度超過動(dòng)畫表達(dá)范圍時(shí)才值得引入代碼狀態(tài)機(jī)。3.3 觀察者模式與事件中心解耦通信的神兵利器模塊通信耦合這個(gè)事是項(xiàng)目規(guī)模上來之后第一個(gè)爆發(fā)的問題。我記得有一段時(shí)間項(xiàng)目里所有系統(tǒng)都持有其他模塊的引用UI要直接調(diào)戰(zhàn)斗模塊的方法戰(zhàn)斗模塊要直接改玩家的血條UI網(wǎng)絡(luò)模塊又要回調(diào)戰(zhàn)斗模塊……有一次改背包上限崩了三個(gè)UI界面排查了半天最后發(fā)現(xiàn)是背包模塊在Awake里調(diào)用了UI模塊的方法而UI模塊還沒初始化。觀察者模式就是為了解決這種“廣播-訂閱”關(guān)系誕生的。Unity里最直白的實(shí)現(xiàn)就是C#的event或者一個(gè)全局事件中心。我?guī)ы?xiàng)目時(shí)習(xí)慣用后者因?yàn)閑vent在多模塊解耦的同時(shí)也帶來一個(gè)問題監(jiān)聽者的生命周期管理極其麻煩。你訂閱了事件如果忘了退訂或者對(duì)象銷毀了但event列表里還留著引用輕則內(nèi)存泄漏重則調(diào)用已銷毀對(duì)象的委托直接拋異常。我這里提供一個(gè)簡(jiǎn)化版事件中心的思路核心點(diǎn)在于支持“帶參事件”以及“弱引用或安全移除”public class EventCenter { private static Dictionarystring, System.Actionobject _listeners new Dictionarystring, System.Actionobject(); public static void Subscribe(string eventName, System.Actionobject callback) { if (!_listeners.ContainsKey(eventName)) _listeners[eventName] null; _listeners[eventName] callback; } public static void Unsubscribe(string eventName, System.Actionobject callback) { if (_listeners.ContainsKey(eventName)) _listeners[eventName] - callback; } public static void Broadcast(string eventName, object data null) { if (_listeners.TryGetValue(eventName, out var callbacks)) callbacks?.Invoke(data); } }你用的時(shí)候打怪模塊只需要廣播一個(gè)“OnMonsterKilled”事件附帶怪物ID和擊殺坐標(biāo)UI的成就監(jiān)聽者訂閱它音效的監(jiān)聽者訂閱它任務(wù)的監(jiān)聽者訂閱它。模塊之間完全不知道對(duì)方的存在這解耦效果立竿見影。但觀察者模式也有它的軟肋——你很難從代碼里直觀地看出來“誰在聽這個(gè)事件”。有時(shí)候一個(gè)事件被改了參數(shù)所有監(jiān)聽的模塊都要跟著測(cè)一遍漏掉一個(gè)就是線上事故。所以我的建議是事件名不要用模糊的字符串盡量定義一個(gè)靜態(tài)常量類集中管理所有事件名。事件參數(shù)不要用一個(gè)裸的object這樣接收方每次都要強(qiáng)轉(zhuǎn)還容易錯(cuò)。定義一個(gè)事件參數(shù)基類每個(gè)事件有明確的參數(shù)類型。訂閱行為盡量在OnEnable里做在OnDisable里退訂確保生命周期安全。3.4 對(duì)象池模式性能優(yōu)化的必修課對(duì)象池的原理你在leetcode上刷題也見過——預(yù)先創(chuàng)建一批對(duì)象用的時(shí)候取用完了還回去避免反復(fù)創(chuàng)建銷毀。在Unity里的價(jià)值尤其大因?yàn)镮nstantiate和Destroy的成本不只是CPU還會(huì)造成內(nèi)存碎片和GC壓力在移動(dòng)端上表現(xiàn)非常明顯。我的經(jīng)驗(yàn)是凡是頻繁生成且生命周期短暫的對(duì)象必須進(jìn)對(duì)象池。典型的有子彈、粒子特效、飄字、小怪、掉落物。但也不是所有對(duì)象都需要池化比如一次游戲只創(chuàng)建一次的UI面板池化的收益基本可以忽略。這里給一個(gè)比較通用的對(duì)象池實(shí)現(xiàn)思路public class ObjectPoolT where T : Component { private StackT _pool new StackT(); private T _prefab; public ObjectPool(T prefab, int preloadCount 0) { _prefab prefab; for (int i 0; i preloadCount; i) { var obj CreateNew(); obj.gameObject.SetActive(false); _pool.Push(obj); } } private T CreateNew() { var obj Object.Instantiate(_prefab); obj.gameObject.SetActive(false); return obj; } public T Get() { T obj _pool.Count 0 ? _pool.Pop() : CreateNew(); obj.gameObject.SetActive(true); return obj; } public void Return(T obj) { obj.gameObject.SetActive(false); _pool.Push(obj); } }用起來也簡(jiǎn)單射擊的時(shí)候從池子里Get一顆子彈設(shè)置位置和方向子彈擊中或者飛出邊界后把自身Return回池子。整個(gè)過程中不會(huì)產(chǎn)生GC壓力幀率穩(wěn)定很多。不過有幾個(gè)細(xì)節(jié)得提醒你注意池子里的對(duì)象不要跨場(chǎng)景殘留。項(xiàng)目里如果有場(chǎng)景切換池里的對(duì)象如果掛在DontDestroyOnLoad節(jié)點(diǎn)下場(chǎng)景A的對(duì)象跑到場(chǎng)景B就會(huì)出問題。我的做法是場(chǎng)景切換時(shí)清空池子或者為每個(gè)場(chǎng)景維護(hù)獨(dú)立的池子。對(duì)象池不要設(shè)置得太大。預(yù)創(chuàng)建太多對(duì)象會(huì)拖慢啟動(dòng)時(shí)間太少又頻繁創(chuàng)建。我一般取項(xiàng)目里的峰值并發(fā)數(shù)量的1.2倍左右具體數(shù)值靠性能測(cè)試調(diào)。必須做“回收不徹底”的自查。有些對(duì)象被池化后內(nèi)部的協(xié)程、動(dòng)畫、Shader屬性沒有重置就會(huì)出現(xiàn)“第二發(fā)子彈沒有特效”“第三次使用后位置不對(duì)”的詭異問題。給每個(gè)池化對(duì)象寫一個(gè)統(tǒng)一的Reset方法Get時(shí)強(qiáng)制調(diào)用。3.5 工廠模式對(duì)象創(chuàng)建邏輯的“封裝大師”工廠模式和對(duì)象池天生一對(duì)。對(duì)象池負(fù)責(zé)“復(fù)用”工廠負(fù)責(zé)“創(chuàng)建”。但在Unity項(xiàng)目中工廠模式真正的價(jià)值是——隱藏對(duì)象創(chuàng)建的細(xì)節(jié)屏蔽不同類型的構(gòu)造差異。舉個(gè)例子假設(shè)游戲里有近戰(zhàn)怪、遠(yuǎn)程怪、精英怪、BOSS四種敵人它們的預(yù)制體不同、初始屬性不同、掛載的AI組件也不同。如果每次都在戰(zhàn)斗模塊里寫GameObject go Instantiate(meleePrefab); go.GetComponentMeleeEnemy().Init(level);那么戰(zhàn)斗模塊就要知道所有敵人的細(xì)節(jié)一旦新增一個(gè)“法師怪”你就得跑到戰(zhàn)斗模塊里加一條邏輯這違反了開閉原則。用工廠模式改一版public interface IEnemyFactory { EnemyBase CreateEnemy(EnemyType type, Vector3 position, int level); } public class EnemyFactory : IEnemyFactory { private DictionaryEnemyType, GameObject _prefabMap; public EnemyBase CreateEnemy(EnemyType type, Vector3 position, int level) { GameObject prefab _prefabMap[type]; var enemyObj Object.Instantiate(prefab, position, Quaternion.identity); var enemy enemyObj.GetComponentEnemyBase(); enemy.ReInit(level); return enemy; } }用工廠模式的好處是新增敵人類型時(shí)只需要注冊(cè)對(duì)應(yīng)的預(yù)制體到字典里或者在工廠里加一個(gè)case分支調(diào)用方波次系統(tǒng)的代碼完全不用動(dòng)。這個(gè)設(shè)計(jì)在“系統(tǒng)持續(xù)擴(kuò)展”的場(chǎng)景下省下的維護(hù)成本相當(dāng)可觀。在我合作的某公司項(xiàng)目中他們的怪物系統(tǒng)就是這個(gè)思路策劃在表格里配置怪物類型ID工廠根據(jù)ID從配置表加載預(yù)制體、屬性、AI模塊程序完全不需要為每個(gè)新怪物寫創(chuàng)建代碼。這就是工廠數(shù)據(jù)驅(qū)動(dòng)結(jié)合的威力。實(shí)戰(zhàn)心得工廠模式很容易和對(duì)象池模式混用創(chuàng)建邏輯放工廠復(fù)用邏輯放池子。二者組合后的完整流程是工廠Get對(duì)象時(shí)先嘗試從池子拿拿不到再走Instantiate。歸還時(shí)主動(dòng)回池。這套組合拳打出來性能和擴(kuò)展性就都有了。4. 商業(yè)項(xiàng)目實(shí)踐記錄從需求到落地的完整過程拆解4.1 真實(shí)需求場(chǎng)景復(fù)盤某跨平臺(tái)項(xiàng)目曾遇到一個(gè)典型的“模式化開發(fā)需求”我拿這個(gè)案例做一次全流程復(fù)盤。需求背景游戲中有一種資源副本玩法玩家每天可以挑戰(zhàn)三次副本中有若干波怪物怪物死亡后掉落道具副本結(jié)束彈出結(jié)算界面。乍一看這是個(gè)稀松平常的玩法但如果你往深處想會(huì)發(fā)現(xiàn)里面嵌套著好幾層設(shè)計(jì)問題第一層波次怪物的生成機(jī)制。每一波的怪物種類和數(shù)量由策劃配置表動(dòng)態(tài)決定有些波次會(huì)混合出三種以上的怪物有些波次會(huì)出現(xiàn)精英怪。而且玩家在打怪過程中副本內(nèi)部可能會(huì)觸發(fā)“暴走”事件額外生成一波怪。第二層怪物行為的狀態(tài)機(jī)。怪物的行為要區(qū)分待機(jī)、追擊、攻擊、受擊、死亡。每種怪物攻擊方式還不一樣近戰(zhàn)怪近身攻擊遠(yuǎn)程怪保持距離釋放技能。第三層系統(tǒng)通信。怪物被擊殺時(shí)副本計(jì)時(shí)器要更新、任務(wù)系統(tǒng)要計(jì)數(shù)、UI要飄字、音效要播放、成就系統(tǒng)要檢查進(jìn)度。這些模塊之間不能相互硬引用。第四層結(jié)算流程。副本打完之后需要按順序播放勝利動(dòng)畫——發(fā)放獎(jiǎng)勵(lì)——刷新界面——彈出結(jié)算UI期間還有可能被玩家點(diǎn)擊跳過打斷。4.2 模式選型與架構(gòu)設(shè)計(jì)根據(jù)需求我用一張表把方案的選型邏輯列出來模塊選擇理由怪物生成工廠模式 對(duì)象池怪物種類差異大但是創(chuàng)建流程統(tǒng)一生成頻率高必須池化怪物行為狀態(tài)模式 FSM行為邏輯復(fù)雜且后續(xù)會(huì)加新怪、新行為狀態(tài)機(jī)天然抗擴(kuò)展跨模塊通信事件中心觀察者模式戰(zhàn)斗、UI、音效、任務(wù)系統(tǒng)互不引用全靠事件解耦副本流程狀態(tài)機(jī)或用UniTask寫流程編排順序邏輯清晰方便插入打斷點(diǎn)這個(gè)架構(gòu)的漂亮之處在于每個(gè)模塊只關(guān)心自己的事。波次系統(tǒng)根據(jù)配置調(diào)工廠生成怪物不用關(guān)心怪物內(nèi)部邏輯怪物死亡時(shí)廣播一個(gè)事件不用關(guān)心誰在聽UI和音效各自訂閱事件不用關(guān)心戰(zhàn)斗流程。4.3 核心代碼落地拆解以怪物生成為例我先把關(guān)鍵的生成器簡(jiǎn)化一下。這里要注意的是代碼層面做了兩件很重要的事讀配置表驅(qū)動(dòng)創(chuàng)建以及把業(yè)務(wù)實(shí)體和預(yù)制體解耦。public class MonsterSpawner : MonoBehaviour { [SerializeField] private MonsterFactory _factory; [SerializeField] private ObjectPoolMonsterBase _pool; public void SpawnWave(WaveConfig waveConfig) { foreach (var item in waveConfig.monsterItems) { for (int i 0; i item.count; i) { MonsterBase monster _factory.CreateMonster(item.monsterId); monster.transform.position GetSpawnPosition(); monster.OnDeath HandleMonsterDeath; } } } private void HandleMonsterDeath(MonsterBase monster) { monster.OnDeath - HandleMonsterDeath; _pool.Return(monster); EventCenter.Broadcast(OnMonsterKilled, monster.Data); } }這段代碼的含金量在哪里首先創(chuàng)建怪物交給了工廠把生成邏輯收斂到一個(gè)點(diǎn)其次怪物死亡后自動(dòng)回池不需要業(yè)務(wù)方關(guān)心“回收”這件事最后還有通過事件廣播把“怪物死亡”這一信息廣播出去UI、任務(wù)、成就自己決定要不要訂閱。代碼整潔度和可擴(kuò)展性都在線。再貼一段怪物狀態(tài)機(jī)的簡(jiǎn)化框架你看下狀態(tài)類內(nèi)部是怎么組織的public class MeleeAttackState : StateBase { private MonsterBase _monster; public MeleeAttackState(StateMachine machine, MonsterBase monster) : base(machine) { _monster monster; } public override void OnEnter() { _monster.PlayAnimation(Attack); } public override void OnUpdate() { if (_monster.Target null || !_monster.Target.IsAlive) { machine.ChangeStateIdleState(); return; } if (!_monster.IsInAttackRange) { machine.ChangeStateChaseState(); } } }這套狀態(tài)機(jī)在實(shí)際戰(zhàn)斗中被驗(yàn)證過效果近戰(zhàn)怪的“追擊-攻擊-追擊”來回切換遠(yuǎn)程怪的“保持距離-蓄力-釋放”組合全都靠不同狀態(tài)類的組合實(shí)現(xiàn)邏輯清晰調(diào)試時(shí)用Log打一下狀態(tài)切換就能定位問題。4.4 上線后復(fù)盤模式設(shè)計(jì)的收益與成本這個(gè)副本玩法上線后我做過一次復(fù)盤。收益非常明顯第一后續(xù)加了三種新怪物沒有改任何戰(zhàn)斗模塊代碼只新增狀態(tài)類和在工廠里注冊(cè)預(yù)制體第二性能抖動(dòng)消失了怪潮生成時(shí)幀率穩(wěn)定第三UI和邏輯徹底解耦策劃調(diào)UI布局不碰邏輯代碼。但成本也有。狀態(tài)類和工廠類的數(shù)量增多文件查找變得困難。為了緩解這個(gè)問題我們制定了文件夾組織規(guī)范狀態(tài)類按角色分文件夾工廠類按業(yè)務(wù)模塊分文件夾公共組件放在共享目錄。這些規(guī)范不是設(shè)計(jì)模式教的是項(xiàng)目經(jīng)驗(yàn)沉淀出來的。5. 常見問題排查與避坑技巧實(shí)錄這部分內(nèi)容是我最想分享的因?yàn)樵O(shè)計(jì)模式的書里和文章不會(huì)寫這些全是實(shí)戰(zhàn)踩出來的血淚。5.1 狀態(tài)機(jī)陷入“狀態(tài)抖動(dòng)”怎么辦最常見的問題是所謂狀態(tài)抖動(dòng)State Jitter兩個(gè)狀態(tài)之間的切換條件同時(shí)滿足導(dǎo)致同一幀內(nèi)反復(fù)切換。比如追擊狀態(tài)切攻擊狀態(tài)的時(shí)候攻擊距離判斷邊緣正好抖動(dòng)角色就會(huì)瘋狂抽搐。我的解法加一個(gè)“最小切換間隔”狀態(tài)機(jī)內(nèi)部記錄上一次切換的時(shí)間如果距離上次切換小于一定幀數(shù)直接忽略切換請(qǐng)求。另外狀態(tài)進(jìn)入時(shí)把條件“鎖住”一幀避免OnEnter內(nèi)部立刻觸發(fā)條件判斷。5.2 事件中心導(dǎo)致的對(duì)象泄漏前面用了事件中心后還有個(gè)經(jīng)典的坑UI面板關(guān)閉時(shí)如果忘了退訂事件閉包會(huì)一直持有面板的引用。這時(shí)候你在場(chǎng)景里隱藏了面板但內(nèi)存里它永遠(yuǎn)活著重復(fù)打開關(guān)閉十幾遍內(nèi)存飆到爆炸。排查思路很直接注冊(cè)中心在Subscribe的時(shí)候記錄訂閱對(duì)象的TypeUnsubscribe檢查一次?；蛘咧苯訉懸欢未a在Editor模式下定期掃描所有事件監(jiān)聽器的引用對(duì)象是否已被銷毀。我現(xiàn)在的項(xiàng)目里甚至上線了一個(gè)“事件泄漏報(bào)警器”開發(fā)模式下打印警告。5.3 對(duì)象池“回收不干凈”導(dǎo)致數(shù)據(jù)錯(cuò)亂池化的對(duì)象復(fù)用后如果內(nèi)部有上次使用殘留的數(shù)據(jù)就會(huì)產(chǎn)生各種幽靈Bug。比如怪物的血量沒重置第二次出來只有50%血子彈的方向還是上一次的發(fā)射角度全錯(cuò)。解決方式是強(qiáng)制約定一個(gè)IReset接口所有池化對(duì)象必須實(shí)現(xiàn)。Get的時(shí)候調(diào)用一次ResetReturn的時(shí)候調(diào)一次。這個(gè)接口不能省省了就是給自己埋雷。5.4 過度設(shè)計(jì)的邊界感最后想聊一個(gè)和設(shè)計(jì)模式本身關(guān)系不大但又密切相關(guān)的實(shí)操問題怎么判斷當(dāng)前需求值不值得應(yīng)用設(shè)計(jì)模式。我的判斷標(biāo)準(zhǔn)有三個(gè)如果這個(gè)功能寫死就再也不改直接用最簡(jiǎn)單的方式別上模式。如果需求文檔里明確出現(xiàn)“后續(xù)會(huì)有多種…”“未來要支持自定義…”那值得上模式。如果團(tuán)隊(duì)里其他人對(duì)這套模式不熟悉你需要先花半天時(shí)間做一個(gè)培訓(xùn)分享否則代碼寫出來沒人能維護(hù)。設(shè)計(jì)模式是團(tuán)隊(duì)的溝通語言不是個(gè)人炫技的資本。一個(gè)人寫得飛起全組看不懂這個(gè)成本比代碼本身的結(jié)構(gòu)問題更致命。6. 最后分享我的幾個(gè)習(xí)慣項(xiàng)目做多了其實(shí)能沉淀下來的方法論就那么幾條。我個(gè)人的體會(huì)是設(shè)計(jì)模式的運(yùn)用不是靠背而是靠一次次重構(gòu)練出來的。你第一次寫一個(gè)戰(zhàn)斗系統(tǒng)可能全是if-else第二次寫的時(shí)候發(fā)現(xiàn)相同邏輯出現(xiàn)多處自然而然就抽出了狀態(tài)機(jī)第三次再遇到類似需求你會(huì)直接開始規(guī)劃狀態(tài)接口——這個(gè)過程就是“模式化思維”的養(yǎng)成。另外一個(gè)很實(shí)用的建議每次做技術(shù)方案選型的時(shí)候把你選擇的模式名稱寫進(jìn)代碼注釋里。比如在類注釋上寫“Class: MonsterStateMachine此處使用狀態(tài)模式管理怪物行為便于后續(xù)擴(kuò)展新狀態(tài)”。這能幫你和后來的維護(hù)者快速建立上下文比單獨(dú)寫一份文檔有用得多。對(duì)了還有一個(gè)小技巧Unity的新版本內(nèi)置了部分設(shè)計(jì)模式的官方實(shí)現(xiàn)思路比如Addressables里的資源句柄思想和對(duì)象池思路是互通的。你學(xué)設(shè)計(jì)模式的時(shí)候如果能跟引擎底層的實(shí)現(xiàn)方式對(duì)上號(hào)理解會(huì)深很多。比如協(xié)程本質(zhì)上是一個(gè)迭代器模式ResourceManager的資源加載本質(zhì)上是一個(gè)代理模式AssetBundle的依賴關(guān)系本質(zhì)上是組合模式。最后回答一個(gè)很多人會(huì)問的問題設(shè)計(jì)模式要學(xué)到什么程度才能進(jìn)商業(yè)項(xiàng)目我的答案很簡(jiǎn)單——不要求你會(huì)背二十三種模式的全部定義但以下六種必須能熟練寫出且講清原理狀態(tài)、觀察者、單例、工廠、對(duì)象池、命令。這六種覆蓋了我遇到的大概80%的業(yè)務(wù)場(chǎng)景。其他模式遇到了再學(xué)帶著問題學(xué)得更快。就寫到這里希望對(duì)正在做Unity開發(fā)的你有點(diǎn)幫助。模式這東西用起來才是你的光看文章永遠(yuǎn)都是別人的。