Unity GC卡顿排查与优化：从原理到实践的完整指南

如果你遇到过这种情况帧率曲线看着还行平均帧率甚至接近60可玩家“开技能”“切背包”“击杀怪”那一瞬间画面总要粘一下。找渲染、找动画、找物理排查了一圈都没结果最后在Profiler里看到一帧的GC Alloc飙升紧接着GC耗时几十毫秒才明白原来是垃圾回收在捣鬼。这是《Unity 卡顿·帧率保卫战》系列的第4篇我准备把“GC”这个最会伪装的卡顿来源从原理到排查再到日常写法完整拆一遍。这一篇适合正在做Unity项目、被“偶发卡顿”折磨过的开发者。尤其是移动端GC停顿对帧率稳定性的影响经常比一条复杂Shader还大。我的态度很明确先承认GC问题能造成卡顿再学会看GC分配最后把GC控制变成团队的习惯而不只是优化前临时抱佛脚。1. 帧率数字会骗人平均60帧背后的“尖峰帧”1.1 平均帧率会筛除真相按帧率看游戏往往看不出问题。举个实际存在的例子一段战斗过程里100帧中有99帧只需要10ms剩下的1帧因为GC触发直接干了100ms。算平均帧时间这100帧一共耗时10.9ms折算下来大约91帧。看起来非常漂亮对吧可玩家连续按技能时的体感完全不是“91帧”。他感受到的是99次顺畅操作之间突然插入了一次“顿住”连招断掉、镜头跳变、按键像没响应。这种体感上的落差恰恰是GC类卡顿的典型特征——它不是持续低帧而是偶尔来一根“尖峰帧”。所以我一直建议团队验收时把“平均帧率”降权改成盯住三样东西帧时间曲线的尖峰数量单帧最大耗时1% Low FPS最差的那1%帧的等效帧率。一个平均60帧但1% Low只有30帧的项目比一个平均55帧但曲线平滑的项目更让玩家难受。尤其GC问题最容易在这种“被平均数掩盖”的情况下躲过去。1.2 GC卡顿通常是“规则性痉挛”不是匀速掉帧很多人认为GC卡顿会像渲染压力过大一样表现为“整体掉帧”其实不是。GC不会每帧都跑它一般是分配量累积到某个阈值后在某次分配时突然触发一次完整的标记和清除。所以你在Profiler里看到的往往是长时间平缓的时间线上突然立起一根很高的“柱子”。更值得注意的是GC尖峰和操作事件的相关性非常强。比如击杀怪物的瞬间飘出一堆伤害数字和碎裂特效打开背包时一次性生成几十个物品条目连续射击产生大量弹壳和火花剧情对话每次出现角色名和图标。只要分配量陡增GC就会挑一个“关键帧”突然发作。这也是为什么很多玩家反馈“一打架就卡”“开箱子就卡”“切UI就卡”但你单看帧率曲线又发现多数时间很健康。排查这种问题别一上来就怀疑渲染和动画。先把Profiler切到CPU Usage区域按GC Alloc排序看尖峰之前哪套系统分配最多。十有八九元凶就是那条被你忽略的分配链。1.3 增量GC开起来也逃不开“换了种卡法”在继续往下之前先说一句增量GC。自从Unity支持了Incremental GC很多团队把“Use Incremental GC”当成救命稻草。它能过去一次性的长停顿标记过程拆分到多帧执行让每帧只承担一点额外开销。但我要提醒你增量GC解决的是“毛刺感”并没有消除分配。如果分配量大这些标记和清除工作仍会均匀地消耗每一帧的CPU平均帧率反而可能更难看。低端机上有时“卡一下”会变成“一直卡”玩家会更难受。所以增量GC可以作为一个开关在后期微调时用但真正决定GC卡顿的仍然是分配总量。下面这些原因和写法排查才是治本的部分。2. 托管堆的成本不只在分配GC停顿为什么会被主线程放大2.1 分配快得像发房卡回收却像退房后全楼检查要理解GC为什么卡先纠正一个认知C#里的“分配”本身通常并不贵。你可以把托管堆想象成酒店前台的一沓房卡。新客人来了前台撕一张卡递出去这个操作只要移动一下指针、把字段初始化好成本很低。真正贵的是“退房检查”凌晨三点酒店要挨个房间确认哪些客人已经走了哪些还要继续住然后把空房释放出来。GC触发后的“标记-清除”就是这样一次全楼检查。它会从静态字段、根引用、线程栈等入口出发沿着对象引用关系把整个对象图扫一遍判断哪些对象还能被访问到哪些已经是垃圾。对象数量越多、引用链越复杂这次扫描就越耗时。所以代码里“频繁new”不一定立刻卡但只要GC一触发之前累积的所有分配都会变成账单一次性结算。2.2 堆只增不减碎片化会让下一次GC更慢Unity当前使用的垃圾收集方案在不同的版本和平台上有差异但在很多目标平台上仍然不是压缩式的。换句话说回收之后活对象并不会被重新排列到一起内存里会留下很多“空洞”。这就带来两个连锁反应第一即使总剩余空间很大碎片化的内存也可能无法给某个大对象提供连续区域于是运行时只能在堆的尾部继续扩展堆越来越大。第二堆越大GC扫描范围越大扫描时间越长单次停顿就越明显。这两个效应叠加在移动端很容易形成“越玩越卡”的路径开局堆很小GC还能忍打了十几分钟频繁分配让堆被撑大GC停顿越来越密集帧率曲线越来越毛躁。2.3 主线程一停整帧都跟着陪葬Unity的主循环中Update、LateUpdate、物理步长、渲染提交都有明确的顺序。GC触发时它会按“世界停止”的方式把托管线程暂停主线程同样会被打断。如果GC停顿超过16.6ms这一帧就没了如果超过30ms动画会出现肉眼可见的断裂。有些开发者会问我明明用多线程处理了部分逻辑为什么GC还能卡因为在常规Unity项目里决定渲染提交节奏的是主线程。你在工作线程做了计算最终还是要回到主线程更新场景、提交渲染命令。只要GC停顿发生在主线程上玩家就会直接感受到掉帧和操作延迟。2.4 没有new不代表没有分配还有个常见误区有人以为“只要我少写new就不会有GC”。实际上不少分配藏在API内部、库函数、事件委托和协程的yield里。可能你只是调了一次Debug.Log里面已经做了字符串拼接和数组拷贝只是用了一次LINQ的Where已经产生了迭代器和闭包对象。所以后续排查时我建议不要凭代码里的new来猜而是直接看Profiler的GC Alloc字段。它才是分配行为的“口供”。3. 六个常见的隐藏分配开关在代码里“追凶”3.1 字符串拼接UI和日志里的隐形重灾区先看最经典的写法Debug.Log(玩家受伤 damage);就算你最后不显示这条日志已经来不及了。damage是int拼接时会在堆上生成一个新字符串如果前面再接几个常量加变量中间还会产生临时字符串。一段高频战斗日志如果每帧打一两次GC分配就是持续不断的。正确习惯是日志信息精简战斗里的Debug.Log在发布版本彻底关闭UI文本用复用的StringBuilder不要每帧拼接前缀是常量时不要写成xxx value yyy减少临时字符串的生成。如果你用TextMeshPro优先用SetText的重载它能把数值格式化直接写到内部缓冲区比string.Format更干净。3.2 装箱结构体变成object的那一瞬间C#里把结构体赋值给object类型时会发生装箱。装箱会在托管堆上分配一个新对象把结构体的内容复制一份进去。虽然代码看起来只是“赋个值”但它确实在堆上留下了东西。常见反例ArrayList list new ArrayList(); list.Add(12345); // 每个int都会装箱另一个容易忽略的场景是调用一个接收object参数的方法或事件传入了Vector3、int、Color这样的结构体。Unity一些旧版本API、动画事件回调、自定义事件系统中都存在这种设计。遇到这种调用先看函数签名能换成泛型容器或重载就换别让装箱悄悄埋雷。3.3 闭包和lambda编译器用隐藏类兜底lambda很好用但它捕获外层变量时编译器会生成一个隐藏类用来存放捕获的变量然后在每次执行lambda时分配这个隐藏类的实例。举个例子int threshold 10; var hits enemyList.FindAll(e e.hp threshold);每次执行这段代码捕获的threshold都会让编译器创建一个闭包对象FindAll内部还要新增委托。如果在Update、技能判定、怪物搜索这类高频逻辑里这么写GC压力会成倍增加。改进办法很直接把判断逻辑提成普通方法需要传条件时用一个提前实例化的静态委托使用static局部函数避免捕获变量带来的闭包对象。当然偶尔一次在冷路径上用lambda没问题但热路径上要养成“能省则省”的条件反射。3.4 协程里的yield return new写协程的人几乎都写过while (true) { transform.position Vector3.one * Time.deltaTime; yield return new WaitForSeconds(0.5f); }问题出在每次yield return new WaitForSeconds都会在托管堆上创建一个新对象。如果这个循环每0.5秒跑一次那每0.5秒就会产生一个等待对象垃圾。优化方式是把固定间隔缓存为静态字段private static readonly WaitForSeconds WAIT_TIME new WaitForSeconds(0.5f);但协程的开销不只是等待对象协程本身是迭代器状态机调用StartCoroutine(MyCoroutine())时已经有分配。对那种“短时间反复启动/结束”的协程我建议评估能不能改成Update状态机或JobSystem。尤其在移动端协程用得太随意GC成本会非常可观。3.5 对接口类型做foreach遍历在多数现代Unity版本里直接foreach数组和ListT不会产生分配因为编译器或运行时对它们做了专门优化。但有一种情况要警惕变量类型是接口。IEnumerableTransform all GetComponentsInChildrenTransform(); foreach (Transform t in all) { // 依赖接口迭代时某些平台/版本下可能发生装箱或额外分配 }解决办法是尽量不要把容器类型提升成接口再遍历。方法签名直接返回数组或ListT调用方明确类型。如果必须用接口就定期开Profiler检查这个foreach是否真的无分配不要凭感觉判断。3.6 LINQ、Find、Any业务代码里舒服热路径上危险LINQ写起来确实舒服Where、Select、FirstOrDefault一长串下去代码可读性很高。但每次调用这些方法通常都会创建迭代器对象、委托对象配合lambda时还可能有闭包分配。ListT.Find配合lambda也类似。这不是说LINQ不能用而是要看位置加载界面、配置表解析、低频事件处理——用LINQ没问题Update、战斗遍历、怪物群体筛选——尽量改成普通for循环。我见过不少性能问题最后定位到“就是一行list.Any(...)”引发的。改写成循环后不但分配没了有时还能趁遍历顺手处理break逻辑反而比通用API更灵活。4. 优化落地把“不让GC工作”的做法排进优先级4.1 对象池高频创建销毁的引用类型必须池化子弹、敌人、飘字、伤害数字、技能特效这些生命周期短、数量大、还要反复生成销毁的对象是移动端GC的主要推手。Unity提供了UnityEngine.Pool.ObjectPoolT新版API可以这样定义private ObjectPoolBullet _bulletPool; void Awake() { _bulletPool new ObjectPoolBullet( createFunc: () Instantiate(_bulletPrefab).GetComponentBullet(), actionOnGet: b b.gameObject.SetActive(true), actionOnRelease: b b.gameObject.SetActive(false), actionOnDestroy: b Destroy(b.gameObject), collectionCheck: false, defaultCapacity: 64); }这里有个实操细节collectionCheck开启后Release时会检查对象是否被重复释放开发阶段开着能暴露问题但它会多做一次集合查找。如果确认业务逻辑不会双重要Release发布版本建议关掉。不过对象池也不是万灵药。如果池子长期保留几百个不用的对象本身也是内存浪费反而会把托管堆或本地内存撑大。正确做法是给高频对象分类真正频繁创建销毁的才池化低频对象用普通缓存和延迟加载就够了。4.2 缓存优先策略从字符串到容器再到等待对象很多GC Alloc是“一次性分配后反复使用”就能解决的事根本不需要对象池。比较常用的做法有在类里维护一个StringBuilder字段每次使用前Clear再追加内容声明ListEnemy _nearestEnemies new ListEnemy(32)每次逻辑开始时先Clear再填充把WaitForSeconds、WaitForEndOfFrame这类常用等待对象缓存为静态字段把颜色、矩阵、材质属性等常用UnityEngine对象缓存下来。这套“先缓存再池化最后才考虑new”的顺序比一上来就引入大型对象池框架更容易落地。我实际项目里最大的感受是不要凭感觉乱加缓存先用Profiler定位到高频热点再有针对性地缓存。缓存放错位置反而会让全局状态变得更难维护。4.3 值类型、NativeArray与Burst把分配赶到非托管内存如果频繁需要临时数组或者有大量结构体计算可以考虑使用NativeArrayT和Job System。NativeArray分配在非托管内存不参与托管堆回收不会触发GC停顿配合[BurstCompile]还能把循环代码编译成高效的本机指令。代价是使用门槛变高需要手动Dispose还要正确选择Allocator错误使用会造成Native泄漏。它适合“性能敏感且计算量大”的场景比如千人战场的位置更新、海量粒子的模拟、大规模寻路计算。普通MonoBehaviour逻辑强行改成NativeArray反而得不偿失。这里要泼一点冷水Unit性能优化是一条递进路线不要一上来就把所有数组都换成NativeArray。先做到“不分配”再考虑“用非托管内存”最后才上Burst这个顺序比较不容易翻车。4.4 给项目定一张GC预算表GC优化最大的问题不是不会改而是不知道“何时算完”。我的做法是在项目日常迭代时给每个系统定一个每帧分配预算战斗系统每帧GC Alloc不超过1KBUI单次打开弹窗不超过10KB常驻Update逻辑保持0新增分配场景加载允许一次性分配但需要用Loading界面盖住。这张预算表不需要精确到字节它最大的作用是拦住“上线前统一优化”这句空话。开发时每提交一次相关代码随手跑一下对应场景看到GC Alloc超预算当场改掉。次数多了团队自然就养成了少分配的习惯。5. 用工具把GC毛刺变成可视指标而不是玄学5.1 Profiler先抓尖峰再排序GC Alloc排查GC问题我最常用的流程是这样在Editor里只开CPU Usage模块勾选“Deep Profile”会显著放大分配成本但适合定位分配源头重放目标关卡或反复触发你怀疑的操作直到Profiler出现GC尖峰切到Hierarchy视图按GC Alloc列排序看最高的函数展开调用链找到你自己代码里的那一层不要停在库函数内部修正后关掉Deep Profile用正常模式再跑确认尖峰消失。有一个细节要注意Deep Profile因为会记录每次函数调用本身就会制造大量额外开销所以它显示的GC Alloc数值不是真实水平只能用来横向比较哪些函数分配多。修正后一定要关掉Deep Profile再复测。5.2 Memory Profiler用两个快照找长期增长Profiler能抓“瞬时分配”但长期内存涨势需要Memory Profiler包。我的用法很简单进入游戏在稳定操作前拍一张快照打完十分钟常规战斗后再拍一张。对比两个快照重点看托管堆大小是保持稳定还是一路看涨。如果所有对象看起来都该被销毁了托管堆却还在涨通常就是某个静态容器、事件回调、单例没清理干净。快照里能看到各个对象的保留路径比靠肉眼审代码可靠得多。这种快照对比同样适合排查“为什么打完一局后内存不降”。5.3 把GC分配写进自动化门槛如果你的项目有自动化测试或性能冒烟脚本可以加入一个简单的分配检测long before Profiler.GetTotalAllocatedMemoryLong(); // 触发要压测的战斗/UI逻辑 long delta Profiler.GetTotalAllocatedMemoryLong() - before; if (delta threshold) Debug.LogError($GC Alloc over budget: {delta});把这个检测放进CI里每天跑一遍核心玩法场景回归后一旦超预算就失败。这个门槛前期可能会拦下很多历史代码一旦稳定下来团队就不会再退回“随手new”的状态。前提是别把这套自动化写得太重跑几个高频热点场景就够了。5.4 真机验证和机型分级Editor里不卡不代表真机不卡更不代表低端机不卡。同一个GC在PC上可能只停2ms在骁龙6系中端机上可能停30ms因为托管堆大小、CPU频率和内存带宽完全不同。有条件的话性能测试至少要覆盖三台设备一台低端Android、一台中端Android、一台较老的iOS。用Unity Profiler远程连接真机观察GC尖峰的“高度”和“频率”。真机上的GC Alloc与Editor数据同源但停顿时间系数不同移动端的GC预算要比PC定得更严格。6. 压完堆之后增量GC和版本评估还值得做一轮6.1 增量GC开不开取决于你的“卡法”如果项目已经出现明显的单帧GC尖峰增量GC可以救急。它的原理是把一次完整GC的标记工作拆到多帧逐步执行把“卡一下”摊平成十几帧的低负担。缺点是总开销往往比一次集中GC略高帧率上限会被稍微压低。我的经验帧率有富余的PC或高端机单帧停顿很难受开增量很赚低端机CPU已经很紧张增量反而可能让平均帧率进一步下降。开之前和开之后都测一下1% Low帧确认这项设置是做加法还是做减法。6.2 Unity版本升级后GC行为也可能变不同Unity版本、不同后端Mono、IL2CPP下的垃圾收集细节有差异。项目升级版本后原来优化好的代码可能因为库实现变化产生新的分配点也有可能某个老版本会分配的在新版本里不再分配。所以性能优化记录一定要跟着Unity版本走不要拿三年前的经验硬套新版本。升级后如果出现“不明原因的偶发卡顿”第一步依然是抓GC Alloc不要在渲染层盲目做无用功。6.3 最后的习惯GC优化不是上架前的冲刺说实话我见过太多项目把GC当成“版本上线前一周的统一优化任务”那是最痛苦的。GC分配的排查成本并不高难的是改完以后要反复验证而越到后期代码越复杂牵一发动全身。更划算的做法是把“GC Alloc不超预算”写进设计评审、代码评审和发布检查清单里每回迭代都随手处理小分配。等真到优化期你会发现GC问题已经被提前拆掉了大半。拿Profiler看一遍按预算改几轮把增量GC当成辅助而不是救生圈GC就不再是那个“看不见的卡顿来源”。