Unity内存优化实战：从对象池到资源管理的系统性解决方案

1. 项目概述：为什么Unity内存优化是每个开发者的必修课

如果你在Unity开发中遇到过游戏运行一段时间后越来越卡、偶尔出现不明原因的闪退，或者打包成WebGL后加载时间长得让人失去耐心，那么你大概率正在经历内存问题的折磨。这不仅仅是“优化一下”那么简单，它直接关系到玩家的留存率和产品的口碑。今天，我们不谈那些泛泛而谈的“少用Find”、“多用缓存”，而是深入到引擎底层和代码设计层面，从最经典的对象池技术，到更高级的缓存策略，为你梳理一套完整、可落地的Unity内存优化解决方案。无论你是正在被GC（垃圾回收）卡顿困扰的移动端开发者，还是为WebGL包体初始化缓慢而头疼的前端工程师，这套方法都能帮你找到症结所在。

内存优化不是一个孤立的技巧，而是一个系统工程。它贯穿于资源加载、运行时对象管理、渲染管线乃至脚本编写的每一个环节。很多开发者知道“对象池”这个概念，但往往只停留在“复用GameObject”的层面，忽略了数据缓存、AssetBundle管理、纹理压缩策略等更深层次的内存消耗点。我们将从原理出发，解释为什么这些地方会成为性能瓶颈，然后给出具体的、带有参数和代码示例的实操方案。你会发现，优化之后，不仅帧率更稳定，包体更小，整个项目的可维护性也会大大提升。

2. 核心思路拆解：从“治标”到“治本”的优化层次

2.1 第一层：运行时对象管理——对象池的精髓与误区

对象池几乎是所有Unity性能优化文章都会提到的第一课，但很多人对其理解过于片面。它的核心目标并非仅仅是“减少Instantiate和Destroy的调用”，更深层次的目标是平抑由GC（垃圾回收）引发的帧率波动。

为什么GC是万恶之源？Unity使用的C#托管内存环境，当堆内存上不再被引用的对象积累到一定程度时，GC线程会启动来回收这些内存。这个过程是“停止-复制”或“标记-清除”，会挂起所有托管代码线程（在大多数情况下包括你的游戏逻辑线程），导致游戏卡顿。你看到的Profiler里那根突然飙升的GC.Collect帧时间线，就是它造成的。

一个基础的对象池实现，大家都会写：预创建一批对象，用的时候取出，不用的时候放回。但这里有几个关键误区：

1. 池子大小是静态的：很多教程的池子初始化后大小固定。但在实际游戏中，不同关卡、场景对同一类对象（如子弹、敌人）的需求量差异巨大。静态池要么造成内存浪费（池子过大），要么导致运行时动态扩容（依然触发GC）。
2. 只池化GameObject：这是最大的浪费。一个复杂的敌人Prefab，可能包含MeshRenderer、Animator、多个脚本组件。当你把整个GameObject放回池子并SetActive(false)时，这些组件大部分仍在内存中活跃。更精细的做法是，将数据与表现分离。将敌人的生命值、位置等数据放在一个可复用的结构体或类对象中池化，而渲染实体只在需要时关联或生成。
3. 忽视池对象的“重置”成本：从池中取出的对象，必须被完全重置到一个干净的初始状态。这不仅仅是transform.position = Vector3.zero，还包括所有脚本内部变量的重置、动画状态机的重启、粒子系统的停止与清理。忘记重置任何一个状态，都可能引发诡异的Bug。

正确的对象池设计思路：它应该是一个智能的、可伸缩的、分层的管理系统。对于高频创建/销毁的简单对象（如子弹、伤害数字），使用传统的GameObject池。对于复杂的实体（如敌人、NPC），采用“数据池+实体工厂”的模式，数据部分池化，表现部分按需加载或卸载。

2.2 第二层：资源生命周期管理——超越Resources与AssetBundle

资源是内存占用的大头，包括纹理、网格、音频、动画等。Unity提供了Resources、AssetBundle和Addressables等加载方式，但如果不加以管理，极易造成内存泄漏或冗余。

Resources文件夹的陷阱：所有放在Resources文件夹下的资源，在构建时会被打包到一个巨大的序列化文件中。游戏启动时，这个文件的索引结构会被全部加载到内存。这意味着，即使你从未加载过Resources里的某个纹理，你依然在为它的文件名和路径信息支付内存开销。更糟糕的是，使用Resources.Load同步加载资源后，如果你没有正确调用Resources.UnloadAsset或Resources.UnloadUnusedAssets，这些资源会一直驻留内存。因此，对于大型项目，最佳实践是彻底放弃使用Resources文件夹。

AssetBundle的精细化管理：AssetBundle是更主流的方式，但它同样需要精细的策略。

• 依赖关系：多个AssetBundle可能共享同一个材质或着色器。如果你加载了Bundle A和B，它们都依赖材质M，那么M会被加载两次吗？不会，Unity会智能管理。但如果你先加载A（加载了M），然后卸载A，M会因为被B引用而保留。但如果你再卸载B，M才会被真正卸载。理解这种依赖链至关重要。
• 卸载策略：AssetBundle.Unload(false)和AssetBundle.Unload(true)是天壤之别。Unload(false)只卸载AssetBundle文件本身在内存中的镜像，但已经从中加载出来的资源（如Texture、GameObject）会保留。如果你之后还想通过另一个Bundle加载同名资源，就会产生重复。Unload(true)则暴力卸载所有从中加载出的资源，可能导致场景中正在使用的对象丢失引用而变“粉红”（丢失材质）。通常推荐使用Unload(false)，并配合引用计数或场景生命周期来管理资源卸载。

Addressables的现代化方案：Addressable Asset System是Unity官方推荐的下一代资源管理系统。它本质上是对AssetBundle的封装和增强，提供了异步加载、依赖管理、内存管理（通过引用计数）等开箱即用的功能。它的核心优势在于将资源与路径解耦，你通过一个“地址”字符串来加载资源，系统自动处理底层Bundle的加载、缓存和卸载。对于新项目，强烈建议直接使用Addressables。

2.3 第三层：渲染与图形内存——隐藏的“内存杀手”

即使你的代码和资源管理得天衣无缝，图形API（如OpenGL ES、Metal、Vulkan）和GPU驱动仍然会占用大量内存，这部分通常在Unity Profiler的“GPU”或“Graphics”部分体现。

• 纹理内存：这是图形内存的大头。一张1024x1024的RGBA32纹理，在CPU端（Read/Write enabled）和GPU端各占约4MB内存。如果开启了Mipmap，内存占用会增加约33%。优化策略包括：
  • 使用合适的压缩格式：在移动端，使用ASTC、ETC2或PVRTC，可以将纹理内存减少到原来的1/4甚至更少。在Unity导入设置中根据平台选择。
  • 关闭不必要的Read/Write：只有需要在脚本中通过GetPixels或SetPixels动态修改的纹理才需要开启此选项，它会保留一份CPU端的拷贝。
  • Mipmap策略：对于UI纹理或永远靠近相机的2D精灵，关闭Mipmap可以节省内存。对于3D场景中的物体，Mipmap能提升渲染性能和视觉质量，需要权衡。
  • 最大尺寸限制：不要无脑使用4K纹理。根据物体在屏幕上的最大可能显示尺寸来设定纹理的Max Size。一个在手机上最多显示256像素的物体，用1024的纹理就是浪费。
• 网格内存：确保导入的网格没有不必要的多边形数量。使用LOD（Level of Detail）系统，在物体远离相机时使用面数更少的网格版本。
• 帧缓冲区与渲染目标：屏幕分辨率越高，帧缓冲内存越大。后处理效果（如Bloom、Depth of Field）会创建中间渲染纹理（RenderTexture），这些也是内存消耗点。在移动设备上，需谨慎使用高消耗的后处理。

2.4 第四层：托管堆与代码实践——防微杜渐

这一层关注C#脚本本身如何分配和管理内存。

• 避免在Update中分配新对象：这是最经典的准则。常见的陷阱包括：
  • Debug.Log：在发布版本中，虽然不会输出，但字符串拼接操作依然会发生，产生GC Alloc。应使用条件编译#if UNITY_EDITOR包裹。
  • foreach循环：在Unity的老版本Mono编译器或某些IL2CPP配置下，foreach在值类型集合上可能产生装箱（Boxing）分配。对于性能关键的循环，优先使用for循环。
  • 字符串操作：string.Format、+拼接都会产生新的字符串对象。在频繁调用的地方（如UI文本更新），考虑使用StringBuilder。
  • Lambda表达式与闭包：在帧更新中定义匿名方法或捕获外部变量，可能会在堆上分配内存。如果该操作每帧都执行，应考虑将其提取为类的成员方法。
• 使用结构体（struct）替代类（class）：对于小型、短暂存在的数据（如坐标、颜色、简单的状态数据），使用结构体。结构体是值类型，分配在栈上（或作为其他对象的一部分在堆上），其生命周期结束后自动回收，不经过GC。但要注意避免结构体过大导致的拷贝性能开销。
• 数组与列表复用：与对象池思想类似，对于需要频繁扩容的List<T>，可以预估一个容量，或者复用已有的列表对象，使用Clear()方法清空内容，而不是new List<T>()。

3. 核心方案实现：一套可落地的组合拳

3.1 实现一个智能、可伸缩的对象池系统

我们不再实现一个简单的List<GameObject>池，而是设计一个更通用的、支持任意组件类型、可自动伸缩的池子。

using System.Collections.Generic; using UnityEngine; public class GameObjectPool<T> where T : Component { private Queue<T> pool = new Queue<T>(); private T prefab; private Transform parent; // 构造函数：指定预制体、初始大小和父节点 public GameObjectPool(T prefab, int initialSize, Transform parent = null) { this.prefab = prefab; this.parent = parent; for (int i = 0; i < initialSize; i++) { T obj = CreateNewObject(); obj.gameObject.SetActive(false); pool.Enqueue(obj); } } private T CreateNewObject() { T newObj = Object.Instantiate(prefab, parent); // 可以在这里为对象添加一个标识组件，方便管理和调试 newObj.gameObject.AddComponent<PooledObject>().pool = this; return newObj; } public T Get() { if (pool.Count == 0) { // 池空，自动扩容。这里可以加入扩容策略，比如按百分比扩容。 Debug.LogWarning($"Pool for {prefab.name} is empty, creating new one."); return CreateNewObject(); } T obj = pool.Dequeue(); obj.gameObject.SetActive(true); // 发送一个消息，通知对象已被取出，可以进行自定义重置 obj.SendMessage("OnPoolGet", SendMessageOptions.DontRequireReceiver); return obj; } public void Return(T obj) { obj.gameObject.SetActive(false); // 发送一个消息，通知对象即将被回收，可以进行清理 obj.SendMessage("OnPoolReturn", SendMessageOptions.DontRequireReceiver); // 可选：重置Transform到池根节点下，避免场景杂乱 if (parent != null) { obj.transform.SetParent(parent); } pool.Enqueue(obj); } // 清空池子（谨慎使用，通常用于场景切换时） public void Clear() { while (pool.Count > 0) { T obj = pool.Dequeue(); if (obj != null) { Object.Destroy(obj.gameObject); } } pool.Clear(); } } // 标识组件，用于对象自我管理回池 public class PooledObject : MonoBehaviour { public GameObjectPool<Component> pool; // 这里用Component泛型，实际使用需强转 public void OnDisable() { // 不推荐在OnDisable中自动回池，因为SetActive(false)可能由多种原因触发。 // 最佳实践是：由生成该对象的控制器显式调用回池方法。 } // 提供一个方法供对象自己请求回池 public void ReturnToPool() { if (pool != null) { // 这里需要根据实际池化对象的类型进行转换，设计上可以更优雅，此处为示例 if (this is Component comp) { // 需要一种方式调用泛型池的Return，这里简化处理，实际项目可能需要反射或接口。 // 更常见的做法是，池管理器持有所有池的引用，通过GameObject或ID来归还。 } } } }

使用示例与注意事项：

public class BulletManager : MonoBehaviour { public Bullet bulletPrefab; private GameObjectPool<Bullet> bulletPool; void Start() { // 初始化一个容量为20的子弹池 bulletPool = new GameObjectPool<Bullet>(bulletPrefab, 20, this.transform); } void Update() { if (Input.GetMouseButtonDown(0)) { Bullet bullet = bulletPool.Get(); bullet.transform.position = transform.position; bullet.transform.rotation = transform.rotation; bullet.Shoot(transform.forward); // 调用子弹的初始化方法 } } // 这个方法由子弹对象在击中目标或超出范围后调用 public void ReturnBulletToPool(Bullet bullet) { bulletPool.Return(bullet); } } // Bullet.cs public class Bullet : MonoBehaviour { private Rigidbody rb; void Awake() { rb = GetComponent<Rigidbody>(); } public void Shoot(Vector3 direction) { rb.velocity = direction * 50f; // 可以在这里启动一个协程，3秒后自动回池，避免忘记回收 StartCoroutine(AutoReturn(3f)); } private System.Collections.IEnumerator AutoReturn(float delay) { yield return new WaitForSeconds(delay); // 通知管理器回收自己。更好的方式是用事件，这里简单演示。 FindObjectOfType<BulletManager>()?.ReturnBulletToPool(this); } // 可选：实现池化消息接口 void OnPoolGet() { rb.velocity = Vector3.zero; rb.angularVelocity = Vector3.zero; // 重置所有状态 } void OnPoolReturn() { StopAllCoroutines(); // 停止可能还在运行的协程 } }

注意：上述示例中的PooledObject组件和自动回池逻辑是一种设计思路。在大型项目中，更推荐使用一个中央化的池管理器来管理所有类型的对象池，并通过唯一ID或类型来存取，避免FindObjectOfType这类性能消耗较大的操作。同时，自动回池的协程也可能带来额外的GC Alloc（WaitForSeconds），对于超高频对象需谨慎。

3.2 构建基于Addressables的资源加载与缓存策略

Addressables的核心是“按地址加载”和“引用计数”。我们设计一个简单的资源服务类来封装常用操作，并加入自定义的缓存层。

using UnityEngine; using UnityEngine.AddressableAssets; using UnityEngine.ResourceManagement.AsyncOperations; using System.Collections.Generic; public class ResourceCacheService : MonoBehaviour { private static ResourceCacheService instance; public static ResourceCacheService Instance { get { return instance; } } // 缓存字典：Key为资源地址，Value为加载句柄和引用计数 private Dictionary<string, CachedAsset> assetCache = new Dictionary<string, CachedAsset>(); private class CachedAsset { public AsyncOperationHandle handle; public int refCount = 0; } void Awake() { if (instance != null && instance != this) { Destroy(gameObject); return; } instance = this; DontDestroyOnLoad(gameObject); } // 异步加载资源，并增加引用计数 public AsyncOperationHandle<T> LoadAssetAsync<T>(string address) { if (assetCache.TryGetValue(address, out CachedAsset cached)) { // 已缓存，增加引用计数并返回句柄 cached.refCount++; Debug.Log($"Asset {address} fetched from cache, refCount: {cached.refCount}"); return cached.handle.Convert<T>(); } // 未缓存，发起异步加载 AsyncOperationHandle<T> handle = Addressables.LoadAssetAsync<T>(address); assetCache[address] = new CachedAsset { handle = handle, refCount = 1 }; handle.Completed += (op) => { if (op.Status == AsyncOperationStatus.Succeeded) { Debug.Log($"Asset {address} loaded successfully."); } else { Debug.LogError($"Failed to load asset {address}: {op.OperationException}"); // 加载失败，从缓存中移除 assetCache.Remove(address); } }; return handle; } // 释放资源，减少引用计数，计数为0时真正释放 public void ReleaseAsset(string address) { if (assetCache.TryGetValue(address, out CachedAsset cached)) { cached.refCount--; Debug.Log($"Asset {address} released, refCount: {cached.refCount}"); if (cached.refCount <= 0) { Debug.Log($"Asset {address} reference count is zero, releasing..."); Addressables.Release(cached.handle); assetCache.Remove(address); } } else { Debug.LogWarning($"Trying to release an asset not in cache: {address}"); } } // 场景切换时，可以强制释放所有未被引用的资源（谨慎使用） public void ReleaseUnusedAssets() { List<string> toRemove = new List<string>(); foreach (var kvp in assetCache) { if (kvp.Value.refCount <= 0) { Addressables.Release(kvp.Value.handle); toRemove.Add(kvp.Key); } } foreach (var key in toRemove) { assetCache.Remove(key); } Debug.Log($"Released {toRemove.Count} unused assets."); // 同时也可以调用Addressables自身的清理 // Addressables.CleanBundleCache(); // 清理不再被任何句柄引用的AssetBundle缓存 } }

使用模式：

public class CharacterLoader : MonoBehaviour { public string characterPrefabAddress = "CHAR_Hero_01"; private GameObject loadedCharacter; private AsyncOperationHandle<GameObject> loadHandle; async void Start() { // 加载角色预制体 loadHandle = ResourceCacheService.Instance.LoadAssetAsync<GameObject>(characterPrefabAddress); loadedCharacter = await loadHandle.Task; // 使用async/await等待，需引用UnityEngine.ResourceManagement库 if (loadedCharacter != null) { Instantiate(loadedCharacter, transform.position, Quaternion.identity); } } void OnDestroy() { // 当这个加载器销毁时（如切换场景），释放对资源的引用 if (loadHandle.IsValid()) { ResourceCacheService.Instance.ReleaseAsset(characterPrefabAddress); } } }

缓存策略进阶：上述缓存是基于“地址”的。你还可以扩展为基于“标签”或“分类”的缓存策略。例如，所有“UI”资源常驻内存，所有“场景_关卡1”的资源在离开关卡1时整体卸载。Addressables本身支持通过标签加载资源组，可以结合使用。

3.3 纹理与网格内存的针对性优化配置

这部分优化主要在Unity Editor的导入设置（Import Settings）中完成。

纹理优化清单（在Project窗口选中纹理，在Inspector中设置）：

1. Texture Type：根据用途选择正确类型。UI用Sprite (2D and UI)，普通贴图用Default，法线贴图用Normal map，光照贴图用Lightmap。选错类型可能导致压缩格式不可用或产生不必要的数据。
2. Max Size：绝对不要无脑2048。问自己：这个纹理在屏幕上最大会显示多大？对于手机图标，128或256足矣；对于背景图，根据Canvas分辨率设置。
3. Compression：
   • PC/主机：通常使用BC7（RGBA，高质量）或BC1（RGB无Alpha）。BC3（RGBA，有Alpha）。
   • Android：优先使用ASTC，根据设备支持选择块大小（如ASTC 6x6是质量和内存的较好平衡）。老设备回退到ETC2（OpenGL ES 3.0以上）或ETC（ES2.0）。
   • iOS：优先使用ASTC。老设备（iPhone 5s以前）可使用PVRTC。
   • 注意：Crunch压缩是一种基于DXT或ETC的有损压缩，能显著减小磁盘上的包体大小，但运行时需要解压到GPU内存，其内存占用与未压缩格式相同。它主要用于减小下载包体积。
4. Generate Mip Maps：3D物体通常开启，2D UI精灵和粒子纹理通常关闭。
5. Read/Write Enabled：务必关闭，除非你明确需要在运行时通过脚本修改纹理像素数据。

网格优化清单：

1. Model选项卡：
   • Read/Write Enabled：和纹理一样，除非需要运行时修改网格顶点数据，否则必须关闭。开启会使网格数据在内存中保留两份（CPU一份，GPU一份）。
   • Optimize Mesh：勾选，让Unity重新排序网格的顶点和三角形索引，以提高GPU缓存命中率。
   • Generate Colliders：按需勾选。如果使用简单的碰撞体（如Box、Capsule），不要在这里生成，而是手动添加碰撞体组件，因为这里生成的往往是高精度的Mesh Collider，性能开销大。
2. Rig选项卡：对于人形角色，正确配置Avatar。对于非人形或静态网格，Animation Type选择None，可以节省相关开销。
3. Animations选项卡：对于非动画模型，直接Import Constraints、Import Animation全部取消勾选。对于动画模型，检查并优化动画剪辑的压缩设置（Anim. Compression），使用Optimal或Keyframe Reduction，并调整Rotation Error和Position Error容忍度，在视觉不失真的前提下减少关键帧数量。

3.4 代码层面的内存分配规避实战

在Update或FixedUpdate中，使用Profiler（Window > Analysis > Profiler）的CPU Usage模块，勾选Deep Profile或使用Profiler.BeginSample/EndSample来定位托管内存分配（GC Alloc）的热点。

常见陷阱与优化示例：

1. 字符串处理：

   // 坏：每帧都分配新字符串 void Update() { scoreText.text = "Score: " + currentScore; } // 好：使用StringBuilder复用 private System.Text.StringBuilder sb = new System.Text.StringBuilder(32); void Update() { sb.Clear(); sb.Append("Score: "); sb.Append(currentScore); scoreText.text = sb.ToString(); // 这里仍有分配，但频率和大小可控 } // 更好（对于固定格式）：使用缓存字符串或直接赋值（如果currentScore变化不频繁） // 或者，仅在分数变化时更新UI，而不是每帧。

2. 装箱（Boxing）：

   // 坏：枚举值在添加到ArrayList或作为object参数时会发生装箱 enum State { Idle, Walk, Run } ArrayList stateList = new ArrayList(); stateList.Add(State.Walk); // 装箱发生在这里 // 好：使用泛型集合 List<State> stateList = new List<State>(); stateList.Add(State.Walk); // 无装箱

3. Lambda与闭包：

   // 坏：每帧都定义一个新的委托和闭包 void Update() { someList.RemoveAll(item => item.isExpired); // 这个lambda会产生GC Alloc } // 好：将谓词定义为类的静态或成员方法 private static bool IsExpired(Item item) => item.isExpired; void Update() { someList.RemoveAll(IsExpired); // 无额外分配 }

4. Unity API调用：
   • GetComponent<T>()本身分配很小，但频繁调用仍需优化。在Awake或Start中缓存引用。
   • FindGameObjectsWithTag、FindObjectOfType等函数开销巨大，绝对禁止在每帧中调用。必须在初始化时缓存结果。
   • Camera.main内部相当于FindGameObjectWithTag("MainCamera")，也应缓存。

4. 性能剖析与问题排查实战指南

理论再好，不如实战。当游戏出现内存问题（卡顿、闪退）时，你需要一套系统的排查方法。

4.1 使用Unity Profiler进行内存快照分析

Profiler是你的第一道防线。打开Window > Analysis > Profiler，切换到Memory模块。

1. 获取并比较快照：
   • 在游戏启动后、进入主菜单时，点击Take Sample获取一个基线快照（Baseline）。
   • 进行你认为可能产生内存泄漏或增长的操作（如进入一个关卡，然后退出）。
   • 再次点击Take Sample获取第二个快照。
   • 点击Compare to baseline或Compare to previous，Profiler会高亮显示两次快照之间的差异。
2. 分析差异：
   • Managed Heap增长：关注System.Object[]、String、YourScriptClass等。如果退出关卡后，本该释放的脚本对象或资源引用仍然存在，说明存在非预期的引用，导致GC无法回收。这是托管内存泄漏的典型标志。
   • Native/Graphics增长：关注Texture2D、Mesh、Material等。如果退出场景后纹理内存没有下降，可能是AssetBundle没有正确卸载，或者静态变量、单例中持有了对这些资源的引用。
   • 注意“Other”项：有时内存被归类到“Other”，这可能包括Unity引擎内部数据结构、第三方插件分配的内存等。如果这里异常增长，需要结合代码和插件文档分析。
3. 使用Simple和Detailed模式：在Memory模块的顶部，可以选择模式。Simple模式给你一个总览，Detailed模式可以展开看到每一个具体的资源实例、GameObject实例，以及它们的引用链。这是查找“谁还在引用这个对象”的利器。

4.2 使用Unity Frame Debugger分析渲染内存

如果怀疑是渲染导致的内存或性能问题，打开Window > Analysis > Frame Debugger。

• 启用后，游戏会暂停，你可以逐帧、逐绘制命令（Draw Call）地查看渲染过程。
• 关注：
  • SetPass Calls：这是Draw Call数量的一个近似。数量过多（如超过100-200）是性能瓶颈的常见原因。可以通过静态批处理（Static Batching）、动态批处理（Dynamic Batching）、GPU Instancing、SRP Batcher等技术来合并。
  • 渲染纹理（RenderTexture）：查看每一帧创建了哪些临时RT，它们的大小和格式是什么。不必要的全屏RT或高精度RT会消耗大量内存和带宽。
  • 材质和着色器变体：频繁的材质切换（SetPass Call高）和大量的着色器变体（Shader Variants）也会影响性能。使用Shader Variant Collection来打包和预热需要的变体。

4.3 常见内存问题排查清单

4.4 高级工具：Memory Profiler与Heap Explorer

对于更深入的内存分析，Unity官方提供了Memory Profiler包（通过Package Manager安装）。它比内置Profiler的Memory模块更强大，可以生成完整的内存快照，并可视化对象之间的引用关系图。

1. 捕获快照：在游戏运行时，点击Capture按钮。建议在问题发生前后各捕获一次。
2. 分析引用链：在快照中，你可以搜索任何一个对象类型（如你的MonoBehaviour脚本），查看所有存活实例，并展开其引用树（Referenced By）。这能清晰地告诉你，是哪个根对象（Root）一直保持着对这个对象的引用，导致其无法被GC回收。常见的根对象包括静态变量、活跃的MonoBehaviour、被委托（Delegate）引用的对象等。
3. 比较快照：和Profiler一样，它可以对比两个快照，精确找出哪些对象被意外地保留了下来。

实操心得：内存优化是一个持续的过程，而不是一蹴而就的任务。建议在项目早期就建立性能基线（Baseline），并在每个重要的开发里程碑（如Alpha, Beta）进行全面的性能剖析。将内存和性能检查纳入你的日常测试流程，就像写单元测试一样。记住，预防永远比治疗更有效。当你养成了“分配意识”和“引用意识”，很多内存问题在编码阶段就已经被避免了。