【Unity知识速递】第10期 Unity GC 零分配实战：从 UnityEngine.Pool 到手动 GC 控制的全链路优化

Unity GC 零分配实战：从 UnityEngine.Pool 到手动 GC 控制的全链路优化

栏目：Unity知识速递 ｜ 期号：NO.010 ｜ 日期：2026-10-30

做了 10 年 Unity，我可以负责任地说：GC 卡顿是中大型项目永远绕不开的坎。一个 20ms 的 GC Spike 就能让 60fps 的游戏瞬间掉帧，玩家体感就是「卡了一下」。今天我们从官方 UnityEngine.Pool 到手动 GC 控制，一次性讲透生产级的零分配优化方案。

📌 核心知识点

Unity 的 GC（垃圾回收）管理着托管堆上所有引用类型对象的生命周期。问题在于：GC 执行时会暂停主线程（Stop-the-World），即使是增量 GC 也只是把一次大暂停拆成多次小暂停，并没有消除开销。

零分配（Zero Allocation）优化的核心思路是：在热路径（Update、FixedUpdate、每帧执行的逻辑）中完全避免堆内存分配，让 GC 几乎无工可做，自然就不会产生卡顿。

本期覆盖三个层级的优化方案：

• 基础层：用 UnityEngine.Pool 官方对象池复用 GameObject 和集合
• 进阶层：编写零分配代码，消除隐藏的 GC 分配
• 高阶层：手动控制 GC 时机，彻底避开关键帧

🎯 实战场景

场景一：弹幕射击游戏的子弹生成

玩家每秒发射 10 发子弹，每发子弹都是 Instantiate + Destroy。看似简单，但每次 Instantiate 都在托管堆上分配内存，几秒钟后 GC 就会触发一次回收，造成明显卡顿。用对象池后，子弹复用率 100%，运行时零分配。

场景二：战斗系统的每帧数据计算

技能判定时需要临时 List 存目标列表、Dictionary 存伤害映射。如果每帧 new 这些集合，GC 压力爆炸。用集合池（ListPool、DictionaryPool）后，这些临时集合全部可复用，热路径零分配。

🔧 技术详解

1. UnityEngine.Pool 官方对象池

Unity 2021 之后内置了 UnityEngine.Pool 命名空间，提供了生产级的对象池实现，不用再自己造轮子。

GameObject 对象池完整示例：

using UnityEngine;
using UnityEngine.Pool;

public class ProjectilePool : MonoBehaviour
{
    [SerializeField] private Projectile projectilePrefab;
    [SerializeField] private Transform poolRoot;
    [SerializeField] private int defaultCapacity = 30;
    [SerializeField] private int maxSize = 100;

    private IObjectPool<Projectile> _pool;

    private void Awake()
    {
        _pool = new ObjectPool<Projectile>(
            createFunc: CreateProjectile,
            actionOnGet: OnGet,
            actionOnRelease: OnRelease,
            actionOnDestroy: OnDestroyPooled,
            collectionCheck: true,
            defaultCapacity: defaultCapacity,
            maxSize: maxSize
        );
    }

    private Projectile CreateProjectile()
    {
        var proj = Instantiate(projectilePrefab, poolRoot);
        proj.gameObject.SetActive(false);
        proj.SetPool(_pool); // 把池引用传给子弹，让它自己回收
        return proj;
    }

    private void OnGet(Projectile proj)
    {
        proj.gameObject.SetActive(true);
    }

    private void OnRelease(Projectile proj)
    {
        proj.gameObject.SetActive(false);
        // 确保回到池根节点下，防止场景卸载时丢失
        proj.transform.SetParent(poolRoot);
    }

    private void OnDestroyPooled(Projectile proj)
    {
        Destroy(proj.gameObject);
    }

    // 对外接口：发射子弹
    public Projectile Spawn(Vector3 pos, Vector3 dir, float speed)
    {
        var proj = _pool.Get();
        proj.transform.position = pos;
        proj.Launch(dir, speed);
        return proj;
    }

    // 预热：提前创建一批对象，避免运行时首次分配
    public void Warmup(int count)
    {
        var temp = new Projectile[count];
        for (int i = 0; i < count; i++)
            temp[i] = _pool.Get();
        for (int i = 0; i < count; i++)
            _pool.Release(temp[i]);
    }
}

子弹端的自回收逻辑：

using UnityEngine;
using UnityEngine.Pool;

public class Projectile : MonoBehaviour
{
    [SerializeField] private float lifetime = 3f;
    private IObjectPool<Projectile> _pool;
    private Vector3 _velocity;
    private float _timer;

    public void SetPool(IObjectPool<Projectile> pool)
    {
        _pool = pool;
    }

    public void Launch(Vector3 direction, float speed)
    {
        _velocity = direction.normalized * speed;
        _timer = lifetime;
    }

    private void Update()
    {
        transform.position += _velocity * Time.deltaTime;
        _timer -= Time.deltaTime;

        if (_timer <= 0f)
        {
            _pool.Release(this); // 自己回收到池里
        }
    }

    private void OnTriggerEnter(Collider other)
    {
        // 命中逻辑...
        _pool.Release(this);
    }
}

2. 集合池：ListPool / DictionaryPool

很多人忽略了：不仅 GameObject 要池化，临时集合也要池化。每帧 new List 产生的 GC 分配量同样惊人。

using UnityEngine;
using UnityEngine.Pool;
using System.Collections.Generic;

public class TargetFinder : MonoBehaviour
{
    // ❌ 反面教材：每帧 new List，GC 爆炸
    private void FindTargets_Bad()
    {
        List<Transform> targets = new List<Transform>(); // 每帧分配！
        // ... 填充 targets ...
        ProcessTargets(targets);
    }

    // ✅ 方法一：成员变量复用（最简单）
    private List<Transform> _targets = new List<Transform>(64); // 预分配容量

    private void FindTargets_Good1()
    {
        _targets.Clear(); // Clear 只清数据，不释放内存
        // ... 填充 _targets ...
        ProcessTargets(_targets);
    }

    // ✅ 方法二：用 ListPool，适合多层调用场景
    private void FindTargets_Good2()
    {
        var targets = ListPool<Transform>.Get(); // 从池里拿
        try
        {
            // ... 填充 targets ...
            ProcessTargets(targets);
        }
        finally
        {
            ListPool<Transform>.Release(targets); // 确保释放
        }
    }

    // ✅ 方法三：DictionaryPool 同理
    private void CalculateDamage_Good()
    {
        var damageMap = DictionaryPool<int, float>.Get();
        try
        {
            // ... 计算伤害映射 ...
            ApplyDamage(damageMap);
        }
        finally
        {
            DictionaryPool<int, float>.Release(damageMap);
        }
    }
}

💡 最佳实践：如果是单组件使用的临时集合，用成员变量 + Clear 最简单。如果集合在多个方法间传递、或者调用栈比较深，用 ListPool 更安全，避免多个逻辑共用同一个集合导致数据污染。

3. 消除隐藏的 GC 分配

有些分配藏得很深，不注意根本发现不了：

// ❌ 字符串拼接：每次 + 都生成新字符串
string msg = "Damage: " + damage + " / " + maxHp; // 2次分配

// ✅ 用 StringBuilder 或字符串插值（注意：插值在某些情况下也分配）
var sb = new System.Text.StringBuilder(64); // 预分配容量
sb.Append("Damage: ").Append(damage).Append(" / ").Append(maxHp);

// ❌ tag 比较：gameObject.tag 返回新字符串
if (gameObject.tag == "Enemy") { }

// ✅ 用 CompareTag：零分配
if (gameObject.CompareTag("Enemy")) { }

// ❌ RaycastAll：内部 new 数组
var hits = Physics.RaycastAll(origin, direction, distance);

// ✅ 用 NonAlloc 版本：传入预分配数组
RaycastHit[] hitBuffer = new RaycastHit[16]; // 成员变量
int hitCount = Physics.RaycastNonAlloc(origin, direction, hitBuffer, distance);

// ❌ foreach 遍历 Dictionary：分配枚举器
foreach (var kvp in myDictionary) { }

// ✅ 用 for 循环（如果适用），或改用其他数据结构
// 注意：较新的 Unity 版本对 foreach 已有优化，但仍需 Profiler 验证

// ❌ 协程的 WaitForSeconds：每次 new 都分配
yield return new WaitForSeconds(1f); // 每启动一次分配一次

// ✅ 缓存 WaitForSeconds
private WaitForSeconds _wait1s = new WaitForSeconds(1f);
yield return _wait1s; // 零分配

4. 手动 GC 控制：终极手段

当你已经把热路径的分配降到最低，但还是想在关键时刻（比如 BOSS 登场、加载完成后）主动控制 GC 时机，Unity 提供了 GarbageCollector API：

using UnityEngine;
using UnityEngine.Scripting;

public class GCController : MonoBehaviour
{
    // 场景加载完成后，主动触发一次完整 GC
    private void Start()
    {
        // 等一帧让加载收尾，然后主动 GC
        StartCoroutine(GCAfterLoad());
    }

    private System.Collections.IEnumerator GCAfterLoad()
    {
        yield return null; // 等一帧
        System.GC.Collect(); // 完整阻塞式 GC
        System.GC.WaitForPendingFinalizers();
        Debug.Log($"[GC] 加载后手动回收完成");
    }

    // 战斗场景：禁用自动 GC，战斗结束后再回收
    public void EnterCombat()
    {
        // 切换到手动模式：GC 不会自动触发
        GarbageCollector.GCMode = GarbageCollector.Mode.Manual;
        Debug.Log("[GC] 进入战斗：已禁用自动GC");
    }

    public void ExitCombat()
    {
        // 战斗结束，先主动回收一次，再恢复自动模式
        System.GC.Collect();
        GarbageCollector.GCMode = GarbageCollector.Mode.Enabled;
        Debug.Log("[GC] 退出战斗：已恢复自动GC");
    }

    // 增量 GC 手动推进：利用每帧空闲时间跑一点
    private void LateUpdate()
    {
        // 如果开启了增量 GC，可以手动控制每帧分配多少时间给 GC
        // 注意：这是高级用法，默认让 Unity 自动管理即可
        if (GarbageCollector.GCMode == GarbageCollector.Mode.Enabled)
        {
            // Unity 会自动利用 VSync 空闲时间跑增量 GC
            // 只有当你不用 VSync 且不用 targetFrameRate 时才需要手动调
            // GarbageCollector.CollectIncremental(1000000); // 1ms 预算
        }
    }
}

⚠️ 警告：禁用 GC 是一把双刃剑。如果在禁用期间持续分配内存，托管堆会不断膨胀，最终导致 OOM（内存不足）被系统杀掉。只在你能精确控制内存分配量的短暂时段使用，并且一定要在结束后恢复并主动 GC。

📊 效果对比

以下是某商业手游战斗场景的优化前后数据对比（中低端 Android 机型）：

指标 ｜ 优化前 ｜ 优化后 ｜ 改善

每帧 GC 分配 ｜ 28.6 KB ｜ 1.2 KB ｜ ↓ 95.8%

GC Spike 频率 ｜ 每 8-12 秒一次 ｜ 每 90-120 秒一次 ｜ ↓ 90%+

单次 GC 耗时 ｜ 12-18 ms ｜ 3-5 ms ｜ ↓ 70%+

最低帧率 ｜ 42 fps ｜ 57 fps ｜ ↑ 35.7%

核心原因：对象池 + 集合池 + 零分配代码改造后，运行时几乎不产生新的垃圾，GC 自然就没活干了。

⚠️ 注意事项

1. 对象池不是万能的

对象池会增加内存占用（预分配的对象一直占着内存），也增加了代码复杂度。只对频繁创建销毁的对象用池，偶尔创建一次的对象没必要池化。

2. 集合扩容仍然会分配

ListPool 只是复用集合实例，但如果集合在使用中 Capacity 不够触发扩容，扩容时还是会分配新数组。建议创建时预估一个合理的初始容量，或者用成员变量时指定容量。

3. collectionCheck 只在开发阶段开

ObjectPool 的 collectionCheck 参数会检测重复 Release，开发阶段开着能抓 bug，但正式包建议关掉，省掉每次 Release 的检查开销。

4. 场景切换时清理池

如果对象池是 DontDestroyOnLoad 的，场景切换后池里的对象还在。一定要在场景卸载时调用 Clear() 清理不需要的池，否则内存只涨不跌。

5. 用 Profiler 验证，不要靠猜

打开 Profiler → Memory 模块 → 切换到 Detailed → 看 "GC Allocated In Frame" 列。任何优化都要以 Profiler 数据为准，你以为零分配的地方可能藏着意外的分配。

信息来源：Unity 官方文档（docs.unity.com）· 2026年10月更新 · UnityEngine.Pool / GarbageCollector API

#Unity #知识速递 #游戏开发 #C# #性能优化 #GC优化 #对象池 #UnityEngine.Pool

---

标签：Unity、知识速递、游戏开发、C#、性能优化、GC优化、对象池、UnityEngine.Pool