Unity资源卸载性能优化全解析：从原理到实战避坑指南

1. 项目概述：为什么Unity资源卸载是个“技术活”？

做Unity开发久了，尤其是涉及到大型项目、开放世界或者移动端，你肯定对内存问题深恶痛绝。场景切换后，内存居高不下；玩久了手机发烫、闪退；明明调用了Destroy，Profiler里却还显示着纹理和网格在“赖着不走”。这些问题，十有八九都指向了同一个核心症结：资源生命周期管理不当，特别是对Resources文件夹下资源的卸载。

很多开发者，包括早期的我，都曾天真地认为Resources.Load和Destroy就是资源的“开”和“关”。直到被现实狠狠教育：Destroy一个从Resources加载出来的GameObject实例，只是销毁了那个实例对象，而它背后引用的原始资源（Texture、Mesh、Material等）依然稳稳地躺在内存里。这就是Unity资源管理的第一个大坑：原始资源（Asset）和其实例（Instance）是分离的。Resources系统内部有一个强引用缓存，一旦加载，除非你显式地告诉Unity“我不需要了”，否则它会认为你随时可能再次用到，从而一直保留。

于是，Resources.UnloadAsset和Resources.UnloadUnusedAssets这两个API就成了我们手中的“尚方宝剑”。但用不好，它们也可能是“双刃剑”。用UnloadAsset卸载一个正在被场景中物体使用的材质，瞬间就能让你的游戏画面“紫”成一片（Missing Material）。而盲目调用UnloadUnusedAssets，又可能引发不可预测的卡顿，尤其是在低端移动设备上，这种卡顿足以让玩家摔手机。

所以，这个“Unity资源卸载性能优化全解析”，就是要彻底扒开Resources.Unload系列API的底裤，从原理到实战，从最佳实践到避坑指南，让你不仅能解决内存泄漏，更能做到平滑、高效、可控的资源释放。无论你是正在为移动端包体发愁，还是为开放世界的流式加载头疼，这篇文章里的实战技巧都能直接拿来用。

2. 核心原理深度拆解：Unity资源管理的“里世界”

在挥舞Resources.Unload这把手术刀之前，我们必须先看懂Unity资源系统的“解剖图”。很多性能问题，根源在于对底层机制的一知半解。

2.1 资源生命周期的三重身份：Asset, Instance, Reference

这是理解一切的基础。当你把一张纹理MyTexture.png放进Resources文件夹后，它在运行时会有三种存在形式：

1. 磁盘上的原始数据：就是那个.png文件。在构建时，它会被打包进游戏的resources.assets文件包中。
2. 内存中的Asset对象（原始资源）：当你第一次调用Texture tex = Resources.Load<Texture>("MyTexture")时，Unity会从包中解压、解码数据，在内存中创建一个Texture类型的Asset对象。这个对象被Resources系统内部缓存并强引用。这就是为什么只Load不Unload，内存只增不减。
3. 场景中的Instance（实例）：当你调用Instantiate(tex)（注意，这里tex是Asset）或者直接Instantiate(Resources.Load<GameObject>("MyPrefab"))时，你创建的是这个Asset的一个副本或基于它的GameObject实例。这个实例引用着内存中的Asset对象。

关键点来了：Destroy(instance)仅仅销毁了这个实例，断开了实例对Asset的引用，但Asset本身还在内存的缓存里。要释放Asset占用的内存，你必须针对Asset本身进行操作。

2.2 Resources.UnloadAsset 的精准狙击与致命禁忌

Resources.UnloadAsset(Object assetToUnload)的设计初衷是进行精准的单个资源卸载。它的行为逻辑非常明确：

• 作用对象：只能是非GameObject的Asset类型。比如Texture、Material、Mesh、AudioClip、Sprite、Shader等。你无法用它卸载一个GameObject或Component的Prefab Asset（但可以卸载Prefab中包含的上述资源）。
• 作用条件：该Asset必须是从ResourcesAPI加载的，并且没有任何活跃的引用。这里的“活跃引用”指的是：没有被任何场景中的活跃GameObject、没有被其他未卸载的Asset（如Material引用Texture）、也没有被任何静态变量或MonoBehaviour的字段所引用。
• 执行结果：立即从内存中卸载该Asset对象。如果后续再次Resources.Load同一个路径，Unity会重新从包中加载并创建新的Asset对象。

致命的禁忌与坑点：

警告：这是最容易导致画面变紫（Missing Material/Texture）或音频丢失的操作。UnloadAsset是立即执行且不进行引用检查的（除了检查是否为Resources加载）。如果你卸载了一个正在被使用的材质球（Material）所引用的纹理（Texture），那么当下一次渲染需要这个纹理时，材质就会因为找不到纹理而显示为紫色（或在URP/HDRP中表现为粉色）。同理，卸载一个正在播放的AudioClip所关联的AudioClip资产，会导致静音。

实战心得：我个人的原则是，极度谨慎地使用Resources.UnloadAsset。它只适用于那些你完全掌控其生命周期的、独立的“大块头”资源。例如，在一个过场动画中加载了一段高清视频纹理（RenderTexture），动画播放完毕，确定后续流程和当前场景都不会再使用它，这时可以精准卸载。对于常规的、可能被多处共享的资源（如UI图集纹理、角色公共材质），交给UnloadUnusedAssets来统一管理更安全。

2.3 Resources.UnloadUnusedAssets 的“垃圾回收”与性能陷阱

Resources.UnloadUnusedAssets()是更常用、也更“粗放”的清理方式。你可以把它理解为Unity资源层面的“垃圾回收”（GC），但它回收的不是C#对象，而是Unity引擎管理的Native层资源（纹理、网格等）内存。

• 工作原理：Unity会遍历所有从Resources加载的Asset，检查它们是否还有“有效引用”。其引用计数系统比我们想象的复杂，它不仅看C#层的引用，更看Native层（渲染引擎、音频引擎等）是否还在使用该资源的数据。当一个Asset被判定为“未被使用”时，其占用的Native内存和部分Managed内存会被释放。
• 触发卡顿的元凶：UnloadUnusedAssets的执行本身是同步的，并且可能非常耗时。遍历所有资源、计算引用关系、执行卸载操作，这一系列动作会阻塞主线程。如果你的游戏中有大量资源，这个卡顿会非常明显，尤其是在每帧时间预算紧张的VR或移动设备上。

性能优化核心思路：不要频繁调用！绝对避免在Update中每帧调用。正确的做法是将其与场景切换、加载界面等“天然停顿点”结合起来。例如：

IEnumerator LoadNextSceneAsync(string sceneName) { // 显示加载界面 loadingScreen.Show(); // 异步加载新场景 AsyncOperation asyncLoad = SceneManager.LoadSceneAsync(sceneName); asyncLoad.allowSceneActivation = false; while (asyncLoad.progress < 0.9f) { // 更新加载进度条 loadingScreen.UpdateProgress(asyncLoad.progress); yield return null; } // 在新场景激活前，强制进行垃圾回收和资源卸载 System.GC.Collect(); // 先回收Managed内存，断开一些C#引用 Resources.UnloadUnusedAssets(); // 再回收Unused的Unity资源 yield return null; // 等待一帧，让卸载完成 // 现在激活新场景 asyncLoad.allowSceneActivation = true; // 隐藏加载界面 loadingScreen.Hide(); }

这个流程利用了场景加载的等待时间来进行清理，玩家感知到的只是一个稍长的加载过程，而非游戏过程中的卡顿。

2.4 引用链的复杂性：静态变量、协程与闭包

内存泄漏常常发生在意想不到的地方。即使你正确地调用了卸载API，资源可能因为隐秘的引用而无法被释放。

• 静态变量和单例：这是最常见的“长寿引用”。如果一个静态类持有了某个Material或Texture的引用，那么直到游戏结束它都不会被释放。
• 事件与委托：如果某个Asset（如一个AudioClip）被添加到事件监听器中，而监听器没有正确移除，那么这个引用也会一直存在。
• 协程（Coroutine）：yield return一个WWW、UnityWebRequest或AssetBundleRequest对象时，该请求对象会持有加载的资源，直到协程结束。如果协程被意外中断或忘记停止，资源就会泄漏。
• 闭包（Lambda表达式）：在Lambda表达式中捕获了外部变量，如果这个变量是某个Asset，且该Lambda被注册到一个长期存在的事件（如Button.onClick）中，就会形成隐蔽的引用链。

排查技巧：使用Unity Profiler的Memory Snapshot工具是终极武器。你可以拍摄两张快照：卸载操作前和卸载操作后。然后使用Snapshot对比功能，查看哪些Texture、Material、Mesh对象没有被释放。点击这些对象，在Reference标签页下可以展开完整的引用链，顺藤摸瓜就能找到是哪个C#对象“抓住”了它不放。

3. 实战优化策略：从粗放到精细的卸载方案

理解了原理，我们就能制定出分层、分场景的优化策略。没有一种方案通吃所有情况，关键是匹配你的项目需求。

3.1 策略一：基于场景的生命周期管理（适合中小型项目）

这是最直观的策略。将资源按场景划分，在离开一个场景时，卸载该场景专属的所有资源。

操作步骤：

1. 资源分类：将仅用于Scene_A的UI图集、角色模型、场景特效等放入Resources/Scene_A/目录下。
2. 加载时记录：在场景加载逻辑中，使用一个List<Object>或Dictionary<string, Object>来记录所有通过Resources.Load加载的该场景专属资源。
3. 场景卸载时清理：

   public class SceneSpecificAssetManager : MonoBehaviour { private List<Object> loadedSceneAssets = new List<Object>(); public T LoadAsset<T>(string path) where T : Object { T asset = Resources.Load<T>(path); if (asset != null) { loadedSceneAssets.Add(asset); } return asset; } public void UnloadAllSceneAssets() { // 1. 首先，销毁所有由这些资源实例化的游戏对象 // （假设你通过另一个系统管理了这些实例） // 例如：InstanceManager.DestroyAllInstancesFromScene(currentScene); // 2. 将资源引用列表清空，并调用卸载 foreach (var asset in loadedSceneAssets) { // 注意：这里不能直接UnloadAsset，因为可能被共享。 // 更安全的做法是解除我们自己的记录，然后依赖UnloadUnusedAssets。 // 但如果确定是场景独占且无实例引用，可以： // if (asset != null && !(asset is GameObject)) // { // Resources.UnloadAsset(asset); // } asset = null; // 解除本管理器的引用 } loadedSceneAssets.Clear(); // 3. 强制进行一次彻底的清理 System.GC.Collect(); Resources.UnloadUnusedAssets(); } }

注意事项：这种方法要求资源规划清晰，跨场景的公共资源（如通用UI字体、音效）需要单独管理，不能放在场景专属目录下，否则会被错误卸载。

3.2 策略二：引用计数与懒卸载（适合资源复杂的项目）

对于大型项目，资源复用率高，需要更精细的控制。引用计数是经典解决方案。

实现方案：

1. 封装一个AssetLoader：所有资源加载都通过这个Loader进行。
2. 维护引用字典：Dictionary<string, AssetInfo>，其中AssetInfo包含资源对象Object和引用计数int。
3. 提供Load和Release接口：

   public class RefCountedAssetLoader { private class AssetInfo { public Object asset; public int refCount; } private Dictionary<string, AssetInfo> assetCache = new Dictionary<string, AssetInfo>(); public T Load<T>(string path) where T : Object { if (assetCache.TryGetValue(path, out AssetInfo info)) { info.refCount++; return info.asset as T; } else { T loadedAsset = Resources.Load<T>(path); if (loadedAsset != null) { assetCache[path] = new AssetInfo { asset = loadedAsset, refCount = 1 }; } return loadedAsset; } } public bool Release(string path) { if (assetCache.TryGetValue(path, out AssetInfo info)) { info.refCount--; if (info.refCount <= 0) { // 引用为0，从缓存移除并卸载 assetCache.Remove(path); if (!(info.asset is GameObject)) // GameObject Asset不能UnloadAsset { Resources.UnloadAsset(info.asset); } // 同时，可以考虑将info.asset = null，帮助GC return true; // 表示已卸载 } return false; // 引用减少但未卸载 } return false; // 未找到资源 } // 提供一个强制清理所有未引用资源的方法（安全模式） public void UnloadAllUnused() { List<string> toRemove = new List<string>(); foreach (var kvp in assetCache) { if (kvp.Value.refCount <= 0) { if (!(kvp.Value.asset is GameObject)) { Resources.UnloadAsset(kvp.Value.asset); } toRemove.Add(kvp.Key); } } foreach (var key in toRemove) { assetCache.Remove(key); } } }

实操心得：引用计数的难点在于确保Load和Release必须成对调用。任何一个地方漏调Release，就会导致内存泄漏。这非常依赖于团队的编程规范和代码审查。通常，我们会将资源的生命周期绑定到特定的游戏对象或逻辑模块上，例如，一个角色控制器在OnEnable时Load所需资源，在OnDisable或OnDestroy时调用Release。

3.3 策略三：异步卸载与分帧处理（针对UnloadUnusedAssets卡顿）

对于无法避免要调用Resources.UnloadUnusedAssets，又无法忍受卡顿的情况，可以尝试将其“打散”到多帧中执行。虽然Unity没有提供官方的异步卸载API，但我们可以通过UnloadUnusedAssets返回的AsyncOperation来将其放入后台线程（严格说，是延迟到帧末），并结合分帧逻辑来减轻单帧压力。

注意：Resources.UnloadUnusedAssets()本身会返回一个AsyncOperation，但这个操作仍然在主线程进行大量工作，只是最终的释放动作可能部分异步。巨大的资源量下，遍历检查引用的CPU开销依然可能造成卡顿。

一种缓解方案：分帧触发不要在一次调用中卸载所有内容。如果你的游戏有“大厅”或“安全区”这类低压力场景，可以在这些场景中，每帧或每隔几帧卸载一小部分已知的、确定不再使用的资源类别。

// 伪代码示例：分帧卸载策略 private IEnumerator IncrementalUnloadCoroutine() { // 假设我们有一个待卸载的资源路径列表 List<string> assetsToUnload = GetConfirmedUnusedAssetPaths(); int assetsPerFrame = 5; // 每帧最多处理5个，可根据目标帧率调整 for (int i = 0; i < assetsToUnload.Count; i += assetsPerFrame) { int end = Mathf.Min(i + assetsPerFrame, assetsToUnload.Count); for (int j = i; j < end; j++) { // 这里需要能通过路径获取到具体的Asset对象。 // 如果之前用字典缓存过，可以直接获取。 Object asset = GetAssetFromPath(assetsToUnload[j]); if (asset != null && !(asset is GameObject)) { Resources.UnloadAsset(asset); } } yield return null; // 下一帧继续 } // 分批卸载完后，再执行一次全局的UnloadUnusedAssets清理残余 yield return Resources.UnloadUnusedAssets(); }

这种方法要求你对自己的资源依赖关系了如指掌，实现起来较为复杂，但对于追求极致流畅度的项目是值得的。

4. 高级技巧与避坑指南

掌握了基本策略，再来看看那些容易踩坑的细节和能提升效率的高级技巧。

4.1 AssetBundle与Resources的混合管理

如今，AssetBundle（或它的现代化身Addressable Assets系统）已成为大型项目资源管理的主流。但Resources文件夹因其便捷性，在小型资源、配置表、启动必备资源方面仍有价值。这就涉及到混合管理。

最佳实践：

• 明确分工：Resources只放启动时必须的、体积小的资源（如初始化UI、核心配置、第一个场景的必备资源）。所有大型资源（场景、高清纹理、模型、视频）都应通过AssetBundle或Addressables加载。
• 生命周期隔离：Resources中的资源，其生命周期通常与游戏进程相同（或直到你显式卸载）。而AssetBundle的资源生命周期与AssetBundle文件本身的加载/卸载绑定。切忌混用。不要用Resources.Load去加载一个来自AssetBundle的资源（虽然技术上可能通过某些hack做到），这会导致管理混乱和难以排查的bug。
• 卸载顺序：如果需要彻底重置游戏状态（如从游戏回到主菜单），卸载顺序应该是：
  1. 销毁所有动态生成的游戏对象。
  2. 卸载所有已加载的AssetBundle(AssetBundle.Unload(true))。
  3. 调用Resources.UnloadUnusedAssets()。这一步会清理掉那些从Resources加载的、以及从已卸载的AssetBundle中实例化出来但Asset已被标记为未引用的资源。
  4. 调用System.GC.Collect()。

4.2 关于“UnloadUnusedAssets无效”的深度排查

有时候，你明明调用了Resources.UnloadUnusedAssets()，Profiler里的内存却纹丝不动。除了前面提到的隐秘引用外，还有以下可能：

• Shader和Material的全局引用：某些Shader或全局Material（如GraphicsSettings中的默认材质）会引用一些纹理。这些引用是引擎内部的，你无法轻易解除。
• DontDestroyOnLoad的对象：标记为DontDestroyOnLoad的游戏对象及其组件上引用的所有资源，在整个游戏生命周期内都不会被判定为“未使用”。
• Resources文件夹外的资源：Resources.UnloadUnusedAssets()只处理从ResourcesAPI加载的资源。通过AssetDatabase.LoadAssetAtPath（仅在Editor下）、WWW、UnityWebRequest或直接序列化到场景中的资源，不受此API管理。它们有自己的内存管理方式。
• 内存碎片化：Unity的内存管理器（尤其是Mono/IL2CPP的托管堆）可能因为内存碎片化，导致即使对象被释放，进程占用的总内存（在任务管理器中看到的值）也不会立即下降。这是正常的，操作系统回收内存的时机由系统决定。关注Unity Profiler中的Used Heap和Reserved Heap更准确。

排查清单：

1. 使用Memory Snapshot对比，确认是哪种类型的资源没释放（Texture? Mesh? Material?）。
2. 在Snapshot中选中该资源，查看References，逐层展开，找到是哪个根对象（Root）持有它。
3. 检查常见的“长寿”对象：静态类、单例、DontDestroyOnLoad对象、挂在Camera.main或Canvas上的脚本。
4. 检查是否有协程未正确停止，其局部变量是否捕获了资源引用。

4.3 移动端与WebGL平台的特别注意事项

不同平台对内存和垃圾回收的策略不同，需要针对性优化。

• iOS/Android（移动端）：

  • 内存压力敏感：移动设备内存有限，且系统在内存紧张时会直接终止后台应用。必须严格管理内存峰值。
  • 避免运行时卡顿：UnloadUnusedAssets的卡顿在30fps或60fps的移动设备上尤为致命。务必在加载界面、过场黑屏时进行。
  • 使用Profiler的真机分析：在Editor里运行良好不代表真机没问题。务必连接真机进行Profiling，关注Memory > Simple视图下的Texture Memory和Mesh Memory。
  • 注意AssetBundle的卸载模式：在移动端，更推荐使用AssetBundle.Unload(false)，然后手动管理Asset的生命周期，而不是Unload(true)立即销毁所有Asset，后者容易因残留引用导致崩溃或紫屏。

• WebGL：

  • 内存即下载大小：在WebGL中，游戏的所有资源（包括代码）都需要在启动时下载。虽然Resources文件夹的内容会被打包，但过大的Resources文件夹会显著增加初始加载时间。
  • 考虑使用AssetBundle进行按需加载：将非首屏资源放入AssetBundle，通过网络按需加载，可以优化首次加载体验。
  • 垃圾回收的差异：WebGL的JavaScript环境垃圾回收机制与Mono/IL2CPP不同，System.GC.Collect()的效果可能不那么直接。资源卸载更依赖Resources.UnloadUnusedAssets()和AssetBundle.Unload。

5. 性能监控与调试实战

优化离不开数据。搭建一套简单的资源监控系统，能让你对项目的内存状况了如指掌。

5.1 简易资源监控器实现

你可以创建一个在开发阶段或测试版本中启用的监控脚本，实时显示关键资源数据。

using UnityEngine; using System.Collections.Generic; using System.Text; #if UNITY_EDITOR using UnityEditor; #endif public class ResourceMonitor : MonoBehaviour { public bool showInGameGUI = true; public float updateInterval = 2.0f; // 更新间隔，避免每帧计算 private float timer = 0f; private string infoText; void Update() { timer += Time.deltaTime; if (timer >= updateInterval) { UpdateResourceInfo(); timer = 0f; } } void UpdateResourceInfo() { StringBuilder sb = new StringBuilder(); // 1. 获取Texture内存 Texture[] allTextures = Resources.FindObjectsOfTypeAll<Texture>(); long textureMemory = 0; foreach (var tex in allTextures) { // 注意：GetRuntimeMemorySizeLong返回的是字节数，除以1024*1024得到MB // 此API在非Editor运行时可能受限，生产环境慎用或使用Profiler API textureMemory += Profiler.GetRuntimeMemorySizeLong(tex); } // 2. 获取Mesh内存 Mesh[] allMeshes = Resources.FindObjectsOfTypeAll<Mesh>(); long meshMemory = 0; foreach (var mesh in allMeshes) { meshMemory += Profiler.GetRuntimeMemorySizeLong(mesh); } // 3. 获取AudioClip内存 AudioClip[] allClips = Resources.FindObjectsOfTypeAll<AudioClip>(); long audioMemory = 0; foreach (var clip in allClips) { audioMemory += Profiler.GetRuntimeMemorySizeLong(clip); } sb.AppendLine($"=== 资源监控 (每{updateInterval}秒刷新) ==="); sb.AppendLine($"纹理数量: {allTextures.Length}, 内存: {textureMemory / (1024 * 1024):F2} MB"); sb.AppendLine($"网格数量: {allMeshes.Length}, 内存: {meshMemory / (1024 * 1024):F2} MB"); sb.AppendLine($"音频数量: {allClips.Length}, 内存: {audioMemory / (1024 * 1024):F2} MB"); // 4. 可以添加GameObject实例计数（谨慎使用，FindObjectsOfType很耗性能） // sb.AppendLine($"活动GameObject: {FindObjectsOfType<GameObject>().Length}"); infoText = sb.ToString(); } void OnGUI() { if (showInGameGUI) { GUI.Box(new Rect(10, 10, 400, 200), "Resource Monitor"); GUI.Label(new Rect(20, 40, 380, 160), infoText); } } }

注意：Resources.FindObjectsOfTypeAll和Profiler.GetRuntimeMemorySizeLong在生产环境（尤其是发行版）中可能不可用或性能开销大，仅用于开发调试。正式版本应移除或通过条件编译禁用。

5.2 利用Unity Profiler进行深度分析

监控器只能看个大概，真正的性能侦探是Unity Profiler。

• Memory Profiler模块：
  • Simple View：快速查看Used Heap、Reserved Heap、Texture Memory、Mesh Memory等总量。
  • Detailed View：点击Take Sample拍摄快照。这里可以看到所有内存中的对象，按类型、大小排序。重点关注Texture2D、Mesh、Material、Sprite、AudioClip等。
  • 比较快照：在资源卸载操作前后各拍一张快照，然后使用Compare to功能。列表中会突出显示新增和移除的对象，这是定位内存泄漏最直接的方法。
• CPU Profiler模块：
  • 记录一次Resources.UnloadUnusedAssets()的调用过程，查看它在主线程上消耗了多少毫秒。如果超过一帧时间（例如，在目标30fps下超过33ms），就必须考虑分帧或优化卸载时机。

5.3 编写自动化资源泄漏测试用例

对于核心的资源管理模块，可以编写单元测试或集成测试来确保没有泄漏。

using NUnit.Framework; using UnityEngine; using UnityEngine.TestTools; using System.Collections; public class ResourceUnloadTests { [UnityTest] public IEnumerator UnloadUnusedAssets_ShouldFreeMemory() { // 1. 记录初始内存 long initialTextureMemory = GetTotalTextureMemory(); // 2. 加载一个测试资源 string testTexturePath = "Test/MyTestTexture"; // 假设Resources/Test/下有一个纹理 Texture2D testTex = Resources.Load<Texture2D>(testTexturePath); Assert.IsNotNull(testTex, "Failed to load test texture."); // 3. 记录加载后的内存 long afterLoadMemory = GetTotalTextureMemory(); Assert.Greater(afterLoadMemory, initialTextureMemory, "Memory should increase after load."); // 4. 解除所有引用 testTex = null; // 移除局部引用 // 如果有全局缓存，也需要从这里清除 // 5. 触发垃圾回收和资源卸载 System.GC.Collect(); yield return Resources.UnloadUnusedAssets(); // 等待异步卸载完成 yield return null; // 再多等一帧确保完成 // 6. 记录卸载后的内存 long afterUnloadMemory = GetTotalTextureMemory(); // 7. 断言内存应回到（或接近）初始水平 // 由于内存碎片等原因，可能不会完全相等，可以设置一个容忍范围 Assert.LessOrEqual(afterUnloadMemory, afterLoadMemory, "Memory should decrease after unload."); // 更严格的断言：Assert.IsTrue(Mathf.Abs(afterUnloadMemory - initialTextureMemory) < tolerance); // 清理：确保测试资源不被缓存影响后续测试 // Resources.UnloadAsset 不适用于这里，因为我们已经置null并触发了Unused。 } private long GetTotalTextureMemory() { long total = 0; Texture[] allTextures = Resources.FindObjectsOfTypeAll<Texture>(); foreach (var tex in allTextures) { total += Profiler.GetRuntimeMemorySizeLong(tex); } return total; } }

这个测试用例可以在CI/CD流水线中运行，确保资源管理代码的修改不会引入新的内存泄漏问题。

资源卸载优化是一个贯穿项目始终的持续性工作。它没有一劳永逸的银弹，需要的是对原理的深刻理解、清晰的资源架构设计、严格的编码规范，以及借助强大工具进行的不断分析和调整。从今天起，告别盲目的Load和Destroy，开始像一位资源管理专家一样思考和编码，你的项目将会更加稳健和高效。