大家在做 Unity 性能优化时往往第一反应是“降低 Draw Call”“压缩贴图”“减少 Overdraw”这些方向没有错但都属于渲染侧的优化。真正让我在项目里反复返工的反而是内存问题游戏越玩越卡、场景切换后内存不回落、Profiler 里出现莫名的“小尖刺”。这些问题如果不从 Unity 内存管理机制入手单纯靠堆代码往往无济于事。本文将围绕 Unity 内存管理机制展开先理清引擎中几块内存的区别再结合 Unity Profiler、Memory Profiler 等工具讲解定位方法然后给出可运行的代码示例和优化思路。无论你是在做手游、PC 端还是 VR 项目这套方法基本都通用。按照本文学完你至少能回答这几个问题Unity 的内存到底是谁在分配GC 为什么会卡顿Asset 为什么总卸载不掉如何验证自己的优化是否有效1. 为什么要单独理解 Unity 内存管理机制1.1 谈性能优化为什么绕不开内存从用户视角看内存问题最直观的表现是“卡”和“闪退”。但程序端的卡顿通常很复杂除了 CPU 与 GPU 的耗时过高还有一条非常典型的链路游戏在玩法或 UI 逻辑中不断分配临时对象。这些对象占满了托管堆内存。Unity 触发垃圾回收GCGarbage Collection。GC 执行时主线程需要被暂停一段时间。玩家感受到明显卡顿甚至出现掉帧、白屏。换言之很多“帧率抖动”并不是渲染压力大而是 GC 在某个瞬间集中回收了大量托管内存。如果你没有内存管理的基本概念可能根本不会往这个方向排查。1.2 Unity 内存不等于“内存占用一个数字”在桌面任务管理器里Unity 进程的内存占用是一个整体。但在 Unity 引擎内部内存被划分为若干区域包括托管堆、本地原生堆、资源内存、GPU 显存等。只看任务管理器里的总内存既看不出分配热点也看不出泄漏源。为了快速定位问题我们需要在概念上先完成一次“拆解”哪些内存由 C# 层管理哪些由引擎 C 层管理哪些资源会被持久化加载哪些资源使用完后必须手动释放。理解了这些边界你才能真正读懂 Profiler 里的内存快照。1.3 本文的预期收获读完这篇文章后你应当能够区分托管内存与非托管内存的典型问题场景。知道 Asset、AssetBundle、Resources 各自的生命周期。使用 Unity Profiler 和 Memory Profiler 定位内存峰值与异常增长。通过代码示例理解字符串、委托、装箱、LINQ 等常见 GC Alloc 来源。在项目中建立一套可执行的内存优化规范。2. 环境准备和工具链说明2.1 Unity 版本与平台Unity 内存相关 API 和 Profiler 面板在近几个大版本里变化不大不过细节仍有一些差异。为了避免写死某个也许不再正确的版本细节下面统一按“常见 LTS 环境”来说明。如果你的项目还在使用 2019 或 2020 系列建议先升级到 2021.3 以上的 LTS 版本再配合补充工具进行排查。实际操作时请以你项目本身使用的 Unity 版本为准。本文的重点是思路与方法而不是某个特定版本的唯一解法。2.2 推荐工具工具说明使用频率Unity Profiler引擎自带的性能分析器可以在编辑器里直接连接项目或在真机上通过 Development Build 连接。日常必备Memory Profiler官方提供的内存快照分析工具打开 Window - Package Manager 搜索安装即可。它能抓取 Unity 原生对象、托管对象、Native 资源的完整快照。定位复杂泄漏时很有用Addressables可寻址资源系统比 Resources 更便于管理和释放资源。项目体量较大时推荐ResizableArray / ArrayPool.NET 或自定义的数组复用方案用于减少高频临时分配。进阶优化如果你使用的是 2021.3 及以上版本推荐安装 Memory Profiler 包。它比传统的 Profiler 内存模块能更清晰地展示“谁引用了谁”“为什么资源没有被卸载”。2.3 示例工程结构为了让后续案例更容易复现建议先新建一个空的 3D 项目再准备以下脚本目录Assets/ ├── Scripts/ │ ├── MemoryDemo/ │ │ ├── GcAllocDemo.cs │ │ ├── AssetLoadDemo.cs │ │ └── LeakSimulator.cs ├── Scenes/ │ └── MemoryDemoScene.unity └── Prefabs/ └── DemoEnemy.prefab以上结构不是必须完全照搬只是方便你跟着文章操作时不会迷失文件位置。3. 核心概念拆解Unity 的内存到底分几块3.1 托管堆与 Mono/IL2CPPUnity 的 C# 脚本默认运行在 Mono 或 IL2CPP 虚拟机之上。C# 里通过new出来的普通对象、数组、字符串、委托等内存都来自“托管堆”。托管堆的特点是Unity 会使用自己的内存分配器管理堆内存。当堆中的对象不再被引用时回收工作交给 GC。GC 发生时程序主线程可能被暂停暂停时间取决于需要回收的对象数量和引用扫描复杂度。在Mono 后端下托管堆通常不会自动把空闲内存归还给操作系统而是保留给后续的分配使用所以你在内存管理器里看到进程占用很高时一部分可能只是“曾经用过的托管堆空洞”。在IL2CPP 后端下内存管理的实现会有些差异但核心概念相同。只要 C# 层有大量临时分配GC 依然会产生只是具体阈值与回收策略略有不同。3.2 本地原生内存Unity 引擎本身是 C 编写的。当你加载材质、贴图、网格、音频、Shader、动画片段时引擎会在本地堆里创建对应的原生资源对象。这些资源不代表 C# 中某个简单的new object()而是由引擎侧承载的大块数据。典型场景一个 2048×2048 的 RGBA 纹理占用的显存或内存约 16MB。一个包含大量顶点的 Mesh会占据数百 KB 到数 MB 的本地内存。一个音频 Clip 的解码缓冲也可能占用较大的非托管区域。如果你只是在 C# 层创建一个Texture2D对象但没有真正加载纹理数据它并不会占用多少原生内存。真正的大头在“资源的实际数据”上。3.3 Asset 与 AssetBundle 的生命周期Unity 的资源加载体系绕不开三类 APIResources.LoadAssetBundle.LoadFromFileAddressables.LoadAssetAsync它们都受“引用计数”的影响。资源第一次加载后会被缓存在引擎里下次再加载同一资源时引擎会直接返回已加载的对象。只有当你调用对应的卸载 API并且没有其他对象继续引用该资源时内存才会真正释放。很多开发者的误区是把AssetBundle.Unload(false)理解成了“资源立刻从内存消失”。实际上Unload(false)只会卸载 AssetBundle 本身并不会销毁已从该 Bundle 加载出来的资源对象。正确的流程是先销毁所有实例然后调用Resources.UnloadUnusedAssets()最后由 GC 或引擎层异步清理。3.4 容易混淆的几个概念概念含义常见误解GC Alloc托管堆上产生的分配量不一定会立刻导致 GC但会增加 GC 压力内存峰值程序运行过程中最高内存占用值与“当前内存占用”不是一回事内存泄漏本应释放却持续无法释放的内存不只是 C# 对象被静态字段引用也可能来自原生引用内存碎片堆中空闲内存不连续导致大块分配失败不是所有内存增长都是泄漏Native 资源由引擎 C 持有的资源数据不一定显示在 C# 堆栈里在进入实战前先把这些边界弄清楚后续的优化手段才不会用错地方。4. 实战入门用 Unity Profiler 定位 GC Alloc4.1 每帧分配为什么会卡先来看一段非常典型的“问题代码”。它的功能是在Update里拼接日志并输出看起来毫不起眼// 文件路径Assets/Scripts/MemoryDemo/GcAllocDemo.cs using UnityEngine; public class GcAllocDemo : MonoBehaviour { private int _frameCount; private void Update() { _frameCount; Debug.Log(当前帧数: _frameCount); } }这段代码每帧会产生一次字符串拼接。C# 中的字符串是不可变的当前帧数: _frameCount底层会创建一个新的字符串对象同时int在拼接时也会发生装箱操作。如果这个脚本在项目里大量存在GC Alloc 会非常可观。4.2 在 Profiler 中验证打开 Unity Profiler切换到CPU Usage面板。运行游戏后你会看到每个PlayerLoop节点下都有GC.Alloc数据。如果某一行的 GC Alloc 持续增加说明存在高频分配问题。更直观的操作步骤如下打开 Window - Analysis - Profiler。在 Profiler 面板中点击Frames区域选择当前帧。点击某个Update方法右侧会有该方法的详细调用堆栈以及GC Alloc数字。观察 GC Alloc 的字节数如果经常在单帧内达到几十 KB 甚至几百 KB就说明需要优化。性能报告中GC Alloc的单位是 BByte例如2.3 KB。常规项目在运行时间内如果 GC Alloc 持续上涨则最终会触发 GC如果不希望频繁 GC就要想办法降低每帧的堆分配。4.3 先优化字符串拼接针对字符串拼接最直接的办法是避免每帧分配新的字符串// 文件路径Assets/Scripts/MemoryDemo/GcAllocDemo.cs using UnityEngine; using System.Text; public class GcAllocDemo : MonoBehaviour { private int _frameCount; private readonly StringBuilder _builder new StringBuilder(64); private void Update() { _frameCount; _builder.Clear(); _builder.Append(当前帧数: ); _builder.Append(_frameCount); Debug.Log(_builder.ToString()); } }但这里要提醒一个细节虽然StringBuilder.Clear()和Append不会频繁分配堆内存但ToString()仍然会生成一个新的字符串对象。如果你真的需要每帧输出日志这依然会产生少量分配。更好的方案是在必要的时候才打印或者只在标志位开启时打印if (Debug.isDebugBuild) { Debug.Log(_builder.ToString()); }实际项目中上线版本不会保留每帧大量 Debug.Log因此这属于“编辑器辅助性”代码不应在发布版本造成干扰。4.4 更常见的隐藏分配委托、LINQ、装箱字符串拼接只是最浅层的问题。另一个高频陷阱诞生于事件与委托// 文件路径Assets/Scripts/MemoryDemo/DelegateAllocDemo.cs using UnityEngine; using UnityEngine.UI; public class DelegateAllocDemo : MonoBehaviour { public Button btn; private void Start() { // 这种写法在每次调用 AddListener 时创建一个新的 lambda 对象 // 如果这段代码在 Update 中重复执行GC 压力会不断累加。 btn.onClick.AddListener(() { HandleClick(); }); } private void HandleClick() { Debug.Log(按钮被点击); } }如果AddListener本身不在Start中调用而是在每次操作时动态添加旧的匿名委托还会被反复挂载既增加分配也容易造成重复触发。解决思路是把逻辑写成具名方法在初始化时一次性注册btn.onClick.AddListener(HandleClick);同样LINQ 是新手经常忽略的性能黑洞。Where、Select、OrderBy等方法多数都会分配迭代器对象这在高频调用中会造成明显压力。如果你的战斗、UI 刷新逻辑中大量使用 LINQ建议先用纯循环改造再对比 GC Alloc 曲线。还有一个基础但很常见的装箱问题int hp 100; object boxedHp hp; // 这里发生了装箱Debug.Log的一些重载接收object参数如果你传入的是值类型可能会发生装箱。高版本 Unity 中部分 API 提供了泛型重载或专用重载但更多时候需要你自己留意参数类型。4.5 代码实践验证为了验证优化效果可以写一个简单的压力脚本在连续 10 秒钟内循环调用“优化前版”和“优化后版”再对比 Profile 中的总 GC Alloc// 文件路径Assets/Scripts/MemoryDemo/AllocCompareDemo.cs using UnityEngine; public class AllocCompareDemo : MonoBehaviour { private void Start() { // 示例思路通过点击屏幕分别触发优化前后的逻辑 Debug.Log(点击屏幕开始测试优化前); } private void Update() { if (Input.GetKeyDown(KeyCode.A)) { RunBeforeOptimize(); } if (Input.GetKeyDown(KeyCode.B)) { RunAfterOptimize(); } } private void RunBeforeOptimize() { int total 0; for (int i 0; i 100000; i) { // 这里只是示例实际项目中不要用日志做压测 total i; string s Total: total; } } private void RunAfterOptimize() { System.Text.StringBuilder sb new System.Text.StringBuilder(32); int total 0; for (int i 0; i 100000; i) { total i; sb.Clear(); sb.Append(Total:); sb.Append(total); } } }这段代码里RunAfterOptimize中StringBuilder虽然也分配了一次对象但整体分配量远低于前面每轮都创建字符串的版本。跑完后你会发现两者的GC Alloc相差几百 KB 甚至几 MB。这已经足够说明问题代码层的临时分配是内存优化与性能调优的第一道关卡。5. 深入 Unity 资源内存与引用计数5.1 谁在占用你真正的显存和内存很多项目在统计内存时发现 GC Alloc 很小但Profiler中的 Total Allocated 仍然很高。这时候问题通常不在脚本而在 Asset 与纹理、网格等资源身上。资源加载会在引擎本地内存和 GPU 显存中开辟空间。如果你把 100 个高精度模型全部放在一个场景里且这些模型默认会被场景加载那么它们的内存占用自然很高。对于这种问题优化方向是减少单分辨率纹理体积。使用 ASTC 或 ETC2 等压缩格式。开启纹理 Mipmap如果场景比例变化大。使用 LOD 或遮挡剔除减少同时驻留的对象。通过 AssetBundle/Addressables 按需加载并释放。5.2 一个模拟资源泄漏的示例大多数 Unity 初学者的第一个“内存泄漏”来自对预制体的实例化与 Destroy 理解不足。看这个例子// 文件路径Assets/Scripts/MemoryDemo/LeakSimulator.cs using UnityEngine; public class LeakSimulator : MonoBehaviour { public GameObject enemyPrefab; private void Update() { if (Input.GetKeyDown(KeyCode.Space)) { // 生成 50 个敌人 for (int i 0; i 50; i) { Vector3 pos new Vector3(Random.Range(-10f, 10f), 0, Random.Range(-10f, 10f)); GameObject enemy Instantiate(enemyPrefab, pos, Quaternion.identity); Destroy(enemy, 2f); } } } }表面上看这个对象在 2 秒后会被销毁。但如果enemyPrefab内部引用了某些需要手动释放的资源或者这些 Enemy 对象访问了某个静态容器并在OnDestroy中没有移除就可能出现“假销毁、真滞留”的问题。比如using System.Collections.Generic; using UnityEngine; public class Enemy : MonoBehaviour { private static readonly ListEnemy AllEnemies new ListEnemy(); private void OnEnable() { AllEnemies.Add(this); } private void OnDisable() { // 故意不写 AllEnemies.Remove(this) } }当场景里大量生成并销毁 Enemy 后AllEnemies仍然保存着已销毁对象的引用。虽然对象已经在场景中消失但 GC 因为static List的强引用而无法回收它导致内存不断上涨。这就是典型的C# 托管堆内存泄漏。要验证这种问题可以每 2 秒打开一次 Profiler 的 Memory 面板观察Mono或Managed Heap的 Used Size 是否持续上升且不回落。5.3 正确释放 AssetBundle 资源如果你通过 AssetBundle 加载工具很容易遗漏卸载步骤。下面是一个简化版示例模拟从 AssetBundle 加载随机资源并释放的场景// 文件路径Assets/Scripts/MemoryDemo/AssetLoadDemo.cs using System.Collections; using UnityEngine; public class AssetLoadDemo : MonoBehaviour { private AssetBundle _bundle; private IEnumerator Start() { string bundlePath Application.streamingAssetsPath /demo_enemy_bundle; AssetBundleCreateRequest bundleRequest AssetBundle.LoadFromFileAsync(bundlePath); yield return bundleRequest; _bundle bundleRequest.assetBundle; if (_bundle null) { Debug.LogError(AssetBundle 加载失败); yield break; } // 从 AssetBundle 加载资源 Object enemyPrefab _bundle.LoadAsset(Assets/Prefabs/DemoEnemy.prefab); if (enemyPrefab ! null) { Instantiate(enemyPrefab); } } private void OnDestroy() { // 仅卸载 AssetBundle并不销毁已经实例化的对象或已加载的 asset 对象 if (_bundle ! null) { _bundle.Unload(false); } } }很多团队在这里就会产生一个认知误差认为调用了Unload(false)资源就释放干净了。实际上Unload(false)执行后AssetBundle 对象本身被卸载但 Map 中对应的资源实体如果没有被清理内存依旧存在。更安全的做法是减少使用 AssetBundle 直接加载改为Addressables借助引用计数自动管理加载与释放。Addressables 中加载到界面或怪物身上的资源需要调用 API 获取句柄待使用完毕后Addressables.Release释放。如果忘了Release资源同样不会卸载using UnityEngine; using UnityEngine.AddressableAssets; using UnityEngine.ResourceManagement.AsyncOperations; public class AddressableSpawnDemo : MonoBehaviour { public AssetReference enemyRef; private AsyncOperationHandleGameObject _handle; private async void Start() { _handle Addressables.LoadAssetAsyncGameObject(enemyRef); await _handle.Task; if (_handle.Status AsyncOperationStatus.Succeeded) { GameObject enemy Object.Instantiate(_handle.Result); } } private void OnDestroy() { Debug.Log(加载句柄即将由 Addressables 管理); // 关键点需要在使用完毕后调用 Release } }在上面的示例中我们需要注意实例化出来的 GameObject 与通过Addressables加载出来的原始 Prefab 不是同一个对象。如果只Destroy实例没有Release句柄原始 Prefab 资源会一直存在于内存中。这也是 Addressables 最常被误用的地方。5.4 Resources.UnloadUnusedAssets 的正确打开方式当你结束某个场景或地图后通常希望把不用的资源清理掉。最简单的方式是调用Resources.UnloadUnusedAssets();这个 API 会异步扫描引擎中没有被引用的资源并释放它们。但它有两点限制它不会释放仍然被 C# 对象“强引用”的资源。它不能替代 AssetBundle 或 Addressables 中的手动Release。如果你在场景切换完成后看到一个明显的内存尖峰随后逐渐回落这说明UnloadUnusedAssets生效了。如果内存始终不回落则需要回到引用链路上寻找“残留引用”。6. 用 Memory Profiler 抓内存残留6.1 为什么有时 Unity Profiler 不够用Unity Profiler 的 Memory 面板提供了整体内存曲线也展示了 Notable Allocation 列表但它的层级比较粗。当你想知道“某个 Texture 为什么还活着”或“某个 C# 对象为什么没被回收”时普通 Profiler 并不直观。这时候用Memory Profiler更合适。它可以把当前内存状态保存成一个快照文件你通过对比两个快照能够找出新增对象、新增 Native 资源以及引用关系。6.2 基本使用流程打开 Package Manager搜索Memory Profiler并安装。在菜单栏点击 Window - Analysis - Memory Profiler。运行游戏或针对想要测量的玩法流程。提前抓取一张快照 A例如进入玩法前。执行玩法和循环逻辑。返回主界面或场景卸载后抓取快照 B。在界面里切换到 “Compare” 模式选择 A 与 B 进行对比筛选出“新增且仍被引用”的对象。对比后你可以逐个检查对象类型例如Texture2D 的存活数量有没有持续增长。GameObject 与 Component 有没有堆积。Managed Object 引用树里哪个容器没有清空。Native Object 的父级引用是谁。Memory Profiler 中“Reference”面板能显示引用链。一个常见的泄漏路径是GameObject (Enemy) - Enemy.cs (MonoBehaviour) - m_targetTexture (Texture2D)如果 Enemy 对象本身没有被销毁那么它引用的 Texture 会一直占用内存。此时处理的重点就不是“卸载资源”而是先清理 Enemy 对象切断引用链。6.3 用快照对比验证优化以第 5 节的LeakSimulator为例正确的排查方式是运行游戏前记录一次快照。点击 Space 生成 100 个敌人。等待所有敌人销毁后记录第二次快照。比较两次快照中Enemy类型对象的数量。如果敌人已经执行了Destroy但快照中Enemy数量没有下降你就能立刻判断出有静态容器持有 Enemy 引用。这个方法比在 Profiler 中肉眼盯帧更可靠。7. 高频误区与排查清单7.1 常见内存问题速查表在实际项目中团队最常遇到的问题可以汇总成下表。问题现象常见原因解决思路Profiler 中 GC Alloc 偏高Update 中字符串拼接、LINQ、匿名委托、装箱频繁用 profiler 定位堆栈改用复用对象、StringBuilder、具名方法内存曲线持续上涨不回落静态容器持有对象引用或注册的事件没有反注册使用 Memory Profiler 比较快照寻找 Managed Object 残留场景切换后内存仍很高场景中的资源还被管理器缓存或 AssetBundle 未正确卸载确认加载方式使用 Addressables.Release / UnloadUnusedAssets实例化大量 GameObject 后卡顿高频 Instantiate 与 Destroy 造成 GC 压力与瞬时 CPU 峰值使用对象池 容量预警显存或内存纹理占用过大纹理尺寸过高或 mipmap 策略不当检查 Texture Streaming 与压缩格式7.2 排查六步法如果你在一个陌生项目里排查内存问题建议按下面的顺序走一遍先看 Profiler 的 Memory 总曲线确定是持续增长还是瞬时高峰。切到 CPU Usage 面板检查是否有单帧 GC Alloc 尖峰。临时关闭所有 UI 或玩法规避逻辑再跑一段流程确认问题是否由特定逻辑触发。用 Memory Profiler 抓取“进入玩法前”和“退出玩法后”的两张快照。对比快照按照对象类型和引用链筛选新增对象。修复后再次抓取快照确认内存回到预期基线。按这个顺序走往往不需要全团队开会讨论就能快速定位到写代码的人最熟悉的那段逻辑。7.3 不要忽视 Unity 编辑器自带的内存开销在编辑器里运行项目时Unity 编辑器自身也会占用大量内存并且很多资源会保留两份一份在编辑器中用于预览一份用于播放模式。因此用编辑器直接测内存绝对值是不可靠的。如果要验证最终性能请使用 Development Build 在真机或目标平台运行并使用 Profiler 连接或通过 Profiler 日志从设备上取数据。关于真机 ProfileAndroid 和 iOS 平台都会提供相关的连接方式这里不再展开。核心原则是编辑器数据只适合观察趋势不适合作为最终结论。8. 工程最佳实践与编码规范8.1 用对象池代替高频 Instantiate/Destroy无论是子弹、敌人还是飘字高频实例化都可能让托管堆持续产生分配。一个合格的对象池至少需要实现Get从池中提取对象没有则创建。Release将对象归还池并挂起。支持对池内对象执行OnGet与OnRelease生命周期回调。示例简化逻辑// 文件路径Assets/Scripts/MemoryDemo/SimpleObjectPool.cs 核心片段 using System.Collections.Generic; using UnityEngine; public class SimpleObjectPoolT where T : Component { private readonly StackT _pool new StackT(); private readonly T _prefab; public SimpleObjectPool(T prefab, int prewarmCount 0) { _prefab prefab; for (int i 0; i prewarmCount; i) { T instance Object.Instantiate(_prefab); instance.gameObject.SetActive(false); _pool.Push(instance); } } public T Get() { if (_pool.Count 0) { T instance _pool.Pop(); instance.gameObject.SetActive(true); return instance; } T newInstance Object.Instantiate(_prefab); newInstance.gameObject.SetActive(true); return newInstance; } public void Release(T instance) { instance.gameObject.SetActive(false); _pool.Push(instance); } }使用对象池后只有在池空时才发生Instantiate运行过程中的分配量会显著下降。但你也要记得在场景切换时清理池中引用避免池对象滞留资源。8.2 高频路径避免使用 LINQ 和隐式分配代码规范上我所在的团队会约定战斗逻辑与帧循环中禁止使用 LINQ。字符串拼接尽量在非帧循环中使用需要每帧显示的文本应使用StringBuilder并只在文本变化时ToString。事件注册与反注册必须成对出现尤其是OnEnable/OnDisable、Start/OnDestroy。避免在循环中捕获局部变量生成闭包。谨慎使用FindObjectOfType或GameObject.Find它们内部会产生搜索开销和临时分配推荐缓存引用。8.3 静态引用与单例的生命周期约束静态字段的最大风险是容易让对象生命周期变成“全局生命周期”。比如一个BattleManager.Instance持有了大量敌人引用那么敌人即使被Destroy也会因为这个静态单例的强引用而无法回收。如果必须使用静态或单例对象需要约定静态字段只存放“常驻数据”不允许存放临时实体。持有集合的单例必须提供Clear方法在场景切换或玩法结束时调用。定期用 Memory Profiler 扫描静态引用树。8.4 资源打包时注意“冗余引用”当使用 AssetBundle 时一个常见的坑是同一份贴图或材质被打进了多个 Bundle。如果两个 Bundle 引用了同一份资源但打包时没有做依赖分离加载时 Unity 可能会在内存中保留多份资源。虽然现代版本有依赖打包机制但错误配置仍然存在。工程上的建议是公共图集、Shader、通用 UI 资源单独打 Bundle。业务资源只依赖公共包不交叉引用。构建后使用 Asset Bundle Browser 检查资源依赖关系避免把超大贴图重复打入不同 Bundle。8.5 纹理与音频的内存规范在没有特殊需求的情况下UI 图集尽量用SpriteAtlas做合批避免小图散图多次加载。3D 场景纹理建议开启 Streaming Mipmap根据相机距离动态加载不同 mip 层级。音频文件可以选择压缩格式避免大量无压缩的 WAV 在内存中解码。考虑使用 Addressables 的Remote Load和Local Load分组区分常驻与低频资源。9. 高效内存优化的落地顺序9.1 从 Profiler 数据出发而非从猜测出发内存优化最忌讳“想到哪做到哪”。正确顺序应当是先拿到客观数据再决定优先处理哪块。比如你的 Profiler 显示 GC Alloc 只有 30 KB/帧但原生内存中的 Mesh 占用了 500 MB那优化代码层分配并没有太大意义此时重点应放在资源压缩与卸载策略上。结合我的经验一般移动端项目的优先级是纹理与图集内存往往占了最大部分。场景资源与模型内存影响加载峰值和切换速度。C# 托管堆与 GC 分配影响每帧稳定性和瞬时卡顿。音频、动画、粒子等其他系统视项目类型而定。9.2 小步验证不要一次性推翻架构很多团队在内存优化中容易走上两个极端要么完全不动架构只靠压缩贴图要么推翻现有加载方案全面引入 Addressables。后者风险极大因为资源管理重构会牵连大量业务逻辑。更稳妥的方案是先做静态检查找出明显的高频分配代码。再对核心玩法流程抓 Profiler 数据。使用场景切换测试定位资源残留。若现有 Resources/AssetBundle 方案限制太死才考虑渐进式迁移 Addressables。9.3 建立内存基线与回归测试内存优化不是一次性的工作。项目后续每增加一个玩法、UI 或资源都可能重新引入问题。因此建议在 CI 或版本验证流程中加入“内存基线”检查记录关键场景进入前、进入后、退出后的内存快照数字。设置警戒线例如玩法退出后比进入前多出的常驻内存不能超过 15 MB。一旦超标自动触发警报或让开发者在 MR 阶段重新检查。这样能有效防止内存问题在开发周期中悄然回归。10. 总结与下一步实操方向Unity 内存管理机制并不算一门“新语言”但它涉及多个层级C# 托管堆、引擎原生堆、资源缓存、引用计数、GC 机制。真正的性能优化高手不是背下了很多冷门 API而是能快速判断当前的内存压力来自哪一层并选择合适的工具去验证。在本期内容中我们重点梳理了托管内存与非托管内存的区别。字符串拼接、LINQ、委托、装箱带来的额外 GC Alloc。AssetBundle、Addressables 和 Resources 在资源生命周期管理上的差异。如何通过 Unity Profiler 和 Memory Profiler 定位内存残留。对象池、编码规范、资源打包等工程层面的落地手段。如果你是刚开始接触 Unity 性能优化不建议一股脑去读引擎源码。先打开一个你最近维护的项目运行起来点开 Profiler把内存面板截图下来观察 GC Alloc 曲线、总内存曲线和资源个数曲线。哪怕你只做这一步也会比之前的自己更接近问题本质。下一期可以继续聊 Searchable 的分块内容例如“对象池实现细节”“Addressables 从零迁移指北”或“DOTS 与 Job System 对内存布局的重构”你可以根据项目需要挑选方向。如果本文对你有帮助可以点个收藏后面真机排查时随时翻出来对照清单。欢迎在评论区留下你遇到的 Unity 内存报错或高占用场景我看到后会整理成更多实战案例一起把 Unity 性能优化这门“玄学”彻底变成工程科学。