了解一下Unity Object的内存管理机制-优快云博客

本文链接：https://blog.youkuaiyun.com/ZeroBugX/article/details/149394260

Unity的双重内存管理架构

Unity对象存在于两个不同的内存空间中：

C# 托管内存 (Managed Memory)

存储C#对象引用和元数据
由.NET垃圾回收器(GC)管理
包含对Native对象的句柄/指针

Native内存 (Unmanaged Memory)

存储实际的Unity资源数据
由Unity的Native内存管理器控制
包含纹理、网格、音频等具体数据

例如：

// 这个引用在托管内存中
GameObject obj = new GameObject();
// 实际的GameObject数据在Native内存中

其中，obj引用在托管内存中，而实际的GameObject数据在Native内存中。

UnityEngine.Object 在失去引用后是否需要调用 Destroy 进行销毁？

不一定需要手动调用 Destroy 销毁 UnityEngine.Object，但在大多数情况下，推荐显式调用 Destroy 以确保及时释放资源。

UnityEngine.Object 对象的生命周期由 Unity 的原生层（C++）管理，而不是完全依赖 C# 的垃圾回收器（GC）。当一个 UnityEngine.Object 失去所有 C# 引用后，它不会立即被销毁，而是由 Unity 的引用计数机制决定其是否可以被销毁。以下是具体情况：

场景对象（Scene Objects）：

如 GameObject 和其附加的组件（MonoBehaviour、Transform 等），这些对象通常存在于场景中。如果它们没有被显式销毁（通过 Destroy），会在场景卸载时（例如调用 SceneManager.UnloadSceneAsync）自动销毁。

如果场景不卸载（例如在单一场景的游戏中），这些对象会一直存在，直到显式调用 Destroy 或游戏结束。

资源对象（Asset Objects）：

如 Texture、Material、AudioClip 等，这些对象通常通过 Resources.Load、AssetBundle 或其他方式加载到内存中。即使失去 C# 引用，它们仍可能驻留在内存中，直到显式调用 Destroy ，AssetBundle.Unload 或 Resources.UnloadUnusedAssets。

为什么推荐显式调用 Destroy？

控制销毁时机

显式调用 Destroy 可以立即释放原生层的资源，避免内存占用过高。例如，动态创建的 GameObject 或加载的 Texture 如果不销毁，可能导致内存泄漏。

避免延迟释放

Unity 的原生层资源不会立即被 GC 回收，显式销毁可以确保资源在不再需要时立即释放。

场景切换的限制

场景对象在切换场景时会自动销毁，但资源对象（如通过 Resources.Load 加载的）不会，除非手动调用 Destroy 或 Resources.UnloadUnusedAssets。

示例

GameObject go = new GameObject("TestObject");
go = null; // 失去引用
// 此时 go 仍存在于场景中，直到场景卸载或显式销毁
Destroy(go); // 推荐显式销毁

go虽然被置为null，但是go对象仍存在于场景中，直到场景卸载或显式销毁，因此推荐用 Destroy(go) 显式销毁go对象。

Texture2D texture = Resources.Load<Texture2D>("MyTexture");
texture = null; // 失去引用，但纹理仍驻留在内存中
Destroy(texture); // 显式销毁以释放资源

texture被置为null后，失去引用，但纹理仍驻留在内存中，使用Destroy(texture)显式销毁以释放资源。

UnityEngine.Object 是否会被 GC 自动回收？

UnityEngine.Object 的 C# 部分（托管对象）可以被 GC 自动回收，但其底层的原生资源（C++ 对象）不会被 GC 直接管理，必须通过 Unity 的机制（如 Destroy 或 Resources.UnloadUnusedAssets）释放。

UnityEngine.Object 的内存构成

UnityEngine.Object 是一个混合对象，包含：

托管部分（Managed Part）：C# 中的对象引用，存储在托管堆上，由 Mono/IL2CPP 的垃圾回收器管理。
原生部分（Native Part）：底层的 C++ 对象，存储在原生堆上，由 Unity 引擎管理。

当 UnityEngine.Object 失去所有 C# 引用时：

托管部分：GC 会回收 C# 对象的内存（例如 GameObject 的 C# 引用）。
原生部分：对应的 C++ 对象不会被 GC 回收，而是由 Unity 的引用计数机制管理。如果没有其他引用（例如场景中或资源管理器中），Unity 会在特定时机（如场景切换或 Resources.UnloadUnusedAssets）释放这些资源。

回收机制的细节

引用计数

Unity 使用内部引用计数来跟踪 UnityEngine.Object 的使用情况。当一个对象的引用计数为 0（即没有 C# 引用、场景引用或其他引用）时，它成为“未使用”状态，可以被 Unity 回收。

场景对象

在场景卸载时，Unity 会自动销毁所有场景中的 GameObject 和组件，无需显式调用 Destroy。

资源对象

通过 Resources.Load 或 AssetBundle 加载的资源不会自动销毁，必须调用 Destroy ，AssetBundle.Unload 或 Resources.UnloadUnusedAssets 来释放。

GC 回收的限制

GC 仅回收托管部分

即使 C# 引用被 GC 回收，原生部分的内存仍可能驻留，导致内存占用。

延迟回收

Unity 的原生资源回收依赖于特定触发（如场景切换或手动卸载），可能导致资源滞留在内存中。

引用问题

如果开发者未正确管理引用（例如将对象存储在静态变量中），即使对象看似失去引用，也可能无法被回收。

因此，UnityEngine.Object在失去引用后不一定需要显式调用 Destroy，因为场景对象会在场景卸载时自动销毁，资源对象可以通过 Resources.UnloadUnusedAssets 清理。但为了精确控制内存释放，推荐显式调用 Destroy，尤其是对动态创建的 GameObject 或加载的资源。

UnityEngine.Object 的托管部分（C# 对象）可以被 GC 回收，但原生部分（C++ 对象）需要 Unity 的机制（如 Destroy 或场景卸载）释放。GC 无法直接管理原生资源，因此仅靠 GC 可能导致内存驻留。