Unity 原生对象生命周期
篇章 ：09-核心技术-内存管理篇 | 阅读时间 ：约 40 分钟 | 前置知识：了解 Unity 资源系统和 GC 基本概念
一、引言
UnityEngine.Object 是 Unity 世界中一切对象的基类。它的原生生命周期由引擎及对应资源 API 管理，不能一概归结为引用计数；托管包装对象则受 GC 管理。这个"双重管理"架构是理解 Unity 内存行为和避免常见陷阱的关键。
理解 UnityEngine.Object 的双重身份是掌握 Unity 内存管理的基础。每个 UnityEngine.Object 实例都包含两个层面：C# 侧的托管堆包装对象和 C++ 侧的原生对象。GC 只管理前者，引擎管理后者。这种分离设计使得 Unity 能够在编辑器中实现拖拽式资源管理，但也带来了内存管理的复杂性。
核心论点：Unity 内存问题的根因几乎都可以追溯到对"双重管理"模型的理解不足。开发者常常误以为将 C# 引用置为 null 就释放了资源，却忽略了 C++ 侧的原生对象仍然占用显存或内存。只有同时管理好两个层面的生命周期，才能真正控制内存使用。
二、UnityEngine.Object 的双重身份深度分析
2.1 双重身份的架构设计
Unity 采用 C# 作为脚本语言，C++ 作为引擎底层语言。这种架构下，Unity 需要在托管堆和原生堆之间建立映射关系。每个 UnityEngine.Object 实例就是一个映射的端点：C# 侧的实例包含一个 IntPtr，指向 C++ 侧的原生对象。
C# 侧的包装对象由 GC 管理，大小通常在 100 到 200 字节之间，包含运行时对象信息与关联引擎对象所需的数据，实际布局和大小依赖版本与平台。C++ 侧的原生对象由引擎管理，大小从几十字节（如 Transform）到数兆字节（如纹理）不等，包含对象的实际数据和功能实现。
这种设计的优势在于：GC 可以自动回收不再使用的 C# 包装对象，而引擎可以独立管理原生资源的生命周期。但劣势在于：两个层面的生命周期不同步，C# 引用被切断后，原生对象仍然存活，直到对应的引擎对象或资源协议结束。
2.2 双重生命周期的不同步性
理解双重生命周期的不同步性是避免内存泄漏的关键。当调用 Destroy 时，销毁请求按引擎时序处理，而非调用点立即归零一套统一引用计数，但 C# 侧的包装对象仍然存在，只是被标记为"假死"状态。在这个状态下，C# 对象的 == 运算符被 Unity 重载，返回 true（表示 null），但 (object)obj == null 返回 false，因为 C# 引用本身不为 null。
这种假死状态会持续存在，直到 C# 包装对象被 GC 回收。GC 回收的时机取决于托管堆的使用情况和 GC 的触发策略，可能立即发生，也可能延迟多帧。在假死状态期间，C# 包装对象仍然占用托管堆内存，仍然会被 GC 的标记阶段扫描，增加了 GC 的工作量。
2.3 假死状态的 GC 影响
假死对象对 GC 的影响被严重低估。当一个对象被 Destroy 后，它的 C# 包装对象变为假死状态。如果开发者没有将 C# 引用置为 null，这个包装对象会一直存在于托管堆上，直到 GC 下次回收周期才被发现并回收。
在大型项目中，如果场景中有 2000 个对象被 Destroy 但 C# 引用未被清理，这 2000 个假死包装对象会占用约 200 到 400KB 的托管堆内存。更重要的是，GC 在标记阶段需要扫描每个假死对象的引用链，发现它们指向已销毁的原生对象后跳过。这个扫描过程增加了 GC 标记阶段的时间，在对象数量巨大时可能成为性能瓶颈。
三、Destroy 与 GC 的关系深度分析
3.1 Destroy 的执行时机
Destroy 的执行时机是 Unity 内存管理中最容易被误解的概念之一。调用 Destroy(obj) 时，原生对象在当前帧末被销毁，C# 包装对象变为假死状态。这意味着在调用 Destroy 的同一帧内，obj == null 返回 true，但 obj 变量本身仍然指向一个有效的 C# 对象。
这种设计有其原因：如果 Destroy 同步销毁 C# 对象，那么在 Destroy 调用时所有引用该对象的变量会立即变为 null，可能导致同一帧内其他代码访问已销毁对象时的崩溃。通过延迟销毁，Unity 确保了当前帧内所有对对象的访问仍然是安全的。
3.2 DestroyImmediate 与 Destroy 的区别
DestroyImmediate 是 Destroy 的同步版本，立即销毁原生对象和 C# 包装对象。它只在编辑器开发阶段使用，因为同步销毁会阻塞主线程，影响运行时性能。在运行时代码中，应该始终使用 Destroy，让 Unity 在当前帧末统一处理销毁操作。
3.3 GC.Collect 对原生对象的影响
GC.Collect 只回收托管堆上的 C# 包装对象，对 C++ 侧的原生对象没有任何影响。这是一个常见的误解：开发者调用 GC.Collect 后期望释放所有内存，但实际上只释放了托管堆部分，原生内存仍然占用。
要释放原生内存，必须调用 Destroy 或 UnloadUnusedAssets 等引擎 API。GC.Collect 只能释放 C# 包装对象的内存，通常是总内存的极小一部分（对于 GPU 资源，比例可能低至 1:10000）。
四、常见陷阱的深度分析
4.1 假死对象的检测与处理
假死对象是 Unity 内存管理中最隐蔽的陷阱之一。一个对象被 Destroy 后，C# 引用仍然指向一个"看起来有效"的对象（== 返回 true 因为 Unity 重载了运算符），但实际上原生对象已经不存在。
检测假死对象的方法是使用 Unity 的 == 运算符。如果 obj == null 返回 true，说明对象要么是真正的 null，要么是假死状态。如果需要区分这两种情况，可以使用 (object)obj == null，这在假死状态下返回 false。
处理假死对象的最佳实践是在 Destroy 后立即将引用置为 null。这样可以确保 GC 在下次回收周期中回收这个包装对象，减少托管堆的无用占用。
4.2 场景切换后残留引用的危害
场景切换后，旧场景中的所有 GameObject 和 Component 都被 Destroy，但它们通过字段、属性、字典等持有的 C# 引用仍然存在于托管堆上。这些残留引用阻止 GC 回收包装对象，更重要的是，它们可能持有对已销毁原生对象的引用，导致访问时的运行时错误。
一个典型的场景是：在场景 A 中加载一个 Texture2D 并缓存在字段中。切换到场景 B 后，场景 A 被销毁，Texture2D 的原生对象被释放。但缓存字段仍然指向这个 Texture2D 的 C# 包装对象。当在场景 B 中尝试使用这个纹理时，会访问到已销毁的原生对象，导致渲染异常或崩溃。
4.3 DontDestroyOnLoad 的内存影响
DontDestroyOnLoad 的对象在场景切换时不会被 Destroy，其引用的资源也不会被 UnloadUnusedAssets 回收。这意味着 DontDestroyOnLoad 持有的所有资源常驻内存，直到对象被显式销毁。
DontDestroyOnLoad 的内存影响在以下场景中特别严重：将包含大量纹理的 GameObject 标记为 DontDestroyOnLoad，这些纹理将永远驻留在显存中。将包含大量子对象的场景根节点标记为 DontDestroyOnLoad，整个场景的内存将常驻。
五、最佳实践的深度实践
5.1 安全清理模式
安全清理模式的核心是在 Destroy 后立即将引用置为 null。这个简单的动作确保了 GC 可以在下次回收周期中回收包装对象，减少托管堆的无用占用。对于泛型场景，可以封装一个通用的 SafeDestroy 方法，自动处理 Destroy 和 null 赋值。
5.2 引用清理的生命周期钩子
在 MonoBehaviour 的生命周期中，OnDisable 和 OnDestroy 是清理引用的最佳时机。OnDisable 在场景切换或对象禁用时调用，此时可以主动清理缓存的资源引用。OnDestroy 作为兜底清理，确保即使 OnDisable 未被调用（如应用崩溃），引用也能被清理。
5.3 DontDestroyOnLoad 的正确使用
DontDestroyOnLoad 应该仅用于真正的单例对象，如 AudioManager、GameManager、NetworkManager 等。这些对象应该只持有管理器引用，不持有资源数据。将资源数据（纹理、音频、预制体）与管理器分离，可以让资源数据在场景切换时被正常卸载，而管理器保持存活。
5.4 僵尸对象的监控
僵尸对象是 Destroy 了原生但 C# 包装仍存在的情况。它们占用 GC 的标记时间------GC 会在标记阶段扫描它们，发现它们已假死，跳过它们。大量僵尸对象会拖慢 GC 标记速度。
监控僵尸对象的方法是使用 Resources.FindObjectsOfTypeAll 获取所有指定类型的对象，然后检查每个对象的存活状态。统计假死对象的数量和增长趋势，可以帮助发现引用清理不彻底的问题。
六、原生对象生命周期的监控
6.1 实时对象计数监控
实时查看场景中某类型原生对象的数量，可以使用 Resources.FindObjectsOfTypeAll 方法。通过定期调用这个方法并统计存活和假死对象的数量，可以监控对象的生命周期健康度。
如果假死对象数量持续增长，说明很多对象被 Destroy 但 C# 包装未被 GC 回收------可能存在泄漏的 C# 引用阻止 GC 回收。这种情况下，应该检查代码中是否有在 Destroy 后未将引用置为 null 的情况。
6.2 生命周期监控的工程化
将生命周期监控集成到性能分析框架中，定期（如每秒一次）统计各类原生对象的数量，输出报告。当某类对象的数量超过预期阈值时，输出警告日志，提示开发者检查相关代码。
在编辑器中，可以显示一个实时面板，展示各类原生对象的存活数量、假死数量、增长趋势。这帮助开发者在开发阶段就发现生命周期管理问题，而非等到线上用户遇到内存问题时才追溯。
七、总结
UnityEngine.Object 有 C# 托管包装和 C++ 原生对象双重身份。Destroy 销毁原生对象，GC 回收包装。使用 null == 检查假死状态，OnDestroy 中清理引用。
理解双重管理模型是 Unity 内存管理的基础。每个 UnityEngine.Object 的生命周期都涉及两个独立的回收机制：引擎生命周期协议和托管 GC 的可达性回收。只有同时管理好这两个机制，才能真正控制内存使用。
工程实践建议：在 Destroy 后立即将引用置为 null，在 OnDisable 和 OnDestroy 中清理缓存引用，DontDestroyOnLoad 仅用于真正的单例，定期监控僵尸对象数量。将这些实践纳入代码审查流程，从源头上减少内存问题。
6.3 长期持有包装对象的真实成本
Unity 常见的 Boehm 系列收集器不是 CoreCLR 的分代收集器，不能用包装对象晋升到 Gen2 来解释其成本。长期保留已销毁对象的托管包装，会扩大仍然可达的对象图，还可能通过组件字段间接保留其他业务对象。应通过引用链确认真正的持有者，并清理事件、静态集合和异步状态。
6.4 原生对象池的设计与实现
对象池是减少原生对象创建销毁频率的有效手段。对于频繁创建销毁的 GameObject（如子弹、粒子效果），使用对象池可以显著降低 GC 压力。对象池的核心思想是：不真正销毁对象，而是将其隐藏并放入池中，下次需要时重新激活。
对象池的 GC 影响分析：对象池在启动时分配所有池化对象的引用，产生一次性的 GC 分配。在运行时，对象的激活和隐藏不产生 GC 分配（因为对象已经存在，只是改变激活状态）。与频繁创建销毁相比，对象池将 N 次创建销毁的 GC 分配减少为零。但对象池也增加了常驻内存占用，因为池化对象始终存在于场景中。
对象池的设计要点包括：预分配池大小，避免运行时动态扩容产生 GC 分配。为不同类型的对象使用不同的池，避免类型混用导致的资源浪费。在对象激活时重置状态，确保不会携带上一个使用周期的残留数据。
假空值与生命周期测试
UnityEngine.Object 的空值比较包含引擎语义；原生对象已销毁时，托管包装仍可能存在。ReferenceEquals 检查的是托管引用本身，和重载的相等比较回答不同问题。空条件运算符和空合并运算符也不能替代 Unity 的对象有效性检查。审查工具如果只搜索"是否判空"，很容易漏掉这类语义差异。
设计测试时，应分别保留组件引用、普通 object 引用以及静态集合引用，销毁原生对象后观察各自的状态。不要依靠捕获异常作为常规控制流，应让资源持有者知道对象何时失效。对跨帧回调，还要携带业务代号：池对象被归还再复用后，旧回调看到的对象可能仍然有效，却已经属于另一轮使用。
对象池的激活回调可能订阅事件、创建集合或启动协程，因此 SetActive 不等于整个业务调用链零分配。池的验证应同时覆盖初次使用、重复使用和清空销毁；除了观察分配，还应确认旧目标引用、协程和定时器都已解除。