★ FEATURED ARTICLE 1. 为什么Unity内存管理值得你花时间搞透做Unity开发这些年被问得最多的问题里“为什么我的游戏跑着跑着就卡了”“为什么手机发烫这么严重”“为什么低端机上直接闪退”这三类能占一半以上。追到根子上十有八九都指向同一个东西——内存。Unity的内存管理不像C那样需要你手动malloc和free很多人就以为可以撒手不管了结果项目一上真机就原形毕露。我见过太多团队在编辑器里跑得飞起打包到移动端帧率直接腰斩查了半天发现是纹理没压缩、AssetBundle没卸载、GC垃圾回收每帧都在触发。Unity内存管理的核心说白了就三件事知道内存花在哪了、知道什么时候该释放、知道怎么释放才不卡。它涉及托管堆Mono/IL2CPP的GC管理区域、原生内存引擎底层分配、AssetBundle与Resources的加载卸载策略、纹理与网格的压缩格式选择以及对象池与引用计数的配合使用。这些东西单独拎出来都不算特别难但组合在一起就很容易踩坑因为它们的生命周期和释放时机各不相同。这篇文章适合谁看如果你已经写过至少一个完整的Unity项目对GameObject、Component、Prefab这些基本概念不陌生但一遇到性能分析就头疼不知道Profiler里那些数字代表什么或者你已经在带团队做上线项目需要一套可落地的内存管理规范那这篇内容就是给你准备的。我会从整体设计思路讲到具体实操步骤再到常见问题的排查方法尽量把每个“为什么”都说清楚让你看完能直接在自己项目里用起来。2. Unity内存的整体版图与设计思路拆解2.1 托管内存与原生内存的分工逻辑Unity的内存大致可以分成两大块托管内存Managed Memory和原生内存Native Memory。托管内存由Mono或IL2CPP的运行时管理你写的C#代码里所有new出来的class实例、数组、字符串、委托都在这块区域里。原生内存则是引擎自己分配的比如纹理的像素数据、Mesh的顶点缓冲、AudioClip的采样数据、AssetBundle的压缩数据等这些不受GC管辖需要你显式地通过Destroy或Resources.UnloadUnusedAssets来释放。为什么要分这两块因为它们的分配和回收机制完全不同。托管内存的回收靠GCGC的工作方式是“标记-清除-压缩”这个过程会暂停主线程也就是我们常说的GC Spike。原生内存的回收靠引用计数和显式调用如果引用没断干净内存就一直在那占着直到你调用卸载接口。理解这个分工是做好内存管理的第一步。很多新手会混淆这两者比如以为Destroy了一个GameObject它引用的纹理内存就自动释放了。实际上Destroy只销毁了GameObject和它上面的Component纹理资源如果还被其他地方引用着原生内存是不会释放的。这就是为什么你明明销毁了对象Profiler里纹理内存还是居高不下。2.2 为什么不能完全依赖GC自动回收GC听起来很美好自动帮你清理不再使用的对象但问题在于它的触发时机不可控而且每次触发都要暂停主线程。在移动端一次完整的GC可能要几十毫秒甚至上百毫秒对于要求60帧的游戏来说一帧只有16.6毫秒的预算一次GC就能让你掉好几帧。更麻烦的是托管堆碎片化。GC在回收时虽然会做压缩但频繁的小对象分配和释放会导致堆内存忽大忽小最终堆的容量会稳定在历史峰值附近不会缩回去。也就是说如果你的游戏在某个场景瞬间分配了大量临时对象即使后来这些对象都被回收了托管堆的容量也不会降下来这部分内存就一直被占着。所以正确的思路不是“让GC去管”而是“尽量少产生垃圾让GC没事可做”。具体怎么做后面会详细讲对象池、字符串拼接优化、避免装箱拆箱这些手段。2.3 资源加载策略的选型考量Unity提供了多种资源加载方式Resources、AssetBundle、Addressables、直接引用等。每种方式对内存的影响完全不同。Resources文件夹是最方便的方式直接Resources.Load就能拿到资源。但它的问题在于Resources文件夹里的所有资源都会被编进一个巨大的序列化文件里游戏启动时就要加载这个索引导致启动变慢、内存占用高。而且Resources里的资源无法动态更新卸载也只能靠UnloadUnusedAssets粒度很粗。AssetBundle是更灵活的方案可以按需加载、按需卸载支持热更新。但它的管理复杂度也高得多需要自己维护依赖关系、引用计数、加载和卸载的时机。一旦引用计数算错要么内存泄漏要么资源被提前卸载导致显示异常。Addressables是Unity后来推出的资源管理系统底层还是AssetBundle但封装了引用计数和依赖管理用起来比裸写AssetBundle方便很多。不过它也有自己的坑比如异步加载的回调时机、句柄释放的时机等。选哪种方案取决于你的项目规模和更新需求。小项目用Resources也能凑合但中大型项目或者需要热更新的项目AssetBundle或Addressables是绕不开的。3. 核心细节解析与实操要点3.1 托管堆内存的分配与回收机制托管堆的分配策略是线性分配也就是说只要堆顶还有足够的连续空间分配一个新对象就是移动一下指针的事速度非常快。但问题在于当堆顶空间不够时就会触发GC。GC会遍历所有根对象静态变量、栈上的局部变量、寄存器中的引用等标记出所有可达对象然后清除不可达对象最后做压缩把存活对象移到一起。这个过程中标记和压缩是最耗时的。标记需要遍历整个对象图压缩需要移动内存并更新所有引用。所以减少GC开销的核心就是两点减少堆上的对象数量减少对象之间的引用复杂度。具体到代码层面有几个高频的垃圾产生源需要特别注意字符串拼接每次用拼接字符串都会产生新的字符串对象。在Update里拼接字符串是新手常犯的错误。解决方案是用StringBuilder或者缓存字符串。装箱拆箱把值类型赋给object类型会装箱在堆上分配内存。比如Debug.Log(123)就会装箱因为Log的参数是object。在频繁调用的地方要避免。闭包和委托Lambda表达式捕获外部变量时会生成闭包类实例分配在堆上。在Update里创建委托就会每帧产生垃圾。数组和List的频繁创建每次new一个数组或List都会在堆上分配。应该复用而不是每次新建。协程的yield return new WaitForSeconds每次都会new一个WaitForSeconds对象。应该缓存起来复用。3.2 纹理与网格的内存优化要点纹理通常是游戏里最占内存的资源。一张2048x2048的RGBA32纹理未压缩时占用204820484 16MB。如果游戏里有几十张这样的纹理内存很快就爆了。纹理优化的核心是压缩格式的选择。不同平台支持的压缩格式不同平台推荐格式说明AndroidETC2 (RGB/RGBA)兼容性好压缩比高但Alpha通道质量一般AndroidASTC质量好压缩比可调但低端机可能不支持iOSASTC / PVRTCASTC是主流PVRTC是旧设备备选PCDXT (BC1/BC3/BC7)BC7质量最好BC1最省内存选择压缩格式时要在质量、内存、兼容性之间做权衡。比如ASTC 6x6的压缩比是6:1左右一张2048的纹理压缩后大约2.7MB比未压缩的16MB省了80%以上。但ASTC在部分低端Android设备上不支持需要做降级处理。除了压缩格式Mipmap也会增加约33%的内存占用但对于3D场景中的纹理是必要的可以减少远处纹理的闪烁和带宽消耗。对于UI纹理或者始终以原始大小显示的纹理可以关闭Mipmap。Read/Write Enabled选项也要注意。开启后纹理数据会保留一份在CPU可访问的内存里方便你用脚本读写像素。但如果不是必须应该关闭否则会多占一份内存。网格方面顶点数量和索引格式是关键。顶点数越多占用的内存越大。一个顶点包含位置、法线、UV、切线等属性每个属性都是float或half类型。如果顶点数超过65535索引需要用32位格式内存直接翻倍。所以能合并的网格要合并能减面的要减面。3.3 AssetBundle的引用计数与卸载时机AssetBundle的卸载有两个层面卸载AssetBundle本身和卸载从AssetBundle加载出来的资源。AssetBundle.Unload(false)只卸载AssetBundle的压缩数据从它加载出来的资源比如Texture、Prefab还留在内存里。AssetBundle.Unload(true)会连同加载出来的资源一起卸载但如果这些资源还被其他地方引用着就会导致引用丢失出现粉色材质或者MissingReferenceException。正确的做法是维护一套引用计数系统。每次加载资源时给对应的AssetBundle引用计数加一每次释放资源时引用计数减一。当引用计数为零时调用AssetBundle.Unload(true)彻底卸载。但这里有个坑如果两个AssetBundle共享了同一个资源比如都依赖同一个纹理卸载其中一个AssetBundle时如果直接Unload(true)会把共享的资源也卸载掉导致另一个AssetBundle的资源出问题。所以还需要处理依赖关系确保共享资源被所有依赖它的AssetBundle都释放后才真正卸载。Addressables在这方面做了封装它内部维护了引用计数和依赖图你只需要调用Addressables.Release就行。但要注意Addressables的引用计数是基于句柄的每次LoadAssetAsync都会返回一个句柄必须对应一次Release否则就会泄漏。3.4 对象池的设计与实现细节对象池是减少GC压力的利器尤其适用于子弹、特效、敌人这类频繁创建销毁的对象。核心思想是创建后不销毁用完放回池子里下次需要时直接取出来复用。一个基本的对象池需要包含这几个部分池容器用Dictionary或List存储可用对象。获取接口从池中取出一个对象如果池为空则创建新的。归还接口把对象重置状态后放回池中。容量上限池子不能无限增长超过上限的对象应该真正销毁。实现时要注意几个细节重置状态归还对象时要重置它的位置、旋转、缩放、粒子系统、动画状态等否则下次取出来会带着上次的残留状态。激活与禁用用SetActive(true/false)来控制对象的显示和隐藏而不是Destroy和Instantiate。线程安全如果对象池会在多线程中被访问需要加锁。但Unity的大部分API只能在主线程调用所以通常不需要考虑这个问题。预热在场景加载时预先创建一批对象放入池中避免运行时突然创建导致卡顿。对象池的粒度也要考虑。是按Prefab类型建一个池还是按功能建一个池通常按Prefab类型建池比较合理因为不同类型的对象初始化成本不同。4. 实操过程与核心环节实现4.1 用Profiler定位内存热点Unity Profiler是排查内存问题的第一工具。打开Profiler切换到Memory区域可以看到几个关键指标Total Allocated当前总共分配的内存。Texture Memory纹理占用的内存。Mesh Memory网格占用的内存。Material Count材质数量。Object Count对象数量。GC Alloc每帧的GC分配量这个值在CPU区域的GC Alloc列也能看到。排查时先看GC Alloc。如果每帧都有几百KB甚至几MB的分配那肯定有问题。在Hierarchy视图里按GC Alloc排序找到分配最多的函数然后去代码里优化。再看Total Allocated的趋势。如果内存持续增长不下降说明有泄漏。用Detailed模式拍两张快照对比哪些对象在增长。比如你发现Texture2D的数量一直在涨那就要检查是不是每次加载纹理都没有释放。对于AssetBundle的泄漏可以用AssetBundle Profiler需要安装Asset Bundle Browser插件查看当前加载了哪些AssetBundle它们的引用计数和内存占用。提示Profiler在编辑器里看到的内存数据和真机上有差异因为编辑器本身会占用额外内存。要准确评估真机内存应该用Development Build打包到真机上再通过Profiler连接查看。4.2 托管堆优化的具体代码实践先看一段典型的“垃圾制造机”代码void Update() { string info HP: hp MP: mp; debugText.text info; if (hp 0) { Debug.Log(Player gameObject.name died at Time.time); } }这段代码每帧都在拼接字符串产生大量垃圾。优化后的版本private StringBuilder sb new StringBuilder(64); void Update() { sb.Clear(); sb.Append(HP: ).Append(hp).Append( MP: ).Append(mp); debugText.text sb.ToString(); }但sb.ToString()仍然会分配一个新字符串。如果UI文本更新频率不高可以接受如果每帧都要更新更好的做法是用TextMeshPro的SetText方法它支持直接传入StringBuilder避免额外的字符串分配。再看委托和闭包的优化// 每帧创建闭包产生垃圾 void Start() { for (int i 0; i 10; i) { int index i; button[i].onClick.AddListener(() OnClick(index)); } } // 优化缓存委托 private Actionint cachedOnClick; void Start() { cachedOnClick OnClick; for (int i 0; i 10; i) { int index i; button[i].onClick.AddListener(() cachedOnClick(index)); } }不过上面的优化仍然有闭包因为捕获了index。彻底避免闭包的方式是用自定义的MonoBehaviour或者结构体来传递参数但那样代码会复杂很多。实际项目中按钮点击这种低频操作产生的垃圾可以接受重点优化的是Update里的高频分配。4.3 AssetBundle加载与卸载的完整流程假设我们有一个AssetBundle叫“weapons”里面有一个Prefab叫“Sword”。加载和卸载的完整流程如下// 加载 AssetBundle bundle AssetBundle.LoadFromFile(path); GameObject swordPrefab bundle.LoadAssetGameObject(Sword); GameObject swordInstance Instantiate(swordPrefab); // 使用中... // 卸载实例 Destroy(swordInstance); // 卸载资源 bundle.Unload(false); // 先卸载bundle的压缩数据 Resources.UnloadUnusedAssets(); // 再卸载不再引用的资源但这种方式的问题在于Resources.UnloadUnusedAssets()会扫描整个场景开销很大而且时机不好控制。更好的方式是用引用计数public class AssetBundleManager { private Dictionarystring, AssetBundle loadedBundles new Dictionarystring, AssetBundle(); private Dictionarystring, int refCounts new Dictionarystring, int(); public GameObject LoadAsset(string bundleName, string assetName) { if (!loadedBundles.ContainsKey(bundleName)) { var bundle AssetBundle.LoadFromFile(GetPath(bundleName)); loadedBundles[bundleName] bundle; refCounts[bundleName] 0; } refCounts[bundleName]; return loadedBundles[bundleName].LoadAssetGameObject(assetName); } public void ReleaseAsset(string bundleName) { if (!loadedBundles.ContainsKey(bundleName)) return; refCounts[bundleName]--; if (refCounts[bundleName] 0) { loadedBundles[bundleName].Unload(true); loadedBundles.Remove(bundleName); refCounts.Remove(bundleName); } } }这个简化版没有处理依赖关系实际项目中还需要加载依赖的AssetBundle并确保依赖的引用计数也正确。4.4 对象池的完整实现下面是一个通用的对象池实现public class ObjectPoolT where T : Component { private T prefab; private Transform parent; private StackT pool new StackT(); private int maxSize; public ObjectPool(T prefab, Transform parent, int prewarmCount 0, int maxSize 100) { this.prefab prefab; this.parent parent; this.maxSize maxSize; for (int i 0; i prewarmCount; i) { var obj Object.Instantiate(prefab, parent); obj.gameObject.SetActive(false); pool.Push(obj); } } public T Get() { T obj; if (pool.Count 0) { obj pool.Pop(); } else { obj Object.Instantiate(prefab, parent); } obj.gameObject.SetActive(true); return obj; } public void Return(T obj) { if (pool.Count maxSize) { Object.Destroy(obj.gameObject); return; } obj.gameObject.SetActive(false); obj.transform.SetParent(parent); pool.Push(obj); } }使用时在场景加载时创建池并预热运行时用Get和Return代替Instantiate和Destroy。注意归还时要重置对象的状态比如粒子系统要调用Clear和Stop动画要重置到初始帧。注意对象池不是万能的。对于占用内存很大的对象比如高面数模型池子里缓存太多会导致内存浪费。要根据实际内存预算设置合理的maxSize。5. 常见问题与排查技巧实录5.1 内存泄漏的典型表现与定位方法内存泄漏最明显的表现是内存持续增长不下降。在Profiler里看Total Allocated曲线如果每次进出场景都涨一截从来不降那基本可以确定有泄漏。常见的泄漏原因有这几类事件监听未取消用注册了事件或委托对象销毁时没有用-取消导致委托持有对象的引用GC无法回收。协程未停止对象销毁了但协程还在跑协程里的引用导致对象无法回收。静态变量持有引用静态字段的生命周期和应用程序一样长如果静态字段引用了场景对象对象就永远无法回收。AssetBundle未卸载加载了AssetBundle但没有调用Unload或者引用计数算错导致没有触发Unload。纹理的Read/Write Enabled开启后CPU端保留一份数据如果忘记释放内存会一直占着。定位泄漏的方法用Profiler的Memory Detailed模式在进入场景前拍一张快照退出场景后再拍一张对比两张快照中对象的数量。如果某个类型的对象数量只增不减那就是泄漏点。5.2 GC Spike的成因与缓解策略GC Spike是指GC触发时导致的帧率骤降。要缓解这个问题核心思路是减少单次GC的标记和压缩时间。具体策略包括减少堆上的对象数量对象越少GC标记越快。避免大对象大对象超过85KB会分配在大对象堆上GC处理大对象堆的开销更大。分帧处理如果必须在运行时做大量分配可以分多帧进行避免一次性产生大量垃圾。手动触发GC在场景切换或者加载界面时手动调用GC.Collect()把GC的开销放在玩家不感知的时刻。但要注意手动GC本身也很耗时不要频繁调用。使用增量式GCUnity 2019.1以后支持增量式GC可以把GC的工作分摊到多帧减少单帧的卡顿。在Player Settings里开启Use Incremental GC即可。5.3 常见问题速查表问题现象可能原因排查方法解决方案内存持续增长事件未取消、静态引用、AssetBundle未卸载Profiler对比快照检查事件注册和AssetBundle引用计数帧率周期性下降GC频繁触发查看GC Alloc列减少Update中的分配使用对象池纹理内存过高纹理未压缩、Mipmap开启、Read/Write开启Profiler的Texture Memory选择合适压缩格式关闭不必要的选项加载场景时卡顿资源加载同步进行、GC触发Profiler的加载阶段异步加载、分帧加载、预加载低端机闪退内存超限被系统杀掉真机Profiler降低纹理质量、减少同时加载的资源材质变粉AssetBundle被提前卸载检查Unload调用修正引用计数确保资源被引用时不卸载5.4 独家避坑经验分享坑一Resources.UnloadUnusedAssets的陷阱。这个函数会扫描整个场景找出所有没有被引用的资源并卸载。但它有个问题它不会卸载被静态变量引用的资源也不会卸载被AssetBundle引用的资源。而且它的执行时机是在一帧的末尾如果你在Update里调用它它会在这一帧结束后才执行期间如果又有新的引用产生可能会导致资源被错误卸载。坑二Texture2D的Apply与内存。用代码创建Texture2D并调用Apply后纹理数据会上传到GPU但CPU端的内存是否释放取决于makeNoLongerReadable参数。如果传falseCPU端还会保留一份数据。对于只需要在GPU上使用的纹理应该传true。坑三Mesh的Combine与内存。用Mesh.CombineMeshes合并网格可以减少Draw Call但合并后的网格会占用更多内存。如果合并后的网格顶点数超过65535索引格式会变成32位内存直接翻倍。所以合并前要评估内存预算。坑四粒子系统的内存。粒子系统在播放时会动态分配内存尤其是当粒子数量很多时。可以通过设置ParticleSystem.main.maxParticles来限制最大粒子数避免内存失控。坑五音频的加载方式。AudioClip的Load Type有Decompress On Load、Compressed In Memory、Streaming三种。Decompress On Load会在加载时解压占用内存最多但播放时CPU开销最小Streaming不占内存但CPU开销大适合背景音乐Compressed In Memory是折中方案。要根据音频的使用场景选择合适的加载方式。6. 内存管理的持续优化与团队协作6.1 建立内存预算与监控机制内存管理不是一次性的工作而是需要持续监控和优化的过程。建议在项目初期就建立内存预算比如移动端总共不超过1.5GB其中纹理不超过600MB网格不超过200MB音频不超过100MB其余留给运行时分配。监控机制可以通过自动化工具实现。比如在CI流程中加入内存检测步骤每次打包后自动运行一个测试场景记录内存峰值和GC Alloc数据如果超过阈值就报警。Unity提供了ProfilerRecorderAPI可以在运行时获取内存指标并上报到服务器。using Unity.Profiling; public class MemoryMonitor : MonoBehaviour { private ProfilerRecorder totalMemoryRecorder; private ProfilerRecorder gcAllocRecorder; void OnEnable() { totalMemoryRecorder ProfilerRecorder.StartNew(ProfilerCategory.Memory, Total Used Memory); gcAllocRecorder ProfilerRecorder.StartNew(ProfilerCategory.Memory, GC Allocated In Frame); } void Update() { if (totalMemoryRecorder.Valid) { long totalMemory totalMemoryRecorder.LastValue; if (totalMemory warningThreshold) { Debug.LogWarning($Memory usage high: {totalMemory / 1024 / 1024} MB); } } } void OnDisable() { totalMemoryRecorder.Dispose(); gcAllocRecorder.Dispose(); } }6.2 团队协作中的内存规范在团队协作中内存管理需要有一套统一的规范否则每个人按自己的习惯写最后合在一起就是灾难。建议制定以下规范禁止在Update中分配堆内存包括字符串拼接、new对象、装箱等。代码审查时重点检查。所有Instantiate必须配套对象池除了场景初始化阶段运行时的对象创建必须走对象池。AssetBundle的加载和卸载必须成对出现用引用计数管理禁止直接调用Unload。纹理导入设置统一按用途分类UI纹理、场景纹理、角色纹理分别设置不同的压缩格式和Mipmap选项。定期跑内存测试每个版本发布前在目标机型上跑一遍内存测试记录数据并对比上个版本。这些规范听起来简单但执行起来需要工具辅助。比如可以写一个Editor脚本在导入纹理时自动根据路径设置压缩格式或者写一个代码分析工具扫描Update函数中的堆分配。6.3 面向未来的内存管理趋势Unity的内存管理工具链在不断完善。Addressables已经比较成熟未来可能会成为资源管理的标准方案。增量式GC在后续版本中会进一步优化减少GC Spike。ECS和DOTS的推广也会改变内存管理的模式因为ECS的数据导向设计天然对缓存友好内存布局更紧凑。但无论工具怎么变核心原则是不变的知道内存花在哪、控制分配频率、及时释放不再使用的资源。掌握了这些原则不管用什么工具都能做好内存管理。我个人在实际项目中的体会是内存管理最难的其实不是技术本身而是坚持。优化一次容易难的是在整个项目周期里持续关注、持续优化。很多团队在项目初期做得很好到了后期赶进度就放松了要求结果上线后各种内存问题爆发。所以我的建议是把内存指标纳入每日构建的监控中让问题在萌芽阶段就被发现而不是等到上线前才去救火。
阅读完成 · 觉得有帮助？
