Unity 内存全景
篇章 ：01-认知篇
阅读时间 ：约 35 分钟
前置知识：了解 Unity 基本架构
一、引言
在深入讨论 GC 之前，我们必须先建立一个完整的"内存地图"。很多开发者在分析 GC 问题时，之所以会得出错误的归因结论，根本原因在于他们只看到了内存的一个切面------通常是托管堆（Managed Heap），却忽略了 Unity 引擎中还有原生内存、引擎内部分配以及 GPU 显存这三个同样重要的层面。GC 只负责管理托管堆，但性能问题往往发生在四层内存的交互边界上。
理解 Unity 的四层内存模型，是正确进行 GC 性能归因的前提条件。如果你不知道一段内存属于哪一层，你就无法判断它是否受 GC 管辖，也就无法判断 GC 是否应该为某个性能问题负责。本文将从架构层面逐层拆解 Unity 的内存体系，并重点分析各层之间的交互边界------这些边界正是性能问题的高发区域。
二、Unity 的四层内存模型
Unity 引擎的内存体系可以划分为四个层次：托管内存（Managed Memory） 、原生内存（Native Memory） 、引擎内存（Engine Memory） 和 GPU 显存（Video Memory）。这四层并非简单的线性叠加，而是存在复杂的引用关系和生命周期依赖。
| 层次 | 管理者 | 分配方式 | GC 是否管辖 | 典型内容 |
|---|---|---|---|---|
| 托管内存 | Mono/IL2CPP 运行时 | new / Instantiate |
✅ 是 | C# 对象、脚本数据 |
| 原生内存 | C++ malloc/new | 手动管理 | ❌ 否 | Mesh、Texture、AudioClip 数据 |
| 引擎内存 | Unity 内部分配器 | 对象池/缓存 | ❌ 否 | AssetBundle、Scene、GameObject 树 |
| GPU 显存 | 图形 API | 上传/释放 | ❌ 否 | 顶点缓冲、纹理、RenderTexture |
这四层内存的生命周期各不相同。托管内存由 GC 自动回收，原生内存由引擎的 C++ 层手动管理，引擎内存通过 Resources.UnloadAsset 或场景卸载来释放，GPU 显存则依赖资源上传/卸载的显式调用。理解这种分层关系，是避免将非 GC 问题错误归因于 GC 的关键。
一个常见的误解是：只要内存增长，就是 GC 没有及时回收。实际上，在 Unity 项目中，托管堆通常只占总内存的 20%-40%，大部分内存消耗发生在原生层和 GPU 层。如果你的 Profiler 显示总内存持续增长，但托管堆大小稳定，那么问题几乎可以确定不在 GC 身上。
三、托管内存（Managed Memory）
托管内存是 GC 唯一直接管理的内存层。在 Unity 中，托管内存由 Mono 运行时（Mono 后端）或 IL2CPP 运行时（IL2CPP 后端）负责分配和回收。所有 C# 脚本中通过 new 关键字创建的对象，都会分配在托管堆上。
托管堆的核心特征是连续地址空间。GC 通过维护一个连续的堆空间来管理对象分配，当空间不足时触发垃圾回收。这种连续性带来了一个重要的副作用：即使你释放了大量小对象，如果堆中存在存活的大对象，堆的大小也无法自动缩小。这就是所谓的"堆碎片化"问题------已释放的内存空间被存活对象分割成碎片，无法被有效利用，导致堆只增不减。
在 Unity 中，托管堆的分配行为有几个值得注意的特点。首先，Instantiate 创建的 GameObject 会在引擎层分配，但其上挂载的 C# 组件实例则分配在托管堆上。其次，foreach 迭代器在某些 Unity 版本中会产生额外的堆分配（装箱分配），这是性能优化中常被提及的"foreach 陷阱"。最后，闭包（lambda 捕获变量）和协程（Coroutine）也会产生隐式的托管堆分配。
托管堆的大小直接影响 GC 的停顿时间。堆越大，GC 需要扫描的对象越多，标记-清除阶段耗时越长。因此，控制托管堆大小不仅是内存优化的问题，更是 GC 性能优化的核心策略之一。在 Unity Profiler 中，你可以通过 "Memory" 面板查看 "GC Alloc" 列来追踪每帧的托管堆分配量，这是定位 GC 压力来源的第一手数据。
四、原生内存（Native Memory）
原生内存是 Unity 引擎底层 C++ 代码分配的内存，完全不受 GC 管辖。这包括 Mesh 的顶点数据、Texture 的像素数据、AudioClip 的音频数据等。这些数据通过 Unity 的 C++ 层分配和管理，C# 侧只持有对这些原生对象的引用（wrapper 对象）。
原生内存的管理方式与托管内存截然不同。原生资源的生命周期由引用计数和显式卸载共同管理。当你调用 Object.Destroy() 时，引擎层的原生数据会被标记为待释放，但实际的内存释放可能延迟到当前帧结束后。而 Resources.UnloadUnusedAssets() 则会扫描所有原生资源，释放引用计数为零的资源。
一个关键的理解点是：C# 侧的 wrapper 对象（如 Texture2D 的 C# 实例）被 GC 回收，并不意味着原生数据也被释放。反之，原生数据被卸载后，C# wrapper 对象可能仍然存在于托管堆上，只是其内部指针已失效。这种"生命周期不同步"是导致 MissingReferenceException 的常见原因，也是内存泄漏的隐蔽来源。
原生内存的另一个重要特征是它不参与 GC 的标记-清除过程。这意味着即使原生内存占用很大，也不会直接增加 GC 的停顿时间。但是，如果 C# 侧存在大量 wrapper 对象（例如数千个 Material 实例），这些 wrapper 本身作为托管对象会参与 GC 标记，间接增加 GC 扫描成本。因此，控制原生资源的 C# wrapper 数量，也是 GC 优化的一个间接手段。
五、引擎内存（Engine Memory）
引擎内存是 Unity 内部运行所需的内存，包括场景图（Scene Graph）、GameObject 层级树、组件系统、物理引擎内部数据、动画系统状态等。这部分内存由 Unity 引擎自行管理，使用对象池和缓存策略来优化分配效率。
引擎内存的分配模式与托管堆不同。Unity 内部大量使用对象池技术------GameObject、Component 等对象在销毁后并不立即释放内存，而是回收到池中等待复用。这就是为什么 Instantiate/Destroy 频繁操作时，内存不会持续增长的原因。但这种设计也意味着引擎内存的"水位线"由峰值使用量决定，而非平均使用量。
AssetBundle 是引擎内存的重要组成部分。加载的 AssetBundle 会驻留在内存中，直到显式调用 AssetBundle.Unload()。一个常见的内存陷阱是：Unload(false) 只卸载 AssetBundle 的压缩数据，但保留已加载的资源；Unload(true) 则同时卸载资源和压缩数据。如果使用 Unload(false) 后忘记手动释放资源，就会造成资源级别的内存泄漏。
引擎内存与 GC 的关系是间接的。当场景中的 GameObject 数量增加时，引擎需要维护更多的组件引用关系，这些引用关系中的 C# 侧部分（如 MonoBehaviour 的 C# 实例）会增加托管堆的压力。因此，场景复杂度不仅影响引擎内存，也会通过组件实例间接影响 GC 的工作量。
六、GPU 显存（Video Memory）
GPU 显存是四层内存中最"远离"GC 的一层。它存储着上传到显卡的顶点缓冲区（VBO）、索引缓冲区（IBO）、纹理、RenderTexture、Shader 常量缓冲等。GPU 显存的分配和释放完全由图形 API（OpenGL/Vulkan/Metal/D3D）管理，GC 无法触及。
GPU 显存与托管内存的交互主要通过"上传"操作发生。当你在 C# 中创建一个 Texture2D 并调用 Apply() 时，像素数据从 CPU 侧（原生内存）上传到 GPU 侧（显存）。这个上传过程本身不产生托管堆分配，但 Texture2D 的 C# wrapper 对象存在于托管堆上。当 wrapper 被 GC 回收时，如果没有显式调用 Texture2D 的释放方法，GPU 显存可能不会被及时释放。
RenderTexture 是 GPU 显存管理的另一个重点。每个 RenderTexture 都会在 GPU 上分配一块显存，如果创建后忘记 Release()，就会造成显存泄漏。在移动平台上，显存极其有限（可能只有几百 MB），RenderTexture 的泄漏会迅速导致 OOM 崩溃。
| GPU 资源类型 | 显存占用估算 | 释放方式 | 常见泄漏场景 |
|---|---|---|---|
| Texture2D | 宽×高×像素字节 | Destroy() |
动态创建后未释放 |
| RenderTexture | 宽×高×格式字节 | Release() + Destroy() |
后处理 RT 未释放 |
| Mesh | 顶点数×顶点stride | Destroy() |
运行时生成 Mesh 未释放 |
| ComputeBuffer | count×stride | Release() |
GPU Skinning 缓冲未释放 |
| Material | 较小（引用Shader） | Destroy() |
new Material(shader) 未释放 |
七、四层内存的边界与交互
四层内存之间的交互边界是性能问题的高发区域。理解这些边界如何交互，是进行正确性能归因的核心能力。
托管 ↔ 原生边界 ：这是最频繁的交互边界。每次 C# 代码访问原生资源（如读取 Mesh.vertices），都会发生跨边界的数据 marshaling。这种 marshaling 可能产生临时数组分配在托管堆上，成为隐性的 GC 压力来源。例如，mesh.vertices 属性的 getter 会在每次调用时创建一个新的 Vector3[] 数组并复制数据，这个数组分配在托管堆上，成为 GC 需要扫描的对象。优化建议是缓存这些数组引用，避免每帧重复访问。
原生 ↔ GPU 边界 ：这个边界的数据传输通过图形 API 完成。纹理上传、顶点缓冲更新等操作会通过 GL.texImage2D 或等效 API 将数据从 CPU 侧传输到 GPU 侧。这个过程不涉及 GC，但如果上传频率过高（如每帧更新动态纹理），会造成 CPU 侧的带宽瓶颈，间接影响帧率。
托管 ↔ 引擎边界 ：GameObject 的创建、组件的添加/移除、场景的加载/卸载都跨越这个边界。Instantiate 在引擎层创建 GameObject 树，同时在托管堆上创建组件的 C# 实例。Destroy 则先标记引擎层对象为待销毁，C# 侧的 wrapper 在下一帧 GC 时才可能被回收。这种延迟回收机制意味着：即使你调用了 Destroy，托管堆上的组件实例仍会在短时间内存活，继续被 GC 标记。
引擎 ↔ GPU 边界：场景渲染时，引擎从引擎内存中读取场景图数据，将需要渲染的资源提交到 GPU。这个过程涉及渲染排序、合批（Batching）、Draw Call 提交等操作。如果场景中存在大量小 Mesh 无法合批，会导致 Draw Call 数量激增，虽然这不直接影响 GC，但会影响整体帧率，间接影响 GC 的可用时间窗口。
八、内存分析工具与查看方法
Unity 提供了多种工具来分析四层内存的使用情况，正确使用这些工具是定位内存问题的关键。
Profiler Memory 面板：这是最基础的内存分析工具。它按类别显示内存使用情况，包括 "GC Alloc"（托管堆分配）、"Used Heap"（已用托管堆）、"Total Objects in Scene"（场景对象数）等指标。关键是要关注 "GC Alloc" 列------如果某帧的 GC Alloc 不为零，说明该帧有托管堆分配，这是 GC 压力的直接来源。
Memory Profiler（Package）：这是更强大的内存分析工具，可以生成内存快照（Snapshot）并进行对象级别的分析。它可以显示托管堆中每种类型的对象数量和大小，帮助定位内存泄漏和堆碎片化问题。通过对比两个时间点的快照，可以精确找到哪些对象在增长。
Frame Debugger：虽然主要用于渲染分析，但 Frame Debugger 可以帮助你理解 GPU 显存的使用模式。通过查看 Draw Call 序列，你可以判断是否有不必要的资源上传或冗余的渲染状态。
| 工具 | 主要用途 | 关注指标 | 适用层次 |
|---|---|---|---|
| Profiler Memory | 帧级内存概览 | GC Alloc, Used Heap | 托管/引擎 |
| Memory Profiler | 堆快照分析 | 对象数量, 引用链 | 托管/原生 |
| Frame Debugger | 渲染调试 | Draw Call, SetPass | GPU/引擎 |
| Platform Profiler | 原生内存 | Total Allocated | 原生/GPU |
GC.GetTotalMemory |
运行时代码查询 | 托管堆字节数 | 托管 |
在实际分析中，建议遵循"从宏观到微观"的路径：先用 Profiler Memory 确认问题出在哪一层（托管堆增长？原生内存增长？GPU 显存增长？），再用对应层级的工具深入分析。如果托管堆稳定但总内存增长，问题在原生层或 GPU 层，与 GC 无关；如果托管堆持续增长且 GC 频繁触发，则需要用 Memory Profiler 找出泄漏对象。
九、总结
Unity 的四层内存模型------托管、原生、引擎、GPU------构成了一个复杂的内存生态系统。GC 只负责其中一层（托管内存），但四层之间的交互边界会产生间接的 GC 压力。理解这个模型的核心要点是：
- GC 只管托管堆：不要将原生内存或 GPU 显存的问题归因于 GC。
- 边界交互产生隐性分配 ：跨边界的数据访问（如
mesh.vertices）会在托管堆上产生临时分配。 - 生命周期不同步：C# wrapper 和原生数据的生命周期不同步，是内存泄漏的常见原因。
- 工具分层使用：根据问题所在的内存层选择合适的分析工具。
掌握了这个全景模型，我们才能在后续章节中正确地进行 GC 性能归因------区分哪些问题真正是 GC 的责任，哪些是使用方式的问题，哪些根本与 GC 无关。