企业官网建设流程全解析

1. 资源模块到底在解决什么问题

做过完整游戏项目的人都有一个共识：代码写得再漂亮，资源管理一旦崩了，整个项目就会变成一场灾难。我见过太多团队在Demo阶段跑得飞快，一到正式版就出现加载卡顿、内存暴涨、资源重复加载、热更后引用错乱这些要命的问题。GameFramework 这套框架里的 Resource 模块，本质上就是冲着这些痛点去的。

它要解决的核心问题可以归纳成三件事：资源的统一加载入口、资源的生命周期管理、以及资源加载方式的解耦。听起来像是老生常谈，但真正落地的时候，每个环节都有大量细节需要处理。比如同一个资源被十个地方同时请求，你是加载十次还是只加载一次？加载中的异步请求怎么合并？资源不用了什么时候释放？对象池里的资源和直接加载的资源怎么区分对待？这些问题如果没有一套统一的机制，代码里就会到处散落着Resources.Load和各种AssetBundle的调用，维护成本会随着项目规模指数级上升。

Resource 模块的设计思路，是把“资源的获取”和“资源的加载方式”彻底分开。上层业务代码只关心“我要一个资源”，至于这个资源是从本地读取、从 AssetBundle 解包、还是从远端下载，全部由底层组件决定。这种分层带来的好处是，你可以在编辑器模式下用最简单的直接加载方式快速迭代，打包时切换到 AssetBundle 模式，甚至可以在运行时动态切换加载策略，而业务层代码一行都不用改。

适合阅读这篇内容的人，应该是对 Unity 有一定了解、写过一些资源加载代码、但还没有系统化资源管理经验的开发者。如果你正在做一个中型以上的项目，或者正在考虑引入一套成熟的资源管理方案，那 Resource 模块的设计思路和实操细节会非常有参考价值。即使你最终不用这套框架，理解它的设计取舍也能帮你在自研方案时少走很多弯路。

2. 核心架构与设计思路拆解

2.1 组件化的分层结构

GameFramework 的 Resource 模块采用了非常典型的组件化设计。最上层是ResourceComponent，它是挂载在游戏对象上的 Unity 组件，也是业务层直接交互的入口。中间层是ResourceManager，负责具体的资源加载逻辑调度。底层则是各种ResourceLoader，每一种 Loader 对应一种加载方式，比如ResourcesResourceLoader、AssetBundleResourceLoader、FileSystemResourceLoader等等。

这种三层结构的好处在于职责非常清晰。ResourceComponent只做参数校验和事件转发，不掺和具体逻辑；ResourceManager管理资源的引用计数、加载任务队列和对象池；ResourceLoader则专注于“怎么把资源读出来”这一件事。当你需要新增一种加载方式时，只需要实现一个新的 Loader 并注册进去，完全不影响现有代码。

我特别想强调的是引用计数机制。ResourceManager 内部维护了一个资源到引用次数的映射表。每次调用LoadAsset都会让对应资源的引用计数加一，每次调用UnloadAsset则减一。只有当引用计数归零时，资源才会真正进入待卸载队列。这个机制看起来简单，但它是避免资源重复加载和内存泄漏的基石。没有引用计数，你要么不敢释放资源导致内存越用越多，要么释放了还在用的资源导致各种空引用异常。

2.2 加载方式的策略模式

Resource 模块最精妙的地方在于它对加载方式使用了策略模式。ResourceManager本身不关心资源从哪里来，它只持有一个IResourceLoader接口的引用。这个接口定义了LoadAsset、LoadAllAssets、UnloadAsset等核心方法。具体的实现类负责处理各自的加载逻辑。

在编辑器环境下，通常会使用ResourcesResourceLoader或者EditorResourceLoader，直接通过 Unity 的Resources.Load或者AssetDatabase.LoadAssetAtPath来加载资源。这样做的好处是迭代速度快，不需要打包就能看到效果。而在真机环境下，则会切换到AssetBundleResourceLoader，从已经打包好的 AssetBundle 文件中读取资源。

这种设计带来的一个实际好处是，你可以在开发阶段用直接加载模式快速验证玩法，在性能测试阶段切换到 AssetBundle 模式来评估真实的加载耗时和内存占用。两种模式之间的切换只需要改一个配置，不需要修改任何业务代码。我在实际项目中就经常利用这一点，在排查“编辑器里好好的，打包后就出问题”这类疑难杂症时，通过切换加载模式来快速定位问题范围。

2.3 对象池与资源缓存的协同

Resource 模块内部有两套缓存机制在同时工作：一套是资源对象的缓存，另一套是资源实例的对象池。这两者的区别经常让人混淆，但理解它们的差异对正确使用这个模块至关重要。

资源对象缓存指的是已经加载到内存中的 Asset 对象本身。比如一张纹理、一个预制体、一段音频剪辑。这些对象被缓存在 ResourceManager 内部的一个字典里，键是资源的完整路径，值是资源对象和它的引用计数。当引用计数归零时，资源对象并不会立即被销毁，而是进入一个待卸载列表，等待下一次 GC 或者手动触发卸载。

对象池则是针对“资源实例”的。比如你从一个预制体实例化出一个游戏对象，这个游戏对象就是资源实例。对象池的作用是复用这些实例，避免频繁的 Instantiate 和 Destroy 操作带来的性能开销。Resource 模块提供了LoadAsset和Instantiate两个不同的接口，前者返回资源对象本身，后者返回资源对象的实例。如果你只是需要读取资源数据而不需要实例化，就用LoadAsset；如果你需要把预制体变成场景中的游戏对象，就用Instantiate。

注意：很多新手会混淆这两个接口，用LoadAsset加载预制体然后手动Instantiate，这样虽然功能上没问题，但会绕过对象池机制，失去实例复用的优化效果。

3. 核心接口与实操要点详解

3.1 资源加载的核心接口

Resource 模块对外暴露的接口主要分为同步加载和异步加载两大类。同步加载接口以LoadAsset为代表，它会阻塞当前线程直到资源加载完成。异步加载接口以LoadAssetAsync为代表，它返回一个加载任务对象，你可以通过回调或者轮询来获取加载进度和结果。

在实际项目中，我强烈建议除极少数特殊情况外，一律使用异步加载。同步加载在资源较小的时候可能感觉不到卡顿，但一旦遇到大纹理或者复杂的预制体，就会造成明显的帧率下降。异步加载虽然代码写起来稍微麻烦一点，但它能把加载耗时分散到多帧，对玩家体验的影响要小得多。

异步加载的典型用法是这样的：调用LoadAssetAsync得到一个LoadAssetTask对象，然后注册OnLoadAssetSuccess、OnLoadAssetFailure、OnLoadAssetUpdate等回调。成功回调里可以拿到加载好的资源对象，失败回调里可以拿到错误信息，更新回调里可以获取加载进度用于显示进度条。

// 异步加载资源的典型写法 var task = resourceComponent.LoadAssetAsync( "Assets/GameMain/UI/UIForms/MainMenuForm.prefab", typeof(GameObject), priority: 100, userData: null ); task.OnLoadAssetSuccess += (sender, assetName, duration, userData) => { // 加载成功，assetName 是资源路径，duration 是耗时 var prefab = sender.Asset as GameObject; // 后续处理 }; task.OnLoadAssetFailure += (sender, assetName, errorMessage, userData) => { // 加载失败，errorMessage 包含失败原因 Debug.LogError($"加载失败: {assetName}, 原因: {errorMessage}"); };

这里有一个细节值得展开：priority参数。ResourceManager 内部维护了一个加载任务队列，优先级高的任务会排在前面执行。这个参数在场景切换或者打开大型 UI 时特别有用。你可以给当前界面急需的资源设置高优先级，给预加载的资源设置低优先级，这样就能保证玩家最先看到的内容优先加载出来。

3.2 资源卸载的正确姿势

资源卸载是比加载更容易出问题的环节。我见过太多项目因为卸载时机不对导致各种诡异 bug：贴图变成紫色、模型丢失、音效播放到一半突然中断。Resource 模块通过引用计数来管理卸载，但前提是你必须成对调用加载和卸载接口。

每调用一次LoadAsset，就必须在合适的时候调用一次UnloadAsset。这里的“合适的时候”通常是指资源不再被任何逻辑使用时。比如一个 UI 界面关闭了，它加载的图标、背景图、字体就应该被卸载。但要注意，如果这些资源同时被其他界面引用，卸载操作只会减少引用计数，不会真正释放资源。

// 加载和卸载必须成对出现 resourceComponent.LoadAsset("Assets/GameMain/UI/Icons/Icon_Coin.png", typeof(Sprite)); // ... 使用资源 ... resourceComponent.UnloadAsset("Assets/GameMain/UI/Icons/Icon_Coin.png");

提示：在开发阶段，可以开启 ResourceManager 的引用计数调试日志，每次加载和卸载都会输出当前资源的引用计数变化。这个日志在排查资源泄漏时非常有用。

还有一个容易被忽视的点是：资源卸载后，之前获取的资源对象引用就失效了。如果你在卸载之后还持有这个对象的引用并试图访问它，就会遇到空引用或者已销毁对象的异常。所以卸载操作一定要确保所有使用该资源的地方都已经不再需要它了。

3.3 对象池的配置与使用

对象池的使用需要一些额外的配置。ResourceManager 内部有一个ObjectPoolManager，它负责管理所有通过Instantiate接口创建的对象实例。每个预制体路径对应一个对象池，池子里存放着已经实例化但当前未被使用的游戏对象。

当你调用Instantiate时，对象池会先检查对应路径的池子里有没有空闲对象。如果有，直接取出复用；如果没有，才真正执行实例化操作。当你调用UnloadAsset或者手动调用UnloadUnusedAssets时，对象池里的空闲对象会被销毁，但正在使用的对象不受影响。

// 通过对象池实例化预制体 var instance = resourceComponent.Instantiate( "Assets/GameMain/Entities/Enemy.prefab", parent: enemyRoot ); // 回收实例到对象池 resourceComponent.UnloadAsset( "Assets/GameMain/Entities/Enemy.prefab", instance );

对象池的容量是可以配置的。在 ResourceComponent 的 Inspector 面板上，你可以设置ObjectPoolCapacity和ObjectPoolExpireTime。容量决定了每个池子最多缓存多少个空闲对象，超过这个数量的对象在回收时会被直接销毁。过期时间则决定了空闲对象在池子里最多停留多久，超时后会被自动清理。这两个参数的设置需要根据具体项目的资源使用模式来调整，没有放之四海而皆准的数值。

4. 完整实操流程与关键环节

4.1 环境准备与组件配置

在开始使用 Resource 模块之前，需要先完成一些基础配置。首先是在场景中创建一个挂载了ResourceComponent的游戏对象。通常这个对象会作为游戏启动流程的一部分，在游戏初始化阶段就被创建出来，并且设置为DontDestroyOnLoad，确保它在整个游戏生命周期内都存在。

ResourceComponent 的 Inspector 面板上有几个关键参数需要配置。ResourceMode决定了使用哪种加载模式，可选值包括Resources、AssetBundle、FileSystem等。在编辑器开发阶段，通常选择Resources模式，这样可以直接利用 Unity 的 Resources 系统快速加载资源。在打包发布时，则需要切换到AssetBundle模式。

LoadResourceAgentHelperCount参数决定了同时进行的加载任务数量上限。这个值设置得太小会导致加载队列拥堵，设置得太大则会占用过多系统资源。根据我的经验，在移动端设备上，这个值设置在 3 到 5 之间比较合适；在 PC 端可以适当提高到 8 到 10。

还有一个重要的配置是ResourceHelperTypeName，它指定了底层使用的资源辅助器类型。框架默认提供了DefaultResourceHelper，但你可以根据需要实现自己的 ResourceHelper，比如加入资源加密解密、自定义缓存策略等逻辑。

4.2 资源加载的完整代码实现

下面通过一个完整的示例来展示资源加载的标准流程。假设我们要加载一个 UI 预制体并实例化到场景中。

public class ResourceLoadExample : MonoBehaviour { private ResourceComponent resourceComponent; private void Start() { // 获取 ResourceComponent 引用 resourceComponent = GameEntry.GetComponent<ResourceComponent>(); // 异步加载 UI 预制体 LoadUIFormAsync("Assets/GameMain/UI/UIForms/MainMenuForm.prefab"); } private void LoadUIFormAsync(string assetPath) { var task = resourceComponent.LoadAssetAsync( assetPath, typeof(GameObject), priority: 100 ); task.OnLoadAssetSuccess += OnLoadSuccess; task.OnLoadAssetFailure += OnLoadFailure; task.OnLoadAssetUpdate += OnLoadUpdate; } private void OnLoadSuccess(object sender, string assetName, float duration, object userData) { var loadTask = sender as LoadAssetTask; var prefab = loadTask.Asset as GameObject; if (prefab != null) { // 通过对象池实例化 var instance = resourceComponent.Instantiate( assetName, parent: transform ); if (instance != null) { // 设置实例的初始状态 instance.transform.localPosition = Vector3.zero; instance.transform.localScale = Vector3.one; } } } private void OnLoadFailure(object sender, string assetName, string errorMessage, object userData) { Debug.LogError($"资源加载失败: {assetName}, 错误: {errorMessage}"); } private void OnLoadUpdate(object sender, string assetName, float progress, object userData) { // progress 取值范围 0 到 1 Debug.Log($"加载进度: {assetName} - {progress * 100:F1}%"); } }

这段代码展示了几个关键点。第一，加载和实例化是分开的两步操作，先通过LoadAssetAsync把预制体加载到内存，再通过Instantiate创建实例。第二，实例化时传入的assetName必须和加载时使用的路径完全一致，否则对象池无法正确匹配。第三，加载成功回调中获取资源对象的方式是通过loadTask.Asset，而不是直接使用sender。

4.3 资源依赖关系的处理

在实际项目中，资源之间往往存在依赖关系。比如一个 UI 预制体可能引用了多个贴图、字体和材质。当你加载这个预制体时，它的依赖资源也需要被一并加载。Resource 模块通过 AssetBundle 的依赖关系来自动处理这个问题。

在 AssetBundle 模式下，每个 AssetBundle 文件都会记录它依赖的其他 AssetBundle。当 ResourceManager 加载一个 AssetBundle 时，它会先检查依赖列表，确保所有依赖的 AssetBundle 都已经加载完成，然后再加载目标 AssetBundle。这个过程是递归的，所以即使依赖链很深，也能正确加载。

但这里有一个性能陷阱需要注意：如果依赖关系设计得不好，可能会导致大量不必要的资源被加载。比如你把所有 UI 共用的图集打成一个 AssetBundle，那么加载任何一个 UI 都会把这个大图集加载进来，即使这个 UI 只用了其中一小部分图标。所以在规划 AssetBundle 打包策略时，需要在“减少包体数量”和“减少不必要的依赖加载”之间找到平衡点。

我的经验是，按照资源的使用频率和生命周期来划分 AssetBundle。高频使用且贯穿整个游戏生命周期的资源（比如通用图集、基础字体）放在一个常驻的 AssetBundle 里；低频使用或者只在特定场景使用的资源（比如某个关卡的专属贴图）单独打包，用完就卸载。

4.4 资源更新与版本管理

Resource 模块还提供了资源更新的能力。通过UpdateResource接口，可以检查并下载远端的最新资源。这个功能在需要热更新的项目中非常关键。

资源更新的流程大致是这样的：首先通过GetResourceVersion获取本地资源版本号，然后与远端版本号进行比对。如果远端版本更新，则通过UpdateResource下载差异部分的资源清单和资源文件。下载完成后，新的资源清单会被保存到本地，后续加载资源时会优先使用新版本的资源。

// 检查资源版本更新 resourceComponent.GetResourceVersion((version) => { Debug.Log($"本地资源版本: {version}"); // 与远端版本比对，决定是否需要更新 }); // 更新资源 resourceComponent.UpdateResource( resourceUpdateType: ResourceUpdateType.Update, callback: (result) => { if (result == ResourceUpdateResult.UpdateSuccess) { Debug.Log("资源更新完成"); } } );

注意：资源更新涉及网络请求和文件写入，在移动端设备上需要特别注意权限问题和存储空间限制。建议在更新前先检查可用存储空间，并在更新过程中提供明确的进度提示。

5. 常见问题与排查技巧实录

5.1 资源加载失败排查表

这张表里的每一行都是我或者身边同事实际踩过的坑。特别是第一行“编辑器正常，打包后加载失败”，这个问题困扰过无数开发者。根本原因通常是编辑器模式下用的是Resources.Load或者AssetDatabase接口，而打包后用的是 AssetBundle 接口，两者的路径规则和资源组织方式完全不同。解决办法就是在开发阶段就定期用 AssetBundle 模式进行测试，不要等到打包前才第一次切换。

5.2 引用计数泄漏的排查方法

引用计数泄漏是最难排查的问题之一，因为它的表现往往不是立即崩溃，而是内存缓慢增长，直到某个临界点才突然爆发。我在实际项目中总结了一套排查流程，分享给大家。

第一步，开启 ResourceManager 的引用计数日志。在 ResourceComponent 的 Inspector 面板上勾选EnableReferenceCountLog，这样每次引用计数变化都会输出日志。日志格式通常是“资源路径: 旧计数 -> 新计数”。

第二步，在游戏运行一段时间后，导出当前的引用计数快照。快照包含了所有已加载资源的路径和当前引用计数。正常情况下，场景中正在使用的资源引用计数应该大于零，已经不再使用的资源引用计数应该等于零或者已经不在快照中。

第三步，对比不同时间点的快照，找出引用计数只增不减的资源。这些资源就是泄漏的嫌疑对象。然后根据资源路径回溯代码，找到对应的加载调用，检查是否有配对的卸载调用。

第四步，如果代码逻辑上看起来没问题，那就要考虑是否是异常路径导致的泄漏。比如加载成功回调中抛出了异常，导致后续的卸载逻辑没有执行。这种情况下需要在回调中加入 try-catch 保护，确保即使业务逻辑出错，资源也能被正确释放。

提示：在开发阶段，可以定期调用resourceComponent.ForceUnloadUnusedAssets()来强制清理引用计数为零的资源。这个接口会遍历所有已加载资源，释放那些不再被引用的资源。但要注意，这个操作可能会造成短暂的卡顿，不建议在游戏运行过程中频繁调用。

5.3 异步加载的时序问题

异步加载带来的一个常见问题是时序不确定性。你无法预知加载回调什么时候执行，这可能导致一些微妙的 bug。比如你在加载回调中访问了某个已经被销毁的游戏对象，或者在回调执行前就切换了场景。

处理这类问题的基本原则是：在异步回调中访问任何外部对象之前，先检查它是否还有效。对于 Unity 对象，可以用== null来判断，但要注意 Unity 重写了==运算符，被销毁的对象和真正的 null 都会返回 true。对于非 Unity 对象，则需要自己维护生命周期标志。

另一个技巧是使用加载任务的取消机制。Resource 模块的加载任务支持取消操作，当你不再需要某个资源时，可以调用task.Cancel()来取消加载。取消后的任务不会触发成功或失败回调，这样可以避免在场景切换后收到已经无意义的加载回调。

// 保存加载任务引用，以便后续取消 private LoadAssetTask currentTask; private void LoadSomething() { currentTask = resourceComponent.LoadAssetAsync(...); currentTask.OnLoadAssetSuccess += OnLoadSuccess; } private void OnDestroy() { // 对象销毁时取消未完成的加载任务 if (currentTask != null && !currentTask.IsDone) { currentTask.Cancel(); currentTask = null; } }

5.4 性能优化的几个实操心得

关于 Resource 模块的性能优化，我有几个经过实际项目验证的心得。

预加载时机的选择。不要在游戏启动时一次性预加载所有资源，那样会导致启动时间过长。更好的做法是分阶段预加载：登录界面加载登录相关资源，进入主城时加载主城资源，打开某个功能界面时提前加载该界面的资源。Resource 模块的优先级参数可以帮助你控制预加载的顺序。

合理设置同时加载数量。前面提到过LoadResourceAgentHelperCount参数，这个值不是越大越好。在移动设备上，同时进行太多的 IO 操作反而会拖慢整体加载速度，因为磁盘的读取带宽是有限的。我通常会在性能测试阶段尝试不同的数值，找到加载耗时和帧率表现的最佳平衡点。

利用对象池减少实例化开销。对于频繁创建和销毁的对象，比如子弹、特效、飘字，一定要通过对象池来管理。Resource 模块的Instantiate接口已经内置了对象池支持，你只需要确保使用这个接口而不是直接调用Object.Instantiate。

注意资源卸载的时机。不要在每帧都调用卸载接口，那样会造成不必要的性能开销。更好的做法是在场景切换、界面关闭等明确的时机批量卸载不再需要的资源。Resource 模块提供了UnloadUnusedAssets接口，可以一次性清理所有引用计数为零的资源。

6. 资源模块的扩展与定制

6.1 自定义 ResourceLoader 的实现

虽然框架自带了多种 ResourceLoader，但在某些特殊场景下，你可能需要实现自己的加载器。比如你需要从加密的 AssetBundle 中加载资源，或者需要从自定义的压缩包中读取资源。

实现自定义 ResourceLoader 的步骤并不复杂。首先创建一个类实现ResourceLoader抽象类，然后重写LoadAsset、LoadAllAssets、UnloadAsset等核心方法。在LoadAsset方法中，你需要完成实际的资源读取操作，并通过回调通知 ResourceManager 加载结果。

public class CustomResourceLoader : ResourceLoader { public override void LoadAsset(string assetName, Type assetType, int priority, LoadResourceAgentHelper.LoadResourceAgentHelperLoadCompleteCallback callback) { // 自定义加载逻辑 // 比如从加密文件中解密并读取资源 byte[] data = DecryptResource(assetName); AssetBundle bundle = AssetBundle.LoadFromMemory(data); object asset = bundle.LoadAsset(assetName, assetType); // 通知加载完成 callback(assetName, asset, null); } public override void UnloadAsset(object asset) { // 自定义卸载逻辑 // 比如释放解密后的内存数据 base.UnloadAsset(asset); } }

实现完成后，需要在 ResourceComponent 初始化时注册这个自定义 Loader。注册方式通常是通过ResourceManager的AddResourceLoader接口，或者通过修改 ResourceComponent 的配置来指定默认的 Loader 类型。

6.2 资源加载的监控与统计

在大型项目中，对资源加载进行监控和统计是非常有必要的。Resource 模块提供了一些内置的统计接口，可以获取当前已加载资源数量、总内存占用、加载任务队列长度等信息。

// 获取资源统计信息 int loadedAssetCount = resourceComponent.ResourceManager.GetLoadedAssetCount(); int loadingTaskCount = resourceComponent.ResourceManager.GetLoadingTaskCount(); long totalMemorySize = resourceComponent.ResourceManager.GetTotalMemorySize();

这些数据可以接入到项目的性能监控面板中，实时显示资源加载状态。在性能测试阶段，这些数据能帮你快速定位资源相关的性能瓶颈。比如如果发现加载任务队列长期处于满载状态，说明同时加载的资源太多，需要降低加载频率或者提高同时加载数量上限。

我在实际项目中还会定期记录资源加载的耗时分布，统计哪些资源的加载时间最长。这些数据对于优化 AssetBundle 打包策略非常有价值。如果一个资源的加载时间异常长，可能是因为它的 AssetBundle 打包得太大了，需要拆分成更小的包；也可能是因为它的依赖链太深，需要重新组织依赖关系。

6.3 与热更新流程的配合

Resource 模块的资源更新能力通常需要和项目的热更新流程配合使用。一个典型的热更新流程是这样的：游戏启动时先检查版本号，如果有新版本则下载更新资源，更新完成后重新加载资源清单，然后进入游戏。

在这个过程中，Resource 模块负责的是资源层面的更新，而代码层面的更新通常由另一个模块负责。两者需要协调工作，确保代码和资源的版本匹配。如果代码更新了但资源没有更新，或者反过来，都可能导致运行时错误。

注意：资源更新过程中如果发生网络中断或者应用被杀，可能会导致资源文件损坏。建议在更新前先备份关键文件，或者在更新完成后进行完整性校验。Resource 模块提供了资源校验接口，可以检查本地资源是否与清单一致。

7. 一些踩坑之后的个人体会

Resource 模块我用了挺长时间，从最初的一知半解到后来逐渐摸清它的脾气，中间踩过的坑确实不少。最大的体会是：资源管理没有银弹，任何框架都只是工具，关键还是在于使用它的人是否理解背后的原理。

引用计数这个机制，用好了是利器，用不好就是灾难。我见过有团队为了省事，在加载资源后从来不调用卸载接口，结果游戏运行半小时后内存直接爆掉。也见过有团队过度卸载，每次界面关闭都把资源卸得干干净净，结果下次打开界面又要重新加载，玩家体验极差。正确的做法是根据资源的实际使用频率和生命周期来制定卸载策略，高频资源常驻内存，低频资源用完即卸。

另一个深刻的体会是关于 AssetBundle 的打包策略。这个东西真的是需要根据项目实际情况反复调整的。教科书上说的“按功能模块打包”“按资源类型打包”都只是原则，具体怎么分、分多细，需要结合项目的资源规模、更新频率、目标平台的 IO 特性来综合考虑。我的建议是在项目早期就建立一套打包规范，并且在开发过程中持续监控打包结果，发现不合理的地方及时调整。

最后想说的是，Resource 模块的源码值得花时间读一读。它的代码结构清晰，注释也比较完善，读源码能帮你理解很多接口设计背后的考量。比如为什么LoadAsset和Instantiate要分开，为什么异步加载要有优先级参数，为什么卸载要基于引用计数而不是手动控制。理解了这些设计决策，你在使用的时候就能更加得心应手，遇到问题也能更快地定位原因。