很多人做 Unity 性能优化时上手就看 Draw Call、看帧率、看 CPU 耗时但往往等到游戏在低端手机上频繁闪退或者玩家反馈“玩久了越来越卡”时才想起来查内存。我见过不少团队陷入同一种困境用 Profiler 一看内存占用高得吓人手动调用 GC画面又卡了一下切了几次场景之后内存像泻药一样止不住等到想查到底是谁分配了对象时Unity 自带工具给出的信息又不够直观。结果陷入“加缓存、清缓存、调用 GC、重启游戏”的恶性循环。这里想先给一个更底层的主判断Unity 内存管理的核心难题不在于你占用了多少内存而在于你无法预期内存什么时候涨、为什么涨、释放后是否真的能还给系统。所以做内存优化真正要学会的不是“省内存”这一招而是管理“分配与释放的生命周期”。这篇文章会从内存机制本身讲起结合资源加载、场景切换、托管堆分配、工具链排查等几个真实作战场景把这个话题拆透。第二期内容不会去列一堆“调优大法”而是想帮大家先建立一套稳定的判断框架——遇到内存问题你该先怀疑哪里、按什么顺序查、用什么办法验证。1. 先明白一件事Unity 的内存不是你一家的内存1.1 为什么游戏越玩越卡重启又好了先从一个最典型的现象说起。一款 Unity 游戏在 Android 手机上运行刚开始流畅玩了十分钟后开始掉帧二十多分钟后操作明显变慢切场景时偶尔卡死。玩家会直接总结为“垃圾优化”。但重启应用后又恢复正常。这个表现通常指向两类问题一类是资源泄漏——加载过的对象没有释放每进一次新界面就带走几十兆内存一类是托管堆的频繁分配和 GC 压力——内存没有泄漏但每一帧都在产生大量垃圾对象导致 GC 频繁介入CPU 被反复打断。很多开发者只记得查前者因为 Profiler 里内存曲线一路向上像极了泄漏。但真正的麻烦往往是后者内存总量稳定GC 却一直在“摘果子”每次摘果子都让游戏卡一下。于是游戏表现为“阶段性掉帧”而不是持续飙升。这两种原因的处理方向完全不同排查顺序也完全不同。所以遇到内存问题先别急着“卸载资源”“清缓存”先确认异常是“总量持续上涨”还是“稳定但周期性卡顿”。前者看泄漏后者看分配。1.2 把内存想象成公共厨房理解 Unity 内存管理可以把它想象成一个对外开放的公共厨房。厨房里有两块核心区域一块是固定的灶台和橱柜相当于引擎原生内存由 C 侧管理资源和渲染数据常驻在这里另一块是临时加出来的备菜区相当于托管堆由 C# 侧的 GC垃圾回收器维护用来频繁创建和丢弃临时对象。问题是备菜区不像橱柜那样“用完擦干净就完了”。C# 里的对象不再被引用后不会立刻消失而是要等 GC 在某个时间点统一清扫。清扫需要暂停执行这就是“卡顿”的来源。清扫完之后空闲内存也不一定会立刻归还给操作系统这就解释了为什么切完场景内存曲线还在高位徘徊。更麻烦的是备菜区里如果总是残留各种大小不一的零碎空间新来的“大块食材”找不到连续位置放GC 就得频繁做线性压缩和移动。这个过程在 Profiler 里会被标记为 GC 的耗时飙升但你看代码又很难找到具体是哪个类导致的。1.3 把优化目标改成“可预期”所以内存管理的关键指标不应该是“内存占用尽量低”而应该是“分配和回收尽量可控”。这听起来像一句废话但落到实际操作上会改变很多习惯你会更关注“谁在 Update 里分配了对象”而不是只看“启动后总内存有多少”。你会更关注“场景卸载后旧资源是否真的被释放”而不是只看“Profiler 峰值”。你会更关注“托管堆的 GC 什么时候触发”而不是只在“卡顿发生时”无脑调用System.GC.Collect()。整个第二期内容就是围绕“分配可控、释放可预期、工具可查”这三个目标展开的。2. 托管堆和原生内存Unity 内存到底是谁在管2.1 引擎侧和脚本侧各有各的内存地盘很多初学者容易混淆一件事Unity 里说的“内存”其实横跨原生层C和托管层C#两个世界。Unity 引擎本身用 C 编写纹理、网格、Shader、音频、动画片段等资源本质上都存在于引擎原生内存里。这些资源的申请和释放由引擎的资源生命周期管理你加载了一个 AssetBundle实例化了一个 GameObject这些操作最终都会在引擎侧产生原生内存。而 MonoBehaviour 里写的 C# 类、List、Dictionary、字符串拼接、LINQ 查询等则运行在 Mono 或 IL2CPP 的托管环境中。托管堆里的对象由 GC 统一管理GC 会追踪哪些对象不再被引用并在某个时候回收它们。两层内存互相可见度不高。你在 Profiler 里看到的 Overall 内存是引擎原生内存和托管堆的直接相加但很难直接看到“这个纹理是哪一次加载留下来的”“那个字符串数组是谁分配的”。2.2 Mono 或 IL2CPP 只是执行环境GC 机制才是关键不同脚本后端会改变内存管理的表现。使用 Mono 时补全——调试相对方便但堆内存模型更接近传统 .NET切换到 IL2CPP 后AOT 编译会让静态内存排布有差异但 GC 的逻辑依然来自 Unity 提供的 Boehm GC 或增量式 GC 方案。这里不必过分纠结“换成 IL2CPP 内存会自动减少”这种说法。IL2CPP 的优势主要在包体、执行效率和跨平台内存机制层面的改变远没有想象中那么大。真正决定托管堆失控的还是代码里的分配行为。所以判断执行环境时可以记住一个简单的经验如果你的问题出在“字符串拼接特别多”“容器频繁扩容”“临时数组一帧一建”换 IL2CPP 并不会帮你解决。这些垃圾产生的根源在代码不在执行环境。2.3 托管堆为什么会“只涨不降”托管堆设计的初衷是高效分配对象内存够时新对象像往抽屉里放东西一样不断向上堆叠当 GC 检测到内存压力或触发条件时它会遍历对象引用图把不再引用的对象标记为垃圾然后回收空间。但回收之后GC 通常不会把内存还给系统。它会保留这个堆的容量以便下一次分配时可以复用。于是你看到的现象就是游戏启动时托管堆只有几 MB运行一段时间后某个场景里需要批量创建对象堆一下涨到 200 MB之后即使那些对象全部被释放堆容量依然维持在 200 MB 左右。这不是泄漏而是堆的“水位”上去了就不愿降下来。从 Profiler 图上看就是一条阶梯式上升的曲线。你要处理的核心不是“让水位降回几 MB”而是“别让峰值水位无缘无故上涨”。注意看到托管堆的 Reserved Memory 一直很高不要立刻判断为泄漏。先看当前堆里“存活对象”的大小。如果存活对象不大但保留容量很高说明是历史高峰期留下的“顶”需要做的事是减少历史峰值分配而不是反复 GC。3. 一次真实的卡顿排查我最后找到了 5 个分配热点3.1 用 Profiler 还原现场不要凭感觉猜有一次一个朋友的项目遇到出招时掉帧招式的特效和伤害计算都比较复杂。他怀疑是特效加载太慢想用缓存 预热的方式解决。我用 Profiler 录了一段战斗过程的帧数据切换到 CPU Usage 模块排序后看到真正的问题不是特效资源加载而是几个高频调用引起的 GC 分配角色每次攻击时会拼接技能描述字符串并在 UI 上显示。字符串拼接使用了string.Format每帧触发时都会分配新的字符串。技能伤害结算里用了一个Dictionary每次获取配置会增加一层封装返回一个临时 List然后立刻被丢弃。实现了一个“筛选敌人”的函数内部用 LINQ 的Where().ToList()这个调用隐藏了非常多的临时分配。Update 函数里持续判断敌人距离并用transform.position创建临时 Vector3 列表每帧产生一个小的 container。绘制小地图时用Camera.WorldToScreenPoint计算坐标每帧生成结构体数组并交给 UI 绘制。这些在单帧里看起来都微不足道但一秒钟发生 60 次、三个角色同时在战斗里产生的垃圾数量就足以让 GC 一秒钟工作好几次。3.2 先分类再决定优化策略处理时我没有一上来就改成 StringBuilder 和对象池而是先把问题归成三类类型 A高频、少量、可轻易避免比如 Update 里的字符串拼接直接改代码避免分配。类型 B低频、一次性但量大比如切场景时的英雄列表、任务奖励配置可以不优化生成过程但要确保生成后能复用或使用后能被及时清理。类型 C高频、数据结构复杂比如战斗管理里的 List、Dictionary更适合用对象池 缓存机制而不是每一次都重新分配。这个分类方式后来变成我处理内存分配问题时的默认路径先看调用频率再看单次分配量然后决定是“改写法”还是“引入缓存”还是“接受分配但错峰执行”。3.3 这里最容易踩的坑在 Update 里做逻辑判断但忘了隐藏分配排查这类问题的难点在于分配热点往往藏在看似无害的写法里。常见的隐藏分配场景包括字符串拼接a b c、string.Format、${var}都会分配。LINQWhere、Select、OrderBy、ToArray大部分会产生 delegate 或 iterator。装箱把值类型丢进object类型参数、老版本的ArrayList、Hashtable。闭包匿名函数捕获外部变量每次执行都会生成一个新的闭包类实例。协程WaitForSeconds如果用new创建每次等待都会分配一个对象。数组和 List 扩容可以预分配容量的场景没有初始化容量。判断方法不复杂在 Profiler 的 Hierarchy 视图里按GC Alloc排序找出顶部的函数逐一检查这些函数的实现——这样定位准确率比看代码结构要高得多。4. 资源加载与释放AssetBundle 不是清理了就万事大吉4.1 从 Resources 到 Addressables资源加载思路的演进Unity 的资源管理早期依赖Resources文件夹所有资源打进包体运行时直接用Resources.Load加载用Resources.UnloadUnusedAssets清理未使用的资源。这种方式在小型项目里够用但问题也很明显Resources 目录像一块永不淘汰的公共储存间——资源一旦放进去就全部打包不存在“可下载”和“可释放”的高度可控性。后面逐渐有了 AssetBundle资源被拆成一个个 Bundle由代码按需加载、释放。AssetBundle 给了团队精细控制权但引入了依赖管理的地狱——不同 Bundle 之间的依赖、引用计数、版本更新、资源冗余都需要团队自行维护。再往后Addressables 试图把这种精细控制封装成更友好的 API配合引用计数来管理资源的加载和释放。它的目标不是消灭 AssetBundle而是把复杂的依赖和生命周期问题收敛成一套更易用的接口。从内存机制角度看这套演进的核心变化是资源不再天然驻留而是由你决定何时加载、何时卸载、卸载后是否需要保留引用。这比“加载更多资源”更有价值。4.2 为什么加载了资源却释放不掉实际开发者经常遇到一个困惑我明明调用了 AssetBundle.Unload(true)为什么场景里的纹理和网格还躺在内存里原因是优先级理解错了。AssetBundle.Unload(true) 会强制立即卸载所有从该 Bundle 加载的对象哪怕这些对象还被场景引用着后果是场景里的对象变成“无源之水”显示会变紫或丢失网格。Unload(false) 则只卸载 Bundle 的镜像文件已经加载的对象还会继续存留直到下次自动清理或你手动逐个卸载。所以理想流程是先把场景中对资源的引用都释放比如移除不必要的 Sprite、释放纹理引用。再调用 Assets 未使用资源清理比如Resources.UnloadUnusedAssets()。最后调用 AssetBundle 的卸载接口。但这种方式有一个前提你必须能准确判断对象是否还被“非场景”的强引用持有。比如你有一个全局静态容器保存了所有已加载的角色的图标 Texture2D即使你卸载了所在 Bundle这个 Texture2D 也不会被释放因为在 C# 对象图里仍“活着”。4.3 资源管理里最容易被忽略的“引用泄漏”很多资源泄漏不是加载接口使用错误而是“业务逻辑引用泄漏”。比如有两个界面A 界面是一个英雄详情界面B 界面是设置界面。每次打开 A 界面都会加载对应英雄的立绘纹理切换到 B 界面时A 界面被销毁但全局的事件管理器里一个订阅了 A 界面刷新事件的方法没有退订。于是 A 界面对象本身没被销毁它引用的那批纹理自然也无法被回收。排查这类问题时最有效的方式不是盯着内存总览看而是用 Memory Profiler 抓一份快照查找“仍然存活但不应存在”的对象实例。看它们的引用路径就能定位到是哪个持久化对象持有它们。提示动态加载资源前先做一个“加载、使用、卸载、快照”四步测试。加载前后各抓一次 Memory Profiler 快照对比差异对象。如果卸载完成后仍然有多余对象残留看引用路径通常能直接找到泄漏源头。5. 场景切换与内存回落为什么切了几次场景后内存越来越高5.1 场景卸载不等于内存释放场景切换是内存峰值的重灾区。如果游戏里有两个场景主城场景有大量建筑纹理和角色模型战斗场景有特效和音效。玩家从主城进入战斗再从战斗返回主城。每次切换场景都伴随着 UI 控件的销毁与重建、角色配置表的重新加载、特效资源的新一波缓存。场景切换时Unity 会销毁当前场景的 GameObject。问题是这些被销毁的对象的原生资源不一定同步释放。纹理、音频、网格资源的最终释放依赖于引擎侧的引用计数和资源管理器。如果你在代码里额外持有任何资源的引用泄漏就会叠加。更多时候场景切换后的高内存是“可复用的资源不断变体”同一个角色的战斗模型换了一套特效特效里的贴图换个颜色组合资源系统无法识别出这是同一个 Shared Material于是每套表现都缓存在内存里。5.2 让旧资源在合适的时机被清理在场景切换之后常见做法是调用Resources.UnloadUnusedAssets();这个接口会扫描当前资源集找出不再被引用的资源并释放它们。但注意它不是立刻执行的而是在后台异步完成。而且它无法释放“仍然被持久化引用”的对象。所以要把它放在场景切换完成后的一个合适时机而不是帧底部。我一般会在切换流程里插入一个加载界面然后在加载界面等待期间调用配合 yield 等待确保清理完成后再进入新场景的可交互状态。5.3 处理“场景常驻 动态加载”混合模式大多数现代 Unity 项目不是纯粹地切换场景而是“一个常驻场景 动态加载多个功能场景”。这种模式下内存管理的难点就不是“场景卸载后能不能清理”而是“常驻场景里的对象持有临时资源的引用导致资源卸载失败”。比如常驻场景里有个 UI 管理器负责管理每个面板的实例。面板 A 打开时会生成英雄列表列表里每一项持有一张远程头像 Sprite。关闭面板 A 时列表被销毁但 UI 管理器持有的一个“最近打开的面板引用”还没来得及清空。结果无论怎么切换场景这批头像资源都会一直被引用着。定位方法还是回到快照内存异常时抓快照看哪些资源本应释放但仍在图上顺着路径找到常驻对象然后把“旧引用清理”这一步写进面板关闭流程里。6. 对象池、容器和缓存释放绑定的正确姿势6.1 对象池是解决高频分配的首选但不是万能钥匙对象池的核心思想是把创建和销毁变成取出和归还。战斗里的子弹、飘字、特效、敌人这些高频生成的对象都适合放到池里避免每帧创建新实例。但对象池实践中有一个常见误区池里默认保存了最大数量限制。如果不加限制敌人一波波的生成池会越来越大。当场景转化后这些对象仍在池里待着内存自然就降不下来。有效的对象池策略应该包含池的初始容量预分配但不必按极限情况分配。池有最大空闲数量超过最大值后允许释放多余实例。对象归还到池时尽量把它的数据恢复到初始状态避免下次取出时残留。如果要支持资源切换池里的对象在释放时需要依赖的加载上下文否则“回池”仍然会泄漏。6.2 容器要预分配容量避免扩容风暴List、Dictionary 这类容器的内部存储是按需扩容的。每当你 Add 一个元素时如果容量不够就会申请一个更大的内部数组把旧数据复制过去再丢弃旧数组。这个过程在数据量小的时候无所谓但如果你在游戏初始化时往 List 里分批添加几千条配置或每次进入战斗时创建一个只用到几步就被清空的 List隐藏的 GC 分配量会非常可观。常见的改进方式是尽量为容器预留容量var enemies new ListEnemy(64);如果你知道上限就按上限分配如果不知道可以取一个合理的经验值。至少可以避免大量小步扩容引起的碎片和分配高峰。6.3 对象池要配合“生命周期上下文”如果对象池里的对象引用了场景里的资源——比如敌人挂了一堆粒子特效、角色动态加载了皮肤贴图——那么这些对象的引用必须能在场景切换时统一释放。否则你只会把“频发创建”的垃圾问题转变成“池中永远驻留”的容量问题。更安全的做法是把对象池按“场景分类”。每个场景维护自己的池容器。场景退出时将池一并清空归还其中的实例并卸载它们持有的资源。7. 该不该手动调用 GC很多人踩过这个坑7.1 手动 GC 是“止痛药”不是“治疗方案”许多开发者的第一反应是内存太高了调用System.GC.Collect()强制垃圾回收。这在调试期看着有用内存数字确实掉下来了帧率也恢复了。但它有代价。手动 GC 会引发一次完全阻塞式回收游戏会明显地卡一下在手机上尤其明显。而且如果代码里仍然持续产生大量垃圾GC 也只是暂时清空了堆新的分配高峰很快又会出现。正确使用场景是场景切换后的静态清理点。大型战斗结束后确定玩家正在加载界面或看结算动画。接受暂时的低帧率用来避免后续更多次的间歇性卡顿。不要在 Update 或高频逻辑里调用。它不会阻止垃圾产生只会提前收割并把 CPU 开销集中到某一帧。7.2 增量式 GC 也不是一劳永逸Unity 提供增量式 GCIncremental Garbage Collection原理是把一次 GC 的长暂停拆散到多帧里从玩家的观感上降低卡顿。但它并没有减少 GC 的总工作量也没有减少堆内存的占用。它只是让卡顿更衣蔽没有从根源上解决。如果项目里存在严重的分配峰值和泄漏即使开启增量式 GC也可能出现“稳定但恼人的周期性掉帧”或者仍在低端机上出现 GC 停顿。所以增量式 GC 更适合作为体验优化手段用于“短时间内可接受的 GC”——更利于做移动端优化。实际判断标准是在 Profiler 里看 GC 的耗时是否还能被其他逻辑掩盖。如果 GC 每次出现都会制造明显卡顿说明代码层的分配压力仍然过大这时候该做的是回到定位分配热点而不是调 GC 模式。8. 用工具支撑判断Profiler 与 Memory Profiler 的正确打开方式8.1 从 CPU 视图切入你看到的是“分配结果”Unity Profiler 里与内存分析相关的入口非常多常用的几类CPU Usage模块同样可以帮助定位脚本分配热点因为它记录了每个函数的GC Alloc字段。Memory模块看总内存、资源分类、托管堆容量、Mono 堆与原生内存之间的关系。Memory Profiler Package可以抓取详细快照分析对象引用和资源来源。引擎自带的Allocation和Memory页面在 Windows 编辑器里打开Window Analysis Profiler可以配合使用。我比较推荐的最小观测步骤是先在 CPU 视图里按 GC Alloc 排序找出 Top 函数。修正代码后录一段同场景数据对比 GC Alloc 前后的总量。再切到 Memory 视图看托管堆的 Reserved Memory 是否还在涨。如果仍有存续内存异常用 Memory Profiler 快照查引用链。这套顺序能避免一个常见盲区一开始就把时间花在分析资源泄漏上却没有发现真正的元凶是每帧分配。8.2 Memory Profiler 快照怎么读使用 Memory Profiler Package 时通常进入以下流程在 Player 或 Editor 中待分析场景。Capture 一个 Baseline 快照。执行“加载资源、打开界面、销毁界面、卸载资源”。再 Capture 第二个 Intermediate 快照。执行一次场景切换或大量 GC Alloc 操作。最后 Capture 一个 Final 快照。然后比较第二个快照与基线快照排查新增的 Managed Object 和 Native Object再比较第三个快照与第二个快照看哪些对象没有回到基线水平。如果某些对象在 Final 快照中依然存在点击后查看“Reference”面板找到持有它们的源。通常你会看到一个 Manager 单例、全局静态配置表或未退订的事件处理器。这种对比方法比单纯看“总内存涨了 100MB”有效得多因为它能直接指出“是什么导致这 100MB 没降下来”。8.3 用日志辅助定位难复现的内存问题有些内存问题只在特定机型上出现本地 Profiler 难以录制。这时候可以在关键路径插入专门的日志每次加载和释放都输出资源名称和引用计数值配合 Android 等设备端 Profiling 工具采集日志找出“加载了但没卸载”的事务。在 Unity 中用 Debug.Log 打印对象名即可不必额外引入第三方插件。如果担心性能可以只保留 Release 下默认关闭的日志组在出问题时用开关临时调整。也就是说内存异常排查有时不必一开始就想得太玄。只要保证你能回答三件事这次加载了什么资源、谁在持有它、释放时它还在不在引用图上。9. 给不同阶段项目的实战建议9.1 学习期先把自己的代码写好如果你的项目还在功能开发阶段不要急着引用复杂的内存管理框架。先把最容易造成 GC 的坏习惯戒掉不在 Update 里链式拼接字符串。不用 LINQ 写高频查询。不给集合频繁使用动态扩容。不用new WaitForSeconds创建重复的等待对象。不把临时对象丢给静态容器。这听起来非常“基础”但能阻止 70% 以上的托管堆高水位问题。能在 MonoBehaviour 开发的日常习惯里避免分配未来引入任何资源管理框架都会轻松很多。9.2 进阶段引入 Addressables并重视引用计数功能稳定后如果项目有明显的资源量和场景需求建议尽快从 Resources 切换到 Addressables。Addressables 的价值不只是“异步加载”而是让资源加载有了引用计数概念。它要求你显式释放资源实例否则每次加载同一个资源都会产生一条引用记录。漏 Release 就会造成资源重复加载、池化资源无法回收最终内存曲线持续上升。同时建议在项目的核心架构层封装一套“资源加载代理”统一处理加载、异步回调、引用计数和卸载。避免直接在业务代码里四处调用Addressables.InstantiateAsync。加了这一层后后期做资源统计、逐个功能模块的加载清理都会方便很多。9.3 面向移动平台重点关注包体、纹理格式和压缩内存移动端 Unity 项目经常遇到的特殊问题是内存上限小、GPU 资源吃紧、iOS 和 Android 的内存权限不同。尤其在低端 Android 设备上纹理内存往往是内存占用的大头。解决这类问题的常见路径使用Texture Compression格式并根据设备机型选择合适的压缩方案。开启Mipmap因为场景距离较近时使用大 mip 会显著占用内存。对不需要高清纹理的对象用 Atlas 工具打包图集并注意 Sprite Atlas 的使用边界。慎用RenderTexture因为临时创建大尺寸 RT 会给内存带来瞬时冲击。考虑异步加载和分帧实例化把大资源的内存峰值打散。不过要注意这些手段是设备平台特有的“内存水位控制”与第一部分的托管堆稳定性是两条线。二者都要管但在排查时必须分开判断。9.4 微信小游戏和 WebGL这一类平台有更苛刻的边界在微信小游戏或 WebGL 这类基于浏览器/虚拟机的环境中Unity 的内存管理还受到运行平台限制。很多热词里提到“Unity 微信小游戏打包”实际上这一类平台的问题是内存上限通常远小于原生手机端要求超限会被直接杀掉。平台侧的资源压缩、缓存策略、内存统计方式与原生不一致。代码分配触发 GC 的代价被放大因为运行环境本身不允许长时间停顿。如果碰到“在微信小游戏里一打开某界面就闪退”的问题首先要做的是压降单次资源加载的峰值比如把大图拆小、分批实例化、避免同一个界面加载过多高清资源其次是检查托管堆看看是否是 IL2CPP 的代码分配导致堆峰值超标。这一类平台的排查顺序不要先从引擎层面入手而要先确认平台运行环境的限制、资源总大小、内存阈值。不同老板平台往往有自己的性能与内存检测工具优先用它们拿到内存判定信息。10. 回到根本Unity 内存优化不是“少用点”而是“更可控”做了多年 Unity 项目后有一个心得可以分享内存优化和功能开发很像越到晚后期越依赖“规则 工具”而不是“灵感 临时救火”。在项目早期你需要一套约定资源怎么加载、UI 怎么释放、频繁生成的对象怎么走池、日常开发不用哪些高风险语法。到了中后期你需要一个“性能走廊”每个开发机上定期跑一遍 Profiler / Memory Snapshot输出关键指标报表让团队清楚地看到最近 7 天某功能的内存趋势。不要等到玩家反馈“闪退、卡顿”了才开始急救。到那个阶段定位问题的成本会非常高因为真实环境里可能有几十种资源加载序列和复杂的场景互操作。对个人开发者或小团队来说最可行的路径是先用一个实际场景把问题逼出来写几个 Mini Demo 测试资源加载与释放。在 Demo 里熟悉 Profiler、Memory Profiler、对象池、Addressables 的基本流程。再回游戏主项目尝试把某一个常见操作链例如背包界面打开 → 加载物品图标 → 关闭界面 → 释放这批图标做成一个完整闭环示范。如果发现调试进程变复杂了就先不扩展范围——把一个闭环真正做到可控比同时优化十个功能更有长期价值。C# 托管代码里每一次new、每一次字符串拼接、每一个 LINQ 查询都在给系统的“可预期性”增加不确定性。引擎原生这一侧每次资源加载、每张纹理和每个场景切换也同样消耗着系统资源。最后再回到开头那个判断Unity 内存管理机制看似的难点是占用高、释放慢但真正的优化空间几乎全都在“分配的生命周期”里。在动手优化之前我建议你先在项目里建立一个最朴素的习惯所有加载操作都放在统一入口所有释放都有一个唯一出口。你可能还会遇到“这个模型加载后该什么时候卸载”“哪里持有这个 Sprite 的引用”之类的问题。这种“查不清、理不顺”的时刻恰恰说明内存设计还没真正成型。先跑通一个小闭环再用 Profiler 验证结果相比盲目地清缓存、调 GC会有用得多。在新项目启动阶段就设计好资源加载与释放规则比等项目大了再花一周抢救要省力得多。像 UI 面板打开不关闭、事件监听不释放、单例持有临时资源之类的问题很容易成为内存泄漏的定时炸弹。如果你的项目已经能稳定运行想进一步压低内存可以尝试用 Memory Profiler 给每个玩法模块做一次全链路加载-释放测试把每个模块的内存归属整理出来。这样手上就有一份“内存治理地图”后面任何一次优化都有了可以做横向对比的基线。同一个缓存系统、同一个资源生命周期模型在小项目里可能完全没问题切到大世界或高复杂度 UI 时才暴露出弱项。这也是为什么我会更建议所有 Unity 团队相信“可观测”而非“习惯性优化”。能一眼看明白的分配和释放过程比难以追踪的共享缓存池更容易长期维护。 Unity内存优化实战：托管堆、GC与资源生命周期管理
很多人做 Unity 性能优化时上手就看 Draw Call、看帧率、看 CPU 耗时但往往等到游戏在低端手机上频繁闪退或者玩家反馈“玩久了越来越卡”时才想起来查内存。我见过不少团队陷入同一种困境用 Profiler 一看内存占用高得吓人手动调用 GC画面又卡了一下切了几次场景之后内存像泻药一样止不住等到想查到底是谁分配了对象时Unity 自带工具给出的信息又不够直观。结果陷入“加缓存、清缓存、调用 GC、重启游戏”的恶性循环。这里想先给一个更底层的主判断Unity 内存管理的核心难题不在于你占用了多少内存而在于你无法预期内存什么时候涨、为什么涨、释放后是否真的能还给系统。所以做内存优化真正要学会的不是“省内存”这一招而是管理“分配与释放的生命周期”。这篇文章会从内存机制本身讲起结合资源加载、场景切换、托管堆分配、工具链排查等几个真实作战场景把这个话题拆透。第二期内容不会去列一堆“调优大法”而是想帮大家先建立一套稳定的判断框架——遇到内存问题你该先怀疑哪里、按什么顺序查、用什么办法验证。1. 先明白一件事Unity 的内存不是你一家的内存1.1 为什么游戏越玩越卡重启又好了先从一个最典型的现象说起。一款 Unity 游戏在 Android 手机上运行刚开始流畅玩了十分钟后开始掉帧二十多分钟后操作明显变慢切场景时偶尔卡死。玩家会直接总结为“垃圾优化”。但重启应用后又恢复正常。这个表现通常指向两类问题一类是资源泄漏——加载过的对象没有释放每进一次新界面就带走几十兆内存一类是托管堆的频繁分配和 GC 压力——内存没有泄漏但每一帧都在产生大量垃圾对象导致 GC 频繁介入CPU 被反复打断。很多开发者只记得查前者因为 Profiler 里内存曲线一路向上像极了泄漏。但真正的麻烦往往是后者内存总量稳定GC 却一直在“摘果子”每次摘果子都让游戏卡一下。于是游戏表现为“阶段性掉帧”而不是持续飙升。这两种原因的处理方向完全不同排查顺序也完全不同。所以遇到内存问题先别急着“卸载资源”“清缓存”先确认异常是“总量持续上涨”还是“稳定但周期性卡顿”。前者看泄漏后者看分配。1.2 把内存想象成公共厨房理解 Unity 内存管理可以把它想象成一个对外开放的公共厨房。厨房里有两块核心区域一块是固定的灶台和橱柜相当于引擎原生内存由 C 侧管理资源和渲染数据常驻在这里另一块是临时加出来的备菜区相当于托管堆由 C# 侧的 GC垃圾回收器维护用来频繁创建和丢弃临时对象。问题是备菜区不像橱柜那样“用完擦干净就完了”。C# 里的对象不再被引用后不会立刻消失而是要等 GC 在某个时间点统一清扫。清扫需要暂停执行这就是“卡顿”的来源。清扫完之后空闲内存也不一定会立刻归还给操作系统这就解释了为什么切完场景内存曲线还在高位徘徊。更麻烦的是备菜区里如果总是残留各种大小不一的零碎空间新来的“大块食材”找不到连续位置放GC 就得频繁做线性压缩和移动。这个过程在 Profiler 里会被标记为 GC 的耗时飙升但你看代码又很难找到具体是哪个类导致的。1.3 把优化目标改成“可预期”所以内存管理的关键指标不应该是“内存占用尽量低”而应该是“分配和回收尽量可控”。这听起来像一句废话但落到实际操作上会改变很多习惯你会更关注“谁在 Update 里分配了对象”而不是只看“启动后总内存有多少”。你会更关注“场景卸载后旧资源是否真的被释放”而不是只看“Profiler 峰值”。你会更关注“托管堆的 GC 什么时候触发”而不是只在“卡顿发生时”无脑调用System.GC.Collect()。整个第二期内容就是围绕“分配可控、释放可预期、工具可查”这三个目标展开的。2. 托管堆和原生内存Unity 内存到底是谁在管2.1 引擎侧和脚本侧各有各的内存地盘很多初学者容易混淆一件事Unity 里说的“内存”其实横跨原生层C和托管层C#两个世界。Unity 引擎本身用 C 编写纹理、网格、Shader、音频、动画片段等资源本质上都存在于引擎原生内存里。这些资源的申请和释放由引擎的资源生命周期管理你加载了一个 AssetBundle实例化了一个 GameObject这些操作最终都会在引擎侧产生原生内存。而 MonoBehaviour 里写的 C# 类、List、Dictionary、字符串拼接、LINQ 查询等则运行在 Mono 或 IL2CPP 的托管环境中。托管堆里的对象由 GC 统一管理GC 会追踪哪些对象不再被引用并在某个时候回收它们。两层内存互相可见度不高。你在 Profiler 里看到的 Overall 内存是引擎原生内存和托管堆的直接相加但很难直接看到“这个纹理是哪一次加载留下来的”“那个字符串数组是谁分配的”。2.2 Mono 或 IL2CPP 只是执行环境GC 机制才是关键不同脚本后端会改变内存管理的表现。使用 Mono 时补全——调试相对方便但堆内存模型更接近传统 .NET切换到 IL2CPP 后AOT 编译会让静态内存排布有差异但 GC 的逻辑依然来自 Unity 提供的 Boehm GC 或增量式 GC 方案。这里不必过分纠结“换成 IL2CPP 内存会自动减少”这种说法。IL2CPP 的优势主要在包体、执行效率和跨平台内存机制层面的改变远没有想象中那么大。真正决定托管堆失控的还是代码里的分配行为。所以判断执行环境时可以记住一个简单的经验如果你的问题出在“字符串拼接特别多”“容器频繁扩容”“临时数组一帧一建”换 IL2CPP 并不会帮你解决。这些垃圾产生的根源在代码不在执行环境。2.3 托管堆为什么会“只涨不降”托管堆设计的初衷是高效分配对象内存够时新对象像往抽屉里放东西一样不断向上堆叠当 GC 检测到内存压力或触发条件时它会遍历对象引用图把不再引用的对象标记为垃圾然后回收空间。但回收之后GC 通常不会把内存还给系统。它会保留这个堆的容量以便下一次分配时可以复用。于是你看到的现象就是游戏启动时托管堆只有几 MB运行一段时间后某个场景里需要批量创建对象堆一下涨到 200 MB之后即使那些对象全部被释放堆容量依然维持在 200 MB 左右。这不是泄漏而是堆的“水位”上去了就不愿降下来。从 Profiler 图上看就是一条阶梯式上升的曲线。你要处理的核心不是“让水位降回几 MB”而是“别让峰值水位无缘无故上涨”。注意看到托管堆的 Reserved Memory 一直很高不要立刻判断为泄漏。先看当前堆里“存活对象”的大小。如果存活对象不大但保留容量很高说明是历史高峰期留下的“顶”需要做的事是减少历史峰值分配而不是反复 GC。3. 一次真实的卡顿排查我最后找到了 5 个分配热点3.1 用 Profiler 还原现场不要凭感觉猜有一次一个朋友的项目遇到出招时掉帧招式的特效和伤害计算都比较复杂。他怀疑是特效加载太慢想用缓存 预热的方式解决。我用 Profiler 录了一段战斗过程的帧数据切换到 CPU Usage 模块排序后看到真正的问题不是特效资源加载而是几个高频调用引起的 GC 分配角色每次攻击时会拼接技能描述字符串并在 UI 上显示。字符串拼接使用了string.Format每帧触发时都会分配新的字符串。技能伤害结算里用了一个Dictionary每次获取配置会增加一层封装返回一个临时 List然后立刻被丢弃。实现了一个“筛选敌人”的函数内部用 LINQ 的Where().ToList()这个调用隐藏了非常多的临时分配。Update 函数里持续判断敌人距离并用transform.position创建临时 Vector3 列表每帧产生一个小的 container。绘制小地图时用Camera.WorldToScreenPoint计算坐标每帧生成结构体数组并交给 UI 绘制。这些在单帧里看起来都微不足道但一秒钟发生 60 次、三个角色同时在战斗里产生的垃圾数量就足以让 GC 一秒钟工作好几次。3.2 先分类再决定优化策略处理时我没有一上来就改成 StringBuilder 和对象池而是先把问题归成三类类型 A高频、少量、可轻易避免比如 Update 里的字符串拼接直接改代码避免分配。类型 B低频、一次性但量大比如切场景时的英雄列表、任务奖励配置可以不优化生成过程但要确保生成后能复用或使用后能被及时清理。类型 C高频、数据结构复杂比如战斗管理里的 List、Dictionary更适合用对象池 缓存机制而不是每一次都重新分配。这个分类方式后来变成我处理内存分配问题时的默认路径先看调用频率再看单次分配量然后决定是“改写法”还是“引入缓存”还是“接受分配但错峰执行”。3.3 这里最容易踩的坑在 Update 里做逻辑判断但忘了隐藏分配排查这类问题的难点在于分配热点往往藏在看似无害的写法里。常见的隐藏分配场景包括字符串拼接a b c、string.Format、${var}都会分配。LINQWhere、Select、OrderBy、ToArray大部分会产生 delegate 或 iterator。装箱把值类型丢进object类型参数、老版本的ArrayList、Hashtable。闭包匿名函数捕获外部变量每次执行都会生成一个新的闭包类实例。协程WaitForSeconds如果用new创建每次等待都会分配一个对象。数组和 List 扩容可以预分配容量的场景没有初始化容量。判断方法不复杂在 Profiler 的 Hierarchy 视图里按GC Alloc排序找出顶部的函数逐一检查这些函数的实现——这样定位准确率比看代码结构要高得多。4. 资源加载与释放AssetBundle 不是清理了就万事大吉4.1 从 Resources 到 Addressables资源加载思路的演进Unity 的资源管理早期依赖Resources文件夹所有资源打进包体运行时直接用Resources.Load加载用Resources.UnloadUnusedAssets清理未使用的资源。这种方式在小型项目里够用但问题也很明显Resources 目录像一块永不淘汰的公共储存间——资源一旦放进去就全部打包不存在“可下载”和“可释放”的高度可控性。后面逐渐有了 AssetBundle资源被拆成一个个 Bundle由代码按需加载、释放。AssetBundle 给了团队精细控制权但引入了依赖管理的地狱——不同 Bundle 之间的依赖、引用计数、版本更新、资源冗余都需要团队自行维护。再往后Addressables 试图把这种精细控制封装成更友好的 API配合引用计数来管理资源的加载和释放。它的目标不是消灭 AssetBundle而是把复杂的依赖和生命周期问题收敛成一套更易用的接口。从内存机制角度看这套演进的核心变化是资源不再天然驻留而是由你决定何时加载、何时卸载、卸载后是否需要保留引用。这比“加载更多资源”更有价值。4.2 为什么加载了资源却释放不掉实际开发者经常遇到一个困惑我明明调用了 AssetBundle.Unload(true)为什么场景里的纹理和网格还躺在内存里原因是优先级理解错了。AssetBundle.Unload(true) 会强制立即卸载所有从该 Bundle 加载的对象哪怕这些对象还被场景引用着后果是场景里的对象变成“无源之水”显示会变紫或丢失网格。Unload(false) 则只卸载 Bundle 的镜像文件已经加载的对象还会继续存留直到下次自动清理或你手动逐个卸载。所以理想流程是先把场景中对资源的引用都释放比如移除不必要的 Sprite、释放纹理引用。再调用 Assets 未使用资源清理比如Resources.UnloadUnusedAssets()。最后调用 AssetBundle 的卸载接口。但这种方式有一个前提你必须能准确判断对象是否还被“非场景”的强引用持有。比如你有一个全局静态容器保存了所有已加载的角色的图标 Texture2D即使你卸载了所在 Bundle这个 Texture2D 也不会被释放因为在 C# 对象图里仍“活着”。4.3 资源管理里最容易被忽略的“引用泄漏”很多资源泄漏不是加载接口使用错误而是“业务逻辑引用泄漏”。比如有两个界面A 界面是一个英雄详情界面B 界面是设置界面。每次打开 A 界面都会加载对应英雄的立绘纹理切换到 B 界面时A 界面被销毁但全局的事件管理器里一个订阅了 A 界面刷新事件的方法没有退订。于是 A 界面对象本身没被销毁它引用的那批纹理自然也无法被回收。排查这类问题时最有效的方式不是盯着内存总览看而是用 Memory Profiler 抓一份快照查找“仍然存活但不应存在”的对象实例。看它们的引用路径就能定位到是哪个持久化对象持有它们。提示动态加载资源前先做一个“加载、使用、卸载、快照”四步测试。加载前后各抓一次 Memory Profiler 快照对比差异对象。如果卸载完成后仍然有多余对象残留看引用路径通常能直接找到泄漏源头。5. 场景切换与内存回落为什么切了几次场景后内存越来越高5.1 场景卸载不等于内存释放场景切换是内存峰值的重灾区。如果游戏里有两个场景主城场景有大量建筑纹理和角色模型战斗场景有特效和音效。玩家从主城进入战斗再从战斗返回主城。每次切换场景都伴随着 UI 控件的销毁与重建、角色配置表的重新加载、特效资源的新一波缓存。场景切换时Unity 会销毁当前场景的 GameObject。问题是这些被销毁的对象的原生资源不一定同步释放。纹理、音频、网格资源的最终释放依赖于引擎侧的引用计数和资源管理器。如果你在代码里额外持有任何资源的引用泄漏就会叠加。更多时候场景切换后的高内存是“可复用的资源不断变体”同一个角色的战斗模型换了一套特效特效里的贴图换个颜色组合资源系统无法识别出这是同一个 Shared Material于是每套表现都缓存在内存里。5.2 让旧资源在合适的时机被清理在场景切换之后常见做法是调用Resources.UnloadUnusedAssets();这个接口会扫描当前资源集找出不再被引用的资源并释放它们。但注意它不是立刻执行的而是在后台异步完成。而且它无法释放“仍然被持久化引用”的对象。所以要把它放在场景切换完成后的一个合适时机而不是帧底部。我一般会在切换流程里插入一个加载界面然后在加载界面等待期间调用配合 yield 等待确保清理完成后再进入新场景的可交互状态。5.3 处理“场景常驻 动态加载”混合模式大多数现代 Unity 项目不是纯粹地切换场景而是“一个常驻场景 动态加载多个功能场景”。这种模式下内存管理的难点就不是“场景卸载后能不能清理”而是“常驻场景里的对象持有临时资源的引用导致资源卸载失败”。比如常驻场景里有个 UI 管理器负责管理每个面板的实例。面板 A 打开时会生成英雄列表列表里每一项持有一张远程头像 Sprite。关闭面板 A 时列表被销毁但 UI 管理器持有的一个“最近打开的面板引用”还没来得及清空。结果无论怎么切换场景这批头像资源都会一直被引用着。定位方法还是回到快照内存异常时抓快照看哪些资源本应释放但仍在图上顺着路径找到常驻对象然后把“旧引用清理”这一步写进面板关闭流程里。6. 对象池、容器和缓存释放绑定的正确姿势6.1 对象池是解决高频分配的首选但不是万能钥匙对象池的核心思想是把创建和销毁变成取出和归还。战斗里的子弹、飘字、特效、敌人这些高频生成的对象都适合放到池里避免每帧创建新实例。但对象池实践中有一个常见误区池里默认保存了最大数量限制。如果不加限制敌人一波波的生成池会越来越大。当场景转化后这些对象仍在池里待着内存自然就降不下来。有效的对象池策略应该包含池的初始容量预分配但不必按极限情况分配。池有最大空闲数量超过最大值后允许释放多余实例。对象归还到池时尽量把它的数据恢复到初始状态避免下次取出时残留。如果要支持资源切换池里的对象在释放时需要依赖的加载上下文否则“回池”仍然会泄漏。6.2 容器要预分配容量避免扩容风暴List、Dictionary 这类容器的内部存储是按需扩容的。每当你 Add 一个元素时如果容量不够就会申请一个更大的内部数组把旧数据复制过去再丢弃旧数组。这个过程在数据量小的时候无所谓但如果你在游戏初始化时往 List 里分批添加几千条配置或每次进入战斗时创建一个只用到几步就被清空的 List隐藏的 GC 分配量会非常可观。常见的改进方式是尽量为容器预留容量var enemies new ListEnemy(64);如果你知道上限就按上限分配如果不知道可以取一个合理的经验值。至少可以避免大量小步扩容引起的碎片和分配高峰。6.3 对象池要配合“生命周期上下文”如果对象池里的对象引用了场景里的资源——比如敌人挂了一堆粒子特效、角色动态加载了皮肤贴图——那么这些对象的引用必须能在场景切换时统一释放。否则你只会把“频发创建”的垃圾问题转变成“池中永远驻留”的容量问题。更安全的做法是把对象池按“场景分类”。每个场景维护自己的池容器。场景退出时将池一并清空归还其中的实例并卸载它们持有的资源。7. 该不该手动调用 GC很多人踩过这个坑7.1 手动 GC 是“止痛药”不是“治疗方案”许多开发者的第一反应是内存太高了调用System.GC.Collect()强制垃圾回收。这在调试期看着有用内存数字确实掉下来了帧率也恢复了。但它有代价。手动 GC 会引发一次完全阻塞式回收游戏会明显地卡一下在手机上尤其明显。而且如果代码里仍然持续产生大量垃圾GC 也只是暂时清空了堆新的分配高峰很快又会出现。正确使用场景是场景切换后的静态清理点。大型战斗结束后确定玩家正在加载界面或看结算动画。接受暂时的低帧率用来避免后续更多次的间歇性卡顿。不要在 Update 或高频逻辑里调用。它不会阻止垃圾产生只会提前收割并把 CPU 开销集中到某一帧。7.2 增量式 GC 也不是一劳永逸Unity 提供增量式 GCIncremental Garbage Collection原理是把一次 GC 的长暂停拆散到多帧里从玩家的观感上降低卡顿。但它并没有减少 GC 的总工作量也没有减少堆内存的占用。它只是让卡顿更衣蔽没有从根源上解决。如果项目里存在严重的分配峰值和泄漏即使开启增量式 GC也可能出现“稳定但恼人的周期性掉帧”或者仍在低端机上出现 GC 停顿。所以增量式 GC 更适合作为体验优化手段用于“短时间内可接受的 GC”——更利于做移动端优化。实际判断标准是在 Profiler 里看 GC 的耗时是否还能被其他逻辑掩盖。如果 GC 每次出现都会制造明显卡顿说明代码层的分配压力仍然过大这时候该做的是回到定位分配热点而不是调 GC 模式。8. 用工具支撑判断Profiler 与 Memory Profiler 的正确打开方式8.1 从 CPU 视图切入你看到的是“分配结果”Unity Profiler 里与内存分析相关的入口非常多常用的几类CPU Usage模块同样可以帮助定位脚本分配热点因为它记录了每个函数的GC Alloc字段。Memory模块看总内存、资源分类、托管堆容量、Mono 堆与原生内存之间的关系。Memory Profiler Package可以抓取详细快照分析对象引用和资源来源。引擎自带的Allocation和Memory页面在 Windows 编辑器里打开Window Analysis Profiler可以配合使用。我比较推荐的最小观测步骤是先在 CPU 视图里按 GC Alloc 排序找出 Top 函数。修正代码后录一段同场景数据对比 GC Alloc 前后的总量。再切到 Memory 视图看托管堆的 Reserved Memory 是否还在涨。如果仍有存续内存异常用 Memory Profiler 快照查引用链。这套顺序能避免一个常见盲区一开始就把时间花在分析资源泄漏上却没有发现真正的元凶是每帧分配。8.2 Memory Profiler 快照怎么读使用 Memory Profiler Package 时通常进入以下流程在 Player 或 Editor 中待分析场景。Capture 一个 Baseline 快照。执行“加载资源、打开界面、销毁界面、卸载资源”。再 Capture 第二个 Intermediate 快照。执行一次场景切换或大量 GC Alloc 操作。最后 Capture 一个 Final 快照。然后比较第二个快照与基线快照排查新增的 Managed Object 和 Native Object再比较第三个快照与第二个快照看哪些对象没有回到基线水平。如果某些对象在 Final 快照中依然存在点击后查看“Reference”面板找到持有它们的源。通常你会看到一个 Manager 单例、全局静态配置表或未退订的事件处理器。这种对比方法比单纯看“总内存涨了 100MB”有效得多因为它能直接指出“是什么导致这 100MB 没降下来”。8.3 用日志辅助定位难复现的内存问题有些内存问题只在特定机型上出现本地 Profiler 难以录制。这时候可以在关键路径插入专门的日志每次加载和释放都输出资源名称和引用计数值配合 Android 等设备端 Profiling 工具采集日志找出“加载了但没卸载”的事务。在 Unity 中用 Debug.Log 打印对象名即可不必额外引入第三方插件。如果担心性能可以只保留 Release 下默认关闭的日志组在出问题时用开关临时调整。也就是说内存异常排查有时不必一开始就想得太玄。只要保证你能回答三件事这次加载了什么资源、谁在持有它、释放时它还在不在引用图上。9. 给不同阶段项目的实战建议9.1 学习期先把自己的代码写好如果你的项目还在功能开发阶段不要急着引用复杂的内存管理框架。先把最容易造成 GC 的坏习惯戒掉不在 Update 里链式拼接字符串。不用 LINQ 写高频查询。不给集合频繁使用动态扩容。不用new WaitForSeconds创建重复的等待对象。不把临时对象丢给静态容器。这听起来非常“基础”但能阻止 70% 以上的托管堆高水位问题。能在 MonoBehaviour 开发的日常习惯里避免分配未来引入任何资源管理框架都会轻松很多。9.2 进阶段引入 Addressables并重视引用计数功能稳定后如果项目有明显的资源量和场景需求建议尽快从 Resources 切换到 Addressables。Addressables 的价值不只是“异步加载”而是让资源加载有了引用计数概念。它要求你显式释放资源实例否则每次加载同一个资源都会产生一条引用记录。漏 Release 就会造成资源重复加载、池化资源无法回收最终内存曲线持续上升。同时建议在项目的核心架构层封装一套“资源加载代理”统一处理加载、异步回调、引用计数和卸载。避免直接在业务代码里四处调用Addressables.InstantiateAsync。加了这一层后后期做资源统计、逐个功能模块的加载清理都会方便很多。9.3 面向移动平台重点关注包体、纹理格式和压缩内存移动端 Unity 项目经常遇到的特殊问题是内存上限小、GPU 资源吃紧、iOS 和 Android 的内存权限不同。尤其在低端 Android 设备上纹理内存往往是内存占用的大头。解决这类问题的常见路径使用Texture Compression格式并根据设备机型选择合适的压缩方案。开启Mipmap因为场景距离较近时使用大 mip 会显著占用内存。对不需要高清纹理的对象用 Atlas 工具打包图集并注意 Sprite Atlas 的使用边界。慎用RenderTexture因为临时创建大尺寸 RT 会给内存带来瞬时冲击。考虑异步加载和分帧实例化把大资源的内存峰值打散。不过要注意这些手段是设备平台特有的“内存水位控制”与第一部分的托管堆稳定性是两条线。二者都要管但在排查时必须分开判断。9.4 微信小游戏和 WebGL这一类平台有更苛刻的边界在微信小游戏或 WebGL 这类基于浏览器/虚拟机的环境中Unity 的内存管理还受到运行平台限制。很多热词里提到“Unity 微信小游戏打包”实际上这一类平台的问题是内存上限通常远小于原生手机端要求超限会被直接杀掉。平台侧的资源压缩、缓存策略、内存统计方式与原生不一致。代码分配触发 GC 的代价被放大因为运行环境本身不允许长时间停顿。如果碰到“在微信小游戏里一打开某界面就闪退”的问题首先要做的是压降单次资源加载的峰值比如把大图拆小、分批实例化、避免同一个界面加载过多高清资源其次是检查托管堆看看是否是 IL2CPP 的代码分配导致堆峰值超标。这一类平台的排查顺序不要先从引擎层面入手而要先确认平台运行环境的限制、资源总大小、内存阈值。不同老板平台往往有自己的性能与内存检测工具优先用它们拿到内存判定信息。10. 回到根本Unity 内存优化不是“少用点”而是“更可控”做了多年 Unity 项目后有一个心得可以分享内存优化和功能开发很像越到晚后期越依赖“规则 工具”而不是“灵感 临时救火”。在项目早期你需要一套约定资源怎么加载、UI 怎么释放、频繁生成的对象怎么走池、日常开发不用哪些高风险语法。到了中后期你需要一个“性能走廊”每个开发机上定期跑一遍 Profiler / Memory Snapshot输出关键指标报表让团队清楚地看到最近 7 天某功能的内存趋势。不要等到玩家反馈“闪退、卡顿”了才开始急救。到那个阶段定位问题的成本会非常高因为真实环境里可能有几十种资源加载序列和复杂的场景互操作。对个人开发者或小团队来说最可行的路径是先用一个实际场景把问题逼出来写几个 Mini Demo 测试资源加载与释放。在 Demo 里熟悉 Profiler、Memory Profiler、对象池、Addressables 的基本流程。再回游戏主项目尝试把某一个常见操作链例如背包界面打开 → 加载物品图标 → 关闭界面 → 释放这批图标做成一个完整闭环示范。如果发现调试进程变复杂了就先不扩展范围——把一个闭环真正做到可控比同时优化十个功能更有长期价值。C# 托管代码里每一次new、每一次字符串拼接、每一个 LINQ 查询都在给系统的“可预期性”增加不确定性。引擎原生这一侧每次资源加载、每张纹理和每个场景切换也同样消耗着系统资源。最后再回到开头那个判断Unity 内存管理机制看似的难点是占用高、释放慢但真正的优化空间几乎全都在“分配的生命周期”里。在动手优化之前我建议你先在项目里建立一个最朴素的习惯所有加载操作都放在统一入口所有释放都有一个唯一出口。你可能还会遇到“这个模型加载后该什么时候卸载”“哪里持有这个 Sprite 的引用”之类的问题。这种“查不清、理不顺”的时刻恰恰说明内存设计还没真正成型。先跑通一个小闭环再用 Profiler 验证结果相比盲目地清缓存、调 GC会有用得多。在新项目启动阶段就设计好资源加载与释放规则比等项目大了再花一周抢救要省力得多。像 UI 面板打开不关闭、事件监听不释放、单例持有临时资源之类的问题很容易成为内存泄漏的定时炸弹。如果你的项目已经能稳定运行想进一步压低内存可以尝试用 Memory Profiler 给每个玩法模块做一次全链路加载-释放测试把每个模块的内存归属整理出来。这样手上就有一份“内存治理地图”后面任何一次优化都有了可以做横向对比的基线。同一个缓存系统、同一个资源生命周期模型在小项目里可能完全没问题切到大世界或高复杂度 UI 时才暴露出弱项。这也是为什么我会更建议所有 Unity 团队相信“可观测”而非“习惯性优化”。能一眼看明白的分配和释放过程比难以追踪的共享缓存池更容易长期维护。