内存管理

原书边界：Chapter 8

Packt 第三版把本章命名为 Masterful Memory Management。官方目录列出的核心范围如下；这些条目共同构成本章的一对一边界：

• The Mono platform：纳入本章实验与验收，不拆到别章重复计数。
• Code compilation：纳入本章实验与验收，不拆到别章重复计数。
• Profiling memory：纳入本章实验与验收，不拆到别章重复计数。
• Memory management performance enhancements：纳入本章实验与验收，不拆到别章重复计数。

区分托管堆、原生对象、显存、临时分配与资产引用链，分别测驻留量、分配率、峰值和回收停顿。IL2CPP、增量 GC 与新版 Memory Profiler 改变工具和停顿形态，但装箱、闭包、字符串、对象池和引用生命周期仍需证据。 因此，本章既保留 2019/2020 语境，也明确标出迁移到现代 Unity 时哪些是稳定原理、哪些只是版本相关接口。

内存是隐形的天花板

上一章你对 GPU 帧预算数着毫秒省，帧率稳住了。可玩家切了几个场景后——游戏闪退了。打开 Memory Profiler，纹理几十兆、Animation 也占了一大片，GC.Collect 每隔几秒就来一次，帧时间图上锯齿扎眼。

渲染优化让你的画面跑得足够快，内存管理让游戏跑得足够久。没有它，再流畅的画面也会在「切关那一帧」卡死或被系统 OOM 杀掉。这章解决的核心问题：每一帧 new 了谁、栈上还是堆上、什么时候回收、谁还拽着不放。

像图书馆：书只能借，不能撕

想象一座图书馆。每次「要一本书」——你跑印刷厂排一本新的（= new / Instantiate），看完扔掉、次日又来排一本同名的——印刷厂排队的成本远超借书本身。

Unity 托管堆就是图书馆书架：书（对象）有借有还（GC 回收），但还书前占据书架空间。对象池相当于「把热门书复印若干本锁在柜台」——借时取、用完还，不再进印刷厂。内存泄漏则是书被借走但永远不还——书架渐渐堆满旧书，新书无处置放。

Mono vs IL2CPP：托管内存跑在哪

Unity 有两套脚本运行时，它们对内存从哪里来、何时回收有根本区别。

Mono 曾是 Unity 的默认脚本后端。C# 编译为 IL、运行时由 JIT 即时翻译成机器码；GC 是经典的 Boehm GC ——每次回收全线程暂停（Stop-The-World），扫描所有托管对象，甚至因「保守式扫描」可能误判某些值为指针而不回收它们。

IL2CPP 是 Unity 当前的默认后端。构建时 IL → C++ → 平台原生代码 AOT，运行时不再有 JIT 开销；GC 可选 增量模式，分步执行而非一次性全暂停。

为什么移动端只用 IL2CPP

iOS App Store 禁止 JIT（代码段不可写），Mono 直接不可用。Android 上 IL2CPP 的 AOT 省去 JIT 预热与内存；增量 GC 比 Boehm 更可预测帧时间。桌面/编辑器仍可能用 Mono，但打包移动端和 Console 必须 IL2CPP。

GC：分配、标记、清除

无论 Mono 还是 IL2CPP，托管堆的 GC 逻辑大同小异：对象在托管堆分配 → 堆满触发 GC → 标记存活对象 → 清除未引用的 → 整理碎片。

为什么每帧 new 一个 List 是灾难

// ❌ 每帧产生 GC.Alloc
void Update() {
    var hits = new List<RaycastHit>(Physics.RaycastAll(ray));
    // ... 用完 hits 被丢弃 → 下次 GC 回收
}

RaycastAll 返回的 RaycastHit[] 和 new List<RaycastHit> 都是托管堆分配。60 FPS 下每秒 120 次分配——GC.Collect 大约几百 KB 触发，几秒就一次全暂停。

// ✅ 缓存 + NonAlloc API
private RaycastHit[] m_Hits = new RaycastHit[32];
 
void Update() {
    int count = Physics.RaycastNonAlloc(ray, m_Hits);
    for (int i = 0; i < count; i++) { /* 使用 m_Hits[i] */ }
}

RaycastNonAlloc 写入预分配的 m_Hits 数组，零托管分配。List<T> 可用 .Clear() 复用而非重新 new；字符串拼接换 StringBuilder（缓存实例并每次 Clear()）。

对象池：一次预热，零分配

对象池（Object Pooling） 是对「不停 new → GC 回收 → 再 new」的根本解法：一次预热，此后 Get 与 Return 零分配。

通用对象池骨架

public class ObjectPool<T> where T : Component {
    private Queue<T> m_Pool = new Queue<T>();
    private T m_Prefab;
 
    public ObjectPool(T prefab, int prewarm) {
        m_Prefab = prefab;
        for (int i = 0; i < prewarm; i++) AddToPool();
    }
 
    void AddToPool() {
        var obj = Object.Instantiate(m_Prefab);
        obj.gameObject.SetActive(false);
        m_Pool.Enqueue(obj);
    }
 
    public T Get() {
        T obj = m_Pool.Count > 0 ? m_Pool.Dequeue() : Object.Instantiate(m_Prefab);
        obj.gameObject.SetActive(true);
        return obj;
    }
 
    public void Return(T obj) {
        obj.gameObject.SetActive(false);
        m_Pool.Enqueue(obj);
    }
}

预热 N 个实例，Get() 取活跃、Return() 退回池——二者均为 O(1)。若池耗尽，自动 Instantiate 扩容；Return 过多按需缩容或设上限。

什么应该进池

必须进池：子弹/弹幕、粒子 (ParticleSystem)、敌人/NPC、UI 列表项。这些每帧大量创建/销毁，不进池 = 每帧几十次 GC.Alloc。

不需要进池：场景唯一的主角、UI 主面板、背景音乐源——生命周期与关卡等长、创建一次用完即弃。

Unity 2021+ 内置 UnityEngine.Pool.ObjectPool<T>（IObjectPool<T> 接口），集成了 Get/Release 与自动扩容缩容，推荐优先使用。

纹理与网格内存

美术资源导入时的开关——Read/Write、MipMap、Max Size、Compression——直接决定运行时内存翻几倍。

Texture Read/Write Enabled 保留一份 CPU 可写像素副本，内存约为不开启时的两倍。纯渲染纹理应关闭——只有运行时 Texture2D.SetPixels、ReadPixels 或部分后处理才需要。

Generate Mip Maps 对远处物体减少闪烁并降低显存带宽，但额外占用约 33% 内存。UI、Sprite Atlas 平面元素不需要 mipmap。

Mesh Read/Write Enabled 同样适用：除运行时改 mesh.vertices 的网格外，一律关闭。MeshCollider 烘焙完成后也应关闭。

动手：内存泄漏五步排查

下面走通「内存持续增长 → 定位保留对象 → 找出谁拽着不放」的全流程。每步配示意图示——建议打开 Memory Profiler + 一个「切关后内存不降」的场景同步操作。

猜一猜：切出 MainMenu、再切回 GameScene，纹理内存翻倍——是 AssetBundle 未 Unload、Read/Write 没关、还是静态事件未注销？

容易踩的坑

小结

• Mono JIT + Boehm GC（全暂停）vs IL2CPP AOT + 增量 GC——移动端必须 IL2CPP
• GC 三阶段 Mark → Sweep → Compact；每帧 new 临时对象 = GC.Alloc 热点 → 帧时间抖动
• 对象池 预热后 Get/Return 零分配；子弹/粒子/敌人类必须进池，Unity 2021+ 内置 ObjectPool<T>
• 纹理/网格：Read/Write 默认关、3D 纹理开 mipmap/UI 关、Max Size 按用途设、平台选 ASTC/ETC2
• 泄漏排查：Memory Profiler 快照对比 → 静态引用/事件 → AssetBundle Unload → 对象池归还