做Unity3d客户端开发这几年我踩过的最深的坑就是项目一变大代码开始互相纠缠。早期写单机小游戏还好到了带多界面、多玩法模块、频繁换活动内容的项目如果里面没有一个统一的Frame架构光是理清调用关系就能耗掉大把时间。今天想把我自己在Unity3d项目里反复沉淀下来的一套Frame架构做一个完整说明。它不是开源库也没有标准答案就是我实际在商业项目和独立项目中迭代验证过的一套代码组织方式希望对正在被混乱脚本困扰的朋友有点参考作用。这套架构的核心思路可以概括成几句话统一入口、分层管理、事件驱动、生命周期可控。它解决的问题主要就是三个初始化顺序乱、UI层级失控、模块之间通信靠硬引用。如果你也遇到类似的痛点看完这篇再动手改应该能省不少试错的时间。1. 为什么我在Unity3d项目里自己搭了一套Frame架构1.1 没有框架的Unity项目通常是什么状态相信不少人和我有同样的经历项目雏形阶段一切都很美好几个场景、几十个脚本自己都能记住每段逻辑在哪。但随着功能迭代剧情模式、关卡系统、商城、排行榜、新手引导陆续加进来项目开始变得很难伺候。常见的失控表现大概是这样的每个面板都自己加载资源、自己注册按钮事件、UI之间互相new对象、模块A需要弹窗时直接去调用模块B的静态方法。更麻烦的是有些全局管理器每个场景里都放了一份场景切换时旧的单例没销毁新的也没注册成功运行期各种空引用。这种状态下每加一个新功能都可能把旧逻辑震出一个洞来。说白了问题不在程序员的能力而在于Unity引擎本身给开发者的自由度太高。MonoBehaviour的Awake、Start、OnEnable执行顺序虽然有一定规则但不同对象的执行先后在引擎内部是不保证的一旦脚本之间有依赖关系这套顺序就成了不稳定的地基。1.2 Frame架构到底要解决哪些核心问题基于上面这些痛点我当时给自己定了几条必须解决的硬指标后来也成了这套Frame架构的设计纲领。第一初始化顺序必须有唯一入口。所有模块的初始化都在同一个地方显式调用先后顺序自己定不依赖场景里对象的加载顺序。这样哪怕场景里挂了二十个脚本彼此之间也不会因为初始化时机不同而踩到空引用。第二UI面板必须能统一管理。包括面板的打开、关闭、层级遮挡、回退逻辑。没有统一管理时最尴尬的情况是弹了个设置界面结果被后面打开的主界面挡住了交互按钮点不到玩家还以为游戏卡死了。第三模块间通信必须解耦。UI按钮点了要通知战斗模块战斗结束了要通知奖励模块不能每个模块都持有其他模块的引用。事件中心是最直接的解法订阅和发布两端完全独立后续加新模块也不需要回头改旧模块的代码。第四对象的创建销毁要控制住。频繁的Instantiate和Destroy会带来大量的GC开销尤其在移动设备上卡顿和掉电都是这么来的。对象池这套东西在Frame架构里必须有一席之地。1.3 这套架构的设计边界我需要特别说明一点框架不是越重越好。市面上有很多成熟的商业框架比如ET、Lockstep、QFramework之类它们功能全面但学习曲线陡峭对小型团队和中小项目来说往往用不到那么多抽象层。我自己的原则是轻量、可裁剪、一个新人一周内能上手。所以这套Frame只做了四件事生命周期管理、UI管理、事件通信、资源与对象池。像热更新、网络模块、可视化编辑器辅助这些并不是每个项目都需要的东西一律不放进核心层按项目需求在外面再做插件化扩展。注意如果你手里的项目还处于原型阶段功能量很小脚本也就十几个那我的建议是不要急着上框架保持朴素就好。框架是为复杂服务的过早的架构设计只会拖慢你的迭代速度。2. Frame架构整体设计思路与模块划分2.1 整体分层入口、管理、逻辑、表现这套Frame架构在逻辑上分了四层每一层只依赖下面一层不跨层调用这让整个项目的代码方向变得非常清晰。最上面是入口层也就是GameRoot。它是一个永不销毁的空GameObject挂一个GameRoot脚本负责整个游戏的生命周期入口。游戏启动之后的所有流程都由它来驱动包括初始化各Manager、加载启动场景、设置全局帧率等。第二层是管理层包括UIManager、ResourceManager、EventCenter、AudioManager、ObjectPool这些。每个Manager都做成单例但单例的创建和初始化都由GameRoot控制不搞那种被外部访问时才懒加载的花活。第三层是逻辑层包括角色控制、战斗规则、关卡进度、任务系统等等。逻辑层之间不做直接的类引用彼此之间的通信走EventCenter收到什么事件做什么反应互不干扰。最下面一层是表现层包括动画控制器、特效组件、UI表现脚本。表现层只负责把逻辑层的数据状态渲染出来本身不写业务判断。分层之后最大的感受是出Bug的时候定位范围小了十次里有八次能一眼看出问题在逻辑层还是表现层。2.2 生命周期管理手动可控的Update调度Unity自带的脚本生命周期有一个让人头疼的地方同样挂一个Update方法不同脚本的执行顺序在官方文档里明确写了“不确定”。一旦你的玩法逻辑强依赖某一帧内多个Manager的执行顺序这个不确定性就是隐患。所以我在Frame架构里做了一个很直接的约定所有需要持续驱动的模块都显式提供Init和Tick方法由GameRoot统一在Update里调度。private void Update() { float dt Time.deltaTime; // 先驱动全局管理器 EventCenter.Instance.Tick(dt); ResourceManager.Instance.Tick(dt); // 再驱动UI系统 UIManager.Instance.Tick(dt); // 最后驱动游戏逻辑层 GameLogicManager.Instance.Tick(dt); }这样做的直接好处是执行顺序写死在代码里任何人接手项目打开GameRoot一眼就能看出全局驱动的顺序。要调整优先级也只需要改这一处不需要跑到各个脚本里改生命周期函数。另外这种集中式调度也方便做全局暂停。比如点击暂停按钮时只需要屏蔽GameRoot的Update里逻辑层的驱动表现层的部分效果还能继续玩家体验上会更灵活。你不用在每个逻辑脚本里写一堆暂停判断。2.3 事件中心让模块通信变得干净事件中心这套Frame里最常用、也最容易被更多人接受的一个模块。我把它封装成一个静态类底层就是一个字典key是事件名value是委托列表。订阅、发布、退订三个方法足够应付绝大多数通信场景。public class EventCenter { private static readonly Dictionarystring, Actionobject _listeners new Dictionarystring, Actionobject(); public static void Subscribe(string evtName, Actionobject handler) { if (!_listeners.TryGetValue(evtName, out Actionobject actions)) { actions delegate { }; _listeners[evtName] actions; } _listeners[evtName] handler; } public static void Unsubscribe(string evtName, Actionobject handler) { if (_listeners.TryGetValue(evtName, out Actionobject actions)) { _listeners[evtName] - handler; } } public static void Dispatch(string evtName, object param null) { if (_listeners.TryGetValue(evtName, out Actionobject actions)) { actions?.Invoke(param); } } }说起来很简单但实际使用中有几个细节值得留意。一个是事件名的定义我习惯用静态常量类把所有事件名集中管理避免字符串散落各处拼写错误编译期还发现不了。另一个就是订阅和退订的成对性谁订阅的事件谁就必须在生命周期结束的时候退订不然就是泄漏和重复触发的隐患。这个坑我在后面的章节还会展开讲。2.4 资源加载与对象池性能的关键资源加载这块早期项目我用的是Resources.Load加字典缓存的方式够用且简单。后来项目体量大了换成了AssetBundle方案再后面统一到了Addressables。但不管底层用哪种加载方案Frame架构里ResourceManager对外暴露的接口始终是统一的Load 按路径加载返回缓存后的结果。对象池的设计思路也很典型预设一个初始容量用完不销毁而是回收进池子下次需要时直接从池里取。比如战斗里子弹、飘字、粒子特效这些高频对象用对象池之后GC Alloc能降一个数量级。后面实操部分我会给出一个简化版的实现并说明几个参数怎么定才合理。2.5 UI管理界面生命周期与层级控制UI部分是玩家直接感知的东西所以我把UIManager单独拿出来说。平时不开框架的时候大家习惯每个面板Prefab自己挂脚本点击打开面板就Instantiate关闭就Destroy。这个做法在面板少的时候没有问题面板一多麻烦就来了。UIManager的核心数据结构是一个栈。打开新面板时压栈关闭时弹栈栈顶永远是最新打开的面板层级上也自然在最上面。面板基类定义了OnEnter、OnExit、OnPause、OnResume四个生命周期方法分别对应入栈、出栈、被压住、重新成为顶层这几个状态。为什么要设计这四个方法因为很多时候从目录页打开详情页目录页不应该被销毁而是应该暂停刷新逻辑等详情页关闭之后再恢复。如果整个面板直接销毁玩家的滑动位置和临时状态就全丢了体验非常糟糕。public abstract class UIBasePanel : MonoBehaviour { public abstract void OnEnter(); public abstract void OnExit(); public virtual void OnPause() { } public virtual void OnResume() { } }3. 实操最小可用Frame的搭建过程3.1 工程目录结构规划写代码之前先把目录划分好。我的习惯是Assets下按Framework和Game两大块来分Framework放通用框架代码Game放具体游戏逻辑。这样做的目的很单纯Framework里的代码不依赖任何Game层的业务拿到下一个项目里可以整套搬走一分钱改动都不用做。Assets/ Scripts/ Framework/ GameRoot.cs EventCenter.cs UIManager.cs UIBasePanel.cs ResourceManager.cs ObjectPool.cs Game/ MainPanel.cs SettingPanel.cs PlayerLogic.cs BattleLogic.cs Resources/ UI/ MainPanel.prefab SettingPanel.prefab Scenes/ BootstrapScene.unityResources目录下的UI子目录和UIManager的加载路径是约定的面板名和Prefab名保持完全一致减少一次路径映射的成本。3.2 GameRoot整个架构的发动机GameRoot是唯一一个在场景里手动挂载的脚本其他Manager都是在Awake里自己派生的单例。把GameRoot做成DontDestroyOnLoad这样在场景切换时管理器不会销毁数据得以保留。public class GameRoot : MonoBehaviour { private void Awake() { DontDestroyOnLoad(gameObject); // 各模块按依赖顺序初始化 EventCenter.Instance.Init(); ResourceManager.Instance.Init(); UIManager.Instance.Init(); GameLogicManager.Instance.Init(); } private void Start() { // 启动流程先出主界面 UIManager.Instance.OpenPanelMainPanel(MainPanel); } private void Update() { float dt Time.deltaTime; EventCenter.Instance.Tick(dt); UIManager.Instance.Tick(dt); GameLogicManager.Instance.Tick(dt); } private void OnApplicationQuit() { // 全局事件清理 EventCenter.Instance.Release(); } }这就是发动机的核心逻辑。初始化顺序一定要按依赖关系的倒序来先初始化基础设施层事件、资源再初始化依赖这些的UI层和逻辑层。如果顺序反了UIManager初始化时想通过ResourceManager加载东西就会踩空引用。3.3 UIManager实现面板栈和缓存的协作UI面板的管理核心是栈结构和字典结构协作。字典负责快速查找某个面板是否存在栈负责维护显示顺序。public class UIManager : MonoBehaviour { private static UIManager _instance; public static UIManager Instance { get { if (_instance null) { GameObject go new GameObject(UIManager); _instance go.AddComponentUIManager(); } return _instance; } } private readonly StackUIBasePanel _panelStack new StackUIBasePanel(); private readonly Dictionarystring, UIBasePanel _panelDict new Dictionarystring, UIBasePanel(); private Transform _uiRoot; public void Init() { _uiRoot GameObject.Find(UIRoot).transform; } public T OpenPanelT(string panelName) where T : UIBasePanel { if (_panelDict.TryGetValue(panelName, out T exists)) { _panelStack.Peek()?.OnPause(); _panelStack.Push(exists); exists.OnEnter(); exists.OnResume(); return exists; } GameObject prefab ResourceManager.Instance.LoadGameObject($UI/{panelName}); GameObject go Instantiate(prefab, _uiRoot); T panel go.GetComponentT(); if (panel null) { Debug.LogError($[UIManager] {panelName} 缺少UIBasePanel组件); return null; } if (_panelStack.Count 0) { _panelStack.Peek()?.OnPause(); } _panelStack.Push(panel); _panelDict[panelName] panel; panel.OnEnter(); return panel; } public void ClosePanel(string panelName) { if (!_panelDict.TryGetValue(panelName, out UIBasePanel panel)) return; if (_panelStack.Peek() ! panel) { Debug.LogWarning([UIManager] 当前面板不在栈顶不建议直接关闭); return; } _panelStack.Pop(); _panelDict.Remove(panelName); panel.OnExit(); Destroy(panel.gameObject); if (_panelStack.Count 0) { _panelStack.Peek().OnResume(); } } public void Tick(float dt) { if (_panelStack.Count 0) return; _panelStack.Peek().Tick(dt); } }这里需要注意几个问题。第一面板的Prefab实例化之后一定要检查GetComponent 是否拿到组件如果没有就立刻报错后面操作返回空引用会非常难排查。第二ClosePanel不是所有面板都在栈顶的时候才允许关闭的但最常见的情况确实是栈顶面板关闭。如果某个底层面板需要被强制关闭我会先把它上面的所有面板都弹掉再关它避免栈里存在已经销毁的对象。3.4 ResourceManager与对象池的简化实现ResourceManager我直接贴一个可用的版本。核心就是一个字典缓存加载过的资源不重复Load。如果项目后来迁移到AssetBundle或者Addressables只需要替换这个类内部的加载逻辑外部接口不变。public class ResourceManager : MonoBehaviour { private static ResourceManager _instance; public static ResourceManager Instance { get { if (_instance null) { GameObject go new GameObject(ResourceManager); _instance go.AddComponentResourceManager(); } return _instance; } } private readonly Dictionarystring, UnityEngine.Object _cache new Dictionarystring, UnityEngine.Object(); public void Init() { } public T LoadT(string path) where T : UnityEngine.Object { if (_cache.TryGetValue(path, out UnityEngine.Object cached)) { return cached as T; } T resource Resources.LoadT(path); if (resource ! null) { _cache[path] resource; } else { Debug.LogError($[ResourceManager] 加载失败: {path}); } return resource; } public void Release(string path) { if (_cache.Remove(path)) { Resources.UnloadUnusedAssets(); } } }对象池的通用实现也不复杂但有两个点很容易被新手写坏。第一是对象的回收状态重置从池里取出来的对象必须OnEnable重新初始化回收时必须OnDisable清理状态。第二是池的上限控制如果池满了还不能回收旧对象宁可创建一个新的也不能无限膨胀。UE和Unity的实战经验都证明一个没有上限的对象池最终会成为内存泄漏的另一种形式。public class ObjectPool { private readonly StackGameObject _pool new StackGameObject(); private readonly GameObject _prefab; private readonly int _maxSize; public ObjectPool(GameObject prefab, int preloadCount, int maxSize) { _prefab prefab; _maxSize maxSize; for (int i 0; i preloadCount; i) { GameObject go CreateInstance(); go.SetActive(false); _pool.Push(go); } } private GameObject CreateInstance() { GameObject go Object.Instantiate(_prefab); go.name ${_prefab.name}_Pooled; IPoolable poolable go.GetComponentIPoolable(); poolable?.OnPoolInit(); return go; } public GameObject Get() { GameObject go _pool.Count 0 ? _pool.Pop() : CreateInstance(); go.SetActive(true); IPoolable poolable go.GetComponentIPoolable(); poolable?.OnPoolGet(); return go; } public void Recycle(GameObject go) { if (_pool.Count _maxSize) { Object.Destroy(go); return; } IPoolable poolable go.GetComponentIPoolable(); poolable?.OnPoolRecycle(); go.SetActive(false); _pool.Push(go); } } public interface IPoolable { void OnPoolInit(); void OnPoolGet(); void OnPoolRecycle(); }对象池的初始预载数量和最大容量要怎么定这个不能拍脑袋。我常用的方法是先跑一遍玩法在Profiler里看同一帧内某个对象类型最多同时存在的数量然后取这个数量的1.2到1.5倍作为最大容量预载量取最大容量的30%左右最经济。这样既不会频繁创建新实例内存占用也不会太离谱。3.5 接入示例场景的完整流程理论讲完了下面说一个实际接入步骤跟着做不出错。第一步创建一个空场景命名为BootstrapScene。场景里创建一个空GameObject命名为GameRoot挂上GameRoot脚本。第二步创建UIRoot。在场景里创建一个Canvas命名为UIRoot。Canvas的渲染模式设为ScreenSpaceOverlayCanvasScaler的UI缩放模式设为ScaleWithScreenSize参考分辨率按你的项目目标设我一般用1920x1080。把UIRoot的RectTransform设为全屏拉伸然后让UIManager的Init方法里通过GameObject.Find找到它。这一步要保证UIRoot和GameRoot在同一个场景里且UIRoot命名不能改。第三步创建MainPanel预制体。在Resources/UI目录下新建一个Panel命名为MainPanel底下挂一个Text组件显示游戏主界面标题再放一个按钮用于打开设置界面。给MainPanel挂上MainPanel脚本这个脚本继承UIBasePanel实现OnEnter和OnExit在OnEnter里注册按钮事件。第四步运行场景。你会看到GameRoot的Start里打开主面板点按钮打开设置面板设置面板关闭后主面板恢复。这一套流程如果走通了后面扩展新面板和新模块只需要照着同样的模式往里面加就行。public class MainPanel : UIBasePanel { public override void OnEnter() { gameObject.SetActive(true); // 注册打开设置面板的按钮时间 transform.Find(Btn_Setting).GetComponentButton().onClick.AddListener(() { UIManager.Instance.OpenPanelSettingPanel(SettingPanel); }); } public override void OnExit() { gameObject.SetActive(false); } public override void OnPause() { gameObject.SetActive(false); } public override void OnResume() { gameObject.SetActive(true); } }3.6 性能观测怎么确认Frame真的有效框架搭完之后不能只看代码写得舒服得用数据说话。我一般会在游戏运行状态下打开Window General Profiler切到CPU Usage模块盯着两三个指标看一是GC Alloc每帧分配的内存如果长时间稳定在0附近说明对象池和缓存策略有效果二是Mono的脚本耗时如果某个Manager的Tick占据过高就说明那个模块需要优化三是DrawCall数量这个主要和UI合批策略相关但也能反映UI面板的组织是否合理。还有个更实用的办法在关闭对象池和不关闭对象池两种状态下各跑一场相同的战斗对比GC Alloc的差异。我实测过一个小规模弹幕游戏不用对象池的时候GC Alloc峰值能到800KB每帧用了之后降到20KB以下卡顿感肉眼可见地消失了。4. 常见问题与排查技巧实录4.1 生命周期执行顺序混乱的问题有一个特别隐蔽的问题GameRoot的Awake里初始化EventCenter之后其他Manager的Awake可能也在这个时刻执行但MonoBehaviour的Awake顺序不确定。如果某个Manager在Awake里就订阅了事件而EventCenter还没初始化好运行期就会偶发找不到字典的异常。我的解决方案是在每个Manager的Init方法里把所有依赖先准备好不在Awake里直接依赖其他Manager。EventCenter底层是字典结构只要Init先被调用其他Manager订阅的时候字典就存在了。在代码里明确写着Init调用顺序这一点比依赖引擎的Awake顺序靠谱得多。4.2 UI层级和遮挡问题UIManager用栈管理层级之后偶尔还是会遇到“弹窗被旧界面挡住”的情况。这通常是因为某个面板的Canvas组件没有排序或者新旧面板不在同一个Canvas下。我的经验是所有UI面板挂在同一个UIRoot下并且每个面板预制体自身带一个Canvas和CanvasGroup。面板的Canvas不用改让UIManager在OpenPanel时按栈的深度动态调整Canvas的sortingOrder。栈顶面板的sortingOrder最高这样在同一个UIRoot下不管面板嵌套多深遮挡关系都能保证正确。千万别用多个根Canvas来管理层级那会让问题失控。多个Canvas互相之间的遮挡顺序跟它们在Hierarchy里的先后顺序有关这个顺序在动态创建面板时很难手动维持纯属给自己挖坑。4.3 事件监听泄漏导致的问题事件中心用久了最容易踩的坑就是泄漏和重复触发。两个现象都指向同一个原因订阅了事件但没退订。最典型的场景是打开设置面板时订阅了一个战斗事件设置面板关闭时没有退订。下次再打开设置面板又订阅一次。第一次分发事件的时候面板里的回调触发一次如果开开关关三次回调触发三次。如果回调里面还有弹窗逻辑那画面基本就乱了。我记得有一次排查线上的一个Bug玩家在背包界面点一件装备有时候弹一个详情有时候连弹三个详情关卡有时还会瞬间重新加载。后来定位发现背包界面的脚本在OnEnable里订阅了“装备变化”事件OnDisable里没有退订几次进出背包后事件回调执行了数遍每次回调都触发一次详情弹窗和一次刷新逻辑几个Bug串在一起才显得那么魔幻。正确做法是强制成对使用订阅和退订必须出现在同一个脚本的成对生命周期方法里。我在UIManager的面板基类里定了规矩OnEnter里订阅OnExit里退订推荐所有面板都遵守这个约定。4.4 架构演进里踩过的坑和扩展方向这套Frame架构用到后期我也发现了一些需要注意的地方写出来供大家参考。过度的架构设计是真实的陷阱。有一次我尝试把每个UI面板都抽象成一个ViewModel还想引入依赖注入框架结果项目进度被拖慢了一倍团队成员连跑通环境都要花几天最后被迫回退到简洁版本。框架是为了提高效率如果引入的成本大于收益那它就是个负面资产。单例的滥用也值得警惕。我早期把很多管理器都写成单例比如货币管理、任务进度管理、成就管理后来发现单例一旦多了测试的时候很难单独隔离一个模块。所以后期我做了一个调整只有真正全局唯一的模块才用单例比如UI、资源、事件中心业务逻辑模块尽量通过事件通信不搞全局访问。音频管理、数据持久化、网络层这些模块我都建议在新项目里按同样的思路封装进Frame统一归GameRoot调度。比如音频管理提供一个PlayBGM和PlayOneShot方法内部走事件中心任何模块只要发一个PlayAudioEvent就能播放声音解耦效果非常明显。最后再分享一个关于扩展方向的想法。Unity3d的工程化水平决定了项目能走多远但框架本身不用一步到位。我建议你从这套最小架构开始跟着真实项目去迭代。第一个月你可能只需要GameRoot和UIManager第二个月发现事件通信太重要了第三个月被GC困扰开始上对象池半年之后回过头看这套Frame已经变得既顺手又成熟而且它里的每一行代码你都清楚为什么而写。这种自底向上积累出来的框架比直接抄一份大而全的框架要实用得多。 
长河君 · 2026/9/19 5:36:39 · 阅读 1.2k Unity3d项目Frame架构搭建：分层管理、事件驱动与对象池实践
做Unity3d客户端开发这几年我踩过的最深的坑就是项目一变大代码开始互相纠缠。早期写单机小游戏还好到了带多界面、多玩法模块、频繁换活动内容的项目如果里面没有一个统一的Frame架构光是理清调用关系就能耗掉大把时间。今天想把我自己在Unity3d项目里反复沉淀下来的一套Frame架构做一个完整说明。它不是开源库也没有标准答案就是我实际在商业项目和独立项目中迭代验证过的一套代码组织方式希望对正在被混乱脚本困扰的朋友有点参考作用。这套架构的核心思路可以概括成几句话统一入口、分层管理、事件驱动、生命周期可控。它解决的问题主要就是三个初始化顺序乱、UI层级失控、模块之间通信靠硬引用。如果你也遇到类似的痛点看完这篇再动手改应该能省不少试错的时间。1. 为什么我在Unity3d项目里自己搭了一套Frame架构1.1 没有框架的Unity项目通常是什么状态相信不少人和我有同样的经历项目雏形阶段一切都很美好几个场景、几十个脚本自己都能记住每段逻辑在哪。但随着功能迭代剧情模式、关卡系统、商城、排行榜、新手引导陆续加进来项目开始变得很难伺候。常见的失控表现大概是这样的每个面板都自己加载资源、自己注册按钮事件、UI之间互相new对象、模块A需要弹窗时直接去调用模块B的静态方法。更麻烦的是有些全局管理器每个场景里都放了一份场景切换时旧的单例没销毁新的也没注册成功运行期各种空引用。这种状态下每加一个新功能都可能把旧逻辑震出一个洞来。说白了问题不在程序员的能力而在于Unity引擎本身给开发者的自由度太高。MonoBehaviour的Awake、Start、OnEnable执行顺序虽然有一定规则但不同对象的执行先后在引擎内部是不保证的一旦脚本之间有依赖关系这套顺序就成了不稳定的地基。1.2 Frame架构到底要解决哪些核心问题基于上面这些痛点我当时给自己定了几条必须解决的硬指标后来也成了这套Frame架构的设计纲领。第一初始化顺序必须有唯一入口。所有模块的初始化都在同一个地方显式调用先后顺序自己定不依赖场景里对象的加载顺序。这样哪怕场景里挂了二十个脚本彼此之间也不会因为初始化时机不同而踩到空引用。第二UI面板必须能统一管理。包括面板的打开、关闭、层级遮挡、回退逻辑。没有统一管理时最尴尬的情况是弹了个设置界面结果被后面打开的主界面挡住了交互按钮点不到玩家还以为游戏卡死了。第三模块间通信必须解耦。UI按钮点了要通知战斗模块战斗结束了要通知奖励模块不能每个模块都持有其他模块的引用。事件中心是最直接的解法订阅和发布两端完全独立后续加新模块也不需要回头改旧模块的代码。第四对象的创建销毁要控制住。频繁的Instantiate和Destroy会带来大量的GC开销尤其在移动设备上卡顿和掉电都是这么来的。对象池这套东西在Frame架构里必须有一席之地。1.3 这套架构的设计边界我需要特别说明一点框架不是越重越好。市面上有很多成熟的商业框架比如ET、Lockstep、QFramework之类它们功能全面但学习曲线陡峭对小型团队和中小项目来说往往用不到那么多抽象层。我自己的原则是轻量、可裁剪、一个新人一周内能上手。所以这套Frame只做了四件事生命周期管理、UI管理、事件通信、资源与对象池。像热更新、网络模块、可视化编辑器辅助这些并不是每个项目都需要的东西一律不放进核心层按项目需求在外面再做插件化扩展。注意如果你手里的项目还处于原型阶段功能量很小脚本也就十几个那我的建议是不要急着上框架保持朴素就好。框架是为复杂服务的过早的架构设计只会拖慢你的迭代速度。2. Frame架构整体设计思路与模块划分2.1 整体分层入口、管理、逻辑、表现这套Frame架构在逻辑上分了四层每一层只依赖下面一层不跨层调用这让整个项目的代码方向变得非常清晰。最上面是入口层也就是GameRoot。它是一个永不销毁的空GameObject挂一个GameRoot脚本负责整个游戏的生命周期入口。游戏启动之后的所有流程都由它来驱动包括初始化各Manager、加载启动场景、设置全局帧率等。第二层是管理层包括UIManager、ResourceManager、EventCenter、AudioManager、ObjectPool这些。每个Manager都做成单例但单例的创建和初始化都由GameRoot控制不搞那种被外部访问时才懒加载的花活。第三层是逻辑层包括角色控制、战斗规则、关卡进度、任务系统等等。逻辑层之间不做直接的类引用彼此之间的通信走EventCenter收到什么事件做什么反应互不干扰。最下面一层是表现层包括动画控制器、特效组件、UI表现脚本。表现层只负责把逻辑层的数据状态渲染出来本身不写业务判断。分层之后最大的感受是出Bug的时候定位范围小了十次里有八次能一眼看出问题在逻辑层还是表现层。2.2 生命周期管理手动可控的Update调度Unity自带的脚本生命周期有一个让人头疼的地方同样挂一个Update方法不同脚本的执行顺序在官方文档里明确写了“不确定”。一旦你的玩法逻辑强依赖某一帧内多个Manager的执行顺序这个不确定性就是隐患。所以我在Frame架构里做了一个很直接的约定所有需要持续驱动的模块都显式提供Init和Tick方法由GameRoot统一在Update里调度。private void Update() { float dt Time.deltaTime; // 先驱动全局管理器 EventCenter.Instance.Tick(dt); ResourceManager.Instance.Tick(dt); // 再驱动UI系统 UIManager.Instance.Tick(dt); // 最后驱动游戏逻辑层 GameLogicManager.Instance.Tick(dt); }这样做的直接好处是执行顺序写死在代码里任何人接手项目打开GameRoot一眼就能看出全局驱动的顺序。要调整优先级也只需要改这一处不需要跑到各个脚本里改生命周期函数。另外这种集中式调度也方便做全局暂停。比如点击暂停按钮时只需要屏蔽GameRoot的Update里逻辑层的驱动表现层的部分效果还能继续玩家体验上会更灵活。你不用在每个逻辑脚本里写一堆暂停判断。2.3 事件中心让模块通信变得干净事件中心这套Frame里最常用、也最容易被更多人接受的一个模块。我把它封装成一个静态类底层就是一个字典key是事件名value是委托列表。订阅、发布、退订三个方法足够应付绝大多数通信场景。public class EventCenter { private static readonly Dictionarystring, Actionobject _listeners new Dictionarystring, Actionobject(); public static void Subscribe(string evtName, Actionobject handler) { if (!_listeners.TryGetValue(evtName, out Actionobject actions)) { actions delegate { }; _listeners[evtName] actions; } _listeners[evtName] handler; } public static void Unsubscribe(string evtName, Actionobject handler) { if (_listeners.TryGetValue(evtName, out Actionobject actions)) { _listeners[evtName] - handler; } } public static void Dispatch(string evtName, object param null) { if (_listeners.TryGetValue(evtName, out Actionobject actions)) { actions?.Invoke(param); } } }说起来很简单但实际使用中有几个细节值得留意。一个是事件名的定义我习惯用静态常量类把所有事件名集中管理避免字符串散落各处拼写错误编译期还发现不了。另一个就是订阅和退订的成对性谁订阅的事件谁就必须在生命周期结束的时候退订不然就是泄漏和重复触发的隐患。这个坑我在后面的章节还会展开讲。2.4 资源加载与对象池性能的关键资源加载这块早期项目我用的是Resources.Load加字典缓存的方式够用且简单。后来项目体量大了换成了AssetBundle方案再后面统一到了Addressables。但不管底层用哪种加载方案Frame架构里ResourceManager对外暴露的接口始终是统一的Load 按路径加载返回缓存后的结果。对象池的设计思路也很典型预设一个初始容量用完不销毁而是回收进池子下次需要时直接从池里取。比如战斗里子弹、飘字、粒子特效这些高频对象用对象池之后GC Alloc能降一个数量级。后面实操部分我会给出一个简化版的实现并说明几个参数怎么定才合理。2.5 UI管理界面生命周期与层级控制UI部分是玩家直接感知的东西所以我把UIManager单独拿出来说。平时不开框架的时候大家习惯每个面板Prefab自己挂脚本点击打开面板就Instantiate关闭就Destroy。这个做法在面板少的时候没有问题面板一多麻烦就来了。UIManager的核心数据结构是一个栈。打开新面板时压栈关闭时弹栈栈顶永远是最新打开的面板层级上也自然在最上面。面板基类定义了OnEnter、OnExit、OnPause、OnResume四个生命周期方法分别对应入栈、出栈、被压住、重新成为顶层这几个状态。为什么要设计这四个方法因为很多时候从目录页打开详情页目录页不应该被销毁而是应该暂停刷新逻辑等详情页关闭之后再恢复。如果整个面板直接销毁玩家的滑动位置和临时状态就全丢了体验非常糟糕。public abstract class UIBasePanel : MonoBehaviour { public abstract void OnEnter(); public abstract void OnExit(); public virtual void OnPause() { } public virtual void OnResume() { } }3. 实操最小可用Frame的搭建过程3.1 工程目录结构规划写代码之前先把目录划分好。我的习惯是Assets下按Framework和Game两大块来分Framework放通用框架代码Game放具体游戏逻辑。这样做的目的很单纯Framework里的代码不依赖任何Game层的业务拿到下一个项目里可以整套搬走一分钱改动都不用做。Assets/ Scripts/ Framework/ GameRoot.cs EventCenter.cs UIManager.cs UIBasePanel.cs ResourceManager.cs ObjectPool.cs Game/ MainPanel.cs SettingPanel.cs PlayerLogic.cs BattleLogic.cs Resources/ UI/ MainPanel.prefab SettingPanel.prefab Scenes/ BootstrapScene.unityResources目录下的UI子目录和UIManager的加载路径是约定的面板名和Prefab名保持完全一致减少一次路径映射的成本。3.2 GameRoot整个架构的发动机GameRoot是唯一一个在场景里手动挂载的脚本其他Manager都是在Awake里自己派生的单例。把GameRoot做成DontDestroyOnLoad这样在场景切换时管理器不会销毁数据得以保留。public class GameRoot : MonoBehaviour { private void Awake() { DontDestroyOnLoad(gameObject); // 各模块按依赖顺序初始化 EventCenter.Instance.Init(); ResourceManager.Instance.Init(); UIManager.Instance.Init(); GameLogicManager.Instance.Init(); } private void Start() { // 启动流程先出主界面 UIManager.Instance.OpenPanelMainPanel(MainPanel); } private void Update() { float dt Time.deltaTime; EventCenter.Instance.Tick(dt); UIManager.Instance.Tick(dt); GameLogicManager.Instance.Tick(dt); } private void OnApplicationQuit() { // 全局事件清理 EventCenter.Instance.Release(); } }这就是发动机的核心逻辑。初始化顺序一定要按依赖关系的倒序来先初始化基础设施层事件、资源再初始化依赖这些的UI层和逻辑层。如果顺序反了UIManager初始化时想通过ResourceManager加载东西就会踩空引用。3.3 UIManager实现面板栈和缓存的协作UI面板的管理核心是栈结构和字典结构协作。字典负责快速查找某个面板是否存在栈负责维护显示顺序。public class UIManager : MonoBehaviour { private static UIManager _instance; public static UIManager Instance { get { if (_instance null) { GameObject go new GameObject(UIManager); _instance go.AddComponentUIManager(); } return _instance; } } private readonly StackUIBasePanel _panelStack new StackUIBasePanel(); private readonly Dictionarystring, UIBasePanel _panelDict new Dictionarystring, UIBasePanel(); private Transform _uiRoot; public void Init() { _uiRoot GameObject.Find(UIRoot).transform; } public T OpenPanelT(string panelName) where T : UIBasePanel { if (_panelDict.TryGetValue(panelName, out T exists)) { _panelStack.Peek()?.OnPause(); _panelStack.Push(exists); exists.OnEnter(); exists.OnResume(); return exists; } GameObject prefab ResourceManager.Instance.LoadGameObject($UI/{panelName}); GameObject go Instantiate(prefab, _uiRoot); T panel go.GetComponentT(); if (panel null) { Debug.LogError($[UIManager] {panelName} 缺少UIBasePanel组件); return null; } if (_panelStack.Count 0) { _panelStack.Peek()?.OnPause(); } _panelStack.Push(panel); _panelDict[panelName] panel; panel.OnEnter(); return panel; } public void ClosePanel(string panelName) { if (!_panelDict.TryGetValue(panelName, out UIBasePanel panel)) return; if (_panelStack.Peek() ! panel) { Debug.LogWarning([UIManager] 当前面板不在栈顶不建议直接关闭); return; } _panelStack.Pop(); _panelDict.Remove(panelName); panel.OnExit(); Destroy(panel.gameObject); if (_panelStack.Count 0) { _panelStack.Peek().OnResume(); } } public void Tick(float dt) { if (_panelStack.Count 0) return; _panelStack.Peek().Tick(dt); } }这里需要注意几个问题。第一面板的Prefab实例化之后一定要检查GetComponent 是否拿到组件如果没有就立刻报错后面操作返回空引用会非常难排查。第二ClosePanel不是所有面板都在栈顶的时候才允许关闭的但最常见的情况确实是栈顶面板关闭。如果某个底层面板需要被强制关闭我会先把它上面的所有面板都弹掉再关它避免栈里存在已经销毁的对象。3.4 ResourceManager与对象池的简化实现ResourceManager我直接贴一个可用的版本。核心就是一个字典缓存加载过的资源不重复Load。如果项目后来迁移到AssetBundle或者Addressables只需要替换这个类内部的加载逻辑外部接口不变。public class ResourceManager : MonoBehaviour { private static ResourceManager _instance; public static ResourceManager Instance { get { if (_instance null) { GameObject go new GameObject(ResourceManager); _instance go.AddComponentResourceManager(); } return _instance; } } private readonly Dictionarystring, UnityEngine.Object _cache new Dictionarystring, UnityEngine.Object(); public void Init() { } public T LoadT(string path) where T : UnityEngine.Object { if (_cache.TryGetValue(path, out UnityEngine.Object cached)) { return cached as T; } T resource Resources.LoadT(path); if (resource ! null) { _cache[path] resource; } else { Debug.LogError($[ResourceManager] 加载失败: {path}); } return resource; } public void Release(string path) { if (_cache.Remove(path)) { Resources.UnloadUnusedAssets(); } } }对象池的通用实现也不复杂但有两个点很容易被新手写坏。第一是对象的回收状态重置从池里取出来的对象必须OnEnable重新初始化回收时必须OnDisable清理状态。第二是池的上限控制如果池满了还不能回收旧对象宁可创建一个新的也不能无限膨胀。UE和Unity的实战经验都证明一个没有上限的对象池最终会成为内存泄漏的另一种形式。public class ObjectPool { private readonly StackGameObject _pool new StackGameObject(); private readonly GameObject _prefab; private readonly int _maxSize; public ObjectPool(GameObject prefab, int preloadCount, int maxSize) { _prefab prefab; _maxSize maxSize; for (int i 0; i preloadCount; i) { GameObject go CreateInstance(); go.SetActive(false); _pool.Push(go); } } private GameObject CreateInstance() { GameObject go Object.Instantiate(_prefab); go.name ${_prefab.name}_Pooled; IPoolable poolable go.GetComponentIPoolable(); poolable?.OnPoolInit(); return go; } public GameObject Get() { GameObject go _pool.Count 0 ? _pool.Pop() : CreateInstance(); go.SetActive(true); IPoolable poolable go.GetComponentIPoolable(); poolable?.OnPoolGet(); return go; } public void Recycle(GameObject go) { if (_pool.Count _maxSize) { Object.Destroy(go); return; } IPoolable poolable go.GetComponentIPoolable(); poolable?.OnPoolRecycle(); go.SetActive(false); _pool.Push(go); } } public interface IPoolable { void OnPoolInit(); void OnPoolGet(); void OnPoolRecycle(); }对象池的初始预载数量和最大容量要怎么定这个不能拍脑袋。我常用的方法是先跑一遍玩法在Profiler里看同一帧内某个对象类型最多同时存在的数量然后取这个数量的1.2到1.5倍作为最大容量预载量取最大容量的30%左右最经济。这样既不会频繁创建新实例内存占用也不会太离谱。3.5 接入示例场景的完整流程理论讲完了下面说一个实际接入步骤跟着做不出错。第一步创建一个空场景命名为BootstrapScene。场景里创建一个空GameObject命名为GameRoot挂上GameRoot脚本。第二步创建UIRoot。在场景里创建一个Canvas命名为UIRoot。Canvas的渲染模式设为ScreenSpaceOverlayCanvasScaler的UI缩放模式设为ScaleWithScreenSize参考分辨率按你的项目目标设我一般用1920x1080。把UIRoot的RectTransform设为全屏拉伸然后让UIManager的Init方法里通过GameObject.Find找到它。这一步要保证UIRoot和GameRoot在同一个场景里且UIRoot命名不能改。第三步创建MainPanel预制体。在Resources/UI目录下新建一个Panel命名为MainPanel底下挂一个Text组件显示游戏主界面标题再放一个按钮用于打开设置界面。给MainPanel挂上MainPanel脚本这个脚本继承UIBasePanel实现OnEnter和OnExit在OnEnter里注册按钮事件。第四步运行场景。你会看到GameRoot的Start里打开主面板点按钮打开设置面板设置面板关闭后主面板恢复。这一套流程如果走通了后面扩展新面板和新模块只需要照着同样的模式往里面加就行。public class MainPanel : UIBasePanel { public override void OnEnter() { gameObject.SetActive(true); // 注册打开设置面板的按钮时间 transform.Find(Btn_Setting).GetComponentButton().onClick.AddListener(() { UIManager.Instance.OpenPanelSettingPanel(SettingPanel); }); } public override void OnExit() { gameObject.SetActive(false); } public override void OnPause() { gameObject.SetActive(false); } public override void OnResume() { gameObject.SetActive(true); } }3.6 性能观测怎么确认Frame真的有效框架搭完之后不能只看代码写得舒服得用数据说话。我一般会在游戏运行状态下打开Window General Profiler切到CPU Usage模块盯着两三个指标看一是GC Alloc每帧分配的内存如果长时间稳定在0附近说明对象池和缓存策略有效果二是Mono的脚本耗时如果某个Manager的Tick占据过高就说明那个模块需要优化三是DrawCall数量这个主要和UI合批策略相关但也能反映UI面板的组织是否合理。还有个更实用的办法在关闭对象池和不关闭对象池两种状态下各跑一场相同的战斗对比GC Alloc的差异。我实测过一个小规模弹幕游戏不用对象池的时候GC Alloc峰值能到800KB每帧用了之后降到20KB以下卡顿感肉眼可见地消失了。4. 常见问题与排查技巧实录4.1 生命周期执行顺序混乱的问题有一个特别隐蔽的问题GameRoot的Awake里初始化EventCenter之后其他Manager的Awake可能也在这个时刻执行但MonoBehaviour的Awake顺序不确定。如果某个Manager在Awake里就订阅了事件而EventCenter还没初始化好运行期就会偶发找不到字典的异常。我的解决方案是在每个Manager的Init方法里把所有依赖先准备好不在Awake里直接依赖其他Manager。EventCenter底层是字典结构只要Init先被调用其他Manager订阅的时候字典就存在了。在代码里明确写着Init调用顺序这一点比依赖引擎的Awake顺序靠谱得多。4.2 UI层级和遮挡问题UIManager用栈管理层级之后偶尔还是会遇到“弹窗被旧界面挡住”的情况。这通常是因为某个面板的Canvas组件没有排序或者新旧面板不在同一个Canvas下。我的经验是所有UI面板挂在同一个UIRoot下并且每个面板预制体自身带一个Canvas和CanvasGroup。面板的Canvas不用改让UIManager在OpenPanel时按栈的深度动态调整Canvas的sortingOrder。栈顶面板的sortingOrder最高这样在同一个UIRoot下不管面板嵌套多深遮挡关系都能保证正确。千万别用多个根Canvas来管理层级那会让问题失控。多个Canvas互相之间的遮挡顺序跟它们在Hierarchy里的先后顺序有关这个顺序在动态创建面板时很难手动维持纯属给自己挖坑。4.3 事件监听泄漏导致的问题事件中心用久了最容易踩的坑就是泄漏和重复触发。两个现象都指向同一个原因订阅了事件但没退订。最典型的场景是打开设置面板时订阅了一个战斗事件设置面板关闭时没有退订。下次再打开设置面板又订阅一次。第一次分发事件的时候面板里的回调触发一次如果开开关关三次回调触发三次。如果回调里面还有弹窗逻辑那画面基本就乱了。我记得有一次排查线上的一个Bug玩家在背包界面点一件装备有时候弹一个详情有时候连弹三个详情关卡有时还会瞬间重新加载。后来定位发现背包界面的脚本在OnEnable里订阅了“装备变化”事件OnDisable里没有退订几次进出背包后事件回调执行了数遍每次回调都触发一次详情弹窗和一次刷新逻辑几个Bug串在一起才显得那么魔幻。正确做法是强制成对使用订阅和退订必须出现在同一个脚本的成对生命周期方法里。我在UIManager的面板基类里定了规矩OnEnter里订阅OnExit里退订推荐所有面板都遵守这个约定。4.4 架构演进里踩过的坑和扩展方向这套Frame架构用到后期我也发现了一些需要注意的地方写出来供大家参考。过度的架构设计是真实的陷阱。有一次我尝试把每个UI面板都抽象成一个ViewModel还想引入依赖注入框架结果项目进度被拖慢了一倍团队成员连跑通环境都要花几天最后被迫回退到简洁版本。框架是为了提高效率如果引入的成本大于收益那它就是个负面资产。单例的滥用也值得警惕。我早期把很多管理器都写成单例比如货币管理、任务进度管理、成就管理后来发现单例一旦多了测试的时候很难单独隔离一个模块。所以后期我做了一个调整只有真正全局唯一的模块才用单例比如UI、资源、事件中心业务逻辑模块尽量通过事件通信不搞全局访问。音频管理、数据持久化、网络层这些模块我都建议在新项目里按同样的思路封装进Frame统一归GameRoot调度。比如音频管理提供一个PlayBGM和PlayOneShot方法内部走事件中心任何模块只要发一个PlayAudioEvent就能播放声音解耦效果非常明显。最后再分享一个关于扩展方向的想法。Unity3d的工程化水平决定了项目能走多远但框架本身不用一步到位。我建议你从这套最小架构开始跟着真实项目去迭代。第一个月你可能只需要GameRoot和UIManager第二个月发现事件通信太重要了第三个月被GC困扰开始上对象池半年之后回过头看这套Frame已经变得既顺手又成熟而且它里的每一行代码你都清楚为什么而写。这种自底向上积累出来的框架比直接抄一份大而全的框架要实用得多。