在 Unity 项目里“代码能跑”和“代码能撑住项目”是两回事。很多人写了一阵子 C# 脚本功能都做出来了但项目一到真机就发热、掉帧或者场景稍微复杂一点就卡顿。这时候回头看代码往往能找到一堆Update里反复GetComponent、字符串拼接、到处Find(xxx)的身影。如果你正处于这个阶段那这篇文章要聊的正是从“能写脚本”走向“能写好脚本”的那道坎。Unity C# 的进阶不是一个新 API 接一个新 API 地背。它真正考验的是你对三个维度的敏感度每帧执行、内存分配、生命周期。这篇文章不会讲“如何用 C# 写一个漂亮的算法”而是从实际项目性能问题和工程结构出发拆解六个最常见的进阶主题查找与缓存、Update 替代方案、GC 与对象池、单例滥用、事件解耦、协程与异步选择。读完你会明白为什么有些代码功能没问题但性能有隐患以及真正的进阶写法应该是什么样。文章会包含完整的可运行代码示例、正反写法对比、常见问题排查表以及工程层面的最佳实践建议。无论你做的是小游戏、商业项目还是正在面试中级岗位这些内容都值得收藏后逐段消化。1. 这篇文章真正要解决的问题先看一段典型的“初级进阶前”代码很多项目里真的存在// 问题示例每帧都在找对象、拿组件、拼字符串 void Update() { GameObject enemy GameObject.Find(Enemy); if (enemy ! null) { enemy.GetComponentHealth().Reduce(Time.deltaTime * 10); } }这段代码功能没错运行起来也不报错。但你应该能感觉到哪里不对劲每一帧都在全场景搜索名为Enemy的对象每一帧都在取Health组件。场景里只要对象多几个这种写法就会在 Profiler 里露出一长串红色的Find和GetComponent开销。初级开发者看到的是“能用”进阶开发者看到的是“每帧浪费”。这篇文章要解决的就是这类看起来没问题、实际上在持续消耗项目性能的代码习惯。它不追求让你学会某个神秘技巧而是让你建立三个习惯让代码少跑别每帧都做不必要的事能缓存就缓存能事件驱动就别轮询。让对象少建控制堆内存分配减少 GC 压力必要时用对象池复用实例。让系统好查单例别乱挂事件记得注销生命周期要清晰出问题能快速定位。如果你已经熟悉 Unity 基本操作能独立写完一个完整玩法循环但项目复杂度上来之后开始频繁遇到卡顿、莫名报错、结构混乱那这篇文章就是为你准备的。2. 进阶前必须先想清楚的三个核心概念2.1 生命周期Unity 脚本的隐形指挥棒每一个挂到 GameObject 上的MonoBehaviour都会在特定时机被 Unity 调用特定方法。理解这些方法的执行顺序是判断“代码该写在哪”的基础。方法执行时机常见用途Awake对象实例化时立即调用早于 Start初始化自身数据、获取自身组件引用、创建对象池OnEnable对象激活时调用每次 SetActive(true) 都会触发注册事件、订阅消息Start首次 Update 前调用一次获取其他对象引用、初始化依赖数据Update每帧调用一次常规逻辑更新、输入处理、状态轮询FixedUpdate按固定时间步长调用与帧率无关物理计算、刚体受力LateUpdate每帧所有 Update 之后调用摄像机跟随、动画状态同步OnDisable对象禁用时调用注销事件、取消订阅OnDestroy对象即将销毁时调用释放资源、注销事件很多“空引用”问题就是生命周期理解不到位造成的。比如在Awake里尝试获取其他还未Awake的对象引用此时可能还是 null或者在OnDisable里没有注销事件导致已禁用的对象仍然收到消息回调。2.2 Update 的代价每帧执行不是免费的Update最容易被滥用因为它“太方便了”。但每帧调用意味着无论场景里有没有变化这段逻辑都会反复执行。一个空场景里挂 100 个带空Update的脚本也会有可见的调用开销。更别说在Update里做寻找、分配、字符串拼接这类昂贵操作。进阶思路不是“不再用 Update”而是想清楚这个行为是否真的需要每帧检测。如果只是在等待某个条件成立用协程或事件等待通常更合适。如果确实需要每帧执行也要保证方法体内的操作尽量轻量。2.3 GC 与堆内存分配卡顿的真正来源之一Unity 的 C# 侧使用托管堆。每当代码里用new创建引用类型、拼接字符串、使用 LINQ 或捕获变量的 Lambda都可能在堆上分配内存。堆内存不会立刻释放而是累积到一定压力后触发 GC垃圾回收回收时往往造成明显的帧卡顿。进阶开发者的一个核心习惯是关心每一帧产生了多少 GC Alloc。打开 Profiler 的 Memory 模块能看到每帧的GC Alloc数值。如果这个数字在持续增长说明有代码在不断创建临时对象。后续第 5 章会展开讲这个问题的解法。这三个概念是后文所有技巧的底层逻辑。不理解生命周期就不知道事件该在哪注册在哪注销不关心 Update 代价就意识不到“顺手写个轮询”有多贵不了解 GC 分配就难以解释为什么项目越跑越卡。3. 查找与缓存告别每帧 Find 和 GetComponent3.1 为什么这些写法是性能黑点GameObject.Find和GetComponent是 Unity 里最常用的两个方法但它们的实现代价完全不同GameObject.Find需要遍历场景中的整个对象层级逐名字匹配非常昂贵。GetComponent需要在对象的组件列表里做类型匹配虽然比Find快但每帧调用依然会产生方法调用和查找开销。GetComponentInChildren、GetComponentInParent更贵因为它们要递归遍历子物体或父物体。这些查找操作本身不算致命致命的是“每帧都做”。一帧 16 毫秒左右的预算里如果 10 个脚本各做一次Find加GetComponent画面复杂度一高预算马上被吃光。3.2 三个层级的优化手段第一层用序列化字段直接拖引用。能拖到 Inspector 的不要用代码找。public class Player : MonoBehaviour { [SerializeField] private Health health; // Inspector 拖引用 [SerializeField] private Transform target; // Inspector 拖引用 // 代码里直接使用完全避免运行时查找 void Update() { if (health.Current 0) { // 处理逻辑 } } }这是最简单、最可靠的方案。缺点是需要手动拖拽但换来的是运行期零查找成本对团队协作也更友好因为依赖关系在 Inspector 上一目了然。第二层必须代码获取时在 Awake 缓存一次。public class Player : MonoBehaviour { private Health health; private Rigidbody rb; void Awake() { health GetComponentHealth(); rb GetComponentRigidbody(); } // 后续所有方法直接使用缓存字段不再重复获取 public void TakeDamage(float value) { health.Current - value; rb.AddForce(Vector3.up * 2f, ForceMode.Impulse); } }把GetComponent放到Awake里执行一次后续查询全部使用缓存的引用。对于“只挂在同一个 GameObject 上”的场景这是最标准的做法。注意Awake里拿到的引用适合当前对象自身如果要找其他对象应该在Start里做因为所有Awake都执行完之后才轮到Start。第三层让对象自己持有引用而不是让外部来找它。这是架构层面的思路。与其让 A 每帧查找 B不如让 B 在初始化时把自己的引用交给 A或者通过事件让 B 主动通知 A。public class Player : MonoBehaviour { [SerializeField] private Health health; // 事件方式Health 变化时主动通知避免其他系统每帧轮询 void OnEnable() { health.OnHealthChanged HandleHealthChanged; } void OnDisable() { health.OnHealthChanged - HandleHealthChanged; } void HandleHealthChanged(float currentHealth) { // 收到通知时才执行逻辑而不是每帧检查 } }这种方式把“每帧检查”变成了“等通知再处理”两者在 CPU 开销上的差异非常明显。事件驱动的细节会在第 6 章展开。3.3 什么时候仍然可以接受 Find有些场景下使用Find并非完全不可比如只在初始化阶段调用一次、场景结构相对固定、代码量小且不追求极致性能。但如果你希望通过这些代码进入进阶行列建议把它当作调试期手段而不是正式架构的一部分。毕竟从工程习惯上Find越多运行时对场景结构的隐式依赖就越强重构时越容易踩空。4. Update 替代方案能少跑就少跑一旦理解了“每帧执行是昂贵的”你会开始频繁审视自己的Update这段代码真的需要每帧跑吗下面的替代方案按“成本从低到高”排列但适用场景不同。4.1 隔帧执行与按时间检测如果逻辑不需要每帧都处理比如一个拾取道具的检测每隔 0.1 秒做一次就够了可以用计时器控制频率。public class PickupDetector : MonoBehaviour { [SerializeField] private float checkInterval 0.1f; private float timer; void Update() { timer - Time.deltaTime; if (timer 0f) return; timer checkInterval; DoCheck(); } void DoCheck() { // 每隔 checkInterval 才执行一次 } }这种“降频检测”对 UI 刷新、位置采样、列表同步等场景都非常实用。画面表现上用户几乎感受不到差异但 CPU 压力直接降到原来的十分之一甚至更低。4.2 协程替代状态轮询很多“等一个条件成立再继续”的逻辑用Update轮询也可以实现但协程的写法更直观也不会每帧空转public class EnemySpawner : MonoBehaviour { [SerializeField] private Transform player; void Start() { StartCoroutine(WaitUntilPlayerNear()); } IEnumerator WaitUntilPlayerNear() { // 每帧检查一次但条件满足后立即结束协程后续不再占用调用开销 while (Vector3.Distance(transform.position, player.position) 5f) { yield return null; } // 玩家靠近后执行生成逻辑 SpawnEnemy(); } void SpawnEnemy() { // 生成敌人 } }注意这个协程在等待期间其实仍然是每帧MoveNext但因为逻辑简单开销远低于在Update里处理完整的生成流程。等条件满足后协程自动结束后面的帧里它完全不再执行。这是“让代码少跑”的典型例子。4.3 用事件替代主动轮询最理想的情况是数据变化时系统主动告诉你而不是让你去反复问。比如玩家血量变化、任务状态变化、背包物品变化都适合用事件来驱动。public class Health : MonoBehaviour { public event Actionfloat OnHealthChanged; private float current; public float Current { get current; set { current value; OnHealthChanged?.Invoke(current); } } }当Current被赋值时所有订阅者都会收到通知。UI 血条、伤害飘字、音效模块只需要分别订阅这个事件完全不需要在各自Update里轮询血量。这种模式对大型项目收益尤其明显因为它把“每个系统各自查状态”变成了“状态自己广播”。从这一章你应该能建立起一个判断标准一个行为如果“偶发”而不是“持续”就不要每帧跑一个状态如果“变化才需要响应”就用事件而不是轮询。5. 内存控制与对象池让 GC 不再成为卡顿元凶5.1 隐式堆分配的五种常见来源请看下面的代码片段哪些地方会产生堆内存分配void Update() { string text Score: score; // 字符串拼接分配新字符串 Debug.Log(text); // 日志调用本身也有开销 var list allEnemies.Where(e e.IsAlive); // LINQ 分配迭代器 foreach (var e in list) { } // foreach 对 ListT 本身无分配但 LINQ 产生分配 Action callback () { score; }; // Lambda 如果捕获了外部变量可能分配闭包对象 }几个常见来源字符串拼接号拼接会创建新的字符串对象String.Format同样有分配。高频执行时非常明显。LINQWhere、Select、OrderBy等操作会分配迭代器和临时集合。在性能敏感代码里应避免。foreach 遍历非泛型集合ArrayList、Hashtable会产生装箱分配遍历ListT本身没有分配。Lambda 闭包捕获当 Lambda 引用了外部局部变量时编译器可能生成一个闭包对象产生分配。装箱把值类型转成object或接口时会装箱比如int塞进ArrayList。要养成查看 Profiler 的习惯右键Memory模块里的GC Alloc按总量排序就能看到哪些系统每帧在悄悄分配内存。5.2 对象池复用而不是反复新建子弹、敌人、飘字、粒子特效这些“频繁创建又频繁销毁”的对象最适合用对象池。核心思路把不用的对象放进栈里需要时取出并激活而不是Destroy后再Instantiate。下面是一个通用的最小对象池实现using System.Collections.Generic; using UnityEngine; public class SimpleObjectPool { private readonly StackGameObject pool new StackGameObject(); private readonly GameObject prefab; private readonly Transform parent; public SimpleObjectPool(GameObject prefab, Transform parent null, int prewarmCount 0) { this.prefab prefab; this.parent parent; // 预热提前创建一批对象避免运行期突刺 for (int i 0; i prewarmCount; i) { GameObject obj CreateInstance(); obj.SetActive(false); pool.Push(obj); } } public GameObject Get() { GameObject obj pool.Count 0 ? pool.Pop() : CreateInstance(); obj.SetActive(true); return obj; } public void Release(GameObject obj) { obj.SetActive(false); pool.Push(obj); } private GameObject CreateInstance() { GameObject obj Object.Instantiate(prefab, parent); obj.name prefab.name; return obj; } }使用方式public class BulletShooter : MonoBehaviour { [SerializeField] private GameObject bulletPrefab; private SimpleObjectPool bulletPool; void Awake() { // 预热 20 个避免第一次射击时卡顿 bulletPool new SimpleObjectPool(bulletPrefab, transform, 20); } public void Shoot() { GameObject bullet bulletPool.Get(); bullet.transform.position transform.position; bullet.transform.rotation transform.rotation; // 注意子弹销毁时不能直接 Destroy回到池里释放 // 可以让子弹在命中后调用 bulletPool.Release(gameObject) } }使用对象池的关键约定是不再用Destroy而是Release回池。这要求团队对“对象生命周期”有统一理解否则容易出现“池里的对象引用残留”“释放后被继续操作”等问题。对于偶尔创建的对象比如 BOSS 出场特效直接 Instantiate 销毁反而更简单不必强行套池。5.3 字符串处理的进阶选择高频拼接字符串时最合理的做法是使用StringBuilderusing System.Text; public class ScoreDisplay : MonoBehaviour { private readonly StringBuilder sb new StringBuilder(32); public void UpdateScore(int score) { sb.Clear(); sb.Append(Score: ); sb.Append(score); text.text sb.ToString(); } }StringBuilder本身是可复用对象Clear()不会释放内部缓冲后续Append也不需要重新分配。相比每帧拼接这能明显减少 GC 压力。另一个选择是直接给Text组件设置整型数值类型的格式化字符串但不同 Unity 版本的TextMeshPro实现有差异建议按当前项目实际版本来写不要照搬网上老代码。6. 单例模式滥用与事件解耦6.1 单例不是罪滥用才是单例是 Unity 项目里最常见的架构模式public class GameManager : MonoBehaviour { public static GameManager Instance { get; private set; } void Awake() { Instance this; } }你几乎可以在任何脚本里直接写GameManager.Instance.xxx。问题在于当全局单例数量越来越多脚本之间的隐式依赖也会越来越重。你在 A 脚本里调用AudioManager.Instance.Play()在 B 脚本里调用UIManager.Instance.OpenPanel()A 和 B 本身没有引用关系但都强耦合到了各自的单例上。后续想替换、测试其中一个模块都很困难。单例适合保存“整个游戏只有一个”的数据或服务比如存档管理器、音频管理、输入管理。但不适合把所有逻辑都挂到单例上。一个判断标准是如果这个组件不依赖任何外部场景对象并且全项目确实只需要一份才考虑做单例。6.2 事件中心让模块之间对话而非互指与其让每个模块都引用其他模块不如让它们只发布和订阅事件public static class GameEvents { public static event Actionint OnScoreChanged; public static event Action OnGameOver; public static void ScoreChanged(int score) { OnScoreChanged?.Invoke(score); } public static void GameOver() { OnGameOver?.Invoke(); } }发布方public class ScoreSystem : MonoBehaviour { private int score; public void AddScore(int value) { score value; GameEvents.ScoreChanged(score); } }订阅方public class ScoreUI : MonoBehaviour { [SerializeField] private TMPro.TextMeshProUGUI scoreText; void OnEnable() { GameEvents.OnScoreChanged HandleScoreChanged; } void OnDisable() { GameEvents.OnScoreChanged - HandleScoreChanged; } void HandleScoreChanged(int score) { scoreText.text score.ToString(); } }这套模式的关键是OnEnable订阅、OnDisable注销。很多人只订阅不注销导致对象销毁后事件列表里还留着引用轻则产生无效调用重则对象无法被 GC 回收造成内存泄漏。这是事件系统的头号坑。6.3 ScriptableObject 作为数据事件通道比静态事件中心更“Unity 原生”的方案是使用ScriptableObject定义事件或共享数据。using UnityEngine; [CreateAssetMenu(fileName GameEvent, menuName Events/GameEvent)] public class GameEvent : ScriptableObject { private readonly System.Action callbacks delegate { }; public void Raise() { callbacks(); } public void Register(System.Action callback) { callbacks callback; } public void Unregister(System.Action callback) { callbacks - callback; } }然后在 Inspector 里创建一个GameEvent资产多个组件都可以引用同一个资产。发布方调用Raise()订阅方调用Register/Unregister。这种方式的优点是不依赖静态类方便多人协作和配置化。缺点是资产比较多时需要统一管理命名要清晰。我个人的建议是小项目用静态事件中心足够中大型项目优先考虑ScriptableObject事件架构因为它在复制场景、多人协作、热更新资源管理上更灵活。第 6 章的核心判断是事件系统能把“互相调用”变成“互不感知”但代价是你必须严格遵守订阅/注销的生命周期纪律。没有纪律的事件系统比单例更危险。7. 协程与 async/await异步逻辑的选型与坑点7.1 协程的优势与限制协程是 Unity 原生支持的异步方案起步简单示例多几乎所有项目都在用。但有两个容易被忽略的缺点异常处理困难协程里的try/catch对yield中途返回的处理不直观一旦抛出异常协程往往直接终止且不留下清晰日志。每帧 MoveNext 的开销虽然比Update轮询轻但大量协程同时运行时依然有调度开销。生命周期不受控协程挂载在MonoBehaviour上如果对象被禁用协程默认不会继续执行除非用了WaitWhile等仍在执行的条件等待。这既是特性也是坑对象禁用后“协程消失”如果你期望它在OnEnable后继续完成某段逻辑需要自己处理状态。协程适合处理延迟等待、顺序播放、简单的定时逻辑。public class SimpleSequence : MonoBehaviour { IEnumerator Start() { yield return new WaitForSeconds(1f); Debug.Log(1 second passed); yield return new WaitForSeconds(0.5f); Debug.Log(0.5 second passed); } }7.2 async/await 与 UniTask 的进阶选择Unity 2020.3 之后项目可以启用Microsoft.NET Core或NET Standard 2.1配置原生支持async/await。但直接使用Task有几个问题Task默认运行在线程池上Unity 主线程之外访问UnityEngine.Object会报错。Task的延续不保证回到主线程需要手动UnityMainThreadDispatcher之类的东西。对象的生命周期同样不会自动处理物体销毁后异步继续执行会引发空引用。因此社区更推荐UniTask它专为 Unity 设计不分配额外 GC、默认回到主线程、支持CancellationToken。如果你的项目网络栈或复杂流程需要大量异步逻辑值得认真考虑 UniTask。但要注意引入第三方库需要评估版本和团队适配成本不能因为“听说很强”就盲目替换所有协程。一个更保守的建议是能用协程写清楚的逻辑先用协程如果逻辑嵌套复杂、需要取消、需要超时控制再切换到基于 UniTask 或 async/await 的方案。7.3 CancellationToken异步逻辑的刹车无论协程还是 async/await真正的进阶习惯是给异步操作加取消机制。以 UniTask 为例仅作思路演示不绑定版本// 思路示例用 CancellationToken 在对象销毁时取消异步流程 CancellationToken token this.GetCancellationTokenOnDestroy(); await UniTask.Delay(TimeSpan.FromSeconds(3f), cancellationToken: token);如果不支持 UniTask也可以在协程里自己检测!gameObject.activeInHierarchy主动终止流程。关键是“异步逻辑必须知道什么时候该停”而不是指望对象销毁之后代码自动停止。这在对象池场景里尤其重要一个子弹从池里取出、发射、飞行、命中、回池整个过程的异步流程如果不知道取消时机就会出现“子弹回池后还在跑逻辑”的诡异 bug。8. 常见问题与排查思路下面这张表汇总了 Unity C# 进阶过程中最常踩的坑每个问题都有排查路径。问题现象可能原因排查方式解决方案游戏运行一段时间后明显卡顿堆内存持续增长GC 频繁触发Profiler 查看 GC Alloc按总量排序定位高频分配代码改用缓存、对象池、StringBuilder场景中大量对象时 Update 开销巨大Find、GetComponent、轮询逻辑过多Profiler CPU 模块展开各脚本耗时缓存组件引用、改用事件驱动或降频检测对象销毁后仍收到事件回调事件订阅后没有在 OnDisable 注销在回调方法里加断点查看调用栈统一 OnEnable 订阅、OnDisable 注销协程不执行对象被禁用/销毁或 StopCoroutine 调用方式错误检查对象的 activeSelf 和 Coroutine 引用确认生命周期或在启用状态再启动协程物理抖动或不稳定FixedUpdate 里处理了受帧率影响的逻辑检查 Fixed Timestep 设置和代码逻辑位置物理相关逻辑放 FixedUpdate视觉跟随放 LateUpdate单例 Instance 为 nullAwake 执行顺序问题或场景中缺少单例组件检查场景层级和脚本执行顺序确保单例组件存在且初始化顺序正确物体从对象池取出后出现残留状态回池时没有重置状态检查 Release 方法是否清空引用和状态在 Release 里重置 transform、组件状态、事件订阅排查这类问题第一原则是不要凭感觉猜直接开 Profiler。CPU 模块看耗时Memory 模块看分配这两块数据能快速把问题缩小到具体脚本。第二原则是看调用栈异常信息里的堆栈比日志文字更可靠顺着调用栈能定位到是哪个事件触发的、哪个协程卡住的。9. 最佳实践与工程建议技巧和知识之外工程习惯才是进阶的分水岭。下面几条是我在多个项目里验证过能实实在在减少返工和线上事故的建议。9.1 生命周期配对的模板要背下来事件订阅、协程启动、资源加载凡是有“启用”就必须有“禁用”。建议固定写法void OnEnable() { GameEvents.OnScoreChanged HandleScoreChanged; } void OnDisable() { GameEvents.OnScoreChanged - HandleScoreChanged; }不要只在OnDestroy里注销因为对象被禁用但未销毁时事件依然可能触发。9.2 字段暴露方式统一需要外部修改的数据用[SerializeField] private 公开只读属性。只在内部使用的引用一律private。不要在场景里到处挂public GameObject xxx然后手动拖拽能分类就用[Header]分组。public class Player : MonoBehaviour { [Header(References)] [SerializeField] private Health health; [SerializeField] private Animator animator; [Header(Settings)] [Range(0f, 100f)] [SerializeField] private float maxHealth 100f; }9.3 空引用防御要统一在团队项目里空引用异常占了 bug 的大头。值得建立的规范是外部传入的引用先判空再使用。查找类引用如果可能为空加if (xxx null)加Debug.LogWarning而不是让异常在调用栈深处爆发。不要用?.一把梭掩盖逻辑问题空值本身意味着某个依赖没配置好日志要打清楚。9.4 性能预算和 Profiler 习惯每个系统都该有一个“每帧预算”的概念。比如动画系统 1ms、AI 2ms、UI 1ms、物理 2ms超出预算就是优化信号。日常开发中每写完一个系统先跑一下 Profiler 看看有没有明显的GC Alloc。这个习惯能让你在问题积累前就发现它而不是等项目卡到无法发布才回头找。9.5 区分开发期写法与正式架构Find、SendMessage、Invoke这些写法开发期快速验证可以用但如果进入正式版本建议逐步替换成缓存引用和事件驱动。给团队定一个“代码评审红线”Update里不允许出现Find和GetComponent单例数量有明确上限所有事件订阅必须有对应注销。红线不一定要特别多但每条都要严格执行。10. 总结与后续学习方向这篇文章讲穿了三件事让代码少跑、让对象少建、让系统好查。围绕这三件事你学会了用序列化引用和 Awake 缓存替代查找用它事件和降频检测替代轮询用对象池和字符串复用控制 GC用事件中心替代部分单例职责协程与异步选择的判断标准也给了明确建议。接下来的实践建议是先打开一个你最近写的项目用 Profiler 看三处——CPU 模块里哪个脚本耗时最多Memory 模块里 GC Alloc 每帧分配多少以及场景里到底有多少个Find和GetComponent出现在 Update 调用链中。先找到问题再对照本文的优化思路逐个替换。不要想着一次全部重构一个模块一个模块来每次改完对比 Profiler 数据你会慢慢找到对代码成本的直觉。如果这这篇文章的内容你已经理解吸收下一步值得深入的方向包括DOTS 与 Job System面向数据的设计批量处理大量实体的正确姿势。Unity 的 DI 框架比如 VContainer用依赖注入替代手写单例和服务定位。Addressables 与资源管理资源加载和释放的生命周期和本文讲的 GC 控制是同一类问题。UI Toolkit 与 UGUI 深挖UI 重建开销、布局计算的优化空间。最后送你一个实际经验团队重构一个卡顿项目时最容易犯的错误是先把架构全部推翻。真正值得先做的永远是打开 Profiler找到那几行每帧都在浪费的代码用缓存和事件替代掉。架构优化是锦上添花性能优化往往只需要先解决最痛的几个点。从一行Update里的Find改起你会发现进阶的路并没有那么玄。