做 Unity 项目的朋友大概都经历过这样一个夜晚真机上跑着跑着突然闪退日志只留下一行冷冰冰的 OOM你打开 Profiler 一看纹理内存已经涨到了两百多兆而场景里明明只有十几个模型。更让人抓狂的是同一个包在编辑器里跑得好好的一出真机就出问题。这类事故里真正的元凶八成不是渲染、不是逻辑、也不是网络而是 Unity 资源管理这条看似简单的链路。很多团队的第一版资源方案都是从Resources.Load一把梭开始的等到项目中期资源量上来才发现自己已经踩进了一个填不满的坑。这篇内容我想把 Unity 资源管理的那些痛点从为什么痛这个层面拆开讲透而不是只告诉你哪个 API 该用哪个不该用。因为 API 是死记硬背就能会的难的是建立一套正确的心智模型——当你知道每一次加载背后发生了什么、内存里到底有几份数据、谁在持有谁很多玄学 Bug就会自动变成算术题。内容面向的是已经写过一些 Unity 代码、被资源问题折磨过、准备做资源框架或者正在准备面试的朋友纯新手也能看懂我会尽量用生活化的类比把底层机制讲明白。1. 先把资源管理这四个字拆开看1.1 资源的三副面孔文件、导入产物、运行时对象很多人讨论资源管理时会陷入鸡同鸭讲根源在于资源这个词在 Unity 里其实对应三种完全不同的东西而这三者占用的空间、存储的位置、生命周期完全不同。把它们混为一谈后面所有的判断都会错。第一副面孔是源资源文件也就是你从美术、音效、策划那边拿到的东西hero.png、boss.fbx、bgm_login.wav。它们躺在Assets目录里是给人看的也是版本管理工具真正追踪的东西。第二副面孔是导入产物Unity 在 Import 的时候会把源文件转换成引擎内部格式同时生成同名的.meta文件里面记录着这个资源的 GUID 和各项导入设置。GUID 是资源在工程里的身份证号你重命名文件、移动目录引用关系之所以不会断就是靠这个 GUID 在撑。第三副面孔才是运行时对象也就是你代码里能拿到的Texture2D、Mesh、AudioClip、GameObject它们住在内存里是真机上 OOM 的直接责任人。理解这三者的分离是理解一切资源问题的起点。举个最典型的例子你在 Inspector 里把一张贴图的 Max Size 从 2048 改成 1024源文件一个字节都没变但导入产物变了运行时内存直接砍到四分之一。反过来你修改了.meta文件里的 GUID 或者删掉.meta源文件还在但所有引用会全部丢失材质变粉、预制体丢组件。我见过不止一次有人在整理工程目录的时候顺手删了一堆.meta然后整个项目报了几千个 Missing 引用最后只能从版本库回滚。所以记住一句话源文件管内容meta 管身份导入产物管运行时表现三者各司其职谁都别乱动。1.2 内存账本到底谁在持有谁在计数要搞懂资源为什么释放不掉必须先明白 Unity 里内存被占用这件事是怎么发生的。答案很简单只要还有任何一个地方持有对它的引用它就不该被释放。这个地方可以是场景里的一个 GameObject可以是一个静态字段可以是一个还没结束的协程闭包可以是你自己写的缓存字典也可以是 AssetBundle 这层容器的句柄。Unity 的卸载逻辑本质上就是在做一件事——遍历所有引用把没人指向的对象回收掉。我这里画不出图但你可以用快递柜来类比。资源就是一个个包裹引用就是取件码。Resources.UnloadUnusedAssets相当于管理员定期巡查快递柜把没人认领的包裹清出去。问题在于只要还有一张取件码存在哪怕这张码被塞在某个你早就忘了的静态 List 里包裹就一直占着柜子。真机上那些明明切换了场景内存却没降的案例九成都是这种情况场景都销毁了但某个事件回调、某个单例缓存、某个static变量还攥着资源的引用。更需要警惕的是 Unity 内存的两套账原生内存Native和托管堆Mono/IL2CPP Heap。纹理像素、网格顶点、音频 PCM 数据这些大块头都在原生侧由引擎自己管理而Texture2D、Mesh这些 C# 包装器对象住在托管堆上由 GC 管。这两套账的回收时机是不同步的。你把一个Texture2D引用置空之后原生侧的像素数据并不会立刻释放托管侧的包装器也要等到下一次 GC 才被回收。更麻烦的是如果原生对象已经销毁、托管外壳还留在堆上Memory Profiler 里就会显示为Leaked Managed Shell托管外壳泄漏。这类泄漏单次只有几十字节但如果有几万个资源反复加载卸载累加起来就非常可观了而且它会让你的内存曲线看起来毛毛的怎么都压不平。1.3 为什么该不该卸载这件事 Unity 不替你做决定很多从其他引擎转过来的朋友会问为什么 Unity 不给资源加个自动引用计数用完就自动释放答案在于语义。Unity 不知道你手里这个Texture2D是准备立刻丢掉还是打算留在内存里当缓存还是下一个场景马上要用。同一个资源在不同的业务场景下正确的处理方式完全相反。缓存能提升性能但会抬高内存水位立刻释放能压低内存但会带来反复 IO 和卡顿。所以 Unity 的选择是把决策权交给你同时给你一堆开关Resources.UnloadAsset、Resources.UnloadUnusedAssets、AssetBundle.Unload(bool)、AudioClip.UnloadAudioData、Addressables.Release。开关给多了选择困难就出现了——这正是 Unity 资源管理痛点的本质。它不是技术难题而是一个决策难题。你需要在加载速度、内存水位、代码复杂度、团队协作成本这四个维度之间做取舍而这个取舍没有标准答案只有适合不适合。2. 六个绕不开的经典痛点逐一拆解2.1 痛点一Resources 文件夹是最甜的陷阱Resources目录大概是 Unity 新手最爱的功能没有之一。Resources.Load(Prefabs/Enemy)一行代码就能拿到资源不需要路径管理、不需要异步、不需要打包写起来特别爽。但它有三个致命的特性几乎注定了它只能用来做原型。第一Resources目录下的所有资源会被无条件打进包体不管你有没有用到。你放进去一个 500MB 的测试模型忘了删包体就实打实多 500MB。第二Resources 的数据会合并进一个序列化文件并且它的索引表在游戏启动时会常驻内存。资源越多索引越大这个开销在启动阶段就要付掉而且降不下来。第三Resources目录不支持热更新因为它已经被编进主包了你没法在不重新发版的前提下替换里面的内容。所以业内的共识是Resources只用来放那些启动就要用、永远不删、体积很小的东西比如启动 Logo、默认字体、几个小图标。真要做正式的资源管理从第一天就得把Resources目录当成禁区来治理。这里有个实操建议在 CI 里加一条检查规则扫描Assets/Resources下的文件数量和总体积超阈值直接让构建失败。用规则去约束人比靠 Code Review 去抓有效得多。注意面试里被问Resources 和 AssetBundle 的区别只答一个同步一个异步是拿不到分的。要答出无条件打包、索引常驻、无法热更这三点再补一句只适合放少量常驻小资源才算说到点上。2.2 痛点二AssetBundle 的依赖地狱与冗余打包为了绕开Resources的限制大家自然转向AssetBundle后文简称 AB。AB 解决了热更新和按需加载的问题但顺手带来了一堆新麻烦其中最恶心的就是依赖管理。一个预制体引用了材质材质引用了贴图贴图又引用了另一张遮罩图。打包的时候如果这几个东西被分到了不同的 AB 里那么加载预制体所在的 AB 时你必须先把它的所有依赖 AB 也加载进来否则就会出现贴图丢失、材质变粉、Shader 报错。这个依赖关系不是随便猜的它记录在打包时生成的 Manifest 文件里运行时需要你自己去解析、递归加载、并且保证加载顺序正确。手写这套逻辑稍不留神就是运行时黑屏。另一个痛点是资源冗余。假设一张公共贴图被 20 个 AB 引用如果不做特殊处理Unity 会把它在每个 AB 里都打一份包体直接膨胀 20 倍。更隐蔽的情况是同一个资源被Resources目录和 AB 同时引用这会导致它被打包两次——一份进主包一份进 AB运行起来还要占两份内存。这种问题用肉眼看是看不出来的必须借助打包分析工具看 Build Report 里的资源列表或者自己写脚本把每个 AB 包含的资源清单导出来做去重对比。依赖问题的本质是粒度划分。粒度太粗一个 AB 几百兆加载慢、内存峰值高、改一个资源要重下整个包粒度太细AB 数量上百IO 次数暴涨、依赖管理代码复杂度爆炸、文件头开销占比过高。找一个平衡点这是资源框架设计里最考验功力的一环后文第 3 章会专门讲切分原则。2.3 痛点三卸载时机的两难选择AB 的卸载接口只有一个AssetBundle.Unload(bool unloadAllLoadedObjects)。这个 bool 参数看起来人畜无害实际上坑了无数人。传true意思是卸载这个 AB 的序列化数据同时把所有从它加载出来的对象也一并销毁。听起来很合理但如果此时场景里还有一个物体正在用这个 AB 里的材质或者你代码里还缓存着这个Texture2D那么这些对象会被强行销毁表现为模型变粉、贴图变白、Mesh 消失甚至直接抛MissingReferenceException。传falseAB 的序列化数据也就是那个压缩包本身占的内存会被释放但从它加载出来的对象会继续留在内存里活着。问题是这些对象从此就成了孤儿——你没法再通过这个 AB 去卸载它们了因为容器已经被销毁了它们只能等着UnloadUnusedAssets来收尸。我自己踩过一次特别典型的坑做小游戏平台的适配时某个平台的包体与内存限制都很紧我们把资源切成很多小 AB场景切换时统一Unload(true)。结果偶尔会闪一下粉排查了整整两天最后发现是上一个场景的 UI 用了某个公共图集里的 Sprite而这个图集 AB 被场景切换逻辑强行卸载了而DontDestroyOnLoad的 UI 还活着。修复方式是把这个图集单独归到常驻包里永远不参与场景卸载。至于Resources.UnloadUnusedAssets它的名字有很强的误导性——它卸载的是未被引用的资源而不是你不想要的资源。它内部会做一次全量遍历开销不小在移动端调用一次可能造成几十毫秒的卡顿。所以不要把UnloadUnusedAssets当成万能解药在每个场景切换时无脑调用它更像是一把大扫帚得挑时机用比如 Loading 界面里、或者玩家没有操作压力的时刻。2.4 痛点四引用计数错配带来的泄漏与重复加载自己写资源框架的人很快就会撞上引用计数这个坎。理想模型很简单加载时计数加一释放时计数减一减到零就真正卸载。但现实中的调用关系是一张网不是一棵树。同一个资源被 A 界面、B 界面、C 特效同时使用。A 关闭时减一还剩 2B 关闭时减一还剩 1C 播完特效减一归零可以卸载。模型没错错在必须保证每一次加都有对应的减。一旦某个界面是被强制关闭的、某个特效是被对象池回收的、某条异常分支提前 return 了这个减就丢了计数永远降不到零资源永远不释放。这就是典型的内存泄漏。反过来也有问题重复加载。你在界面 A 里加载了贴图并缓存界面 B 又独立加载了一次拿到的是同一个原生对象Unity 底层会做去重但引用计数变成了 2。等两边都释放之后计数只降到 0 恰好对应一次另一次就凭空多出来了。如果框架没有做同路径复用同一句柄的处理这种重复计数会让计数永远归不了零。我的经验是引用计数必须绑定在句柄对象上而不是绑定在资源路径或者字段上。加载接口返回一个IResourceHandle释放必须调用这个句柄自己的Dispose并且要在句柄上做幂等保护重复 Dispose 不生效并打警告。这样即使某处代码写错也能通过日志快速定位到是谁多释放了、谁少释放了。2.5 痛点五内存峰值不可控肉眼看不见的大块头很多项目内存爆掉不是因为它泄漏了而是因为它在一瞬间要的东西太多。Unity 加载 AB 的典型流程是从磁盘读取二进制数据占一份内存解压再占一份反序列化成对象又占一份。如果这个 AB 有一百兆峰值可能瞬间冲到两三百兆。在低端机上这就是一次必死的闪退。所以做资源管理必须对一个资源值多少内存有量化直觉。下面这张表是我自己常用的估算速查平时评估方案时直接套用比凭感觉靠谱得多。资源类型规格内存占用约说明纹理 RGBA321024×1024无 Mipmap4.0 MB32 位真彩最奢侈的格式纹理 RGBA321024×1024有 Mipmap5.33 MBMipmap 额外增加约 33%纹理 RGBA322048×2048有 Mipmap22.4 MB分辨率翻倍内存涨 4 倍纹理 ASTC 6×61024×1024有 Mipmap约 0.59 MB约 3.56 bpp压缩比接近 9:1网格 Mesh10 万顶点含位置/法线/UV/切线约 4.8 MB每顶点约 48 字节开启 Read/Write 会翻倍网格索引15 万三角形32 位索引约 1.8 MB三角形数 ×3 ×4 字节音频 PCM44.1kHz / 16bit / 立体声约 172 KB/秒3 分钟约 31 MB非常恐怖这张表里最值得盯的是最后一行。一段三分钟的立体声未压缩音乐内存占用和一张 2048 的大图差不多而它经常被忽略。移动端项目里长音频一定要用流式加载Load Type设为Streaming音效才用Decompress On Load中长音频用Compressed In Memory选择逻辑跟音频时长直接挂钩。还有一点容易被忽视编辑器下的内存表现和真机完全不同。编辑器里资源是通过 AssetDatabase 实时读取的不经过 AB 打包流程也有大量编辑器自身的开销。你在编辑器里看到的 300MB真机上可能是 150MB 也可能是 500MB完全没参考价值。所有内存结论都必须以真机 Profiler 采样为准这一点我后面还会再强调。2.6 痛点六团队协作下的规范失控技术问题好解决协作问题才要命。资源管理最怕的不是机制复杂而是每个人对资源的处理方式都不一样。美术同学导出一张贴图有人设 Max Size 2048有人设 4096有人忘了取消 Read/Write有人勾了 Mipmap 有人没勾。策划同学命名时有的用下划线有的用驼峰有的带版本号有的不带。程序同学有的从Resources读有的从 AB 读有的场景里直接拖引用有的代码里硬编码路径。等到项目中期要做资源优化你连工程里到底有多少张超过 2048 的贴图这种问题都要现写脚本去统计。治理这件事的方法论很朴素能自动化的绝不靠人能靠工具的绝不靠文档。具体可以做三件事。第一写 AssetPostprocessor 脚本在资源导入时自动套用预设配置比如按目录规则自动设置纹理压缩格式、Max Size、是否 Mipmap美术根本不需要关心这些参数。第二写一个资源检查工具定期扫描工程输出问题清单超规格贴图、重复资源通过 MD5 或资源内容哈希比对、未引用资源、命名不合规资源。第三在 CI 构建前跑一次检查有严重问题直接卡住构建。这三件事做下来资源规范能自动落地八成以上比开十次会都管用。3. 从痛点反推设计建立自己的资源管理模型3.1 四代方案演进与选型对照把 Unity 资源管理的方案按时间线捋一遍能清楚看到每一步演进是为了解决上一代的什么痛点。这些内容在面试里也常被问到但更重要的是它能帮你在新项目立项时做出正确选择。方案出现动机核心优势主要痛点适用场景直接引用Inspector 拖拽最简单零代码、编辑器可视化无法按需加载、场景体积大、无法热更极小 Demo、教学项目Resources免去路径管理同步加载、API 极简无条件进包、索引常驻、不能热更启动常驻小资源AssetBundle支持热更、按需加载灵活、可增量更新依赖管理复杂、卸载易错、需自研框架中大项目、有热更需求Addressables官方封装 AB自动依赖、句柄化、可远程学习成本、版本坑、调试黑盒大多数中大型项目Addressables是目前官方的推荐方案它把 AB 的依赖解析、引用计数、异步加载、远程更新都封好了返回的是AsyncOperationHandle用Addressables.Release释放。它的设计思路和我前面说的句柄绑定引用计数是一致的这也是为什么我一直建议团队优先学 Addressables而不是花大力气自研一套能力重复的框架。当然它也有坑比如InstantiateAsync出来的实例销毁时有额外的计数语义、Catalog 更新流程要摸清、编辑器下 Play Mode Script 的模式选择会影响调试结果这些需要专门花时间趟一遍。选型的判断标准我总结成三句话有没有热更需求有就必须用 AB 系方案。资源总量超过 500MB必须做按需加载和卸载。团队小于三人且项目体量小能简单就别复杂。很多团队吃了亏不是因为选了错方案而是因为在小项目上用了一套重工业级的框架维护成本把开发效率吃干净了。3.2 包的切分原则与参数估算AB 的粒度切分是资源框架里最需要动脑子的部分我给几条可执行的规则。第一按生命周期切而不是按类型切。常驻资源公共图集、UI 通用材质、通用音效打成一个常驻包全程不卸载。场景资源按场景打包跟随场景加载卸载。临时资源活动特效、战斗场景单独成包用完即卸。按类型切所有贴图一个包、所有预制体一个包是最常见的错误做法因为它会导致引用关系跨越所有包任何一个包加载都要拖家带口。第二控制单包大小在 1MB 到 5MB 之间。太小了文件头开销和 IO 次数不划算太大了加载峰值扛不住而且改一个资源要重下整包。当然这个数字要根据你的目标平台调整小游戏平台上可能要压到 500KB 以内。第三把依赖收敛到少数几个公共包。公共包越少依赖图越简单运行时需要维护的引用关系就越清晰。理想状态下依赖层级不要超过三层。第四预加载与分帧策略。AssetBundle.LoadFromFileAsync是异步的但解压和反序列化仍然可能阻塞主线程。如果某个包必须同步加载要做好 Loading 界面的遮蔽或者用Application.backgroundLoadingPriority调整后台加载优先级避免主线程被抢占导致掉帧。3.3 引用计数与句柄谁申请谁释放我自己的框架里资源管理层暴露给业务层的只有一个接口Load返回句柄句柄负责Release。业务代码永远拿不到裸的AssetBundle对象也永远不直接调用Unload。这样做的价值在于把复杂度关在笼子里。具体机制上句柄内部记录三个东西资源路径、所属 AB 的引用、以及一个释放标记。同一个路径第二次加载时直接返回已有句柄的副本并计数加一而不是重新走一遍加载流程。释放时计数减一归零才真正触发 AB 卸载。释放标记用来做幂等保护——如果同一个句柄被Release两次第二次直接打警告日志并忽略日志里带上调用堆栈这样谁写错了代码一眼就能看出来。还有一条实战经验加载和释放最好成对出现在同一层代码里。界面的OnOpen里加载OnClose里释放特效的播放里加载播放结束时释放。不要出现A 模块加载、B 模块释放这种跨模块持有那种代码半年后连作者自己都理不清。4. 动手复现把痛点变成看得见的数据4.1 验证环境与思路光讲原理容易飘我用一个最小 Demo 把泄漏这件事复现出来这样你在自己项目里排查时就知道该看什么指标。环境上Unity 2022 LTS 就够需要装两个包Memory Profiler用于抓内存快照和AssetBundle Browser用于看打包内容和依赖。目标平台建议直接用真机退而求其次用 Development Build 加上Autoconnect Profiler。验证思路很直接制造一个看起来释放了、其实没释放的场景用 Memory Profiler 抓两次快照做对比看目标资源是否还活着。这个套路适用于任何你怀疑有泄漏的场合。4.2 制造一个典型泄漏下面这段代码是我故意写错的版本它模拟了很多项目里真实存在的写法。using UnityEngine; using UnityEngine.UI; public class LeakyIconLoader : MonoBehaviour { // 静态缓存典型的忘了清理源头 private static readonly Dictionarystring, Sprite s_cache new Dictionarystring, Sprite(); [SerializeField] private Image iconTarget; [SerializeField] private string iconPath UI/Icons/icon_hero; private AssetBundle m_bundle; public void LoadIcon() { if (s_cache.TryGetValue(iconPath, out var cached)) { iconTarget.sprite cached; return; } // 加载 AB 并取出 Sprite m_bundle AssetBundle.LoadFromFile(Path.Combine(Application.streamingAssetsPath, icons)); var sprite m_bundle.LoadAssetSprite(iconPath); // 缓存一份方便下次直接用 s_cache[iconPath] sprite; iconTarget.sprite sprite; } public void ClosePanel() { // 面板关了引用置空看起来干干净净 iconTarget.sprite null; Destroy(gameObject); } }这段代码里有三个问题我一个一个说。问题一s_cache是静态的它永久持有所有加载过的Sprite引用。只要这个静态字典不清Resources.UnloadUnusedAssets就永远看不到这些资源是无主的一个都卸载不掉。这就是缓存和内存水位之间最直接的矛盾。问题二AssetBundle.LoadFromFile加载的 AB 对象m_bundle从来没有被Unload。即使把静态缓存清了这个 AB 的序列化数据也还占着内存。加载 AB 是一个容器级的引用它和它里面的资源是两层关系必须分别处理。问题三ClosePanel里只是把Image.sprite置空并销毁了 GameObject但没有任何卸载动作也没有清理缓存。看起来把引用断了实际上断的只是一个引用还有两个引用静态字典 AB 容器活着。4.3 用 Memory Profiler 抓到它复现步骤是这样的。第一步启动游戏进入空场景用 Memory Profiler 抓一张基线快照。第二步打开面板加载图标关闭面板再抓一张快照。第三步对比两次快照的 Assets 页签搜索icon_hero这个资源名。如果你看到它仍然存在并且引用链References 面板指向的是那个静态字典那泄漏就被实锤了。这一步是整个排查流程里最有价值的地方——关键在于找到谁在持有而不是为什么没释放。Memory Profiler 的引用链功能会直接告诉你答案比你在代码里大海捞针快一百倍。顺手再补充一个观察点在快照里搜Leaked Managed Shell如果这个数值随着反复开关面板持续增长说明你在反复销毁和重建资源托管外壳在堆积。这种情况通常需要通过GC.Collect()或者减少资源反复创建来缓解根本上还是要靠对象池把加载卸载的频率降下来。4.4 修复对照改几行代码看内存曲线修完之后的版本长这样核心变化就是引入句柄和显式释放。public class IconHandle : System.IDisposable { private AssetBundle m_bundle; private bool m_released; public Sprite Sprite { get; private set; } public IconHandle(AssetBundle bundle, Sprite sprite) { m_bundle bundle; Sprite sprite; } public void Dispose() { if (m_released) { Debug.LogWarning($[IconHandle] 重复释放请检查调用栈\\n{System.Environment.StackTrace}); return; } m_released true; Sprite null; if (m_bundle ! null) { m_bundle.Unload(false); // 只卸容器对象由 UnloadUnusedAssets 收尾 m_bundle null; } Resources.UnloadUnusedAssets(); } }然后业务层改成OnClose里调用handle.Dispose()同时把静态缓存整个删掉改成由框架层统一维护弱引用缓存或者干脆不做缓存因为图标本来就在常驻图集里。修复后重新跑一遍对比同一个操作路径下纹理内存的峰值应该能稳定在一个水平线上反复开关十次也不会持续上涨。这里我要强调一个观念做资源优化不要凭感觉要建立操作路径 → 内存曲线的对照关系。每一次优化都应该有一个可复现的操作序列和一份前后对比的数据否则你永远不知道自己到底优化了多少。5. 常见问题与排查速查5.1 症状、原因与处理对照表下面这张表是我这几年攒下来的很多问题看一眼症状就能猜到方向。症状高概率原因处理方向模型变粉、贴图全白依赖 AB 未加载或 AB 被Unload(true)强制卸载检查依赖加载顺序公共资源单独常驻切场景后内存不降静态字段、单例、事件回调、协程持有引用用 Memory Profiler 看引用链清理静态引用内存曲线持续缓慢上涨托管外壳泄漏、重复加载导致计数不归零检查句柄幂等性减少加载卸载频率加对象池低端机随机闪退无日志加载峰值太高瞬时内存超限拆分大包、降低纹理规格、改流式音频编辑器正常真机报错编辑器不走打包流程路径/大小写/依赖表现不同所有验证必须在真机 Development Build 上做包体比预期大很多资源冗余打包、Resources目录混入大文件、测试资源未清理用 Build Report 分析去重CI 卡阈值音频播放卡顿长音频用了 Decompress On Load加载时占用主线程长音频改 Streaming音效用短音频5.2 通用排查四步法遇到资源问题我一般按固定顺序走不跳步。第一步是量化现象一共有多少内存峰值出现在哪个时刻是持续上涨还是一次性高把描述从内存很高变成进入战斗场景后纹理内存从 80MB 涨到 210MB 且不回落问题的范围就缩小了一半。第二步是定位类型用 Memory Profiler 的快照对比看涨的是纹理、网格、音频还是托管堆。不同类型的资源成因和解法完全不同。纹理涨多半是加载没释放或者规格超标托管堆涨多半是 C# 对象在堆积比如字符串拼接、闭包、事件订阅没解除。第三步是追引用链找到那个不该存在的资源点开 References一层一层往上翻直到找到业务层的持有者。这一步是最关键的也是很多人会跳过的一步。跳过它你就只能靠猜而猜出来的修复往往治标不治本。第四步是验证闭环修完之后用同一套操作路径重新采样对比前后数据。没有闭环的修复等于没修。5.3 几个我踩过的坑和积攒的经验最后说几个文档里不会写、但很值钱的点。关于数字孪生类项目这类项目的特点是模型数量巨大、贴图数量巨大但玩家视野范围内同一时刻其实只需要看到一小部分。这时候按空间分块的流式加载就非常关键思路是把大场景切成网格根据相机位置动态加载邻近块的资源、卸载远处的块。这种周边即加载、离开即卸载的模式配合合理的预加载距离能把内存水位从几个 G 压到几百兆。要注意的是卸载不能太激进否则玩家快速移动时会看到资源来不及加载的空洞预加载半径和卸载半径要错开一段形成滞后。关于小游戏平台适配这类平台对首包体积和运行内存都有硬性上限而且对同步加载、多线程、某些文件 IO 接口的支持和原生平台不一样。我的做法是把资源全部走 CDN 远端加载首包里只放一个 Loading 场景和必要的框架代码同时把所有资源的规格再压一档——纹理 Max Size 降到 1024 甚至 512音频全部走短音效加流式音乐模型面数砍一半。听起来很粗暴但在小屏幕上画质损失其实感知很小内存收益却非常明显。关于 Shader 和材质变体这个东西的内存开销经常被低估。同一个 Shader 因为关键字不同会产生大量变体变体多了不仅包体大运行时编译还会卡顿。项目中期一定要做一次变体剔除把实际用不到的变体从打包里去掉同时用 Shader 变体集合Shader Variant Collection在加载界面预热常用的那几个避免首次出现时卡帧。关于自动化检查的必要性我现在的习惯是每接一个项目前两天先把资源检查脚本搭起来。脚本要能输出超过规格的贴图列表、重复资源列表按内容哈希比对不看文件名、未被引用的资源列表、命名不合规的资源列表。这份清单每次构建前跑一遍邮件发给负责人。坚持几个月团队的资源规范就自然形成了。靠人记住规范是不现实的靠工具卡住才是可持续的。关于版本管理配置Unity 工程的版本库配置一定要正确尤其是要把Library、Temp、Obj、Logs这些目录排除掉Assets下的.meta必须全部提交。同时建议开启 Unity 的 Force Text 序列化模式这样预制体和场景文件都是文本格式合并冲突的时候能看懂、能手动处理。二进制格式的资源虽然也能存但冲突起来基本只能靠二选一团队协作时非常痛苦。关于对象池的边界对象池能显著降低加载卸载频率但池子本身也是内存占用。池子的设计要有上限和回收策略比如超过一定数量的空闲对象就真正销毁掉不能让池子无限膨胀。我见过为了优化性能把池子做得很大结果内存反而更紧张的项目这就本末倒置了。资源管理这件事说到底是一个需要长期打磨的手艺。它没有一劳永逸的银弹只有不断根据项目实际数据调整的取舍。我个人的体会是越早建立量化的评判标准后面就越省心——什么时候该缓存、什么时候该卸载、纹理该开什么规格、包该切多大这些问题的答案都应该来自你自己的真机数据而不是别人的经验值。
