先说我踩过的一个坑。项目帧率统计显示长期贴着60fps跑可玩家一直反馈“操作一多就黏糊糊的”我们自己录屏回放才发现平时挺流畅但每隔十来秒画面会像短暂窒息一样卡一下位置还很随机。当时第一个反应是查渲染、查Shader、查后处理结果Renderer耗时几乎没变化主线程上却冒出一根一根深红色的尖刺——全部指向GC。这是《Unity 卡顿·帧率保卫战》系列的第四篇。前三篇处理了渲染、资源加载和逻辑层的问题这篇专门讲GCGarbage Collection垃圾回收。如果你正在做UI频繁刷新的游戏或者战斗系统里全是飘字、技能指示器、伤害数字这类高频更新逻辑这篇文章尤其对胃口。我会从GC卡顿的底层机制讲起把高频路径上最常见的分配雷区一个个列出来最后用Profiler实际定位一遍并给出能在团队里落地的GC预算管理建议。1. GC这个“隐形杀手”为什么这么难排查1.1 平均帧率骗过了大多数人的眼睛很多团队看性能习惯性盯着平均帧率。60fps项目平均帧时间16.7ms左右大家就觉得“挺稳”。但GC卡顿最迷惑人的一点恰恰就在这里它导致的不是持续掉帧而是周期性尖峰。举个例子一帧正常消耗8ms某一帧因为GC跑出120ms这120ms平均到后面十帧里可能只是让平均帧率从60fps掉到57fps数值变化不大。可玩家的体感完全是另一回事——画面像是被什么东西拽住再突然跳回正常。特别是GC尖峰发生在开箱、战斗结算、技能释放这些玩家注意力最集中的时刻观感会被放大好几倍。所以排查卡顿我一般先不看平均帧率而是直接看帧时间曲线看P99甚至P999。平均帧率是骗人的帧时间的“尖刺分布”才反映真实手感。1.2 托管堆与垃圾回收的基本运行机制先说机制不然后面所有优化都像在隔靴搔痒。你在C#里写的new GameObject()、new Listint()、字符串拼接产生的临时string最终都落在托管堆Managed Heap上。这个堆由运行时Unity用的是Mono或IL2CPP运行时统一管理。当一个对象不再被任何地方引用它就变成了“垃圾”但不会立刻被清除而是等GC来统一回收。Unity的GC实现以标记-清除Mark-Sweep为主整体思路是从根引用静态字段、栈上变量、寄存器出发把整个对象图遍历一遍能到达的对象标记为“活着”遍历结束后没被标记的内存统一回收。这个过程中游戏线程必须停在那里等GC跑完也就是常说的Stop The World停顿。理解这点很重要GC卡顿不是你某个函数写得慢而是运行时在一瞬间把所有逻辑都按了暂停键去收拾内存垃圾。房间里垃圾越多收拾的时间就越长。1.3 为什么它平时隐藏、发作时却惊天动地GC难排查我总结下来有四个原因不报错、不警告。它不像空引用异常那样立即弹出来也不会像显存泄漏那样过一阵子就黑屏。它只是在某个没规律的时刻让帧率跳水一下。性能面板根本不显示。Unity编辑器右下角的Stats只显示帧率、顶点数、绘制调用。GC Alloc这个关键指标藏在Profiler里而且还要切到CPU模块的Hierarchy视图才看得到。发作时机滞后。分配像往桶里倒水GC是桶满才清理。你在A帧分配了一堆对象可能到B帧才触发GC这中间的延迟让“作案现场”和“案发时间”完全错开。容易被误判成渲染问题。很多人看到卡顿第一反应就是优化Shader、降后处理、检查GPU Bound。但GC尖峰的帧时间构成很特别几乎没有GPU时间整段都是主线程卡住Render线程是饿着的。只有理解了这几点你才会明白为什么新手经常对着GC Alloc数据发呆——明明看到了分配却找不到是哪段代码造的孽。2. 一次GC尖刺的完整解剖从一帧分配到大停顿2.1 分配的累积是悄悄发生的先说一个最常见的情况战斗系统里每帧都在刷新技能冷却文本、伤害飘字、血条数值。这种代码往往“看起来没什么问题”因为它分配得很均匀。比如某段刷新逻辑每帧执行一次字符串拼接和几次枚举转字符串单帧分配50KB到100KB。你觉得没事因为100KB对内存来说连九牛一毛都算不上。但算一笔账200KB每帧乘以60帧一秒就是12MB跑一分钟720MB被分配出去。托管堆就算有几百MB水位也很快会被塞满。分配快GC也会来得快。真正的心跳不是你分配了多少而是堆被推到了什么水位。2.2 GC在什么时机触发GC的触发一般有三种情况自动触发运行时检测到托管堆内存分配达到阈值主动跑一次GC。这是绝大多数停顿的来源。手动触发代码里调用了System.GC.Collect()强制立即GC。滥用这个API是很多项目卡顿屁股后面那根隐形鞭子。系统内存压力触发低端Android机上当整个系统的内存都不够用时操作系统会要求正在运行的进程主动释放内存Unity也可能因此触发GC。很多人看Profiler只盯GC发生的帧却忘了GC阈值是运行时自己定的不同平台、不同版本都不一样。编辑器里跑20分钟不卡不代表手机上不卡Mono跑起来没事不代表IL2CPP没事。后面第5章我专门讲真机验证的差异。2.3 Mark-Sweep停顿为什么这么痛理解了标记-清除的原理就能理解为什么GC停顿随对象数量非线性增长标记阶段从根引用出发递归遍历所有可达对象。管你在不在用只要是活着的对象GC都要摸一遍。对象从几千个涨到几十万个标记时间轻松翻几十倍。清除阶段回收不可达对象把空闲内存记录进分配器。如果内存碎片多这一步也不轻松。还有一个坑Unity的GC是非移动式回收也就是说它不会帮你压缩堆里的对象位置。这意味着你反复分配小对象再释放堆可能出现碎片某些大对象分配请求会因为找不到连续内存而去扩展堆进一步推高水位。所以GC卡顿的痛本质上不是“释放垃圾”痛而是“遍历活对象”和“内存碎片整理”痛。你压减小分配量其实就是在给GC减负。2.4 帧时间曲线上的尖刺长什么样在Profiler的Frame Time曲线里GC尖刺的特征非常明显平日里帧时间稳定在8ms到10ms某几帧突然窜到100ms、150ms甚至更高然后又迅速回落。尖峰与尖峰之间往往隔着一段相对固定的间隔有点像心电图里的早搏。如果你在真机上把帧时间图导出来会看到一种“梳子齿”一样的形状锯齿密集的时期就是玩家觉得卡顿最明显的时期。还有一个新手必踩的认知坑分配发生的帧和GC停顿的帧不是同一帧。你在帧A分配了大量垃圾堆水位飙升但触发GC可能要到帧D。你在帧D看到GC尖刺去帧D的调用栈里找大概率只找到一些无关痛痒的代码真正的分配源头在帧A的调用栈里。所以定位GC问题我最常用的一招是先看哪几帧GC Alloc高再看这些帧的调用栈而不是直接盯着GC停顿帧看。3. 高频路径上的常见GC雷区3.1 字符串拼接UI文本和日志的重灾区string是不可变类型每一次操作都可能创建中间字符串对象。比如下面这段在Update里执行的代码就是典型的GC制造机string text 等级: level 金币: gold; label.text text;它的执行过程比你看到的更浪费先是level.ToString()分配一个字符串再和等级:拼接出另一个再处理金币最后又拼出一个最终字符串。整个过程至少产生3个临时string。如果这段代码在战斗UI的刷新逻辑里每帧几KB基本是保底。优化方向有两条。第一用TextMeshPro的SetText格式化重载它可以从源头上避免中间字符串的产生m_TmpText.SetText(等级:{0} 金币:{1}, level, gold);TMP内部会复用缓存这个重载设计出来就是为了解决高频文本更新问题的。第二数据没变化就不要刷新UI纯数字改动再赋值值是固定的就跳过。这一点很多团队会忽略实际收益比任何字符串优化都大。日志也是重灾区。线上版本别留着满屏Debug.LogDebug.Log(go.name something)这种写法参数的字符串拼接和装箱在你关掉日志之前就已经发生了。我见过一个项目打了一整年日志没清理卡顿排查了大半个月最后发现是日志字符串在每帧造垃圾。用条件编译包一层#if UNITY_EDITOR Debug.Log(message); #endif发布版干干净净。3.2 装箱悄无声息的值类型转引用装箱就是把值类型int、float、enum、struct包装成object放到托管堆上。它比字符串拼接还隐蔽因为你可能完全意识不到它发生了。典型场景是string.Formatstring s string.Format(怪物{0}出现了, monsterId); // monsterId是int装箱还有枚举转字符串string n monsterType.ToString(); // enum.ToString()内部有装箱以及弱类型集合ArrayList list new ArrayList(); list.Add(42); // int装箱 int v (int)list[0]; // 取出来再拆箱单次装箱的分配很小但架不住高频。UI列表、战斗日志、技能冷却提示这些地方一天到晚都在装箱。替代方案不难枚举建一个static readonly string[] enumNames按索引直接取字符串绕开ToString()。int转字符串用TMP的SetText重载或者第四节我写的手动数字buffer法。集合优先用Dictionaryint, T、ListT这种泛型集合别碰ArrayList和Dictionaryobject, T。复盘的时候我经常干一件事全局搜索string.Format和ToString()凡是在循环或Update函数里的全部排查一遍。3.3 LINQ与闭包语法糖的隐藏账单很多人写代码喜欢用LINQ因为确实简洁。但简洁是要付账的而且Unity的Mono和IL2CPP运行时对LINQ完全不做逃逸分析优化。var item inventory.Where(x x.id targetId).FirstOrDefault();这一行背后发生了什么Where生成一个迭代器对象x x.id targetId如果捕获了局部变量还会生成一个闭包对象。一次操作至少两个堆分配。放在Update里等于每帧造两个垃圾。再看排序和查找var sorted units.OrderBy(u u.hp).ToArray();OrderBy要分配排序迭代器ToArray要分配新数组。列表越大垃圾越多。替代方案是回归传统写法。查找就用for循环列表不大时性能反而更好Unit target null; for (int i 0; i units.Count; i) { if (units[i].id targetId) { target units[i]; break; } }排序用List.Sort配合自定义比较器比较器定义成struct可以避免额外分配。我见过有团队为了用LINQ省脑细胞结果把AI选择目标做成每秒几千次分配低端机直接卡成一帧一帧跳。性能代码和高层业务代码还是分开写比较好。3.4 协程、委托和事件隐式分配的三座山协程看起来很方便但它是隐式分配大户。StartCoroutine(DoSomething()); IEnumerator DoSomething() { yield return new WaitForSeconds(1f); // 每次执行都new一个WaitForSeconds }StartCoroutine本身会分配Coroutine对象yield return new WaitForSeconds(1f)每次也要new一个。如果这个协程每帧启动一次或者一个战斗逻辑里高频启动多个协程GC压力直线上升。解法很务实凡是固定等待时间的协程把WaitForSeconds实例缓存成静态字段static readonly WaitForSeconds s_DamageTick new WaitForSeconds(0.5f); yield return s_DamageTick;委托和事件也是坑。用匿名函数/lambda注册事件时编译器会生成一个闭包对象enemy.OnDamaged () { hpBar.UpdateHp(); };这段代码每次执行到赋值语句就new一个闭包对象。有些项目在怪物生成的地方这么写一只怪物一个闭包怪海一开几千个垃圾就进堆了。替代方案是写具名方法注册时传方法组enemy.OnDamaged OnEnemyDamaged;方法组也会分配委托但一次初始化分配一次不会在运行时反复发生。如果是UnityEvent在Inspector里配置的持久化监听触发时内部还会分配参数数组高频调用时要留意——能用C# event就用C# event能缓存就缓存。3.5 一些Unity API的隐性分配每个版本Unity API的分配情况有差异但有几类是老牌分配大户FindObjectOfType、FindObjectsOfType、GameObject.Find。这些API每次调用都会遍历场景创建匹配结果数组。循环里用它们等于往GC嘴里送。物理碰撞回调返回的ContactPoint[]、射线检测的RaycastHit[]。高频物理逻辑应该用NonAlloc版本比如RaycastNonAlloc就是专门用来避免每帧分配数组的。Resources.Load反复加载同一个资源。加载本身分配资源对象应该缓存引用而不是每次加载新实例。动画事件回调里传字符串参数内部会有参数对象分配。但也要注意别矫枉过正。GetComponentT()这类API在现代Unity版本里已经基本不分配了别把它列为头号敌人。还有transform.position这种属性访问也不分配。分配大头永远是字符串拼接、装箱、LINQ、闭包、以及高频API的隐式创建。雷区常见位置解决思路字符串拼接UI刷新、日志TMP SetText重载、条件编译日志装箱string.Format、枚举ToString预建字符串数组、泛型集合LINQ闭包查找、排序、选择目标for循环、struct比较器协程WaitForSeconds战斗逻辑、冷却缓存WaitForSeconds实例事件匿名方法注册回调、怪物生成具名方法、缓存委托Unity查询APIFindObject、射线检测NonAlloc版本、缓存资源引用4. 实战压GC把“用完即弃”改成“循环复用”4.1 对象池不只用于GameObjectGameObject对象池很多人都在用但普通C#对象的池化经常被忽略。最典型的例子是ListT和StringBuilder某段逻辑每帧new Listint()收集一批数据用完就当垃圾扔了。下一次再new一个再扔。完全没必要。一个简单的List池public static class ListPoolT { private static readonly StackListT s_Pool new StackListT(); public static ListT Get() { return s_Pool.Count 0 ? s_Pool.Pop() : new ListT(); } public static void Release(ListT list) { list.Clear(); s_Pool.Push(list); } }使用的时候注意两点归还前Clear不然脏数据泄漏到下一个使用者不要在归还后继续持有引用这是各类诡异bug的温床。在战斗系统里碰撞检测结果列表、敌人列表、路径点列表都特别适合用ListPool。我在自己项目里把AI的候选目标列表改成池化以后GC Alloc从每帧9KB直接掉到接近0KB。4.2 字符串与数字的低分配显示方案之前提到TMP的SetText重载是最省事的方案这里专门展开讲一个实战案例技能冷却图标。最初的代码长这样float remain GetRemainCooldown(); label.text 剩 remain.ToString(F1) 秒;每帧两个临时字符串起步。改成TMPm_TmpLabel.SetText(剩{0:F1}秒, remain);这个API内部会复用StringBuilder不会产生中间string。如果你的项目还在用老的UI Text没法用TMP那就自己写一个数字buffer把float转成字符数组按位填进char[]只在值变化时才组装字符串。这里有个关键经验不是所有地方都需要零分配但高频显示一定要零临时分配。我把伤害飘字系统从“每个飘字生成一个独立string”改成“对象池复用文字对象TMP SetText格式化”后整场战斗下来GC Alloc基本是平的。4.3 缓存委托与替代协程的高频调度写法前面提到事件注册别用匿名方法。如果确实要用lambda缓存也要小心捕获变量。正确的是在Awake里存一次下次直接用private Action m_OnHpChanged; void Awake() { m_OnHpChanged () UpdateHud(); // 初始化时创建一次 hpSystem.onChanged m_OnHpChanged; } void OnDestroy() { hpSystem.onChanged - m_OnHpChanged; }只要不反复创建委托事件系统的GC压力就在可控范围。协程也一样。战斗里的高频轮询逻辑比如“每帧检测玩家周围敌人”“每帧更新技能指示器方向”本质上不适合协程。协程更适合低频、流程型逻辑等待动画结束、延迟执行一次技能、关卡流程控制。高频逻辑用Update状态机或者事件驱动代码看起来朴素性能却干净得多。4.4 struct数组的价值一次分配数据连续这条建议对战斗单位管理特别有用。很多人定义单位数据喜欢用classclass UnitInfo { public float hp; public float maxHp; public Vector3 pos; }然后UnitInfo[] units new UnitInfo[1000];。你以为只分配了一个数组实际上数组里存的是引用每个UnitInfo对象还要单独new一次一共1001次分配。GC标记的时候要遍历1001个对象每个对象还有额外头信息。改成structstruct UnitInfo { public float hp; public float maxHp; public Vector3 pos; }UnitInfo[] units new UnitInfo[1000];这一个数组就把所有数据包进去了内部是连续内存没有引用跳转GC只需要遍历数组这一个对象。对几百几千个单位做轮询、排序、查找时差别非常大。但用struct有个容易踩的坑它是值拷贝。如果你这样写var info units[i]; info.hp - 10; // 改的是副本数组里的数据没变正确写法是直接操作数组元素units[i].hp - 10;新手团队我建议先从字符串拼接和日志这两个“最显眼”的地方入手改起来风险低、收益直观。struct数组属于进阶优化等GC Alloc的预算卡得紧了再上避免一上来就把架构搅乱。5. 用Profiler把GC源头揪出来定位与验收5.1 先看GC Alloc列定位GC问题第一步永远是打开Profiler的CPU模块切到Hierarchy视图然后看右侧的GC Alloc列。操作顺序我一般固定不变进Play模式让目标场景稳定运行至少1分钟不要只抓前几帧。在Hierarchy视图中按GC Alloc降序排序找出“每帧分配量大”的函数。双击进入函数调用栈顺着调用关系追到业务代码。这里要强调一点GC Alloc和GC时间是两个东西。有些函数分配量大但GC没触发你看帧时间觉得不卡有些函数分配多到把堆推爆GC一触发就卡。所以别只看GC Time要盯GC Alloc的累计量和增长趋势。5.2 通过托管堆增长曲线发现“慢性失血”另一种定位思路不是抓单帧而是长时间观察托管堆水位。在Memory Profiler里能看到Managed Heap Used曲线稳定场景中如果曲线是一根持续向上的斜线说明有对象不断分配且没被释放。这不是GC的问题是泄漏问题。如果曲线像锯齿一样反复冲到高位又回落说明GC一直在工作但分配量太大触发太频繁。如果GC触发后曲线回落到一个比较低的水位那每次触发的原因基本就是“不必要的临时对象”。如果GC触发后水位还是很高那可能是堆被常驻对象占满需要查静态引用、事件注册未注销、资源未释放。记住一点Boehm这类非移动式GC水位线不会把内存马上还给操作系统。堆涨上去了后面就一直在高位运行后续分配不再申请系统内存但GC要遍历的对象也变多了。所以“GC后堆回落到底”并不是必须的关键在触发频率和停顿时间。5.3 一次完整的GC卡顿定位复盘分享一个实际案例。一个RPG项目的背包和商店系统测试机反馈“打开商店后每隔10秒卡一下”。复现路径很稳定正好拿来当教学。第一步Profiler录制1分钟Frame Time曲线出现间隔大约10秒的120ms尖峰。第二步切到CPU Hierarchy按GC Alloc排序发现每帧分配10KB左右峰值在尖峰前几帧。第三步点进分配最高的调用栈顺着函数找到业务代码TooltipManager.Refresh方法。代码长这样void Refresh() { var tip 物品: item.name 品质: item.quality.ToString(); Debug.Log(tip); tooltipLabel.text tip; }问题一目了然字符串拼接一次item.quality.ToString()一次装箱Debug.Log参数再拼一次tooltipLabel.text tip又触发一次UGUI网格重建。修复方案删除Debug.Log或用条件编译包好。物品品质枚举转字符串改成预建的静态数组。tooltipLabel.text改成TMP的SetText重载并且只在item对象变化时刷新而不是每帧刷新。修完之后同样跑1分钟GC Alloc从每帧10KB降到接近0尖峰完全消失。这个案例的价值在于分配帧和GC帧分离如果你只在GC停顿帧找调用栈永远找不到TooltipManager.Refresh这个真凶。5.4 真机验收与IL2CPP/Mono的坑编辑器里Mono运行时的GC行为和真机IL2CPP有实质差异。编辑器测试没毛病真机可能照样卡。我的验收流程是开发阶段建议用Development Build 真机Profiler连接跑典型战斗场景至少5分钟导出帧时间曲线和GC Alloc曲线。发布前再用Release Build做一次真机抽样因为Release Build的性能特征和Development Build也不一样比如日志系统、Profiler本身的埋点都会影响表现。特别提醒IL2CPP不等于没有GC。它是把C#编译成C但托管堆和GC机制依然存在只是底层实现不同。网上有些说法“IL2CPP能解决GC卡顿”在我实际测试里完全站不住脚。IL2CPP在某些平台确实比Mono更稳但GC尖峰该有还是有。还有一点容易被带偏有些第三方SDK会在原生层报错信息里带“gc handle”之类的字样很容易让团队以为是自己托管代码的GC问题。实际上原生层句柄管理和Unity托管堆是两码事看到类似报错先查第三方库别浪费精力在托管堆上找原因。6. 和GC相处久了的实战体会6.1 不是所有分配都需要被消灭写了几年Unity以后我对GC的态度从“零容忍”变成了“分场景对待”。一次性初始化阶段分配再多也不怕比如加载场景、创建对象池、构建全局数据表真正需要盯死的是“每帧执行”和“高频交互触发”路径上的分配。做一个新功能时我习惯把代码按执行频率分三档每帧执行、事件触发、一次性初始化。每帧执行那档清零分配事件触发那档控制规模一次性初始化放开了写。这个分层思维比单纯追求“零GC”更高效也更容易落地。6.2 场景切换时主动GC是合理的平时我不主张手动调用System.GC.Collect()但场景加载、回主菜单这种大换血时机例外。场景切换时大量资源被卸载、大量对象变成垃圾承接下一场战斗前主动清理一次可以避免把一堆垃圾带进新场景里。做法是在黑屏/加载过渡界面里调用System.GC.Collect(); Resources.UnloadUnusedAssets();注意顺序先卸载资源再GC效果最好。但在战斗循环里千万别调那会直接制造卡顿。6.3 把GC预算写进团队规范GC优化做一次容易防回潮很难。我们团队现在把人肉Review变成了自动化规则新UI系统、新战斗功能上线前必须跑一遍Profiler把GC Alloc峰值写进CR描述。战斗主循环的GC预算定在2KB/帧以内UI刷新只允许数值变化时分配。更进一步Unity的ProfilerRecorder可以让你在代码里直接采样GC Alloc指标我们把它接进了内部性能看板。CI流水线里也有一个阈值检查某个自动化战斗场景测试的GC Alloc超标构建直接失败。别嫌这太严格——GC卡顿这种问题一旦积压到上线前再排查工作量是现在的十倍。6.4 最后说点实在的处理GC卡顿这事儿我最大的感受是它很少是某一行代码的锅而是整个项目“分配习惯”出了问题。你修掉一个字符串拼接旁边还藏着十几个装箱你清完这十几个协程和LINQ又冒出来。所以别指望一次性能把GC清零要建立一套持续排查、持续优化的流程。文中提到的TMP SetText格式化重载、对象池复用、缓存WaitForSeconds、struct数组这些招都是成本低、收益明确的东西建议直接在团队规范里推广。最朴素的检查动作也最简单写完代码切到Profiler看GC Alloc按下回车这已经是我每次提交前的肌肉记忆了。