1. 从一次资源加载卡顿说起：为什么值得深挖 Resource 模块
做过 Unity 商业项目的人大概都有过这种体验：游戏在编辑器里跑得飞快，打包到真机之后，切个场景要黑屏两三秒，点开一个 UI 面板会明显掉帧，Profiler 里Resources.Load的峰值高得吓人。更让人头疼的是，热更新之后资源引用错乱，明明改了图集，线上玩家看到的还是旧图。这类问题十有八九都指向同一个地方——资源管理。
GameFramework 这套框架在国内 Unity 圈子里流传很广，它的 Resource 模块是整个框架里最核心、也最容易被低估的一块。很多人用这套框架，只是照着 Demo 把流程跑通，知道有个LoadAsset能加载资源就完事了，至于它内部怎么管理资源句柄、怎么处理依赖、怎么和对象池配合、怎么支撑热更新，基本是一问三不知。结果就是一旦线上出问题，排查起来毫无头绪。
这篇内容我想把 GameFramework 的 Resource 模块从头到尾拆一遍。不是那种照着 API 文档念一遍的流水账，而是结合我实际在项目里踩过的坑，讲清楚它为什么这么设计、每个关键类承担什么职责、资源从加载到释放的完整生命周期是怎么走的、以及在实际项目里怎么用才不容易翻车。适合已经用过 GameFramework 但想搞懂底层机制的人，也适合正在选型资源管理方案、想借鉴设计思路的开发者。读完之后，你应该能自己判断：什么场景该用同步加载、什么场景必须走异步、资源到底什么时候才能真正释放、以及热更新模式下资源路径该怎么规划。
2. Resource 模块的整体骨架：几个核心类到底谁管谁
2.1 从 ResourceManager 往下看，职责是怎么分层的
GameFramework 的 Resource 模块不是一个大类包打天下，而是拆成了好几层。最上层是我们业务代码直接打交道的ResourceManager，它对外暴露LoadAsset、LoadScene、UnloadAsset这些方法。但ResourceManager本身并不直接读文件，它更像一个调度中心，真正干活的是它内部持有的ResourceLoader和一组ResourceAgent。
往下走，ResourceLoader负责的是"怎么把资源从磁盘或 AB 包里读出来"，它管的是加载通道；而ResourceAgent管的是"这个资源当前被谁引用、引用了几次、能不能释放"，它管的是生命周期。再往下，才是真正和 Unity 引擎打交道的部分，比如AssetBundle的加载、Asset的实例化。这种分层的好处是：加载逻辑和引用计数逻辑解耦，换一套底层加载方式（比如从 AB 包换成别的格式），上层的引用管理几乎不用动。
我见过不少团队自己写的资源管理器，把加载、缓存、引用计数全塞在一个类里，代码写到两千行，谁都不敢改。GameFramework 这种拆法，虽然初看类多了点，但每一块的边界很清楚，出问题的时候能快速定位是哪一层的事。
2.2 ResourceAgent 才是引用计数的真正主角
很多人以为引用计数是ResourceManager在管，其实不是。ResourceManager里维护的是一个资源名到ResourceAgent的映射表，真正的引用计数存在ResourceAgent里。每次你调用LoadAsset，框架会先看这个资源有没有对应的 Agent，没有就创建一个，有就把它的引用计数加一。释放的时候减一，减到零才真正走卸载流程。
这里有个细节特别关键：ResourceAgent的引用计数是分层的。一个资源可能被多个地方引用，比如一张图集既被 UI 用，又被某个特效引用，那它的计数就是 2。只有当这两处都释放了，计数归零，资源才会被标记为可卸载。这个机制听起来简单，但实际项目里最容易出的问题就是"计数泄漏"——某个地方加载了却忘了释放，导致资源永远驻留内存。后面我会专门讲怎么排查这类问题。
2.3 资源对象的三种形态：Asset、AssetBundle、Resource
理解 Resource 模块，必须搞清楚三个概念的区别。AssetBundle是打包后的二进制文件，是磁盘上的东西；Asset是 AB 包里具体的某个资源，比如一张贴图、一个预制体；而Resource在 GameFramework 里是一个抽象概念，它可能是单个 Asset，也可能是一组 Asset 的集合。
框架里有个ResourceObject的概念，它是对加载结果的封装。你调用LoadAsset拿到的不是直接的UnityEngine.Object，而是一个ResourceObject或者通过回调拿到的资源句柄。这样做的好处是框架可以在中间插入自己的逻辑，比如引用计数、依赖管理、加载优先级调度。如果你直接拿UnityEngine.Object，这些事就得自己干。
提示：新手最容易犯的错是把
ResourceObject当成普通资源对象到处传，结果释放的时候不知道该释放谁。记住一个原则：谁加载，谁释放，加载和释放要成对出现。
3. 资源加载的完整链路：一次 LoadAsset 背后发生了什么
3.1 同步加载和异步加载，底层走的根本不是一条路
先说说同步加载。你调用LoadAsset传个资源名进去，框架会先查缓存，缓存里有就直接返回，没有就走加载流程。同步加载会阻塞主线程，直到资源从 AB 包里读出来并实例化完成。这个过程在编辑器模式下可能很快，因为编辑器直接读源文件，但打包之后读的是 AB 包，还要解压、反序列化，耗时可能几十毫秒甚至上百毫秒。所以同步加载只适合那些启动时必须立刻拿到的小资源，比如配置表、少量基础 UI 图。
异步加载就复杂多了。LoadAssetAsync不会立刻返回资源，而是返回一个加载任务，你需要注册回调或者用协程等待。框架内部会把加载请求丢进一个队列，由ResourceLoader按优先级逐个处理。异步加载的好处是不卡主线程，但代价是你要处理好"资源还没加载完，但逻辑已经往下走了"这种情况。我见过太多项目因为异步加载没处理好时序，导致空引用报错。
这里有个经验：异步加载的回调里不要做重逻辑。回调是在加载线程或者主线程的某个时机触发的，你在里面做复杂计算或者再触发一堆加载，很容易把加载队列搞乱。正确的做法是回调里只做状态标记，真正的逻辑放到下一帧或者用事件通知。
3.2 依赖关系是怎么被自动处理的
一个预制体可能依赖材质，材质依赖贴图，贴图又依赖图集。如果你手动管理这些依赖，迟早会漏。GameFramework 的 Resource 模块会自动处理依赖：加载一个资源时，它会先读取这个资源的依赖列表，把依赖的资源也一并加载，并且给每个依赖资源的引用计数加一。
这个机制很省心，但有个坑要注意：依赖资源的引用计数是跟着主资源走的。也就是说，你加载了预制体 A，它依赖贴图 T，T 的计数会加一。当你释放 A 的时候，T 的计数会减一。如果你在别的地方也直接加载了 T，那 T 的计数就是 2，释放 A 之后 T 还剩 1，不会被卸载。这个逻辑是对的，但如果你不清楚，就会疑惑"为什么我释放了预制体，贴图还在内存里"。
排查依赖问题有个实用技巧：在编辑器里打开 GameFramework 的调试窗口，能看到当前所有资源的引用计数和依赖关系。线上出问题的时候，也可以把这份数据打日志出来对比。我一般会在版本提测前跑一遍资源引用快照，和上个版本对比，看看有没有异常增长的资源。
3.3 加载优先级和队列调度，决定了你的加载顺序
异步加载请求不是先来先服务的，框架支持设置优先级。优先级高的请求会插队到前面处理。这个设计在切场景的时候特别有用：场景加载是最高优先级，UI 资源次之，预加载的远景资源最低。这样能保证玩家最先看到的东西优先加载出来。
但优先级不是万能的。如果你一次性丢进去几百个加载请求，即使优先级排得再好，总带宽就那么大，该等还是得等。我的做法是分批加载：先加载必须的，等这一批完成回调之后再加载下一批。这样虽然总时间可能差不多，但内存峰值会低很多，因为不会同时有几百个资源处于"加载中"状态。
3.4 加载失败的处理，比成功路径更值得关注
资源加载失败的原因五花八门：AB 包没下载完、资源名拼错了、依赖缺失、内存不足。框架在加载失败时会走错误回调，但很多人只写了成功回调，失败回调里就打个日志了事。这在线上是灾难。
正确的做法是：失败回调里要有降级方案。比如 UI 图加载失败，用一张默认图顶上；配置表加载失败，用内置的兜底配置。同时要把失败信息上报，方便定位是哪个资源、什么原因。我一般会在失败回调里记录资源名、错误码、当前内存状态，这三个信息基本能覆盖大部分排查场景。
4. 引用计数与资源释放：内存泄漏的重灾区
4.1 引用计数归零不等于立刻释放
这是最容易被误解的一点。引用计数减到零，资源只是被标记为"可卸载"，真正释放要等到框架的卸载时机。GameFramework 里有个UnloadUnusedAssets的机制，它会定期扫描所有引用计数为零的资源，统一卸载。为什么要延迟？因为频繁地加载卸载会产生大量内存碎片，而且Resources.UnloadUnusedAssets本身是个很重的操作，不能每帧调。
所以你会看到一种现象：释放了资源，内存没立刻降。别慌，等下一次卸载周期到了就会降。但如果你发现过了好几个卸载周期内存还是没降，那基本可以确定是引用计数没归零，有地方泄漏了。
4.2 常见的引用计数泄漏场景
我总结了几种最常见的泄漏：
第一种是事件监听没取消。你加载了一个资源，注册了某个事件回调，释放资源的时候忘了取消事件。事件系统持有回调的引用，回调又持有资源的引用，资源就永远释放不了。这种泄漏最隐蔽，因为从引用计数上看不出来，得用内存快照对比才能发现。
第二种是闭包捕获。C# 的 lambda 会捕获外部变量，如果你在异步加载的回调里捕获了某个资源对象，而这个回调又被别的地方持有，资源就释放不了。写异步代码的时候要特别小心这一点。
第三种是对象池没清理。GameFramework 有对象池模块，池子里的对象如果引用了资源，池子不清空，资源就释放不了。切场景的时候一定要记得清理对象池。
第四种是静态变量持有。这个最直接，静态字段引用了资源对象，整个生命周期都不会释放。我见过一个项目把加载好的配置表存在静态字典里，结果每次热更新都重新加载一份，内存越涨越高。
4.3 用引用计数快照定位泄漏
光靠猜没用，得有数据。我的做法是在关键节点（比如切场景前后、打开关闭大界面前后）打一份资源引用计数快照，格式就是"资源名: 计数"。两份快照一对比，计数只增不减的资源就是嫌疑对象。
更进一步，可以记录每个资源的引用来源。框架本身不提供这个，但可以在自己的封装层加：每次加载资源时记录调用堆栈，释放时清除。这样泄漏的时候能直接看到是谁加载了没释放。这个功能在开发期很有用，上线前可以关掉，避免性能开销。
注意：引用计数快照本身也有开销，不要在每帧都打。只在关键节点打，而且线上要能动态开关。
5. 和对象池、热更新的配合：实际项目里的组合拳
5.1 对象池和资源池是两回事，别搞混
很多人把对象池和资源池混为一谈。对象池管的是"实例"，比如子弹、特效这些频繁创建销毁的 GameObject；资源池管的是"资源"，比如贴图、预制体这些加载一次多次使用的东西。GameFramework 里对象池是独立的模块，但它和 Resource 模块有配合。
配合点在于：对象池里的对象如果被回收，它引用的资源不应该被释放，因为下次还要用。所以对象池通常会持有资源的引用，保证资源不被卸载。但切场景的时候，对象池要清空，这时候资源引用也要一并释放。这个顺序很重要：先清对象池，再释放资源，反过来会出问题。
5.2 热更新模式下资源路径的规划
热更新是 GameFramework 的强项，但资源路径规划不好，热更新会变成噩梦。核心原则是：可热更的资源和不可热更的资源要分开。不可热更的（比如框架代码、基础 Shader）放在包内，可热更的（比如 UI 图、配置、玩法预制体）放在可更新目录。
框架通过ReadWritePath和ReadOnlyPath来区分这两类路径。加载资源的时候，框架会先查可更新目录，没有再查包内目录。这个查找顺序决定了热更新的覆盖逻辑。我一般会把所有业务资源都放可更新目录，包内只留最基础的启动资源，这样热更新能覆盖的范围最大。
还有个细节：热更新下载下来的 AB 包要校验完整性。框架提供了校验机制，但需要自己配置校验文件。我见过因为下载不完整导致资源加载失败的案例，排查了半天才发现是网络问题。校验这一步不能省。
5.3 资源版本管理和增量更新
每次热更新不是把所有资源都重下一遍，而是只下变化的。框架通过资源版本文件来对比差异。版本文件里记录了每个资源的哈希值，客户端拿本地版本和服务器版本对比，只下载哈希不同的。
这里有个坑：版本文件的生成要保证确定性。同样的资源，两次打包生成的哈希必须一样，否则会导致无谓的更新。影响哈希的因素包括打包顺序、时间戳、随机数等。打包脚本里要把这些不确定因素排除掉，比如固定打包顺序、去掉时间戳。
增量更新还有个内存问题：下载新资源的时候，旧资源还在内存里。如果更新包很大，内存峰值会很高。我的做法是分批下载，下完一批就卸载一批旧资源，控制内存峰值。
6. 性能调优与踩坑实录：那些文档里不会写的事
6.1 AB 包粒度怎么定，直接影响加载性能
AB 包打得太碎，加载时会有大量小文件 IO，性能差；打得太粗，一个包几百兆，加载一个资源要把整个包读进来，内存浪费严重。合理的粒度是按"使用场景"划分：同一个界面用到的资源打一个包，同一个玩法模块的资源打一个包。
但有个例外：频繁共用的小资源要单独打一个共享包。比如通用按钮图、通用字体，这些被几十个界面引用，如果打进各个界面的包，会重复打包，包体膨胀。单独打一个共享包，所有界面依赖它，只加载一次。
我一般会统计每个资源的引用次数，引用次数超过阈值的（比如 5 次）就抽出来放共享包。这个统计可以在打包脚本里自动做，不用手动维护。
6.2 加载卡顿的排查思路
线上反馈卡顿，怎么定位是不是资源加载的问题？我的排查链路是这样的：
第一步，看卡顿发生的时机。如果是切场景、开界面时卡，大概率是资源加载。如果是战斗中随机卡，可能是 GC 或者别的。
第二步，抓 Profiler。重点看Loading.UpdatePreloading和AssetBundle.LoadFromFile的耗时。如果这两个占比高，就是加载问题。
第三步，看加载的是哪个资源。在加载接口里埋点，记录资源名和耗时，超过阈值的打警告日志。这样能直接定位到具体资源。
第四步，分析这个资源为什么慢。是包太大？是依赖太多？还是磁盘 IO 慢？针对性地优化。
我遇到过最离谱的一次是某个特效预制体依赖了上百张贴图，加载一次要几百毫秒。后来把贴图合并成图集，加载时间降到了几十毫秒。所以依赖数量是个很重要的指标，打包时要输出每个资源的依赖数，超标的要优化。
6.3 内存峰值的控制技巧
内存峰值通常出现在切场景的时候：旧场景资源还没释放，新场景资源已经开始加载。控制峰值的关键是错峰加载。切场景时，先释放旧场景的非必要资源，再加载新场景的核心资源，最后加载次要资源。
框架的卸载是异步的，释放请求发出后不会立刻生效。所以要在释放和加载之间留出时间窗口，比如等一帧或者等卸载完成回调。我一般会用一个加载状态机来管理这个过程：释放阶段、核心加载阶段、次要加载阶段，每个阶段完成后再进下一个。
还有个技巧是预加载。在玩家还在当前场景的时候，提前把下一个场景的核心资源加载好。这样切场景时只需要加载增量部分，峰值会低很多。但预加载要控制量，加载太多会挤占当前场景的内存。
6.4 编辑器模式和真机模式的差异
编辑器模式下资源加载走的是 AssetDatabase，直接读源文件，速度快，而且没有 AB 包的概念。真机模式走的是 AB 包，有打包、压缩、解压的过程。这导致很多问题在编辑器里发现不了。
我的建议是：开发期就要定期用真机模式测试，不要等到提测才发现问题。特别是资源路径、依赖关系、加载时序这些，编辑器和真机差异很大。框架提供了模拟模式，可以在编辑器里模拟 AB 包加载，虽然不完全一样，但能发现大部分问题。
另外，编辑器下的资源引用计数和真机也不一样。编辑器下资源可能被 AssetDatabase 持有，计数不会归零。所以引用计数的调试要在真机模式下做，编辑器下的数据只能参考。
7. 我个人的几条实战心得
用了几年 GameFramework 的 Resource 模块，有几个体会是踩了坑才明白的。
第一，加载和释放一定要成对，而且要就近。加载资源的代码和释放资源的代码最好放在同一个类里，这样不容易漏。如果跨类传递资源引用，一定要有明确的归属约定，谁负责释放要写清楚。
第二，异步加载的回调里只做状态切换，不做业务逻辑。业务逻辑放到状态机里，根据加载状态驱动。这样时序清晰，不容易出竞态问题。
第三，资源命名要有规范。我见过资源名用中文、用空格、用特殊字符的，打包的时候各种报错。统一用英文小写加下划线，按模块分目录，这样路径清晰，也方便自动化工具处理。
第四，打包脚本要自动化，而且要能对比。每次打包输出资源清单，包括资源名、大小、依赖数、哈希。和上个版本对比，能发现异常增长。这个清单也是热更新版本文件的基础。
第五，线上要有资源加载的监控。加载耗时、失败率、内存占用，这些指标要上报。出问题的时候能快速定位是哪个版本、哪个资源的问题。没有监控，排查全靠猜，效率太低。
最后分享一个小技巧：框架的调试窗口可以实时看资源状态，但线上用不了。我的做法是把调试窗口的数据定期 dump 成文本，通过日志上报。这样线上也能看到资源引用情况，排查泄漏特别有用。dump 的频率不用太高，切场景、开关大界面的时候各来一次就够了。
