1. 项目概述从“内存焦虑”到精准定位做Unity开发尤其是手游最怕听到的两个字可能就是“内存”。项目跑着跑着帧率开始不稳设备发烫最后直接闪退后台日志一看OOMOut of Memory。这种场景但凡经历过一次都够头疼好几天。内存问题不像逻辑Bug它往往没有明确的报错而是像慢性毒药一样积累直到系统崩溃。而所有内存问题里最隐蔽、最难缠的就是资源泄漏。资源泄漏不是说你的代码写错了逻辑而是你的代码“忘记”了释放那些已经不再需要的资源。比如一个UI界面关闭了但加载进来的图片、预制体还挂在内存里一个场景切换了上个场景的音效文件、模型网格却赖着不走。这些“僵尸资源”会一点点蚕食你的可用内存最终导致游戏崩溃。更麻烦的是Unity的内存管理机制特别是托管内存的GC和Native资源的卸载有其特殊性很多在其他平台上的经验在这里并不完全适用。所以这个项目的核心就是一次实战演练如何利用Unity Profiler这个“显微镜”结合我们编写的测试代码像侦探一样精准地揪出项目中资源泄漏的“元凶”。我们不止要找到“谁”泄漏了更要搞清楚“为什么”会泄漏以及“如何”修复和预防。我会带你从最基础的Profiler使用讲起到如何设计有效的测试用例来复现泄漏再到深入分析泄漏链最后给出修复方案和编码规范。整个过程我会附上完整的、可运行的测试代码你可以直接拿到自己的项目里验证和参考。2. 理解Unity内存的两大阵营Mono与Native在动手抓“贼”之前我们必须先搞清楚“贼”可能藏在哪里。Unity的内存世界主要分为两大阵营管理方式截然不同泄漏的成因和排查手段也各有侧重。2.1 Mono托管堆你的C#代码之家当我们用C#在Unity中写脚本使用new关键字创建对象、使用List、Dictionary等集合时这些对象所占用的内存就位于Mono托管堆上。它的管理核心是垃圾回收器。GC如何工作GC会定期或在你手动调用GC.Collect()时扫描所有托管对象寻找那些已经没有任何“根引用”如静态变量、活动线程栈上的局部变量等可达的对象。这些对象被视为“垃圾”它们占用的内存会被标记并回收。泄漏的根源在GC看来只要一个对象还被引用着它就不是垃圾。因此Mono内存泄漏的本质就是意外的、持久的引用。比如你把一个本该销毁的临时对象添加到了一个全局的静态列表中那么这个对象就永远无法被GC回收。一个关键特性Mono堆的内存是“只增不减”的。即使GC回收了垃圾释放出来的内存也只是归还给Mono运行时自己的内存池不会立即返还给操作系统。只有当堆内存空闲区域足够大时才可能收缩。更多时候我们看到的是Mono堆的峰值内存不断攀升。2.2 Native堆Unity引擎的资源王国纹理、网格、音频片段、材质球、Shader、乃至通过UnityEngine.Object派生类实例化的对象如GameObject,Component它们所占用的内存位于Native堆。这部分内存由Unity的C引擎核心直接管理。管理方式Native内存没有自动的、周期性的垃圾回收。它的释放依赖于引用计数和显式卸载。核心接口Resources.UnloadUnusedAssets(): 这是最常用的接口。它会遍历所有Native资源如果某个资源没有任何“有效”的Mono对象引用它注意是“有效”引用后面会细说并且没有被标记为“DontDestroyOnLoad”它就会被卸载。Resources.UnloadAsset(Object assetToUnload): 强制卸载指定资源无论它是否被引用。非常危险除非你百分百确定该资源在任何地方都不会再被使用。泄漏的根源Native资源泄漏通常是因为在Mono层存在未被察觉的引用导致UnloadUnusedAssets认为该资源仍在使用中。另一种情况是卸载时机不对在卸载后才清除了引用。2.3 引用类型强引用与弱引用理解引用是解决泄漏的关键。在C#中类的字段、属性、局部变量、静态变量等对对象的持有默认都是强引用。只要强引用存在GC就不会回收该对象Unity也不会卸载该对象引用的资源。public class LeakyClass : MonoBehaviour { private Texture2D _cachedTexture; // 这是一个强引用 void Start() { _cachedTexture Resources.LoadTexture2D(BigTexture); } void OnDestroy() { // 如果忘记将 _cachedTexture 置为 null即使LeakyClass的GameObject被销毁 // _cachedTexture 仍然被这个“已销毁”的组件实例引用着无法被卸载。 // _cachedTexture null; // 正确的做法 } }弱引用WeakReference则不同它允许你引用一个对象但不会阻止该对象被垃圾回收。它主要用于缓存场景不是我们解决泄漏的主要工具但知道它的存在有助于理解内存管理。注意这里有一个巨大的误区很多人认为GameObject.Destroy(gameObject)或Component被销毁后其对资源的引用就自动解除了。这是错误的Destroy只是将对象标记为“待销毁”并移出场景 hierarchy。但该对象实例在Mono堆中依然存在直到GC下一轮回收。在这期间它持有的所有强引用依然有效会阻止Native资源被卸载因此在OnDestroy中手动清除对大型资源的引用是至关重要的好习惯。3. 实战准备构建一个“可控泄漏”的测试场景理论讲再多不如亲手实践。我们来构建一个简单的测试项目故意制造几种典型的资源泄漏然后用Profiler来观察和定位。3.1 测试场景搭建创建一个新的Unity项目建议使用较新的LTS版本如2022.3。在场景中创建一个空GameObject命名为MemoryLeakTester。我们将为它挂载多个脚本每个脚本演示一种泄漏模式。3.2 编写泄漏测试脚本脚本1静态引用泄漏经典且致命using UnityEngine; public class StaticReferenceLeak : MonoBehaviour { // 静态列表是全局的生命周期与应用程序域相同。 public static ListSprite GlobalSpriteCache new ListSprite(); public Sprite leakySprite; void Start() { if (leakySprite ! null) { // 将资源添加到静态列表创建了一个永久的强引用。 GlobalSpriteCache.Add(leakySprite); Debug.Log($Sprite {leakySprite.name} 已被添加到全局缓存将永远无法卸载。); } } void OnDestroy() { // 即使这个GameObject被销毁GlobalSpriteCache依然持有对leakySprite的引用。 Debug.Log(StaticReferenceLeak 组件被销毁但静态引用仍在。); } }实操要点将这个脚本挂到MemoryLeakTester上并在Inspector中拖入一个Sprite资源。运行游戏然后销毁MemoryLeakTester游戏对象。你会发现这个Sprite永远留在了内存里。脚本2事件委托泄漏隐蔽的杀手using UnityEngine; using UnityEngine.Events; public class EventDelegateLeak : MonoBehaviour { public UnityEvent onSomethingHappened new UnityEvent(); void Start() { // 假设有另一个对象监听这个事件 SomeOtherComponent listener FindObjectOfTypeSomeOtherComponent(); if (listener ! null) { onSomethingHappened.AddListener(listener.HandleEvent); } } void OnDestroy() { // 关键点如果我们不手动移除监听listener对象即使被销毁了 // 在委托链中的引用依然存在这会阻止listener被GC回收。 // 如果listener持有了大量资源这些资源也会泄漏。 // onSomethingHappened.RemoveAllListeners(); // 必须做的清理 Debug.LogWarning(EventDelegateLeak 被销毁但未清理事件监听); } } // 一个假设的监听者 public class SomeOtherComponent : MonoBehaviour { public Texture2D heavyTexture; void Start() { heavyTexture new Texture2D(1024, 1024); // 分配一个大的纹理 } public void HandleEvent() { Debug.Log(Event handled!); } }注意事项C#中的事件和委托会隐式地持有对目标对象的强引用。如果发布者比监听者生命周期长或者像上面这样忘记移除就会导致监听者无法被释放。这是Unity项目中非常常见的一类泄漏。脚本3协程中的引用泄漏using System.Collections; using UnityEngine; public class CoroutineLeak : MonoBehaviour { private SomeBigDataClass _bigData; void Start() { _bigData new SomeBigDataClass(); // 假设这是一个占用内存很大的类 StartCoroutine(MyLeakyCoroutine()); } IEnumerator MyLeakyCoroutine() { // 协程内部通过闭包捕获了 this (即CoroutineLeak实例) // 只要协程还在运行哪怕在等待this 就不会被GC回收。 yield return new WaitForSeconds(10f); // 等待10秒 Debug.Log($Coroutine finished, using data: {_bigData}); } void OnDestroy() { // 即使调用StopAllCoroutines已经启动的协程其内部捕获的引用可能依然存在。 // 更安全的做法是使用一个标志位在OnDestroy中设置协程里检查。 Debug.Log(CoroutineLeak 被销毁但协程可能还在引用它。); } } public class SomeBigDataClass { private byte[] _data new byte[1024 * 1024 * 10]; // 10MB 数据 }实操心得协程是IEnumerator由Unity引擎驱动。只要yield return语句还在执行承载这个协程的IEnumerator对象就存活它捕获的所有外部变量包括this就都被强引用着。在对象销毁时必须确保其启动的所有协程都已停止。4. 启动侦探工具Unity Profiler深度使用指南现在我们的“犯罪现场”测试场景已经布置好了。是时候请出我们的主要侦探工具——Unity Profiler。4.1 配置与连接打开Profiler窗口Window Analysis Profiler。选择Memory模块在Profiler窗口顶部确保Memory模块被选中并启用。录制模式点击左上角的录制按钮圆形红点开始录制性能数据。4.2 捕获关键内存快照排查资源泄漏最有效的方法就是对比不同时间点的内存快照。初始状态快照在游戏刚启动测试对象还未创建时在Memory模块点击Take Sample按钮或使用快捷键。这代表了你的“干净”内存状态。操作并制造泄漏在场景中实例化MemoryLeakTester或者触发那些会加载资源的代码。泄漏后快照执行一系列可能导致泄漏的操作如打开/关闭UI切换场景然后等待几帧让操作稳定下来。再次点击Take Sample。清理后快照执行你认为的“清理”操作如销毁测试对象调用Resources.UnloadUnusedAssets()再取一次快照。4.3 分析快照数据点击Take Sample后数据会出现在下方。关键是要看Detailed视图。All Objects视图这里按类型列出了内存中的所有对象。重点关注Texture2D,Sprite,Mesh,Material,AudioClip这些是占用Native内存的大户。GameObject,MonoBehaviour这些是托管对象但可能引用着Native资源。如何识别泄漏对比步骤1和步骤2的快照。在第二个快照的All Objects列表里筛选出那些在第一个快照中不存在或者数量明显增多的对象。例如你发现一个叫“Background_Leak”的Texture2D在清理后依然存在它就是可疑目标。查看引用链这是Profiler最强大的功能。在All Objects列表中找到可疑对象点击它。右侧会显示Reference和Referenced By两个面板。Referenced By谁引用了我向上追溯显示哪些对象持有对该资源的引用。这是寻找泄漏根源的关键路径。你需要一层层点开直到找到一个你认为不应该再存在的对象比如一个已经被Destroy的GameObject的某个组件。Reference我引用了谁向下追溯显示该对象引用了哪些其他对象。排查技巧当引用链非常长时注意寻找那些生命周期长的对象作为“根”例如static变量、GameManager单例、DontDestroyOnLoad的对象等。泄漏的引用往往最终会链到这些“常驻”对象上。4.4 使用Deep Profile捕获Mono分配对于Mono堆的泄漏比如我们的StaticReferenceLeak中那个ListSprite我们还需要关注代码层面的分配。在Profiler中启用Deep Profile模式注意这会带来巨大性能开销仅用于调试。执行你的测试操作。在CPU Usage模块中查看GC Alloc列。这里显示了每一帧由GC分配的内存量。反复执行某个操作后如果GC Alloc持续出现稳定的峰值说明该操作在持续分配未被回收的内存。点击高GC Alloc的帧在下方Hierarchy视图中可以查看具体的函数调用堆栈定位到是哪行代码在持续分配内存。5. 编写自动化测试代码固化排查流程手动用Profiler抓快照对比是有效的但效率低且无法集成到CI/CD流程中。我们可以编写一些编辑器脚本将这个过程自动化。5.1 内存快照比较工具using UnityEditor; using UnityEngine; using System.IO; using System.Collections.Generic; public static class MemorySnapshotComparer { [MenuItem(Tools/Memory/Compare Snapshots)] public static void CompareTwoSnapshots() { // 提示用户先获取第一个快照干净状态 if (EditorUtility.DisplayDialog(Memory Snapshot, 请确保游戏处于初始状态然后点击OK获取快照A。, OK, Cancel)) { string snapshotAPath Path.Combine(Application.dataPath, ../MemorySnapshots/snapshotA.json); CaptureSnapshot(snapshotAPath); Debug.Log($快照A已保存至: {snapshotAPath}); // 提示用户执行操作后获取第二个快照 if (EditorUtility.DisplayDialog(Memory Snapshot, 现在请执行可能引起泄漏的操作然后点击OK获取快照B。, OK, Cancel)) { string snapshotBPath Path.Combine(Application.dataPath, ../MemorySnapshots/snapshotB.json); CaptureSnapshot(snapshotBPath); Debug.Log($快照B已保存至: {snapshotBPath}); // 比较并输出结果 CompareAndReport(snapshotAPath, snapshotBPath); } } } private static void CaptureSnapshot(string filePath) { Directory.CreateDirectory(Path.GetDirectoryName(filePath)); // 这里需要调用底层Profiler接口获取详细数据 // 注意Unity的Profiler API在不同版本间变化较大以下为概念代码 // var memorySnapshot ProfilerDriver.GetMemorySnapshot(); // string json JsonUtility.ToJson(memorySnapshot); // File.WriteAllText(filePath, json); Debug.LogWarning(实际实现需要调用ProfilerDriver等非公开API此处为流程演示。); // 实际项目中可以考虑使用第三方开源工具或通过命令行调用Profiler并解析输出。 } private static void CompareAndReport(string pathA, string pathB) { // 读取两个JSON文件反序列化 // 比较相同类型的对象数量和总内存占用 // 列出在B中存在但在A中不存在或数量显著增加的对象类型和实例 // 将结果输出到一个文本文件或Unity编辑器的Console中 Debug.Log(快照比较功能需要实现具体的解析逻辑。); } }注意Unity Editor的Profiler API (ProfilerDriver,ProfilerWindow) 很多是内部API在正式项目中使用可能不稳定。一个更稳定的替代方案是使用Unity Test Framework结合UnityEngine.Profiling.Memory.Experimental命名空间下的MemoryProfiler如果版本支持或者直接通过命令行构建并运行带有-profiler-memory参数的独立版本然后解析其输出日志。5.2 集成到单元测试中我们可以创建一个Play Mode测试来自动化执行泄漏检测流程。using System.Collections; using System.Collections.Generic; using NUnit.Framework; using UnityEngine; using UnityEngine.TestTools; using UnityEngine.Profiling; using UnityEditor; // 注意部分API只在Editor下可用 public class MemoryLeakTests { [UnityTest] public IEnumerator UIWindow_OpenAndClose_ShouldNotLeakTextures() { // 1. 初始内存记录 (简化版记录特定资源数量) int initialTextureCount Resources.FindObjectsOfTypeAllTexture2D().Length; // 2. 执行操作实例化一个UI窗口预制体 GameObject uiWindowPrefab Resources.LoadGameObject(Prefabs/MyUIWindow); Assert.IsNotNull(uiWindowPrefab, 请准备测试用的UI预制体); GameObject windowInstance GameObject.Instantiate(uiWindowPrefab); // 等待一帧让Awake/Start执行资源加载完成 yield return null; // 3. 操作中内存记录 int afterOpenTextureCount Resources.FindObjectsOfTypeAllTexture2D().Length; Debug.Log($打开窗口后Texture数量: {afterOpenTextureCount}); // 4. 执行清理关闭/销毁窗口 GameObject.Destroy(windowInstance); yield return null; // 等待Destroy完成 // 强制进行垃圾回收和资源卸载模拟切换场景等时机 System.GC.Collect(); Resources.UnloadUnusedAssets(); yield return new WaitForSeconds(0.5f); // 给卸载一点时间 // 5. 最终内存记录 int afterCloseTextureCount Resources.FindObjectsOfTypeAllTexture2D().Length; Debug.Log($关闭窗口并清理后Texture数量: {afterCloseTextureCount}); // 6. 断言最终Texture数量应回到初始水平或允许有合理缓存 // 这里使用LessOrEqual考虑到Unity或项目自身可能有常驻缓存 Assert.LessOrEqual(afterCloseTextureCount, initialTextureCount 2, $检测到可能的纹理泄漏初始:{initialTextureCount}, 关闭后:{afterCloseTextureCount}。差值过大。); } [UnityTest] public IEnumerator SceneLoad_ShouldNotLeakMeshes() { // 类似逻辑针对Mesh资源进行测试 // 可以使用SceneManager.LoadSceneAsync 和 UnloadSceneAsync yield return null; // ... 具体实现省略 } }实操心得这种测试的关键在于确定一个合理的“基线”。游戏运行时引擎本身或你的资源管理系统可能会有合理的缓存如最近使用过的纹理。因此断言不能是严格的相等而应该是“小于等于基线一个阈值”。这个阈值需要根据项目具体情况来定。6. 高级排查技巧与常见陷阱即使掌握了Profiler和自动化测试有些泄漏依然狡猾。下面分享一些高级技巧和常见坑点。6.1 使用WeakReference诊断“幽灵引用”当你确信一个对象应该被回收但Profiler显示它依然被引用时可能是某个隐藏的引用在作祟。你可以使用WeakReference来辅助判断。// 在怀疑泄漏的类内部 private WeakReference _selfReference; void Start() { // 创建一个指向自己的弱引用 _selfReference new WeakReference(this); Debug.Log($对象 {this.name} 已创建。); } void OnDestroy() { // 在销毁时检查是否还有其他强引用存在 // 如果_isAlive为true说明除了这个弱引用还有别的强引用阻止GC bool isAlive _selfReference.IsAlive; Debug.Log($对象 {this.name} 被销毁但通过弱引用检测是否存活: {isAlive}); if (isAlive) { Debug.LogError($发现幽灵引用对象 {this.name} 在OnDestroy后仍被强引用。); } }6.2 注意ScriptableObject的泄漏ScriptableObject是存放配置数据的好工具但它本身是一个UnityEngine.Object。如果你在代码中持有一个ScriptableObject实例的公共字段并在编辑器中赋值那么这个ScriptableObject资源文件Asset的实例就会被直接引用。即使你后来通过Resources.Load加载了另一个同名的Asset内存中依然会存在两份。正确做法对于需要动态加载的ScriptableObject应该通过Resources.Load或Addressables/AssetBundle在运行时加载并管理好其引用生命周期而不是直接拖拽到Inspector里除非它确实是全局唯一的配置。6.3 AssetBundle与Addressables的泄漏现代Unity项目大多使用AssetBundle或Addressables进行资源管理。它们的泄漏模式稍有不同AssetBundle加载AssetBundle (AssetBundle.LoadFromFile) 会占用内存。即使你加载了其中的资源并实例化AssetBundle文件本身在内存中的映射可能依然存在取决于加载方式。必须调用AssetBundle.Unload(false)或(true)来释放。Unload(false)只释放AssetBundle文件本身内存中的资源对象还在Unload(true)会连同时加载出来的资源一起销毁非常危险。AddressablesAddressables系统有自己更复杂的引用计数和缓存机制。泄漏通常发生在加载资源后LoadAssetAsync没有在适当的时候调用Release。对AsyncOperationHandle管理不当没有保留其引用导致无法Release。最佳实践是将AsyncOperationHandle作为成员变量保存起来在对象销毁时调用Addressables.Release(handle)。6.4 第三方插件与SDK集成广告、分析、社交等第三方SDK时务必仔细阅读其文档中关于初始化和清理的部分。很多SDK会在初始化时创建单例或静态实例并持有对MonoBehaviour的引用。如果游戏退出或场景切换时没有调用SDK提供的清理方法就可能造成泄漏。7. 构建防泄漏的编码规范与工作流排查和修复是亡羊补牢最好的策略是防患于未然。在团队中建立良好的编码规范和工作流至关重要。生命周期配对原则对于任何IDisposable对象、事件监听、协程、资源加载句柄必须遵循“谁创建谁负责”的原则在对象生命周期结束时OnDestroy,OnDisable进行清理。void OnEnable() { EventBus.Subscribe(EventType, Handler); } void OnDisable() { EventBus.Unsubscribe(EventType, Handler); } // 必须配对 void Start() { _loadHandle Addressables.LoadAssetAsyncGameObject(Prefab); } void OnDestroy() { if(_loadHandle.IsValid) Addressables.Release(_loadHandle); } // 必须配对慎用Static严格审查static字段的使用。除非是真正的全局单例或常量否则避免使用。对于缓存考虑使用WeakReference字典或具有大小和过期策略的缓存库。资源卸载时机在场景切换的加载界面、游戏返回主菜单等“天然断点”处主动调用Resources.UnloadUnusedAssets()。可以结合GC.Collect()一起调用但要注意可能引起的卡顿。代码审查清单在代码审查时将内存管理作为必查项。重点关注新加的static字段。事件的订阅与取消订阅。协程的启动与停止。资源加载APIResources.Load,AssetBundle.LoadAsset,Addressables.LoadAssetAsync是否有对应的释放。OnDestroy方法是否清除了对大型资源纹理、网格、音频的引用。自动化测试门禁将类似第5章编写的内存泄漏测试集成到项目的CI/CD流水线中。每次提交或 nightly build 都运行一遍如果发现关键场景的资源计数异常增长则标记构建失败或发出警告。性能预算与监控为关键场景如主城、核心战斗设定内存预算例如Mono堆不超过50MBTexture内存不超过200MB。在开发期和QA测试期使用性能 profiling 工具如Unity Profiler, UPR, Snapdragon Profiler进行监控一旦超出预算立即告警并排查。内存优化是一场持久战而资源泄漏是其中最需要耐心和细心的部分。它没有银弹依靠的是对引擎机制的理解、严谨的编码习惯、有效的工具使用和团队协作的规范。希望这篇实战指南能帮你和你的团队建立起一道坚固的内存防线。