微信小游戏资源管理：YooAsset的Tag与Group策略实战

1. 微信小游戏资源管理的核心矛盾与YooAsset的切入逻辑

微信小游戏这个平台，做过的都懂，它跟传统的App或者端游完全是两个世界。首包体积被卡得死死的，微信官方对主包有硬性上限，超过这个线连审核都过不了。但玩家又不傻，你游戏内容少了他们扭头就走。这个矛盾从第一天做小游戏就摆在面前，绕不过去。

我最早做小游戏那会儿，用的是Unity自带的Resources文件夹，简单粗暴，扔进去就能加载。但很快问题就来了：Resources目录下的所有资源会被无条件打进安装包，不管玩家用不用得到。一个活动界面用的限定皮肤，可能90%的玩家根本不会点进去，但它就躺在首包里占着空间。后来换Addressable，功能是强了，但那个学习曲线和配置复杂度，在小游戏这种快速迭代的场景下显得有点笨重。直到用上YooAsset，才算找到了一个平衡点。

YooAsset是一个开源的Unity资源管理框架，它的核心思路是把资源的“描述信息”和“实际数据”分开。描述信息就是告诉引擎“这个资源叫什么、在哪、依赖谁”，这部分很小，可以放在首包里；实际数据就是贴图、模型、音频这些大块头，放在CDN上按需下载。微信小游戏天然支持这种模式，因为它的运行环境本身就是一个WebView，网络请求是它的强项。

但光有框架还不够，真正决定资源管理效率的，是你怎么给资源打Tag和分Group。这两个概念听起来简单，但用好了和用砸了，差距可能是首包体积差几MB、更新时玩家多等十几秒、甚至热更后资源错乱导致闪退。我见过太多项目，Tag和Group随手一打，前期跑得挺欢，到了中期资源量上来之后，加载慢、内存高、更新包巨大，回头重构的成本高得吓人。

这篇文章就是把我自己在几个上线项目中踩过的坑、试过的方案、最后沉淀下来的策略，完整地讲一遍。不管你是刚接触YooAsset的新手，还是已经在用但觉得资源管理有点乱的老手，应该都能找到能直接抄作业的东西。

1.1 为什么Tag和Group是YooAsset最核心的两个配置

YooAsset的资源配置面板里，每个资源条目都有两个关键字段：Tag和Group。很多人第一次看到这两个字段，觉得Tag就是分类标签，Group就是打包分组，随便填填就完事了。但实际上，这两个字段直接决定了三件事：资源打在哪个包里、什么时候被加载、什么时候被卸载。

Tag在YooAsset里的作用，是给资源打上一个逻辑标记。这个标记不参与打包，但可以在运行时通过Tag来批量加载或卸载资源。比如你给所有“战斗场景”相关的资源打上“Battle”标签，进入战斗时一句代码就能把整个标签下的资源全部加载进来，退出战斗时再一句代码全部释放。这个机制在微信小游戏里特别有用，因为小游戏的内存管理比原生平台更敏感，WebView的内存回收机制跟原生不一样，手动控制资源的生命周期几乎是必须的。

Group则是物理层面的打包单位。同一个Group下的资源会被打进同一个AssetBundle文件。这意味着Group的划分直接决定了：首包要带哪些Bundle、CDN上要放哪些Bundle、更新时哪些Bundle需要重新下载。Group划得太细，Bundle数量爆炸，加载时的IO次数和网络请求数都会飙升；Group划得太粗，一个Bundle里塞了几百个资源，更新时改一个小图也要重新下载整个大包，流量浪费严重。

我个人的经验是：Tag管逻辑，Group管物理。Tag从玩法角度出发，Group从打包和更新角度出发。两者配合好了，资源管理就顺了。

1.2 微信小游戏场景下的特殊约束

在讲具体策略之前，得先把微信小游戏这个平台的几个硬约束说清楚，因为后面的所有决策都要围绕这些约束来做。

第一个约束是首包体积。微信小游戏主包有明确的大小限制，超过就传不上去。这意味着首包里只能放最核心的资源：登录界面、主城场景、基础UI、必要的Shader和配置表。其他所有东西，包括第二个场景、活动界面、高级角色模型，统统要放到CDN上。

第二个约束是网络环境。小游戏的玩家可能在4G、5G、WiFi各种网络下切换，下载大文件时如果断网或者切后台，下载会中断。YooAsset支持断点续传，但前提是你的Bundle划分要合理，不能一个Bundle几百MB，那样断点续传的体验也很差。

第三个约束是内存。微信小游戏的WebView内存上限比原生App低不少，而且不同机型差异很大。低端机上可能只有几百MB可用，资源加载多了直接闪退。所以Tag的卸载策略必须精确，不能出现“加载了但忘了卸载”的情况。

第四个约束是审核。微信小游戏的审核对资源加载有要求，不能出现长时间黑屏或者卡加载。这意味着首包资源要尽可能小，让玩家快速进入游戏，后续资源在后台静默下载。

这四个约束叠加在一起，就决定了YooAsset的Tag和Group策略不能拍脑袋决定，必须有一套系统的方法论。

2. Tag策略：从玩法维度切分资源生命周期

Tag这个东西，表面上看就是个字符串标记，但它的设计直接反映了你对游戏资源生命周期的理解。我见过最离谱的Tag设计是每个资源一个Tag，等于没打；也见过所有资源一个Tag，卸载时全卸了，切个界面都要重新加载。这两种都是极端，实际项目中需要找到一个平衡点。

2.1 Tag的粒度：按场景还是按系统

Tag的粒度选择，本质上是在问一个问题：你希望以多大的单位来加载和卸载资源？

按场景打Tag是最直观的做法。比如“MainCity”标签对应主城所有资源，“Battle”标签对应战斗场景所有资源，“Activity”标签对应活动界面资源。这种打法的好处是逻辑清晰，进入一个场景就加载对应Tag，退出就卸载。缺点是粒度太粗，如果主城里有几十个NPC，每个NPC都有独立的模型和贴图，全部打上“MainCity”标签，那进入主城时就要一次性加载所有NPC资源，内存峰值很高。

按系统打Tag则更细一些。比如“UIMain”对应主界面UI，“UIShop”对应商店界面，“UIBag”对应背包界面。这种打法适合UI系统，因为UI界面通常是独立打开的，打开时加载，关闭时卸载，生命周期很明确。但如果是场景内的物件，按系统打Tag就不太合适，因为场景内的物件往往是同时可见的。

我实际项目中的做法是混合策略：场景级Tag + 系统级Tag + 特殊Tag。场景级Tag用于大块资源的加载和卸载，比如进入战斗时加载“Battle”标签下的所有资源。系统级Tag用于UI界面的精细控制，比如打开商店时只加载“UIShop”标签。特殊Tag用于一些跨场景的常驻资源，比如“Persistent”标签下的资源永远不卸载，包括音频管理器、网络管理器、全局配置等。

这里有个关键点：一个资源可以同时属于多个Tag。YooAsset支持给一个资源打多个Tag，这给了很大的灵活性。比如一个角色模型，既属于“Battle”标签（战斗时加载），又属于“Character”标签（角色图鉴界面也要用）。加载时按“Battle”加载，卸载时如果角色图鉴还开着，就不能按“Battle”卸载，需要检查“Character”标签是否还在使用。

2.2 Tag的命名规范与维护

Tag的命名看起来是小事，但项目一大，命名混乱的代价就出来了。我建议采用“前缀_模块_用途”的三段式命名，比如“Scene_Battle_All”、“UI_Shop_Main”、“Char_Hero_001”。前缀区分大类，模块区分具体功能，用途区分加载策略。

为什么要这么细？因为当你有上百个Tag的时候，在YooAsset的配置面板里找起来会非常痛苦。有了规范的前缀，可以快速筛选。而且代码里写Tag的时候，也容易看出这个Tag是干什么的。

另外，Tag的维护要有文档。我见过项目做到一半，原来的主程走了，新来的人看到一堆Tag完全不知道哪个是哪个，只能猜。猜错了就是资源泄漏或者加载失败。所以从项目第一天起，就应该有一个Tag清单，记录每个Tag的含义、包含哪些资源、什么时候加载、什么时候卸载。这个文档不需要多正式，一个共享表格就行，但必须有。

还有一个容易忽略的点：Tag的废弃处理。项目迭代过程中，有些Tag会不再使用。这时候不能直接删掉，因为可能还有旧版本的资源引用了这个Tag。正确的做法是先标记为废弃，等确认所有旧版本都不再使用后，再在下一个大版本中移除。

2.3 Tag与资源加载卸载的代码实践

YooAsset的Tag在代码里的使用其实很简单，但简单的东西往往容易被用错。先看加载：

// 按Tag加载所有资源 var handle = YooAssets.LoadAssetsAsync<UnityEngine.Object>("Battle"); yield return handle; // 使用handle.AssetObjects获取所有加载的资源

这段代码看起来没问题，但实际项目中我踩过一个坑：LoadAssetsAsync是按Tag加载所有资源，但如果这个Tag下的资源有依赖关系，YooAsset会自动处理依赖。问题是，如果依赖的资源在另一个Tag下，那个Tag的资源也会被加载进来，但不会被记录在当前Tag的引用计数里。卸载时如果只卸载当前Tag，依赖资源可能被误卸载。

解决方法是：加载时用LoadAssetsAsync，卸载时用对应的Release。YooAsset内部有引用计数机制，只要加载和释放成对出现，就不会出问题。但前提是你要确保每个加载操作都有对应的释放操作。我建议在代码层面做一个封装，用一个ResourceManager来统一管理加载和释放，避免在业务代码里直接调用YooAsset的API。

public class ResourceManager { private Dictionary<string, AssetHandle> _handles = new Dictionary<string, AssetHandle>(); public AssetHandle LoadTag(string tag) { if (_handles.TryGetValue(tag, out var existing)) { return existing; } var handle = YooAssets.LoadAssetsAsync<UnityEngine.Object>(tag); _handles[tag] = handle; return handle; } public void ReleaseTag(string tag) { if (_handles.TryGetValue(tag, out var handle)) { handle.Release(); _handles.Remove(tag); } } }

这个封装的好处是，同一个Tag不会被重复加载，释放时也只会释放一次。但要注意，如果两个系统同时使用同一个Tag，这个简单的封装就不够了，需要引入引用计数。实际项目中，我建议Tag的加载和释放都走一个统一的入口，并且记录引用计数，这样才能避免多系统共用Tag时的冲突。

3. Group策略：打包粒度与更新效率的平衡术

如果说Tag决定了资源什么时候加载，那Group就决定了资源怎么打包、怎么更新。Group的划分是YooAsset资源管理里最需要经验的部分，因为它直接影响到首包体积、CDN流量、更新速度和运行时IO。

3.1 Group划分的四个核心原则

我总结下来，Group划分要遵循四个原则：高频更新独立、大文件独立、首包资源独立、依赖关系内聚。

高频更新独立，意思是那些经常改动的资源要单独放一个Group。比如UI贴图、活动配置、数值表，这些可能每周甚至每天都要更新。如果跟不常改的资源混在一个Group里，每次更新都要重新下载整个大Bundle，流量浪费严重。我一般会建一个“Hotfix”Group，专门放这些高频更新的资源。

大文件独立，意思是单个文件超过一定大小的资源要单独放一个Group。比如一个高清角色模型、一段CG视频、一张大地图。这些文件如果跟其他资源混在一起，加载时会把整个Bundle都读进内存，造成不必要的内存占用。而且大文件独立成Group后，可以单独做预下载，不影响其他资源的加载。

首包资源独立，意思是首包必须包含的资源要单独放一个Group，并且这个Group要尽可能小。首包资源包括：启动Logo、登录界面、基础UI图集、必要的Shader、配置表。这些资源要精确控制，不能多放一个字节。我见过项目把新手引导的资源也放进首包，结果首包超了，又回头删资源，浪费了很多时间。

依赖关系内聚，意思是相互依赖的资源尽量放在同一个Group里。比如一个角色模型依赖它的贴图和材质，如果模型和贴图分在两个Group，加载模型时还要额外加载贴图所在的Bundle，增加了IO次数。放在同一个Group里，一次加载就全拿到了。但这里有个矛盾：如果贴图是高频更新的，模型不常更新，那放在一起就会导致模型也跟着重新下载。所以需要在依赖内聚和更新效率之间做权衡。

3.2 首包Group的精细控制

首包Group是微信小游戏资源管理的重中之重，因为首包体积直接决定能不能过审。我一般会把首包Group再细分成几个子Group：Boot、Login、BaseUI、Shader、Config。

Boot Group放启动必须的资源，比如Logo、加载动画、启动场景。这些资源在游戏启动的第一时间就要用，必须放在首包。Login Group放登录界面的资源，包括登录背景、按钮、输入框。BaseUI Group放通用UI资源，比如字体、通用按钮、弹窗底板。Shader Group放所有用到的Shader变体，这个很容易被忽略，但Shader变体在微信小游戏里是必须预加载的，否则运行时会编译卡顿。Config Group放配置表，比如关卡配置、道具配置、数值表。

这几个子Group加起来，我一般控制在首包限制的70%左右，留30%的余量给后续可能的调整。因为微信小游戏的审核标准可能会变，留点余量心里踏实。

首包Group里的资源要定期审查。我每个月会跑一次分析，看看首包Group里有没有可以移到CDN的资源。经常发现一些资源是早期开发时放进去的，后来功能改了，资源已经不用了，但没人清理。这种“僵尸资源”在首包里占着空间，非常浪费。

3.3 CDN Group的更新策略设计

CDN上的Group，核心考虑的是更新效率。YooAsset的更新机制是比较Bundle的Hash值，Hash变了就重新下载。所以Group划分要尽量减少不必要的Hash变化。

一个常见的坑是：把经常变的资源和不常变的资源放在同一个Group。比如把UI贴图和场景模型放在一起，UI贴图每周更新，场景模型半年不动。结果每次UI更新，场景模型所在的Bundle也要重新下载，因为整个Bundle的Hash变了。玩家更新时下载了几十MB，其实只有几百KB是真正需要的。

解决方法是按更新频率分Group。我一般分三类：高频更新（Hotfix）、中频更新（Season）、低频更新（Base）。高频更新放活动资源、UI贴图、数值表；中频更新放赛季内容、新角色；低频更新放基础场景、通用模型。这样更新时只下载对应频率的Group，流量最省。

还有一个技巧是：把同一时间上线的资源放在同一个Group。比如一个活动上线，活动界面、活动角色、活动特效，这些资源同时上线也同时下线，放在一个Group里，更新时一起下载，下线时一起删除，管理起来很方便。

3.4 Group与Bundle的压缩格式选择

YooAsset支持多种Bundle压缩格式，包括LZMA、LZ4、Uncompressed。这个选择在微信小游戏里特别重要，因为不同格式对加载速度和包体大小的影响很大。

LZMA压缩率最高，包体最小，但解压速度慢，加载时CPU占用高。LZ4压缩率中等，解压速度快，是大多数情况下的推荐选择。Uncompressed不压缩，加载最快，但包体最大，只适合那些已经压缩过的资源，比如音频和视频。

我的经验是：首包Group用LZ4，因为首包要快速加载，不能卡。CDN上的大文件用LZMA，因为下载时间比解压时间更敏感，包体小一点，下载快一点。音频和视频用Uncompressed，因为它们本身已经压缩过了，再压缩效果不大，反而浪费解压时间。

这里有个细节：微信小游戏在下载Bundle时，如果Bundle是LZMA压缩的，下载后需要解压到内存再加载。这个过程在低端机上可能造成明显卡顿。所以对于需要在加载后立即使用的资源，比如战斗场景的模型，我建议用LZ4。对于可以预下载、后台加载的资源，比如下一个场景的资源，可以用LZMA。

4. Tag与Group的协同：实战中的组合策略

Tag和Group单独用好已经不容易，但真正的难点在于两者的协同。Tag决定加载时机，Group决定打包方式，两者配合不好就会出现“加载了不该加载的”或者“更新了不该更新的”问题。

4.1 典型场景的资源编排方案

拿一个典型的微信小游戏来说，我一般会这样编排：

主城场景。Tag打“Scene_MainCity”，Group放在“Base”里，因为主城是基础场景，不常更新。主城里的NPC，Tag打“Scene_MainCity”和“NPC_MainCity”，Group放在“Base”里。主城的UI，Tag打“UI_MainCity”，Group放在“Hotfix”里，因为UI经常调整。

战斗场景。Tag打“Scene_Battle”，Group放在“Base”里。战斗角色，Tag打“Scene_Battle”和“Char_Battle”，Group放在“Season”里，因为角色可能随赛季更新。战斗特效，Tag打“Scene_Battle”和“FX_Battle”，Group放在“Hotfix”里，因为特效经常优化。

活动界面。Tag打“UI_Activity”，Group放在“Hotfix”里。活动角色，Tag打“UI_Activity”和“Char_Activity”，Group放在“Hotfix”里。活动特效，Tag打“UI_Activity”和“FX_Activity”，Group放在“Hotfix”里。

这样编排的好处是：进入主城时，加载“Scene_MainCity”标签，会把主城场景和NPC都加载进来，但不会加载战斗和活动的资源。打开活动界面时，加载“UI_Activity”标签，会把活动相关资源都加载进来。更新时，只更新“Hotfix”和“Season”的Group，“Base”不动。

4.2 资源加载的优先级与预下载

微信小游戏里，资源加载不能等到用的时候才加载，那样玩家会看到明显的卡顿。所以需要预下载。预下载的策略跟Tag和Group都有关。

我的做法是：在进入一个场景之前，先根据Tag确定需要哪些资源，然后根据Group确定这些资源在哪些Bundle里，最后按优先级预下载。优先级排序是：首包Group > 当前场景Group > 下一个可能场景Group > 其他。

比如玩家在主城，准备进入战斗。主城加载完后，后台开始预下载“Scene_Battle”标签下的资源。预下载时按Group优先级：先下载“Base”里的战斗场景，再下载“Season”里的战斗角色，最后下载“Hotfix”里的战斗特效。这样玩家点“开始战斗”时，大部分资源已经下载好了，只需要加载内存即可。

预下载的并发数也要控制。微信小游戏同时发太多网络请求会被限制，我一般控制在3-5个并发。YooAsset支持设置并发数，在InitializeParameters里配置。

4.3 资源卸载的时机与顺序

卸载比加载更容易出问题。加载多了最多是内存高，卸载错了直接闪退。YooAsset的卸载是按引用计数来的，但前提是你的加载和释放成对。

我的经验是：场景切换时，先加载新场景资源，再卸载旧场景资源。不要反过来，否则会出现旧场景卸载了、新场景还没加载好，中间有一段黑屏。具体操作是：新场景加载完成后，调用旧场景Tag的Release，然后等一帧，让YooAsset完成实际的卸载。

UI界面的卸载要更精细。因为UI界面可能叠加，比如主界面上面弹了个商店，商店上面又弹了个确认框。这时候不能关闭商店就把商店资源卸了，因为确认框可能还引用了商店的图集。我的做法是：UI界面关闭时不立即卸载，而是标记为“待卸载”，等所有UI都关闭后，统一卸载所有“待卸载”的Tag。

还有一个坑是：有些资源被多个Tag引用，卸载一个Tag时不能直接释放资源，要等所有引用它的Tag都释放了才能释放。YooAsset内部有引用计数，但如果你手动调用了Release，引用计数减到0就会释放。所以千万不要在业务代码里直接调Release，一定要通过ResourceManager统一管理。

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

做微信小游戏资源管理这几年，遇到的问题五花八门，但总结下来，高频问题就那么几类。这一章我把这些问题和排查方法整理出来，希望能帮你少走弯路。

5.1 资源加载失败与依赖缺失

资源加载失败是最常见的问题，表现是加载时报错“Asset not found”或者“Bundle load failed”。原因通常有三种：资源没打进Bundle、Bundle没下载、依赖缺失。

排查步骤是这样的：首先确认资源是否在YooAsset的配置里，并且Tag和Group都填了。然后确认资源所在的Group是否在首包或者已经下载。最后确认资源的依赖是否完整，特别是Shader和材质，这些容易被忽略。

我遇到过一个典型案例：一个角色模型加载失败，报错说依赖的Shader找不到。查了半天发现，Shader被打进了另一个Group，那个Group没有下载。原因是Shader的Tag和模型的Tag不一样，预下载时只下载了模型的Tag，没下载Shader的Tag。解决方法是把Shader的Tag加到模型的Tag列表里，或者把Shader和模型放在同一个Group。

注意：YooAsset的依赖收集是在打包时进行的，如果打包后修改了资源的依赖关系，需要重新打包。不要手动修改Bundle文件，那样会导致Hash不一致。

5.2 内存泄漏与资源未释放

内存泄漏在小游戏里是致命的，因为WebView的内存上限低，泄漏几次就闪退了。表现是游戏运行一段时间后，内存持续上涨，最终崩溃。

排查内存泄漏，我一般用Unity Profiler的Memory模块，看哪些资源在卸载后还留在内存里。重点看Texture、Mesh、AudioClip这几类。如果发现某个资源卸载后还在，说明它的引用计数没归零。

常见原因是加载和释放不成对。比如在A界面加载了资源，在B界面释放了，但A界面关闭时没有释放。或者加载时用了LoadAssetsAsync，释放时用了Release，但LoadAssetsAsync返回的handle没有被正确保存。

我的建议是：所有资源的加载和释放都走ResourceManager，ResourceManager内部维护一个字典，记录每个Tag的加载状态和引用计数。释放时检查引用计数，只有归零才真正释放。另外，在场景切换和界面关闭时，强制清理一次ResourceManager，确保没有遗漏。

5.3 更新后资源错乱与版本不一致

更新后资源错乱，表现是更新后游戏显示异常，比如贴图变白、模型错位、UI错版。原因通常是Bundle版本不一致，或者更新时只更新了部分Bundle。

YooAsset的更新机制是比较本地Bundle和CDN Bundle的Hash，Hash不一致就下载新的。但如果更新过程中断，可能出现本地Bundle和CDN Bundle版本不一致的情况。解决方法是：更新完成后，校验所有Bundle的Hash，确保一致。YooAsset提供了VerifyBundle方法，可以在更新后调用。

还有一个坑是：如果CDN上的Bundle被替换了，但版本号没变，YooAsset不会重新下载。所以每次更新Bundle，都要确保版本号或者Hash变了。我一般用文件内容的MD5作为Hash，这样只要文件变了，Hash就会变。

5.4 常见问题速查表

5.5 独家避坑技巧

第一个技巧：在开发阶段，给每个Group加一个“Debug”后缀，打包时生成详细的Bundle报告，包括每个Bundle的大小、包含的资源、依赖关系。这样排查问题时一目了然。上线时去掉后缀，用正式配置。

第二个技巧：用YooAsset的“模拟模式”在编辑器里测试资源加载，不需要真的打包和下载。模拟模式可以模拟加载延迟和失败，方便测试异常处理逻辑。

第三个技巧：定期跑一次“资源审计”，检查所有Tag和Group的使用情况。找出没有被任何Tag引用的资源、没有被任何Group包含的资源、以及Tag和Group不匹配的资源。这个审计脚本我一般用Python写，解析YooAsset的配置文件和资源目录，输出报告。

第四个技巧：在微信小游戏里，利用微信的“分包加载”机制配合YooAsset。微信小游戏支持把游戏分成多个分包，每个分包有独立的大小限制。可以把YooAsset的Bundle放在微信分包里，这样可以利用微信的分包下载能力，比纯CDN下载更稳定。

第五个技巧：对于特别大的资源，比如CG视频，不要放在YooAsset的Bundle里，直接放在CDN上用URL加载。YooAsset管理Bundle有开销，大文件直接走URL更高效。加载完后用Unity的VideoPlayer播放，播放完释放。

6. 从项目实战中沉淀的配置模板

说了这么多理论，最后给一套可以直接抄的配置模板。这套模板是我在多个项目中迭代出来的，不一定适合所有项目，但可以作为起点，根据实际情况调整。

6.1 Tag配置模板

场景类： Scene_Boot 启动场景 Scene_Login 登录场景 Scene_MainCity 主城场景 Scene_Battle 战斗场景 UI类： UI_Login 登录界面 UI_MainCity 主城界面 UI_Battle 战斗界面 UI_Shop 商店界面 UI_Bag 背包界面 UI_Activity 活动界面 角色类： Char_Hero 英雄角色 Char_NPC NPC角色 Char_Monster 怪物角色 特效类： FX_Battle 战斗特效 FX_UI UI特效 FX_Environment 环境特效 常驻类： Persistent 常驻资源，永不卸载

6.2 Group配置模板

首包Group： Boot 启动资源 Login 登录资源 BaseUI 基础UI资源 Shader 所有Shader变体 Config 配置表 CDN Group： Base_Scene 基础场景资源（低频更新） Base_Char 基础角色资源（低频更新） Season_Char 赛季角色资源（中频更新） Season_Scene 赛季场景资源（中频更新） Hotfix_UI 高频更新UI资源 Hotfix_FX 高频更新特效资源 Hotfix_Config 高频更新配置

6.3 加载策略模板

// 进入主城 ResourceManager.LoadTag("Scene_MainCity"); ResourceManager.LoadTag("UI_MainCity"); ResourceManager.LoadTag("Persistent"); // 进入战斗 ResourceManager.LoadTag("Scene_Battle"); ResourceManager.LoadTag("UI_Battle"); ResourceManager.LoadTag("Char_Battle"); ResourceManager.LoadTag("FX_Battle"); // 战斗结束后 ResourceManager.ReleaseTag("Scene_Battle"); ResourceManager.ReleaseTag("UI_Battle"); ResourceManager.ReleaseTag("Char_Battle"); ResourceManager.ReleaseTag("FX_Battle"); // 打开商店 ResourceManager.LoadTag("UI_Shop"); // 关闭商店 ResourceManager.ReleaseTag("UI_Shop");

这套模板的核心思想是：Tag按玩法维度划分，Group按更新频率和打包需求划分。加载时按Tag批量加载，卸载时按Tag批量卸载。Group的划分确保首包最小、更新最省流量。

实际项目中，我会根据具体游戏的玩法特点调整Tag和Group。比如如果是卡牌游戏，角色数量多，我会把角色按稀有度分Group，SSR角色一个Group，SR角色一个Group，R角色一个Group。这样更新时只更新对应稀有度的Group。如果是MMO，地图大，我会把地图按区域分Group，每个区域一个Group，进入区域时只加载对应Group。

资源管理没有银弹，只有适合当前项目的方案。但只要你理解了Tag和Group的本质——Tag管逻辑生命周期，Group管物理打包更新——剩下的就是根据项目特点做调整。多试几次，多踩几个坑，自然就有感觉了。