Unity 资源管理模块设计：从加载策略到引用计数全解析

开场做第一个商业化项目的时候，资源管理模块是我踩坑最深的子系统之一。某次大版本更新后，玩家在连续切换三个场景后游戏直接闪退，Profiler 抓到的内存峰值是 1.8GB。根源是某个 UI 弹窗持有了一份共享特效的Material实例没释放，导致它所在的 AssetBundle 始终无法卸载，依赖链上几十 MB 的纹理全部驻留内存。更早还翻车过一次：异步加载没做请求合并，同一帧对同一个 AssetBundle 发起了 4 次加载，重复 IO 白烧了不说，几处回调拿到的资源还互不一致。这两次事故指向同一个结论：资源管理不是"调用Load拿资源"这么简单，它是一套状态机——加载、引用、释放三个阶段必须严格闭环。任何一环漏了，表现就是内存只涨不跌，最后在低端机上闪退。本文就从底层机制出发，把这套模块怎么设计讲透。一、先理解 AssetBundle 到底是什么设计之前，得先知道你在管理的东西在引擎里长什么样。一个.ab文件本质上是一个SerializedFile：头部是元数据（包含哪些对象、类型信息、依赖了哪些其他 Bundle），后面跟着压缩过的对象数据块。Unity 支持不压缩、LZMA（压缩率高、解压慢、整体解压）和 LZ4（压缩率中等、按块解压、可随机访问）三种格式——这就是为什么打 Bundle 时推荐 LZ4：运行时只需解压用到的块，加载快、内存占用低；LZMA 适合下载分发，但一般要进包后重转。加载也分两步，理解这两步是理解一切坑的前提：