做Unity客户端优化这几年我最有感触的一件事是帧率掉下来的时候真凶往往不是那些肉眼可见的复杂渲染而是一些看似人畜无害的小代码。尤其是GCGarbage Collection垃圾回收它就像房间里一只看不见的手平时安安静静一到关键帧就给你来个突刺。这一篇我们就死磕Unity GC把这块最难缠的卡顿来源按在地上摩擦。如果你是做Unity游戏、数字孪生项目、微信小游戏或者Pico这类XR设备的开发者只要你的项目里出现过帧率突然跳水、玩家操作一顿一顿、或者Profiler里时不时冒出几个尖峰这篇内容就是为你准备的。我尽量把原理讲明白把实操步骤拆到可以直接抄作业也会分享一些我们在真实项目里踩过、填过的坑。1. GC原理速通先搞懂卡在哪再谈怎么修1.1 托管堆不是无限资源GC也不是随手清理很多人对GC的第一印象是“内存不够了就自动回收一下”这个理解不能说错但太粗糙了。Unity里的C#代码跑在Mono或IL2CPP运行时上所有new出来的对象也就是引用类型都会分配在托管堆Managed Heap上。这个堆有一个水位线当分配的内存达到一定阈值运行时就会触发一次GC。关键点在这里GC不是后台线程悄悄帮你打扫卫生它是要暂停主线程来干活的。在Unity里最常见的GC模式是Boehm Demers WeiserMono默认或者Unity 2021之后的增量式GCIncremental GC。增量式GC虽然把一次完整的回收拆成了多帧来做但每帧依然会消耗时间片而且它降低的是“单帧尖峰”的幅度不是消除问题。更麻烦的是如果你的分配速率太快增量式GC可能跟不上还是会退化成完整的Stop The World。用一句大白话总结GC卡顿的本质是你的代码在一帧内产生了大量垃圾运行时为了腾出空间把主线程按住了几十毫秒。这几十毫秒放在60帧的游戏里就是1到3帧的完全静止。玩家不卡才怪。1.2 触发时机的随机性才是最伤人的我们平时看的平均帧率、平均耗时其实会掩盖GC的可怕。GC造成的卡顿是偶发性的尖峰它可能在玩家刚进入战斗、大量刷怪、或者UI集中更新的时候突然出现。平均帧率如果掉到50多fps可能只是渲染瓶颈但如果你的平均耗时图很平滑、帧率也很正常却在某些特定帧出现一个100ms以上的大尖峰十有八九就是GC在作祟。我见过一个数字孪生项目场景里几万个设备节点在轮询刷新状态每帧都会new一堆字符串和List帧率看起来还行但每隔十几秒就会大卡一下表现就是画面顿一下、操作明显延迟。用Profiler一看GC Alloc那一栏每秒几MB隔一阵就触发一次完整回收耗时飙到200多毫秒帧率直接掉到个位数。这就是典型的“看不见的卡顿”——你不开Profiler看GC Alloc永远只会觉得项目优化得差不多了。2. GC元凶清单这些写法在持续制造垃圾2.1 字符串拼接和装箱最隐蔽的小刀割肉先看一段几乎每个项目里都会出现的代码string msg 当前血量: hp / maxHp;这行代码看着人畜无害但每执行一次会在托管堆上分配出至少3个字符串对象。数量少的时候没事如果你把这种拼接放到Update里、放到UI刷新里、放到每帧都要执行的日志里垃圾量就会指数级膨胀。字符串是引用类型每一次拼接都会产生新对象旧对象就成了垃圾等着GC来收。装箱Boxing是另一个更隐蔽的元凶。当你把一个值类型比如int、float、struct当作object或者接口类型使用时运行时会把它的值复制到托管堆上的一个盒子里这个盒子就是垃圾。最常见的触发点包括字符串拼接时混入数值类型内部会调用object.ToString()但拼接本身还会触发装箱。把int/float往Listobject、ArrayList、HashTable里塞。给UI的Text.text赋值时如果你的数据源是object类型。使用Debug.Log时如果你传的是值类型参数然后走string.Format。最简单的排查方法就是打开Profiler的GC Alloc选项跑一小段操作看看凡是GC Alloc为0的代码才会让你安心。2.2 频繁Instantiate和Destroy堆内存的过山车很多新手写射击游戏子弹用Instantiate生成命中后Destroy掉了事。这在原型阶段很爽但进入正式项目就是噩梦。实例化一个Prefab不仅需要加载资源、实例化组件还会在托管堆上分配大量的对象销毁一个对象同样会把它的所有托管对象标记为垃圾。这种行为的副作用是双重的分配让堆水位上涨垃圾让回收变频繁。更烦人的是如果Instantiate同时伴随资源加载你还会看到明显的加载尖峰和GC尖峰混在一起排查起来特别痛苦。用对象池Object Pool替代Instantiate/Destroy是任何一个带大量实体生成销毁的项目都必须做的事。这个后面我会给一套可落地的池子方案。2.3 闭包、匿名函数和协程你以为没分配其实每帧都在new这是很多Unity开发者的盲区。看这段代码button.onClick.AddListener(() { DoSomething(); });如果你在Awake或Start里写一次闭包分配的额外开销可以忽略。但有一种魔鬼写法是把闭包写进每帧调用的方法里或者写在协程的循环里IEnumerator UpdateSomething() { while (true) { yield return new WaitForSeconds(0.1f); int index currentIndex; entityList[index].OnHovered (entity) { HandleHover(index); }; } }这里每0.1秒就会new一个匿名委托、一个闭包对象还要把捕获的index打包进去。循环跑一分钟就是600次分配运行十分钟就是6000次这些垃圾都会成为GC的盘中餐。还有一个非常隐蔽的点协程本身也是对象。StartCoroutine(IEnumerator())会创建一个MonoBehaviour驱动的协程状态机对象yield return new WaitForSeconds()每执行一次就new一个WaitForSeconds实例。如果你把一个协程做成高频循环累积分配量相当可观。所以高频逻辑请放在Update或FixedUpdate里协程只适合低频的延时操作。2.4 API调用有隐含开销FindXXX和GetComponent的代价GameObject.Find、Transform.Find、GetComponent这些API在调用时会生成临时对象、做类型查询和迭代内部列表必然产生GC Alloc。如果你在高频Update里写GameObject.Find(Enemy).GetComponentRigidbody().AddForce(...);那每一行都在给GC送钱。正确的做法是缓存引用在Awake或Start里查一次存到字段里之后就只读字段。这个道理其实大多数人都知道但项目一赶就容易放飞自我。我建议团队里定一条代码规范Find和GetComponent只允许出现在初始化阶段Update里出现一律Code Review不过。3. 实操用Profiler精准锁定GC源头3.1 Profiler窗口的正确打开方式在Unity编辑器里打开Window - Analysis - Profiler或者直接按快捷键Ctrl7然后在右上角的CPU Usage模块里把Hierarchy模式切换到Timeline模式。优先看到的应该是“GC Alloc”列如果没有你需要在模块右上角的小齿轮里勾选Show GC Alloc。这里有个关键操作Performance Mode不要用Play Mode的默认设置最好把Profiler连接到真机上抓数据因为编辑器本身的GC行为、资源加载、Debug.Log都会干扰数据。在手机上抓Profiler数据的方法是Development BuildAutoconnect Profiler在Build Settings里勾上然后用USB线连着抓。微信小游戏和Pico这类环境Unity同样支持远程Profiler只是要在初始化阶段调用Profiler.logLevel一类配置把网络通道打开。我强烈建议放弃纯编辑器分析因为编辑器模式下大量编辑器自身GC会盖住游戏代码的分配。3.2 学会读GC Alloc数据有的放矢打开Profiler后你会看到一列GC Alloc的字节数。简单说GC Alloc: 0 B完美说明这段操作没有任何托管堆分配。GC Alloc: 几十B到几百B大概率是装箱、字符串拼接或小对象分配。GC Alloc: 几KB以上说明你在new数组、List、字典或者字符串。实操时我会先把游戏跑到一个稳定场景记录一段60秒的Frame数据然后按GC Alloc排序点击单帧往下钻一层层展开调用树直到找到最底部的、属于游戏代码的分配点。Unity的Profiler定位到代码后点击会自动跳到对应C#方法这时你就能明确看到是哪一行产生的分配。用这种方法我曾在一次优化中定位到某个UI界面的刷新函数每帧分配了5KB以上的垃圾就因为里面有个int.ToString()的调用还嵌套在字符串拼接里。改掉那一个函数整个界面的GC直接降了90%。3.3 不要被编辑器自带的分配骗了这里的坑特别多。如果你的Profiler显示“SceneManager”或“GUI”类目有大量GC Alloc先别慌很多时候是编辑器模式下Imgui的开销。真机上的Profiler模块只有Runtime相关开销你在真机上看到的分配下降才可信。另外Development Build本身会比Release多不少开销所以最终性能以Release Build为准但GC定位阶段用Development Build抓数据是可以接受的。4. 实战优化手册一套组合拳解决大部分GC问题4.1 对象池的精简实现别再每帧Instantiate了对象池的核心思路简单预先创建一批对象用的时候从池子里取用完还回池子而不是直接销毁。下面这个精简实现会遵循Unity生命周期并自动完成激活/失活using System.Collections.Generic; using UnityEngine; public class ObjectPool { private readonly StackGameObject _pool new StackGameObject(); private readonly GameObject _prefab; private readonly Transform _parent; public ObjectPool(GameObject prefab, Transform parent, int prewarmCount) { _prefab prefab; _parent parent; Warmup(prewarmCount); } private void Warmup(int count) { for (int i 0; i count; i) { var obj CreateNewInstance(); obj.SetActive(false); _pool.Push(obj); } } private GameObject CreateNewInstance() { var go Object.Instantiate(_prefab, _parent); return go; } public GameObject Get() { GameObject result; if (_pool.Count 0) result _pool.Pop(); else result CreateNewInstance(); result.SetActive(true); return result; } public void Release(GameObject obj) { obj.SetActive(false); _pool.Push(obj); } }这段代码有几个细节值得注意用Stack而不是List因为Stack的Pop和Push都是O(1)且不会产生GC Alloc前提是你不在ToArray()之类的方法里跑遍历。池子预热阶段一次性把对象创建好启动时分配一次运行时零分配。释放时不调用Destroy而是失活这样下次取用时省去重新初始化的开销。真实项目里我会再给池子加一个ReturnAllToPool方法在关卡结束或场景切换时统一回收所有活动对象。这样配合场景管理的卸载GC压力会小非常多。4.2 字符串与装箱优化三个替换方案字符串拼接这块我的经验是分场景处理低频拼接比如一周才触发一次的系统日志直接string.Format没问题别过度优化。高频拼接比如每帧刷新的血条UI用StringBuilder或者更极端地用char[]预分配缓冲区自己拼字符。纯数值转字符串比如toString一类的调用Unity 2022提供UnityEngine.UI.Text的SetText重载版本可以避免分配的方式直接传int/float参数。顺手安利一个很多人不知道的小技巧StringBuilder虽然比拼接省垃圾但它内部有char[]缓冲区如果你创建了很多个StringBuilder实例每个都会有一块不小的缓冲区同样会产生GC。建议在需要高频使用的地方放置一个全局复用的StringBuilder实例用前Clear()用完不用管下个周期继续用。装箱的解法更直接尽量用泛型容器比如Listint代替ArrayList。用struct实现接口也会装箱除非定义成泛型约束。所以对性能敏感的回调别用object参数。协程或事件体系的参数尽量用具体类型别什么都往object里塞。4.3 缓存委托与闭包不让匿名函数背黑锅既然闭包和匿名函数会在调用时new对象那你就把委托缓存成字段private UnityAction _onClicked; private void Awake() { _onClicked OnButtonClicked; button.onClick.AddListener(_onClicked); }如果你的闭包需要捕获参数可以把参数放进一个复用的Context对象里或者干脆用带参数的方法签名从外面传参而不是通过捕获。事件系统如果用CSharpEvent的泛型版本堆分配会比object版本少很多但在小端设备上仍有装箱风险建议统一走泛型约束加struct自己的解析。协程的替代方案也值得认真考虑用Update里的计时器状态机代替高频协程。对需要延时执行的逻辑可以定义一个全局的TimeManager用float倒计时数组管理不new任何对象。如果项目已经使用UniTask它会比原生协程更高效但你要注意UniTask也有自己的分配模式不要以为零分配。4.4 事件监听与静态引用的泄漏陷阱GC又卡又开始很多项目的GC问题不只是垃圾太多而是该回收的对象被不小心“拉住”了——也就是说你创建了一大堆永远不会被回收的对象堆水位越来越高GC每次回收的耗时也越来越长。最常见的原因是静态事件未解绑。比如主角的死亡事件绑定了UI的监听主角切场景后你只销毁了主角没让UI解绑那么UI连同主角的所有字段都会被静态事件表强引用住永远无法回收。这种泄漏用Profiler的Memory Profiler模块能看得很清楚——Take Sample后搜索场景对象你会发现一堆已经“关掉”的对象还挂在内存里。我习惯在对象销毁时统一处理事件解绑一个简单的做法是重写OnDestroyprivate void OnDestroy() { if (_onClicked ! null) button.onClick.RemoveListener(_onClicked); EventCenter.Instance.RemoveListenerint(PlayerDead, OnPlayerDead); }还可以给事件中心做一个弱引用封装但现实建议是能解绑就解绑靠弱引用会损失不少性能和不便。4.5 进阶路线Job System、NativeArray与ECS当你的项目达到一定规模字符串和对象池优化已经满足不了需求时就该考虑把高频数据从托管堆搬到非托管内存里了。Unity的NativeArrayT、NativeListT、Job System就是为此设计的。NativeArray分配在非托管区域GC不会去碰它但你需要手动释放.Dispose()。我见过很多团队用NativeArray却不释放直接把内存泄漏到手机上闪退。如果是ECS/DOTS架构实体数据本身在非托管世界GC压力会急剧下降但学习曲线陡峭适合新项目或彻底重构的模块老项目还是优先做好上面那些基础优化更现实。5. 常见问题速查表与避坑经验现象可能原因解决方向帧率平均正常但隔几秒掉一次帧GC完整回收被触发抓Profiler的GC Alloc定位高频分配点场景切换时明显卡顿大量对象一次性销毁/卸载场景切换前提前释放分批卸载或对象池清理UI刷新时偶尔顿一下字符串拼接/装箱/Unity UI网格重建用StringBuilder、SetText重载合并布局更新低端安卓手机特别卡IL2CPP下GC策略和Mono不同编译到IL2CPP用增量式GC减少分配Debug.Log一多就卡Debug.Log本身有额外开销还会累积发布版剥离日志使用封装好的日志开关大量Instantiate后卡顿托管堆碎片化/水位暴涨对象池预创建并定期收缩池容量删除场景后内存不降反升静态事件/单例强引用导致泄漏用Memory Profiler检查泄漏对象补解绑逻辑关于IL2CPP的GC差异我多说两句。Unity的IL2CPP在导出到iOS、Android默认时用的是Boehm GC它与Mono的GC实现不同表现为分配更频繁时GC触发阈值可能更低回收耗时也可能更不稳定。这就是为什么同一个项目编辑器里跑得挺顺一到真机上的IL2CPP Build就卡成幻灯片。我的建议是项目一开始就要把“减少堆分配”当成硬指标而不是等真机上发现问题再来救火。6. 那些年我踩过的GC坑三条经验总结第一GC优化要放在“需求裁剪”之后。有些高频调用本质上是大需求不合理造成的你优化半天字符串不如直接减少调用次数。比如一个角色的属性面板每帧刷新一次改成事件驱动刷新GC直接清零。第二不要迷信某个单一优化技巧。对象池解决了Instantiate垃圾但如果你池子里的对象启动时又各自new了字符串、协程和闭包回收照样频繁。优化要全链路排查单点优化解决不了系统性问题。第三真机永远是最终标准。编辑器数据仅供参考我在一个项目里体验过编辑器GC Alloc不到100KB真机上一秒好几MB的诡异现象原因是真机上Shader变体、UI合批、物理系统的分配全部暴露出来了。所以做GC优化一定要养成“改一版、抓一次真机、再改一版”的习惯。这一篇把GC的来龙去脉和实战打法讲透了。下一期我打算聊聊Unity UI合批与重建Rebuild的那些细节毕竟UI一复杂Canvas本身的消耗和GC完全可以并列为两大隐形杀手。