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