Unity GC卡顿优化实战：从原理到降分配方案

做了几年 Unity 项目最让人抓狂的从来不是“明显的卡顿”而是那种“一切看起来都正常但一进战斗就偶然顿一下”的幽灵式掉帧。我自己就遇到过战斗逻辑不复杂、场景面数不高、DrawCall 也能压住可老机型上每隔十几秒就来一次肉眼可见的延时。排查到最后矛头全指向了一个大部分视频里都不在意的角色——GC。这是《Unity 卡顿·帧率保卫战》系列的第四篇我打算把 GC 这个“看不见的卡顿来源”彻底讲清楚它是怎么影响帧率的、怎么用工具抓到它、以及我复盘多个项目后总结出的降分配实战方案。1. 先把 GC 的运作机制讲清楚它凭什么影响帧率1.1 简单理解托管堆和垃圾回收GC 的全称是 Garbage Collection中文叫垃圾回收。在 Unity 里C# 脚本中通过 new 实例化出来的引用类型对象会分配在“托管堆”Managed Heap上。堆上的空间不是无限的当很多对象不再被代码引用时运行时就该想办法回收这些空间给后续分配腾位置。GC 就是干这件事的机制。听起来很完美对吧开发者不用手动释放内存Unity 和 .NET 后端Mono 或 IL2CPP会自动处理。但代价在于当 GC 真正开始执行回收时它常常需要暂停当前正在运行的逻辑去扫描堆上的对象引用判断哪些对象已经“不可达”然后再腾出空间。这个暂停在游戏主线程上表现得很直接——角色的脚本、动画更新、渲染提交全部原地等待玩家看到的就是卡了一下。你可以把 GC 想象成一个不定期来你房间打扫的保洁员。你正在游戏里打 Boss保洁员突然推门进来停下来把地上的垃圾扫干净再走。你只能干等。如果你制造垃圾的速度很快保洁员来得就勤快清理时间也变得不稳定帧率自然就被打乱了。1.2 为什么卡顿往往“来得早不如来得巧”普通性能瓶颈和 GC 卡顿在表现上有明显区别。场景物体太多、渲染顶点太多这类问题带来的帧率下降是“均匀分布”的——每一帧都慢一点整体帧率稳定地低玩家感受到的是持续不流畅而不是瞬间停顿。GC 卡顿不一样它更像“间歇性抽风”。平时帧率正常但某一帧因为分配量累积到阈值GC 被触发那一帧的耗时直接顶上去画面的帧时间曲线出现一个尖刺。这种情况难定位是因为你复现时不一定能正好撞上 GC 触发的时机尤其是在编辑器里跑的时候编辑器自身的 GC 行为和真机差异非常大。所以我在项目里碰到“时而掉帧、时而不掉”的问题时第一反应不是去怀疑美术资源或渲染管线而是先用工具检查脚本里有没有持续的内存分配。排查思路很简单同一个场景、同一个操作路径把某段功能关闭后再把帧率曲线拉平。如果关掉后卡顿消失基本可以锁定问题就在这段逻辑里。1.3 增量式 GC 止痛药不是根治方案Unity 在 Player Settings 里提供了一个开关Use Incremental GC开启后可以明显缓解 GC 带来的卡顿峰值。原理是把原本一次性完成的垃圾回收 Mark 阶段标记哪些对象可用、哪些可回收拆成多个小片段穿插到不同帧之间执行。这样单帧暂停时间变短帧率曲线会变得平滑一些。但务必要有个清晰认知增量式 GC 没有减少垃圾回收的总工作量。它只是把一个“大顿”拆成了很多个“小顿”总开销还在只是不那么容易被玩家感知。而且部分实现里Collect 阶段清理和压缩仍有可能出现阻塞。更现实的问题是增量式 GC 会让内存占用略升因为垃圾对象存活的时间变长了堆的浮动水位也随之抬高。我在实际项目中的态度是增量式 GC 可以作为降低尖峰的第一层保护但绝不能因此放松对分配量的控制。你把它当成止痛药可以别当成治疗方案。2. 定位 GC 卡顿的正确姿势先用 Profiler 说话2.1 用 CPU Usage Profiler 盯住 GC Alloc定位 GC 问题Unity 自带的 Profiler 是最直接的武器。打开 Window Analysis Profiler切到 CPU Usage 模块每一行调用后面会有一列 “GC Alloc”数值表示该函数这一帧在托管堆上分配了多少字节。我推荐的排查流程是先跑真机包用 Development Build Autoconnect Profiler 抓数据别在编辑器里看。编辑器模式下的 GC 行为和内存水位跟真机差异很大很容易误导判断。抓到 Profiler 数据后按 GC Alloc 排序重点看分配量最高的那几行函数。如果说某个 Update 里每帧分配几百 KB那它大概率就是卡顿的根源之一。如果你需要更细的定位可以用 Deep Profile 模式记录完整调用栈。这个模式会把每个函数的完整调用关系打出来告诉你分配发生在哪一层。但 Deep Profile 本身会明显拖慢运行速度也会增加内存开销所以只建议在小规模场景或特定复现路径上用不适合长跑。2.2 Memory Profiler 看托管堆的“水位”CPU Profiler 能告诉你分配发生在哪里Memory Profiler 则能告诉你托管堆到底膨胀到了什么程度。Unity 官方提供了 Memory Profiler 包com.unity.memoryprofiler可以抓快照看到托管堆整体大小、对象类型分布以及各对象的引用关系。这里有个重要的知识托管堆和操作系统内存不一样它不会因为对象不再被引用就立刻把空间还给系统。托管堆的增长就像水池水位上涨对象释放后水位不一定下降只是那个空间被标记为“可以复用”。哪怕你的代码里已经没有多少存活对象只要堆曾经涨到过 100MBGC 每次扫描堆的成本就仍然要按这个高水位去算。所以在优化时我不仅关心“当前分配了多少”还关注“堆的最高水位”。如果发现托管堆已经被撑到几十 MB而项目逻辑本不该需要这么多我才会考虑在绝对安全的时机调用 System.GC.Collect()强制触发一次回收让堆缩回来。比如切场景、进 Loading 界面玩家注意力不在游戏操作上这个操作带来的阻塞才不会引发差评。注意System.GC.Collect() 在不同后端Mono/IL2CPP上的表现差异很大而且在某些平台不一定能立刻回收。只能作为临时止血手段不能依赖它做常规优化。2.3 对照帧时间曲线判断是不是 GC 尖峰Profiler 的 Frame 视图右上角会显示每一帧的耗时曲线。当你说“卡顿”的时候最直观的证据就是某一帧的耗时突然比前后帧高出很多。这时候要把帧耗时曲线和 GC Alloc 趋势叠起来看如果耗时尖峰的那一帧恰好也是 GC Alloc 明显累计触发回收的位置那这个尖峰大概率就是 GC 导致的。操作上有个小技巧把 Profiler 的统计范围拉长到十几秒看 GC Alloc 的累计趋势。如果曲线呈阶梯式均匀上涨说明有持续的分配如果曲线平缓、偶尔跳一下那问题大概率出在某个事件触发点上比如打开背包、释放技能、敌人刷新。定位到具体触发点后再针对那一段逻辑去做优化效率比盲目扫全项目高得多。3. 从最痛的地方下手高频分配场景优化实战3.1 字符串UI 文本里的隐形血库字符串是 Unity 项目里最常见的分配来源也是最容易被忽视的。C# 的字符串是不可变类型任何对字符串的“修改”都会创建新对象。举个高频的坑// 错误示范每帧都在拼接字符串 scoreText.text Score: score.ToString();这一行在每帧刷新时score.ToString()会创建一个字符串对象拼接后的Score: score.ToString()又会创建一个新字符串最后赋给scoreText.text时UI 内部可能还会处理一次。如果这一行每帧执行GC Alloc 的累计量非常可观。我的处理策略分几层降低刷新频率很多文本其实不需要每帧更新。分数、倒计时、状态文字可以改成每 0.2 秒刷新或只在数据变化时刷新而不是无脑在 Update 里跑。用 StringBuilder 做高频拼接如果要拼多个片段用可复用的 StringBuilder 而不是频繁使用。实现轻量数字转字符串如果你的项目里有大量伤害飘字、战斗数值显示可以考虑自维护一个 int 到字符串的静态缓存或者用 Unity 自带的低分配方案最大限度避免字符串对象频繁创建。我印象最深的一个项目伤害飘字系统重构之前场景里同时存在 30 个飘字每个飘字每帧都要拼一次字符串GC Alloc 直接爆到每帧几百 KB。后来改成“创建飘字时生成一次字符串后续只修改颜色和位置”分配量几乎降为零。一句话总结字符串分配是刚需但别让它在高频路径上反复发生。3.2 LINQ、闭包和委托看起来优雅的分配刺客LINQ 写起来确实爽Where、Select、OrderBy让代码读起来和数据库查询一样清晰。但代价是背后的分配这些方法在常见实现中会创建委托、闭包对象和迭代器状态机。如果在 Update 或频繁调用的函数里用 LINQ分配量会超出你的想象。// 坏味道每帧筛选 转 List ListEnemy aliveList allEnemies.Where(e e.isAlive).ToList();这里e e.isAlive这个 lambda 表达式如果捕获了外部变量编译器还需要创建一个“闭包类来装这些捕获变量”。即使没捕获变量也有委托分配的开销。加上ToList()新开一个 List几个分配叠加在一起帧率不出问题才奇怪。我改代码的习惯是高频路径禁止 LINQ全部改成 for 循环手工筛选。这不只是强迫症而是经过 Profiler 验证后的实际收益。如果你真的很喜欢 LINQ 的语义可以用预处理的方式把筛选结果缓存起来只在数据源变化时重新生成一次避免每帧都查询。闭包和委托还有一个经典坑在循环里注册事件。很多人会写出这样的代码for (int i 0; i buttons.Count; i) { buttons[i].onClick.AddListener(() DoSomething(i)); }这个 lambda 捕获了循环变量i编译器会为每一次循环创建一个闭包对象而且因为捕获方式不同i的行为可能跟你想的不一样。更稳妥的做法是事件注册放到 Awake/OnEnable用局部变量拷贝值并在 OnDisable 移除监听同时避免在 Update 里反复 AddListener。3.3 装箱一个容易漏掉的分配点装箱是指把值类型int、float、struct、enum 等转换成 object 类型或者转成接口类型时系统会把它包装到一个引用类型对象里这个操作会产生分配。代码里看不到new但分配确实发生了很隐蔽。常见的触发点object o 123; // 装箱 string s string.Format(value {0}, 123); // 参数是 object装箱 Debug.Log(state: currentState); // enum 转 object 装箱string.Format尤其容易踩坑因为它的参数类型是params object[]你传进去的值类型都会发生装箱。在 UI 文本更新、日志打印这类高频场景里装箱带来的分配会被放大。要判断代码里有没有装箱可以用 Profiler 搜索也可以在编译层面留意警告。实践上高频代码里少用string.Format改成用ToString()提前转换或者直接把值类型缓存到字符串。日志方面可以用条件编译指令把正式包的 Debug.Log 关掉这不仅能减少分配还能降低 CPU 开销。3.4 容器扩容List 和 Dictionary 的隐藏成本List 和 DictionaryK,V 这类容器在 Add 元素时如果内部容量不够会触发扩容机制。扩容时容器会新分配一个更大的内部数组把旧数据逐个拷贝过去这个过程的分配量和 CPU 开销都不小。如果你的容器是在 Update 循环里不断 Add 新元素扩容就会成为 GC 的潜在贡献者。规避方式很直接在初始化时就给容器一个足够大的容量。比如// 预估最多 64 个敌人 ListEnemy enemies new ListEnemy(64);这样后续 Add 就不会频繁触发扩容。如果实在预估不了也可以复用 List调用Clear()清空后继续使用而不是每次重新 new。Dictionary 扩容的代价比 List 更高因为不仅要分配新数组还要重新计算所有键的哈希位置。所以对字典更要做到“能复用就复用能预留就预留”。我见过有的项目在战斗初始化时反复 new 一堆 List、Dictionary导致托管堆水位持续上升。后来改成在战斗开始前一次性创建好容量足够的容器战斗过程中复用结束后清理GC 分配量肉眼可见地降了一个档次。4. 进阶策略把 GC 从“被动挨打”变成“主动控场”4.1 对象池的正确打开方式对象池是减少实例化和销毁的经典方案但很多人只把它理解为“少 new 几个对象”。其实对象池更核心的价值是把随机的、分散的内存分配变成可控的、可预测的成本对象创建后被池子缓存下次需要用的时候直接从池里拿不再触发新的托管堆分配。不过对象池设计不当反而会制造新问题。最常遇到的是状态残留从池里拿出来的敌人血条还留着上一局的数值动画状态没重置协程还挂在旧的逻辑上。这些都是没有做完整 Reset 导致的。我自己的做法是在对象入池时调用 OnRecycle出池时调用 OnSpawn把必要状态全部重置干净从根上杜绝数据串位。另一个容易踩的坑是池子无限增长。如果逻辑上创建对象的速度长期超过回收速度池子会越来越大内存占用缓慢上涨。所以对象池最好加一个最大容量限制超出上限的对象直接销毁而不是无限缓存。4.2 分帧处理与事件触发点错峰如果某个功能确实需要一次性生成大量对象比如关卡加载、大规模敌人波次生成、技能特效爆发可以采用分帧策略把一次大分配拆成多个小分配分散到连续几帧里完成。这样 GC 不会被一次性大量垃圾触发帧率曲线也会更平滑。具体实现可以做一个简单的任务队列每一帧只处理固定数量的生成任务直到队列清空。这样即使总量很大单帧的分配量也被限制在可控范围内。分帧处理的代价是逻辑上会出现短暂的“渐进式生成”比如敌人不是瞬间全部出现而是几百毫秒内陆续出现。对大多数玩法来说这个渐进过程完全可以接受。顺便提一下事件触发点的错峰。很多卡顿是因为多个系统在同一帧集中创建、销毁资源。比如战斗开始瞬间既刷新 UI、又生成怪、又播放全屏特效。把这些操作在时间上错开不追求同一帧完成所有工作GC 压力就会均匀很多。4.3 从数据结构设计上消灭分配这一层做的事情更底层不是减少分配次数而是从设计上避免产生分配。核心手段是用 struct 替代 class在合适场景下避免堆分配。比如坐标、碰撞信息、临时计算结果这类轻量数据用 struct 存放可以减少大量堆对象。把临时对象改成缓存字段。如果一个逻辑每帧都要创建一个 List 或数组把它提升为类字段每次先 Clear 再填数据能直接消灭重复分配。避免在热循环中 new 任何引用类型对象。这里说的热循环包括 Update、FixedUpdate、LateUpdate以及频繁调用的工具函数。当然struct 也不是万能药。如果结构体太大频繁赋值和拷贝反而会带来额外的 CPU 开销。所以数据结构的优化需要跟 Profiler 数据对照着来不要为了炫技而滥用。健康的流程是先用工具找出热路径再在热路径里做针对性优化。5. 常见问题与避坑速查5.1 一张表帮你快速定位常见的 GC 隐患现象可能原因解决思路UI 文本每帧刷新帧率随机波动字符串拼接 ToString 高频分配降低刷新频率、缓存字符串、用 StringBuilder打开菜单或技能界面时卡顿大量使用 LINQ、闭包、事件注册高频路径改用 for 循环事件注册移出热路径战斗开始瞬间明显掉帧大量招募名单、粒子、GameObject 集中创建分帧生成、对象池、错峰触发托管堆持续增长GC 尖峰频繁容器扩容、临时 List 每帧 new预分配容器容量、复用 List、缓存结果低端机卡顿尤其严重代码生成垃圾多低配设备 GC 耗时更长全面降分配必要时开启增量 GC5.2 我踩过的一些坑写在这里给你当缓冲垫GC 优化新手最容易犯的错误是“用猜的”。看到一个函数里 new 了一个 List立刻改成复用看到字符串拼接立刻改成 StringBuilder。这样改有一定收益但可能改了半天发现真正的大头在另一段不显眼的代码里。正确做法永远是先上 Profiler让数据告诉你分配在哪儿再决定改哪里。第二个坑是“只优化脚本不看堆水位”。有时候你已经把游戏逻辑里的分配降得很低了但 GC 依然偶尔卡顿。这时候该检查是不是第三方插件、资源加载系统、UI 框架在后台偷偷分配。特别是用 AssetBundle 或 Addressables 加载资源时如果频繁加载卸载资源托管堆会受到很大影响。建议在资源加载/卸载的关键节点打 GC Alloc 标记确保分配不是从资源系统里冒出来的。第三个坑是“在 Update 里做只应该在初始化时做的事”。很多分配问题的根源是代码把本该只执行一次的逻辑写进了每帧执行的循环里。比如每帧都去查找组件、每帧都注册事件、每帧都重新计算某个不会变化的常量。这些可以通过逻辑重构解决而不是靠堆工具去救火。我在 review 代码时只要看到 Update 里有创建对象或获取组件的代码都会额外警觉。5.3 最后的验收标准真机帧时间要“平”而不是“高”优化完成后不要只看平均帧率提升到多少帧要看帧时间曲线是否变平。平均 60 帧但每隔 2 秒跳一下和稳定 55 帧不掉尖峰后者的游戏体验其实更好。我在性能验收时会要求帧时间曲线的 95 分位和 99 分位数据达到目标线而不是只盯着平均帧率。对于 GC 问题只要 GC Alloc 总量降下来了帧时间曲线的尖峰会肉眼可见地减少。还有个经验是不同后端对比测试在 Android 真机上用 Mono 和 IL2CPP 分别跑一遍观察 GC 表现差异。IL2CPP 在长时间运行后的 GC 行为和 Mono 差别不小有些在 Mono 下没问题的代码切到 IL2CPP 后会有不同的堆增长曲线。项目正式打包前两条单机路线都值得跑一遍 Profiler。顺手分享一个我一直保留的习惯新建项目或接手老项目时先把“每帧 GC Alloc”设成一个团队指标写进性能看板。不要等卡顿爆发了才回头查而是每次合代码都留意一下这条曲线。GC 的问题从来不是“一次优化就能永绝后患”的它是随着需求迭代不断长出来的新坑。你代码写得越久越会发现放下对 GC 的侥幸心理才是一个 Unity 客户端技术人开始成熟的第一步。