1. 项目概述为什么Unity性能优化绕不开内存与GC做Unity开发尤其是面向移动端或者有大量动态内容的项目性能优化是每个开发者都绕不开的坎。项目跑起来卡顿、发热、闪退十有八九跟内存和垃圾回收GC脱不了干系。我见过太多项目美术资源堆得华丽逻辑写得复杂结果在真机上一跑帧率像过山车时不时来一次长达几百毫秒的卡顿用户体验直接崩盘。问题的根源往往就藏在那些不起眼的new操作、不当的资源引用以及我们对Unity内存管理机制的一知半解里。“内存与GC优化”听起来是个老生常谈的话题但真正能系统化做好、并稳定提升项目性能的团队并不多。很多人优化了半天可能只是在“感觉”上好了点缺乏量化的数据和清晰的优化路径。这篇笔记就是我结合多个项目踩坑填坑的经验聚焦于CPU脚本侧而非美术资源或渲染管线的内存与GC优化实战总结。我们会深入Unity的托管堆Managed Heap世界弄清楚对象怎么生、怎么死、GC何时来“收尸”以及我们如何通过代码层面的控制让这个过程变得平滑、可预测从而释放CPU压力保障游戏的流畅运行。2. 核心原理Unity的托管内存与垃圾回收机制要优化先得懂原理。Unity使用C#作为主要的脚本语言而C#运行在.NET/Mono这样的托管环境中。这意味着我们通过new关键字创建的绝大多数对象类实例、数组、字符串等其内存分配和回收都是由一个叫做“垃圾回收器”Garbage Collector GC的组件自动管理的这片内存区域就是“托管堆”。2.1 托管堆的工作方式不是简单的“借与还”你可以把托管堆想象成一个连续的内存空间。当我们new一个对象时GC会从堆的末端称为“分配指针”位置划出一块足够大的内存给这个对象。这个过程非常快因为只是移动一下指针。问题出在“回收”上。GC采用的是一种“标记-清除-压缩”的算法。当它认为需要回收内存时通常是堆内存增长到某个阈值或者手动触发会暂停所有托管代码的执行这就是GC卡顿的根源然后进行以下工作标记从一些“根”对象如静态变量、当前活动线程栈上的局部变量等出发遍历所有能被访问到的对象并打上标记。那些无法从任何根对象访问到的对象则被认为是“垃圾”。清除将所有未标记的“垃圾”对象占用的内存空间记录为空闲。压缩可选但常见为了减少内存碎片GC会把所有存活的对象向堆的起始端移动紧密排列然后更新指向这些对象的引用。最后将分配指针移动到最后一个存活对象之后。关键在于GC的触发和耗时是不可预测的而且随着堆上存活对象数量增多标记和压缩的耗时也会显著增加。一次Full GC完全回收在移动设备上造成几十甚至上百毫秒的卡顿是家常便饭。2.2 代际回收与增量式垃圾回收现代GC如Unity后期版本采用的Boehm GC及可选的增量式GC引入了“分代”概念。它假设新创建的对象很快会死亡而存活下来的对象可能会活得更久。因此堆被分为三代Gen 0 Gen 1 Gen 2Gen 0新对象分配的地方。GC最频繁地检查这一代回收速度极快。Gen 1在Gen 0的GC中存活下来的对象晋升到此。GC检查频率较低。Gen 2长期存活的对象所在。对这代的GCFull GC代价最高耗时最长。Unity 2019 提供了增量式垃圾回收选项。它允许将一次GC的标记阶段分割成多个小块穿插在帧与帧之间执行从而将一次大的卡顿分散成多次几乎无法察觉的微小卡顿。这对于维持帧率的稳定性非常有帮助但它并不能减少GC的总工作量只是改变了工作的执行方式。注意即使开启了增量GC减少GC发生频率和每次GC的工作量依然是根本的优化方向。增量GC是“治标”减少垃圾产生才是“治本”。3. 内存与GC优化的核心策略与实操要点理解了原理我们就可以有的放矢。优化的核心思想就一句话减少短期存活对象的分配复用长期存活的对象避免不必要的托管堆增长。3.1 策略一杜绝每帧产生的“微垃圾”这是最常见的性能杀手也是优化收益最高的地方。所谓“微垃圾”就是指那些生命周期极短通常只有一帧、但每帧都在大量创建的小对象。高频踩坑点与解决方案字符串操作坑string在C#中是不可变的。任何拼接、$””、格式化string.Format、ToString()都会产生新的字符串对象。优化使用StringBuilder进行复杂的字符串拼接。缓存频繁使用的字符串如UI显示的状态文本、固定的路径前缀。对于数值转文本如分数显示考虑使用自定义缓存机制或对象池来复用char[]数组。// 糟糕的写法每帧产生垃圾 void Update() { healthText.text “Health: “ currentHealth.ToString(); } // 较好的写法使用StringBuilder但需注意在适当时候清空 private StringBuilder sb new StringBuilder(32); // 预分配容量 void Update() { sb.Clear(); sb.Append(“Health: “); sb.Append(currentHealth); healthText.text sb.ToString(); // 这里仍然会产生新的string但避免了中间垃圾 } // 更优的写法数值变化时才更新 private int cachedHealth -1; void Update() { if (currentHealth ! cachedHealth) { cachedHealth currentHealth; // 使用预分配的格式字符串或更高效的更新方式 healthText.text healthFormatString.Replace(“{0}“, currentHealth.ToString()); } }装箱Boxing操作坑将值类型如int,float,struct赋值给object引用类型或接口时会发生装箱在堆上创建一个新的对象。优化避免使用非泛型的集合如ArrayList改用泛型集合ListT,DictionaryTKey, TValue。在需要值类型作为object参数的API调用时格外小心如某些旧版UI事件回调。// 糟糕的写法每次触发事件都装箱 someEvent.AddListener((value) { /* value被装箱 */ }); // 如果委托参数是object // 好的写法使用泛型委托如UnityEventintLambda表达式与闭包坑捕获了外部变量的Lambda表达式会生成一个匿名类在堆上分配。如果这个Lambda被用作频繁调用的回调如Update中的事件、协程就会持续产生垃圾。优化将需要重复使用的Lambda定义成具名方法。对于简单的条件判断直接写if语句可能比用WhereLambda更高效虽然可读性可能下降。// 可能产生垃圾的写法如果enemies列表很大且每帧调用 var aliveEnemies enemies.Where(e e.IsAlive).ToList(); // Lambda捕获e且ToList()分配新列表 // 优化写法使用for循环和预分配列表 aliveEnemiesList.Clear(); // 复用同一个List for (int i 0; i enemies.Count; i) { if (enemies[i].IsAlive) { aliveEnemiesList.Add(enemies[i]); } }Unity API调用返回数组坑GetComponentsT()不带参数的版本、Physics.OverlapSphere等许多Unity API为了返回结果会每次分配一个新的数组。优化使用非分配版本的API。这些版本通常要求你传入一个预分配的数组或列表作为参数来填充结果。// 糟糕的写法每帧分配新数组 void Update() { Collider[] hits Physics.OverlapSphere(transform.position, radius); // ... 使用hits } // hits数组在本帧结束后变成垃圾 // 优化的写法复用数组 private Collider[] overlapBuffer new Collider[32]; // 根据预估的最大数量预分配 void Update() { int numHits Physics.OverlapSphereNonAlloc(transform.position, radius, overlapBuffer); for (int i 0; i numHits; i) { // 使用 overlapBuffer[i] } }3.2 策略二积极使用对象池对于需要频繁创建和销毁的游戏对象如子弹、特效、敌人实例化Instantiate和销毁Destroy的成本极高不仅是托管堆的分配/回收还涉及引擎底层Native层的操作。对象池是解决这个问题的标准答案。对象池的核心思想在游戏初始化时预先创建一定数量的对象并禁用它们存入一个“池子”。当需要时从池中取出一个对象激活并设置其状态。当对象不再需要时不是销毁它而是将其禁用并放回池中。实操要点与避坑指南池子大小设计池的大小需要根据游戏场景预估。设太小运行时可能不够用需要动态扩容产生新的分配设太大浪费初始内存。一个好的实践是设置一个初始大小并允许按需扩容但扩容后最好就保持住避免频繁伸缩。对象的复位从池中取出的对象必须将其状态完全重置到“出厂设置”。这不仅仅是位置、旋转还包括所有脚本的变量、物理状态、粒子系统等。一个常见的错误是忘记重置某个协程或计时器导致对象行为异常。分层管理对于不同类型的对象应使用不同的池子。一个通用的GameObjectPoolT模板类非常有用可以通过泛型来管理特定组件类型。与Unity生命周期协调池中对象被禁用时其Update、OnTriggerEnter等MonoBehaviour回调不会执行。这通常是期望的行为。但要注意一些基于时间的逻辑可能需要手动暂停或重置。// 一个极简的对象池示例框架 public class SimplePoolT where T : Component { private QueueT pool new QueueT(); private T prefab; private Transform parent; public SimplePool(T prefab, int initialSize, Transform parent null) { this.prefab prefab; this.parent parent; for (int i 0; i initialSize; i) { T obj GameObject.Instantiate(prefab, parent); obj.gameObject.SetActive(false); pool.Enqueue(obj); } } public T Get() { if (pool.Count 0) { T obj pool.Dequeue(); obj.gameObject.SetActive(true); // 这里可以调用一个自定义的复位方法 // obj.GetComponentIPoolable()?.OnSpawn(); return obj; } else { // 池空扩容在实际项目中这可能意味着需要优化初始大小 T obj GameObject.Instantiate(prefab, parent); return obj; } } public void Return(T obj) { obj.gameObject.SetActive(false); // 复位逻辑 // obj.GetComponentIPoolable()?.OnDespawn(); pool.Enqueue(obj); } }实操心得不要过度设计对象池。项目初期可以先用简单的池随着需求复杂再引入更高级的功能如按需加载、分组管理。Unity Asset Store也有一些优秀的对象池插件如Pooly但在引入前要评估其开销是否适合你的项目。3.3 策略三警惕隐秘的“内存泄漏”在托管环境中“内存泄漏”通常不是指内存永远无法访问而是指无意的、长时间的生命周期持有导致本该回收的对象一直存活从而增加GC压力和内存占用。常见泄漏场景事件/委托未注销这是C#开发中最经典的泄漏。当你将一个对象的方法订阅到一个静态事件或长生命周期对象的事件时事件源就持有了对该对象的引用。即使你不再需要这个对象只要事件订阅还在GC就不会回收它。解决方案在对象生命周期结束时如OnDestroy务必取消所有事件订阅。使用弱事件模式如WeakReference是更高级的解决方案但实现复杂。public class LeakyClass : MonoBehaviour { private void OnEnable() { GlobalGameManager.OnGameOver HandleGameOver; // 订阅 } private void OnDisable() { // 必须配对出现 GlobalGameManager.OnGameOver - HandleGameOver; // 取消订阅 } private void HandleGameOver() { /* ... */ } }静态引用静态字段的生命周期与应用程序域相同。如果一个静态变量引用了一个大对象如一个巨大的配置列表那么这个对象在程序运行期间永远不会被回收。解决方案谨慎使用静态变量。对于缓存数据考虑使用WeakReference或在适当的时机如场景切换手动置为null。协程Coroutine的引用启动一个协程StartCoroutine会创建一个Coroutine对象。如果这个协程内部引用了某个类的实例变量并且协程因为yield return new WaitForSeconds这样的指令而挂起那么该实例在协程结束前不会被释放。如果协程因为条件永远不满足而无法结束就造成了泄漏。解决方案在OnDestroy中停止所有在本对象上启动的协程StopAllCoroutines。对于复杂的协程生命周期管理可以考虑使用专门的协程运行器来跟踪和停止。资源引用未释放虽然Unity资源如Texture, Mesh是Native对象但你的脚本中如果持有对Material、Sprite等派生资源的引用也会阻止引擎卸载底层AssetBundle。确保在场景或UI关闭时解除对动态加载资源的引用。3.4 策略四善用结构体Struct与值类型值类型如基本类型、自定义struct分配在栈上或作为引用类型的一部分内联在堆上其生命周期与包含它的上下文同步不存在GC开销。当满足以下条件时考虑使用struct表示一个轻量级的数据集合如坐标点、颜色、简单的状态数据。逻辑上是一个不可变的、小的数据块。需要频繁创建和销毁且数量巨大。使用结构体的注意事项避免装箱如前所述将结构体赋值给object或接口会装箱。注意拷贝语义结构体是值类型赋值和传参会进行内存拷贝。对于大型结构体如超过16字节频繁拷贝的性能开销可能超过其避免GC带来的收益。这时需要做性能测试。不可变性设计为只读的结构体readonly struct能更清晰地表达意图且编译器可能做更多优化。4. 性能分析工具链用数据驱动优化优化不能靠猜必须依靠工具获取数据。Unity提供了一套强大的性能分析工具链。4.1 Unity Profiler你的第一道防线Profiler是性能分析的核心。对于内存和GC重点关注以下几个模块CPU Usage查看GarbageCollector项所占用的CPU时间。如果某一帧GC耗时突然飙升就是需要重点排查的信号。Memory切换到Simple或Detailed视图。Total Used Memory了解整体内存占用。GC Used Memory托管堆的大小。观察其增长趋势是平稳、阶梯式上升GC后部分释放还是只增不减可能泄漏。GC Allocated in Frame这是关键指标它显示这一帧在托管堆上分配了多少字节的内存。你的优化目标就是让这个数字尽可能低且平稳。Deep Profiling与Allocation Call Stacks在Memory模块中开启Deep Profiling对性能有较大影响建议在测试场景使用并勾选Record Allocations Call Stacks。这样当你在游戏中操作时Profiler会记录下每一个内存分配是在哪一行代码触发的。这是定位“微垃圾”来源的最直接方法。使用流程在疑似卡顿的时刻暂停游戏在Profiler中查看对应帧的GC Alloc然后点击该帧在Memory的Allocated by Script部分查看分配详情并展开调用栈定位到你的代码文件行数。4.2 内存快照与内存分析器Memory ProfilerUnity的Memory Profiler包通过Package Manager安装提供了更强大的内存分析能力。它可以捕获某一时刻的完整内存快照并可视化地展示内存中的对象、它们之间的引用关系以及占用大小。核心用途发现内存泄漏在场景A加载后抓取快照1切换到场景B再切回A抓取快照2。对比两个快照查看哪些本应被释放的对象如场景A特有的资源、UI元素仍然存在并沿着引用链找到是谁在持有它们。分析资源内存清晰看到纹理、网格、音频等资源的内存占用识别哪些资源过大或未被共享。理解托管堆布局查看托管堆中对象的类型、数量、大小分布快速定位分配最多的类型。4.3 自定义性能标记与日志除了依赖可视化工具在代码关键路径插入自定义的性能标记和日志也非常有用。System.Diagnostics.Stopwatch用于测量一段代码执行的具体耗时。UnityEngine.Profiling.Profiler.BeginSample/EndSample在Profiler的CPU时间线中插入自定义的采样区块方便定位函数耗时。GC触发计数与耗时统计可以通过System.GC.CollectionCount来获取GC发生的次数结合时间差计算GC频率。在开发板上可以记录每次GC前后的帧时间来判断影响。public class GCMonitor : MonoBehaviour { private int lastGCCollectionCount; private float lastGCTime; void Update() { int currentCount System.GC.CollectionCount(0); // Gen 0的回收次数 if (currentCount ! lastGCCollectionCount) { float deltaTime Time.time - lastGCTime; Debug.Log($GC occurred! Gen0 Count: {currentCount}. Time since last GC: {deltaTime:F2}s); lastGCCollectionCount currentCount; lastGCTime Time.time; } } }5. 高级主题与实战疑难排查当应用了基础策略后项目可能还会遇到一些棘手的性能问题。5.1 大世界/开放场景的内存管理对于无缝大世界或开放场景所有资源不可能同时加载。需要使用动态加载和卸载技术。场景流式加载Scene Streaming将世界分割成多个子场景根据玩家位置动态加载和卸载。资产按需加载Asset Bundle/Addressables将资源打包运行时根据标签或地址异步加载。关键是及时卸载不再需要的资源。使用Addressables系统时要理解其引用计数机制确保在适当的时候调用Release或ReleaseInstance。LOD多层次细节与 occlusion culling遮挡剔除虽然主要是渲染优化但减少了渲染的物体数量也间接减少了需要保持在内存中的渲染相关数据如GPU Buffer的压力。5.2 UI系统的内存陷阱现代UI如UGUI是内存和GC的重灾区因为UI元素频繁变化且涉及大量Draw Call和网格重建。UI对象池对于频繁打开关闭的弹窗、列表项如背包物品、聊天记录必须使用对象池。UGUI的ScrollRect配合对象池是标准做法。重建优化Canvas的“批处理重建”过程是CPU密集型的。减少Canvas数量将动态UI和静态UI分离到不同的Canvas上。避免频繁改变UI元素的属性如Image的sprite、Text的text、LayoutGroup下子物体的增减这些都会触发重建。图集Atlas管理将大量小图打包成图集可以减少Draw Call和内存碎片。但要注意图集尺寸不能超过目标平台限制且要管理好图集的生命周期避免同一个精灵存在于多个图集中造成冗余。5.3 脚本编译与域重载在编辑器模式下每次修改并保存脚本都会触发脚本编译和“域重载”Domain Reload这个过程会清空所有托管内存重新初始化静态变量。虽然不影响运行时但会打断开发流程。对于大型项目域重载可能耗时几十秒。优化建议在Unity 2020.3中可以在Editor设置中关闭“Enter Play Mode Settings”中的“Domain Reload”。但这要求你的代码不能依赖静态变量在Play Mode中的持久化状态需要更健壮的初始化逻辑。对于团队项目需谨慎评估。5.4 第三方插件与SDK接入广告、分析、社交等第三方SDK时它们可能会在后台创建线程、持有静态引用或频繁分配内存。这些问题在Profiler中可能表现为“非用户代码”的分配。排查方法在Profiler的CPU或Allocation视图中注意观察非自身项目DLL的分配如GoogleMobileAds、Firebase等。如果发现某个SDK分配异常查阅其官方文档看是否有初始化配置、缓存设置或清理接口可以调用。隔离测试在集成SDK前后分别进行性能测试量化SDK带来的开销。6. 建立长效的优化文化与流程性能优化不是一次性的任务而应融入日常开发流程。设立性能预算Performance Budget为关键指标设定红线。例如每帧GC分配不超过2KB主场景内存峰值不超过150MB99%的帧率不低于30fps等。在CI持续集成流程中加入性能测试自动检查提交的代码是否导致预算超标。代码审查关注性能在代码审查中除了功能正确性将性能作为一个审查维度。警惕每帧的new操作、未取消的事件订阅、可能装箱的代码。定期进行性能回归测试在每个版本发布前使用固定的测试场景和流程进行性能测试并与基线版本对比防止性能在迭代中不知不觉地退化。知识分享与培训让团队成员尤其是新加入的开发者了解项目中的性能禁忌和最佳实践。一篇内部的技术分享文档或一个简单的检查清单能避免很多低级错误。内存与GC优化是一场与细节的持久战。它没有银弹需要的是对引擎原理的深刻理解、对代码的谨慎编写以及借助工具进行科学的分析和验证。当你养成了“分配感知”的编码习惯并能熟练运用Profiler等工具定位问题时你会发现那些恼人的卡顿和闪退将逐渐远离你的项目流畅稳定的体验将成为你产品的坚实基石。优化之路永无止境但每一次让帧率更稳、让内存更低的努力都会在玩家的体验中得到回报。
