1. 项目概述为什么你的Unity包体总是“虚胖”做Unity开发尤其是面向移动端或者WebGL平台最头疼的事情之一就是包体大小。辛辛苦苦优化了代码压缩了贴图结果一打包几百兆甚至上G的安装包用户下载的意愿瞬间就没了。更让人抓狂的是你明明记得删掉了一些不用的资源但打包出来的AssetBundle大小纹丝不动甚至有时候还会变大。这种“资源冗余”问题就像房间里堆满了你以为已经扔掉的旧东西不仅占地方还让你找起真正需要的东西来特别费劲。Addressables系统作为Unity官方推荐的资源管理方案本意是解决资源加载和热更新的难题但它本身并不是一个“自动瘦身工具”。很多团队在接入Addressables后会发现资源管理变得更清晰了但包体冗余问题反而被放大了。这是因为Addressables的打包逻辑是基于你标记的“地址”和分组策略如果你标记了资源但没使用或者资源之间存在复杂的依赖关系这些“死资源”就会悄无声息地被打进包里。Addressables AnalyzeRule就是Unity提供给你的一把“资源扫描仪”和“手术刀”。它不是新功能但却是很多项目优化流程中缺失的关键一环。很多开发者知道它存在但面对一堆分析规则和报告数据不知道从何下手或者踩了坑也不知道怎么解决。所以这篇内容不是简单的功能介绍而是一个从实战中总结出来的“避坑指南”。我会带你彻底搞懂AnalyzeRule的工作原理手把手教你配置核心的扫描规则并分享那些官方文档里不会写、但能让你少走弯路的实操经验。无论你是正在为包体超标而焦虑的主程还是刚开始接触Addressables的开发者都能从这里找到直接可用的解决方案。2. 核心思路拆解AnalyzeRule到底在分析什么在动刀之前得先明白手术的原理。Addressables AnalyzeRule不是一个魔法按钮按一下包体就小了。它是一套静态分析框架核心工作是在打包之前对你的项目资源、Addressables配置以及它们之间的引用关系进行一次全面的“体检”。2.1 分析的本质建立资源关系图谱想象一下你的项目资源是一个巨大的社交网络。每个Prefab、材质球、贴图、ScriptableObject都是一个“人”。他们之间通过引用Reference互相认识、建立关系。Addressables系统则像是一个社区管理员你把一些人资源分配到了不同的社团Addressables Group里。AnalyzeRule的工作就是绘制出这张庞大的关系网节点Node每一个可寻址的资源Asset都是一个节点。边Edge资源之间的引用关系就是边。例如一个Prefab引用了一个MaterialMaterial又引用了一张Texture这就形成了一条引用链。社团边界Group Boundary每个Addressables Group就是一个社团。分析规则会检查当一个社团需要被打包时它是否“邀请”了所有它依赖的、但不在本社团的朋友资源。分析的目标就是找出这张关系网里的“问题区域”孤立的节点被标记为可寻址但没有任何其他资源引用它即没有被使用。这是最直接的冗余。重复的节点同一个资源被多个不同的社团“邀请”并打包导致在多个AssetBundle里都存在副本。依赖关系混乱资源引用链穿过了多个社团导致打包策略复杂难以优化。2.2 内置规则详解六把标准手术刀Unity Addressables提供了一系列内置的AnalyzeRule每一把都针对一种特定的“病症”。理解它们你才能对症下药。#### 2.2.1 Check Duplicate Bundle Dependencies检查重复的Bundle依赖这是使用频率最高、效果最直接的规则。它检查不同资源组Group中是否存在完全相同的资源依赖项。它解决什么问题避免同一张贴图、同一个Shader等公共资源在多个AssetBundle中被重复打包。比如UI界面的按钮和角色选择界面都用了同一套按钮精灵图如果它们在不同的Group里这张图就会被包进两个Bundle浪费空间。输出是什么一个报告列出所有被多个Bundle依赖的共享资源并指出是哪些Bundle依赖了它。行动建议通常你会将这些被重复依赖的资源提取出来放到一个单独的、共享的Group如“SharedAssets”中并确保其他Group都依赖它。这样公共资源在最终包中只存在一份。#### 2.2.2 Check Resources to Addressable Duplicate Dependencies检查Resources与Addressables的重复依赖这是一个历史遗留问题的清理工具。很多老项目或从传统Resources方式迁移过来的项目会存在两套资源系统并存的局面。它解决什么问题防止同一个资源既通过Resources.Load加载又被Addressables系统管理。这会导致该资源被打包两次一次在Resources文件夹一次在某个Addressables Bundle里是严重的冗余。输出是什么列出所有同时存在于Resources目录和Addressables配置中的资源路径。行动建议这是必须处理的问题。你需要做出选择要么将该资源完全迁移到Addressables中并从Resources文件夹移除或重命名要么放弃用Addressables管理它。通常建议前者以实现资源管理的统一。#### 2.2.3 Check Scene to Addressable Duplicate Dependencies检查场景与Addressables的重复依赖场景文件.unity本身可能引用了一些资源而这些资源同时也被标记为Addressables。它解决什么问题和上一条类似避免场景内嵌的资源与Addressables管理的资源重复。当场景被打包例如打进主包或单独的Scene Bundle时它引用的资源会被一起打包。如果这些资源同时也在Addressables里就会重复。输出是什么列出场景文件及其引用的、同时也存在于Addressables中的资源。行动建议对于场景专属、且不需要动态加载的资源可以将其从Addressables中移除。对于需要共享的资源则需要仔细规划场景打包策略和Addressables分组可能要将场景和其依赖的共享资源分开打包。#### 2.2.4 Build Layout Report构建布局报告这个规则比较特殊它不是在打包前分析而是在打包之后进行分析。它解决什么问题给你一份最终的、详细的“打包结果清单”。它不直接给出优化建议而是展示事实最终生成的每个AssetBundle.bundle文件里具体包含了哪些资源每个资源有多大它们之间的依赖关系如何。输出是什么一个结构化的文本或HTML报告详细至极。你可以看到每个Bundle的构成是验证其他规则优化效果、进行深度手工优化的终极依据。行动建议在进行了其他优化操作后运行一次打包并生成此报告对比优化前后的Bundle组成和大小确认优化是否生效。你也可以用它来发现一些意想不到的大资源或者不合理的依赖捆绑。#### 2.2.5 Check Unused Addresses检查未使用的地址这个规则检查你是否标记了一些“僵尸”资源。它解决什么问题找出那些在Addressables窗口中配置了地址Address但在整个项目代码中通过Addressables.LoadAssetAsync等API没有任何地方真正使用这个地址去加载的资源。注意这个分析是基于静态字符串匹配。如果你的地址是运行时拼接的例如$“Character/{id}/Model”分析器可能无法识别从而产生误报。输出是什么列出所有未被检测到使用记录的地址。行动建议逐一审查列表。对于确认无用的地址直接移除。对于动态拼接的地址可以忽略此次告警但心里要有数。#### 2.2.6 Check for Invalid Addresses and Labels检查无效的地址和标签检查配置中的低级错误。它解决什么问题找出地址字符串为空、包含非法字符或者引用了不存在的资源路径的配置项。也检查标签Labels是否被正确引用。输出是什么列出所有有问题的地址和标签配置。行动建议立即修复。这些是配置错误会导致运行时加载失败。2.3 分析流程的定位CI/CD中的守门员理解AnalyzeRule的定位至关重要它是一个预检查工具而不是运行时工具。它的分析结果不会自动修改你的配置需要你人工审查并做出决策。因此最佳实践是将AnalyzeRule集成到你的持续集成CI流程中。每次提交代码、准备出包前自动运行一套配置好的分析规则。如果分析报告出现了新的问题比如新增了重复依赖CI流程可以标记失败或发出警告阻止有资源冗余问题的包被构建出来。这样资源健康度就成为了代码质量的一部分被常态化监控。3. 保姆级实操配置、运行与解读报告理论讲完我们进入实战环节。我会以最常见的“检查重复依赖”为例展示完整流程并穿插其他规则的注意事项。3.1 环境准备与基础配置首先确保你的项目已经正确导入并启用了Addressables包Window Asset Management Addressables Groups。如果你还没初始化系统会提示你创建设置Settings。打开分析窗口Window Asset Management Addressables Analyze。认识界面你会看到一个规则列表。勾选你想要运行的规则。你可以点击“Rules”右边的齿轮图标启用或禁用某些规则甚至导入/导出规则配置方便团队共享。3.2 运行“检查重复的Bundle依赖”规则这是我们的重头戏。勾选并运行在Analyze窗口中找到“Check Duplicate Bundle Dependencies”勾选它然后点击底部的“Analyze Selected Rules”按钮。等待分析分析时间取决于项目资源规模。首次运行可能会比较慢因为它要构建完整的资源引用关系图。查看结果分析完成后在Unity编辑器底部的Console窗口旁边会多出一个“Analyze”标签页。点击它你会看到分析报告。报告解读实战 假设报告显示如下条目Duplicate Asset: Assets/Art/Textures/Common/Button_BG.png Bundles containing asset: - UI_HUD_Buttons.bundle - UI_Menu_Main.bundle这明确告诉我们Button_BG.png这张贴图同时被UI_HUD_Buttons和UI_Menu_Main两个资源组最终会打成同名的.bundle文件依赖了。#### 3.2.1 解决方案创建共享资源组创建新组在Addressables Groups窗口右键 - Create New Group - Packed Assets。命名为“Shared_UI_Atlas”。优化打包策略选中这个新组在Inspector面板中将“Bundle Mode”设置为“Pack Together”确保组内所有资源打成一个Bundle。将“Compression”设为适合的选项如LZ4在运行时速度和包体大小间取得平衡。移动资源从原来的组比如UI_HUD_Buttons和UI_Menu_Main对应的组中将Button_BG.png的条目拖拽到新建的Shared_UI_Atlas组中。Addressables系统会自动更新依赖关系。设置依赖确保UI_HUD_Buttons和UI_Menu_Main这两个组在Inspector的“Dependencies”列表里或者通过它们的构建脚本声明依赖于Shared_UI_Atlas组。这样在打包时会先打包共享组。验证再次运行“Check Duplicate Bundle Dependencies”规则。理想情况下关于Button_BG.png的重复条目应该消失了。运行一次完整的构建Build New Build Default Build Script然后使用“Build Layout Report”规则查看最终的Bundle内容确认该贴图只存在于Shared_UI_Atlas.bundle中。注意不要盲目地把所有重复资源都塞进一个共享组。过度共享会导致另一个问题Bundle耦合过紧。任何对共享组内资源的修改都会导致所有依赖它的Bundle失效需要重新下载。合理的做法是按功能或使用频率划分共享组比如“Shared_UI_Common”、“Shared_Environment”、“Shared_Character_Base”等。3.3 处理“Resources与Addressables重复”的深水区运行“Check Resources to Addressable Duplicate Dependencies”规则后你可能会发现大量重复。处理这个需要格外小心。识别资源类型对于报告列出的每个资源判断它的用途。配置表、预制体等强烈建议迁移到Addressables。将资源文件移动到Assets目录下非Resources的任意位置如Assets/AddressableAssets/Configs然后在Addressables窗口中将其拖入相应的组分配地址。最后将原Resources目录下的文件删除。代码中直接引用的资源如果代码中是通过public GameObject prefab;这样的字段在Inspector里拖拽赋值的这个资源不能被移动否则引用会丢失。对于这类资源如果必须用Addressables管理需要修改代码为通过地址异步加载。Unity引擎内置或第三方插件放在Resources下的资源这些不要动它们可能是插件运行时必需的。你需要做的是在Addressables的配置中避免去标记和打包这些资源。AnalyzeRule报告的作用就是提醒你注意它们只要确保Addressables不管它们即可。迁移策略建议分模块、分批次迁移并充分测试。一次性全部迁移风险极高。3.4 利用“构建布局报告”进行深度优化当你解决了大部分明显的重复依赖后“Build Layout Report”是你的显微镜。生成报告先进行一次完整的Addressables构建Build New Build Default Build Script。构建完成后在Analyze窗口中只勾选“Build Layout Report”然后运行分析。它会读取本次构建的结果。分析报告报告通常以HTML格式生成在浏览器中打开。你会看到类似树状的结构Bundle A (1.5MB)Assets/Prefabs/Player.prefab (200KB)Assets/Textures/Player_Diffuse.png (1.2MB)Assets/Materials/Player_Mat.mat (100KB)Bundle B (800KB)Assets/Prefabs/Enemy.prefab (150KB)Assets/Textures/Player_Diffuse.png (1.2MB)-- 看重复依赖在这里发现问题如上例虽然“检查重复依赖”规则可能因为某些复杂引用没扫出来但布局报告赤裸裸地显示Player_Diffuse.png这个大家伙在两个Bundle里都存在。这说明你的分组策略或依赖分析仍有问题。优化方向Bundle内资源量级失衡如果一个Bundle里有一个超大资源如上例的1.2MB贴图和一堆小资源考虑将这个超大资源单独分组或者检查其压缩格式是否可以用ASTC/ETC2替代RGBA32。依赖链过长通过报告查看资源的间接依赖。有时一个Prefab会间接依赖一个完全无关的巨型资源这可能是由于材质球引用了共享的Shader变体库或者ScriptableObject的嵌套引用造成的。这需要你手动调整资源结构。4. 高阶技巧与避坑指南官方文档不会告诉你的细节都在这里了。这些都是我和团队在多次包体优化攻坚战中用“血泪”换来的经验。4.1 坑点一Sprite Atlas与重复依赖的“幽灵”这是最容易中招的坑。你使用了Unity的Sprite Atlas精灵图集来合批UI精灵。现象你明明把图集纹理SpriteAtlas texture放在了共享组但“检查重复依赖”规则仍然报告多个UI Bundle依赖了图集里的单个精灵Sprite。原因Addressables的依赖分析在默认情况下会穿透Sprite Atlas。当你把一个Sprite标记为可寻址时分析器会认为你直接依赖了这个Sprite的原始纹理资源而不是它所在的图集。即使这个Sprite实际上是通过图集来渲染的。解决方案推荐不要将图集内的Sprite单独设为Addressable。只将整个SpriteAtlas资源文件本身标记为可寻址并通过Addressables.LoadAssetAsyncSpriteAtlas来加载整个图集再通过SpriteAtlas.GetSprite(name)获取精灵。这样依赖关系就清晰了。如果确实需要按精灵寻址在Addressables的组设置中尝试调整“Bundle Mode”为“Pack Together (Dependencies)”或使用自定义的构建脚本但效果可能不完美。最根本的还是方案1。4.2 坑点二Shader变体、材质球与“依赖爆炸”这是导致Bundle无故增大的隐形杀手。现象你的模型资源很少但打包出来的Bundle却很大。用构建布局报告一看发现Bundle里包含了几百个从未听说过的.shader文件或巨大的ShaderVariants资源。原因材质球Material引用了Shader。一个Shader可能有成百上千个变体Variants由材质球上启用的不同Keyword如_NORMALMAP_ON组合而成。默认情况下Unity为了保证材质球在任何情况下都能正确渲染可能会把该Shader的所有潜在变体都打包进去。解决方案使用Shader Stripping着色器剥离在Project Settings - Graphics - Shader Stripping中可以设置剥离级别。但对于Addressables更关键的是下一个。在Addressables组上配置“Shader Variant Loading”在Addressables Group的Inspector面板找到“Advanced Options”下的“Shader Variant Loading”。默认是“All”。可以尝试改为Mono只打包当前场景或构建时用到的Shader变体。风险是如果运行时动态加载了需要新变体的材质可能会出错。Custom需要配合编写自定义的IPreprocessShaders脚本来精确控制。这是最复杂但最精准的方式大型项目必备。将通用Shader打包成共享Bundle将项目常用的Shader如URP/Lit、Unlit等单独放到一个Addressables组中让所有材质球依赖它。避免每个材质球Bundle都带一份Shader副本。4.3 坑点三AnalyzeRule分析不全或误报静态分析有其局限性。动态加载地址如前所述对运行时拼接的地址$Prefabs/{dynamicId}Check Unused Addresses规则会误报。你需要手动维护一个“动态地址白名单”来忽略这些告警。通过反射或间接方式加载如果资源地址是从配置文件读取或者通过反射机制调用Addressables API分析器也无法追踪。这部分需要代码审查来保证。ScriptableObject的复杂引用如果ScriptableObject A引用了Asset B而Asset B又通过脚本动态加载了Asset C这种间接依赖分析器可能无法完全捕获。对于重要的数据资产建议定期用“构建布局报告”进行人工复核。4.4 技巧自定义AnalyzeRule应对特殊需求如果内置规则不满足你的需求Addressables允许你编写自定义的AnalyzeRule。例如你可以写一个规则来检查所有贴图资源的尺寸是否超过平台最大限制如Android的ETC2要求长宽是4的倍数。检查所有AudioClip的加载类型LoadType是否被设置为适合流式加载的Streaming以优化内存。检查是否有模型文件的网格Mesh开启了“Read/Write Enabled”这在运行时会造成内存翻倍。编写自定义规则需要继承AnalyzeRule类实现CanFix、FixIssues等方法。这为你提供了无限的可能性来定制自己的资源质量守则。5. 将分析纳入开发流程打造资源健康防线单次优化治标不治本。要让包体保持苗条必须将AnalyzeRule制度化。预提交钩子Pre-commit Hook在团队成员提交资源或修改Addressables配置时通过Git钩子自动运行关键的分析规则如检查重复依赖、检查Resources重复。如果发现新问题阻止提交并给出报告。CI/CD流水线集成在Jenkins、GitLab CI等平台上配置打包任务。在正式构建之前先运行全套AnalyzeRule。可以将分析结果生成报告如JUnit格式与构建结果关联。设置质量关卡如果出现“Resources重复”这类高优先级错误则令构建失败如果只是“未使用地址”的警告则发出通知。定期审计每周或每两周由技术负责人或TA运行一次完整的“构建布局报告”分析查看Bundle大小的变化趋势发现新增的巨型资源或不合理的依赖在问题扩大化之前及时介入。新人培训将主要的AnalyzeRule检查项和避坑指南尤其是Sprite Atlas和Shader变体写入团队的新人开发规范。让每个接触资源的开发者都具备最基本的“资源洁癖”。资源优化是一个持续的过程而不是一劳永逸的任务。Addressables AnalyzeRule给了我们一套强大的诊断工具但最终的“手术”决策和“养生”习惯还是依赖于开发团队对项目资源结构的深刻理解和良好的工程实践。从今天开始就把AnalyzeRule用起来让它成为你项目资源健康的守门员彻底告别资源冗余带来的困扰。 Unity Addressables AnalyzeRule实战：彻底解决资源冗余与包体优化
1. 项目概述为什么你的Unity包体总是“虚胖”做Unity开发尤其是面向移动端或者WebGL平台最头疼的事情之一就是包体大小。辛辛苦苦优化了代码压缩了贴图结果一打包几百兆甚至上G的安装包用户下载的意愿瞬间就没了。更让人抓狂的是你明明记得删掉了一些不用的资源但打包出来的AssetBundle大小纹丝不动甚至有时候还会变大。这种“资源冗余”问题就像房间里堆满了你以为已经扔掉的旧东西不仅占地方还让你找起真正需要的东西来特别费劲。Addressables系统作为Unity官方推荐的资源管理方案本意是解决资源加载和热更新的难题但它本身并不是一个“自动瘦身工具”。很多团队在接入Addressables后会发现资源管理变得更清晰了但包体冗余问题反而被放大了。这是因为Addressables的打包逻辑是基于你标记的“地址”和分组策略如果你标记了资源但没使用或者资源之间存在复杂的依赖关系这些“死资源”就会悄无声息地被打进包里。Addressables AnalyzeRule就是Unity提供给你的一把“资源扫描仪”和“手术刀”。它不是新功能但却是很多项目优化流程中缺失的关键一环。很多开发者知道它存在但面对一堆分析规则和报告数据不知道从何下手或者踩了坑也不知道怎么解决。所以这篇内容不是简单的功能介绍而是一个从实战中总结出来的“避坑指南”。我会带你彻底搞懂AnalyzeRule的工作原理手把手教你配置核心的扫描规则并分享那些官方文档里不会写、但能让你少走弯路的实操经验。无论你是正在为包体超标而焦虑的主程还是刚开始接触Addressables的开发者都能从这里找到直接可用的解决方案。2. 核心思路拆解AnalyzeRule到底在分析什么在动刀之前得先明白手术的原理。Addressables AnalyzeRule不是一个魔法按钮按一下包体就小了。它是一套静态分析框架核心工作是在打包之前对你的项目资源、Addressables配置以及它们之间的引用关系进行一次全面的“体检”。2.1 分析的本质建立资源关系图谱想象一下你的项目资源是一个巨大的社交网络。每个Prefab、材质球、贴图、ScriptableObject都是一个“人”。他们之间通过引用Reference互相认识、建立关系。Addressables系统则像是一个社区管理员你把一些人资源分配到了不同的社团Addressables Group里。AnalyzeRule的工作就是绘制出这张庞大的关系网节点Node每一个可寻址的资源Asset都是一个节点。边Edge资源之间的引用关系就是边。例如一个Prefab引用了一个MaterialMaterial又引用了一张Texture这就形成了一条引用链。社团边界Group Boundary每个Addressables Group就是一个社团。分析规则会检查当一个社团需要被打包时它是否“邀请”了所有它依赖的、但不在本社团的朋友资源。分析的目标就是找出这张关系网里的“问题区域”孤立的节点被标记为可寻址但没有任何其他资源引用它即没有被使用。这是最直接的冗余。重复的节点同一个资源被多个不同的社团“邀请”并打包导致在多个AssetBundle里都存在副本。依赖关系混乱资源引用链穿过了多个社团导致打包策略复杂难以优化。2.2 内置规则详解六把标准手术刀Unity Addressables提供了一系列内置的AnalyzeRule每一把都针对一种特定的“病症”。理解它们你才能对症下药。#### 2.2.1 Check Duplicate Bundle Dependencies检查重复的Bundle依赖这是使用频率最高、效果最直接的规则。它检查不同资源组Group中是否存在完全相同的资源依赖项。它解决什么问题避免同一张贴图、同一个Shader等公共资源在多个AssetBundle中被重复打包。比如UI界面的按钮和角色选择界面都用了同一套按钮精灵图如果它们在不同的Group里这张图就会被包进两个Bundle浪费空间。输出是什么一个报告列出所有被多个Bundle依赖的共享资源并指出是哪些Bundle依赖了它。行动建议通常你会将这些被重复依赖的资源提取出来放到一个单独的、共享的Group如“SharedAssets”中并确保其他Group都依赖它。这样公共资源在最终包中只存在一份。#### 2.2.2 Check Resources to Addressable Duplicate Dependencies检查Resources与Addressables的重复依赖这是一个历史遗留问题的清理工具。很多老项目或从传统Resources方式迁移过来的项目会存在两套资源系统并存的局面。它解决什么问题防止同一个资源既通过Resources.Load加载又被Addressables系统管理。这会导致该资源被打包两次一次在Resources文件夹一次在某个Addressables Bundle里是严重的冗余。输出是什么列出所有同时存在于Resources目录和Addressables配置中的资源路径。行动建议这是必须处理的问题。你需要做出选择要么将该资源完全迁移到Addressables中并从Resources文件夹移除或重命名要么放弃用Addressables管理它。通常建议前者以实现资源管理的统一。#### 2.2.3 Check Scene to Addressable Duplicate Dependencies检查场景与Addressables的重复依赖场景文件.unity本身可能引用了一些资源而这些资源同时也被标记为Addressables。它解决什么问题和上一条类似避免场景内嵌的资源与Addressables管理的资源重复。当场景被打包例如打进主包或单独的Scene Bundle时它引用的资源会被一起打包。如果这些资源同时也在Addressables里就会重复。输出是什么列出场景文件及其引用的、同时也存在于Addressables中的资源。行动建议对于场景专属、且不需要动态加载的资源可以将其从Addressables中移除。对于需要共享的资源则需要仔细规划场景打包策略和Addressables分组可能要将场景和其依赖的共享资源分开打包。#### 2.2.4 Build Layout Report构建布局报告这个规则比较特殊它不是在打包前分析而是在打包之后进行分析。它解决什么问题给你一份最终的、详细的“打包结果清单”。它不直接给出优化建议而是展示事实最终生成的每个AssetBundle.bundle文件里具体包含了哪些资源每个资源有多大它们之间的依赖关系如何。输出是什么一个结构化的文本或HTML报告详细至极。你可以看到每个Bundle的构成是验证其他规则优化效果、进行深度手工优化的终极依据。行动建议在进行了其他优化操作后运行一次打包并生成此报告对比优化前后的Bundle组成和大小确认优化是否生效。你也可以用它来发现一些意想不到的大资源或者不合理的依赖捆绑。#### 2.2.5 Check Unused Addresses检查未使用的地址这个规则检查你是否标记了一些“僵尸”资源。它解决什么问题找出那些在Addressables窗口中配置了地址Address但在整个项目代码中通过Addressables.LoadAssetAsync等API没有任何地方真正使用这个地址去加载的资源。注意这个分析是基于静态字符串匹配。如果你的地址是运行时拼接的例如$“Character/{id}/Model”分析器可能无法识别从而产生误报。输出是什么列出所有未被检测到使用记录的地址。行动建议逐一审查列表。对于确认无用的地址直接移除。对于动态拼接的地址可以忽略此次告警但心里要有数。#### 2.2.6 Check for Invalid Addresses and Labels检查无效的地址和标签检查配置中的低级错误。它解决什么问题找出地址字符串为空、包含非法字符或者引用了不存在的资源路径的配置项。也检查标签Labels是否被正确引用。输出是什么列出所有有问题的地址和标签配置。行动建议立即修复。这些是配置错误会导致运行时加载失败。2.3 分析流程的定位CI/CD中的守门员理解AnalyzeRule的定位至关重要它是一个预检查工具而不是运行时工具。它的分析结果不会自动修改你的配置需要你人工审查并做出决策。因此最佳实践是将AnalyzeRule集成到你的持续集成CI流程中。每次提交代码、准备出包前自动运行一套配置好的分析规则。如果分析报告出现了新的问题比如新增了重复依赖CI流程可以标记失败或发出警告阻止有资源冗余问题的包被构建出来。这样资源健康度就成为了代码质量的一部分被常态化监控。3. 保姆级实操配置、运行与解读报告理论讲完我们进入实战环节。我会以最常见的“检查重复依赖”为例展示完整流程并穿插其他规则的注意事项。3.1 环境准备与基础配置首先确保你的项目已经正确导入并启用了Addressables包Window Asset Management Addressables Groups。如果你还没初始化系统会提示你创建设置Settings。打开分析窗口Window Asset Management Addressables Analyze。认识界面你会看到一个规则列表。勾选你想要运行的规则。你可以点击“Rules”右边的齿轮图标启用或禁用某些规则甚至导入/导出规则配置方便团队共享。3.2 运行“检查重复的Bundle依赖”规则这是我们的重头戏。勾选并运行在Analyze窗口中找到“Check Duplicate Bundle Dependencies”勾选它然后点击底部的“Analyze Selected Rules”按钮。等待分析分析时间取决于项目资源规模。首次运行可能会比较慢因为它要构建完整的资源引用关系图。查看结果分析完成后在Unity编辑器底部的Console窗口旁边会多出一个“Analyze”标签页。点击它你会看到分析报告。报告解读实战 假设报告显示如下条目Duplicate Asset: Assets/Art/Textures/Common/Button_BG.png Bundles containing asset: - UI_HUD_Buttons.bundle - UI_Menu_Main.bundle这明确告诉我们Button_BG.png这张贴图同时被UI_HUD_Buttons和UI_Menu_Main两个资源组最终会打成同名的.bundle文件依赖了。#### 3.2.1 解决方案创建共享资源组创建新组在Addressables Groups窗口右键 - Create New Group - Packed Assets。命名为“Shared_UI_Atlas”。优化打包策略选中这个新组在Inspector面板中将“Bundle Mode”设置为“Pack Together”确保组内所有资源打成一个Bundle。将“Compression”设为适合的选项如LZ4在运行时速度和包体大小间取得平衡。移动资源从原来的组比如UI_HUD_Buttons和UI_Menu_Main对应的组中将Button_BG.png的条目拖拽到新建的Shared_UI_Atlas组中。Addressables系统会自动更新依赖关系。设置依赖确保UI_HUD_Buttons和UI_Menu_Main这两个组在Inspector的“Dependencies”列表里或者通过它们的构建脚本声明依赖于Shared_UI_Atlas组。这样在打包时会先打包共享组。验证再次运行“Check Duplicate Bundle Dependencies”规则。理想情况下关于Button_BG.png的重复条目应该消失了。运行一次完整的构建Build New Build Default Build Script然后使用“Build Layout Report”规则查看最终的Bundle内容确认该贴图只存在于Shared_UI_Atlas.bundle中。注意不要盲目地把所有重复资源都塞进一个共享组。过度共享会导致另一个问题Bundle耦合过紧。任何对共享组内资源的修改都会导致所有依赖它的Bundle失效需要重新下载。合理的做法是按功能或使用频率划分共享组比如“Shared_UI_Common”、“Shared_Environment”、“Shared_Character_Base”等。3.3 处理“Resources与Addressables重复”的深水区运行“Check Resources to Addressable Duplicate Dependencies”规则后你可能会发现大量重复。处理这个需要格外小心。识别资源类型对于报告列出的每个资源判断它的用途。配置表、预制体等强烈建议迁移到Addressables。将资源文件移动到Assets目录下非Resources的任意位置如Assets/AddressableAssets/Configs然后在Addressables窗口中将其拖入相应的组分配地址。最后将原Resources目录下的文件删除。代码中直接引用的资源如果代码中是通过public GameObject prefab;这样的字段在Inspector里拖拽赋值的这个资源不能被移动否则引用会丢失。对于这类资源如果必须用Addressables管理需要修改代码为通过地址异步加载。Unity引擎内置或第三方插件放在Resources下的资源这些不要动它们可能是插件运行时必需的。你需要做的是在Addressables的配置中避免去标记和打包这些资源。AnalyzeRule报告的作用就是提醒你注意它们只要确保Addressables不管它们即可。迁移策略建议分模块、分批次迁移并充分测试。一次性全部迁移风险极高。3.4 利用“构建布局报告”进行深度优化当你解决了大部分明显的重复依赖后“Build Layout Report”是你的显微镜。生成报告先进行一次完整的Addressables构建Build New Build Default Build Script。构建完成后在Analyze窗口中只勾选“Build Layout Report”然后运行分析。它会读取本次构建的结果。分析报告报告通常以HTML格式生成在浏览器中打开。你会看到类似树状的结构Bundle A (1.5MB)Assets/Prefabs/Player.prefab (200KB)Assets/Textures/Player_Diffuse.png (1.2MB)Assets/Materials/Player_Mat.mat (100KB)Bundle B (800KB)Assets/Prefabs/Enemy.prefab (150KB)Assets/Textures/Player_Diffuse.png (1.2MB)-- 看重复依赖在这里发现问题如上例虽然“检查重复依赖”规则可能因为某些复杂引用没扫出来但布局报告赤裸裸地显示Player_Diffuse.png这个大家伙在两个Bundle里都存在。这说明你的分组策略或依赖分析仍有问题。优化方向Bundle内资源量级失衡如果一个Bundle里有一个超大资源如上例的1.2MB贴图和一堆小资源考虑将这个超大资源单独分组或者检查其压缩格式是否可以用ASTC/ETC2替代RGBA32。依赖链过长通过报告查看资源的间接依赖。有时一个Prefab会间接依赖一个完全无关的巨型资源这可能是由于材质球引用了共享的Shader变体库或者ScriptableObject的嵌套引用造成的。这需要你手动调整资源结构。4. 高阶技巧与避坑指南官方文档不会告诉你的细节都在这里了。这些都是我和团队在多次包体优化攻坚战中用“血泪”换来的经验。4.1 坑点一Sprite Atlas与重复依赖的“幽灵”这是最容易中招的坑。你使用了Unity的Sprite Atlas精灵图集来合批UI精灵。现象你明明把图集纹理SpriteAtlas texture放在了共享组但“检查重复依赖”规则仍然报告多个UI Bundle依赖了图集里的单个精灵Sprite。原因Addressables的依赖分析在默认情况下会穿透Sprite Atlas。当你把一个Sprite标记为可寻址时分析器会认为你直接依赖了这个Sprite的原始纹理资源而不是它所在的图集。即使这个Sprite实际上是通过图集来渲染的。解决方案推荐不要将图集内的Sprite单独设为Addressable。只将整个SpriteAtlas资源文件本身标记为可寻址并通过Addressables.LoadAssetAsyncSpriteAtlas来加载整个图集再通过SpriteAtlas.GetSprite(name)获取精灵。这样依赖关系就清晰了。如果确实需要按精灵寻址在Addressables的组设置中尝试调整“Bundle Mode”为“Pack Together (Dependencies)”或使用自定义的构建脚本但效果可能不完美。最根本的还是方案1。4.2 坑点二Shader变体、材质球与“依赖爆炸”这是导致Bundle无故增大的隐形杀手。现象你的模型资源很少但打包出来的Bundle却很大。用构建布局报告一看发现Bundle里包含了几百个从未听说过的.shader文件或巨大的ShaderVariants资源。原因材质球Material引用了Shader。一个Shader可能有成百上千个变体Variants由材质球上启用的不同Keyword如_NORMALMAP_ON组合而成。默认情况下Unity为了保证材质球在任何情况下都能正确渲染可能会把该Shader的所有潜在变体都打包进去。解决方案使用Shader Stripping着色器剥离在Project Settings - Graphics - Shader Stripping中可以设置剥离级别。但对于Addressables更关键的是下一个。在Addressables组上配置“Shader Variant Loading”在Addressables Group的Inspector面板找到“Advanced Options”下的“Shader Variant Loading”。默认是“All”。可以尝试改为Mono只打包当前场景或构建时用到的Shader变体。风险是如果运行时动态加载了需要新变体的材质可能会出错。Custom需要配合编写自定义的IPreprocessShaders脚本来精确控制。这是最复杂但最精准的方式大型项目必备。将通用Shader打包成共享Bundle将项目常用的Shader如URP/Lit、Unlit等单独放到一个Addressables组中让所有材质球依赖它。避免每个材质球Bundle都带一份Shader副本。4.3 坑点三AnalyzeRule分析不全或误报静态分析有其局限性。动态加载地址如前所述对运行时拼接的地址$Prefabs/{dynamicId}Check Unused Addresses规则会误报。你需要手动维护一个“动态地址白名单”来忽略这些告警。通过反射或间接方式加载如果资源地址是从配置文件读取或者通过反射机制调用Addressables API分析器也无法追踪。这部分需要代码审查来保证。ScriptableObject的复杂引用如果ScriptableObject A引用了Asset B而Asset B又通过脚本动态加载了Asset C这种间接依赖分析器可能无法完全捕获。对于重要的数据资产建议定期用“构建布局报告”进行人工复核。4.4 技巧自定义AnalyzeRule应对特殊需求如果内置规则不满足你的需求Addressables允许你编写自定义的AnalyzeRule。例如你可以写一个规则来检查所有贴图资源的尺寸是否超过平台最大限制如Android的ETC2要求长宽是4的倍数。检查所有AudioClip的加载类型LoadType是否被设置为适合流式加载的Streaming以优化内存。检查是否有模型文件的网格Mesh开启了“Read/Write Enabled”这在运行时会造成内存翻倍。编写自定义规则需要继承AnalyzeRule类实现CanFix、FixIssues等方法。这为你提供了无限的可能性来定制自己的资源质量守则。5. 将分析纳入开发流程打造资源健康防线单次优化治标不治本。要让包体保持苗条必须将AnalyzeRule制度化。预提交钩子Pre-commit Hook在团队成员提交资源或修改Addressables配置时通过Git钩子自动运行关键的分析规则如检查重复依赖、检查Resources重复。如果发现新问题阻止提交并给出报告。CI/CD流水线集成在Jenkins、GitLab CI等平台上配置打包任务。在正式构建之前先运行全套AnalyzeRule。可以将分析结果生成报告如JUnit格式与构建结果关联。设置质量关卡如果出现“Resources重复”这类高优先级错误则令构建失败如果只是“未使用地址”的警告则发出通知。定期审计每周或每两周由技术负责人或TA运行一次完整的“构建布局报告”分析查看Bundle大小的变化趋势发现新增的巨型资源或不合理的依赖在问题扩大化之前及时介入。新人培训将主要的AnalyzeRule检查项和避坑指南尤其是Sprite Atlas和Shader变体写入团队的新人开发规范。让每个接触资源的开发者都具备最基本的“资源洁癖”。资源优化是一个持续的过程而不是一劳永逸的任务。Addressables AnalyzeRule给了我们一套强大的诊断工具但最终的“手术”决策和“养生”习惯还是依赖于开发团队对项目资源结构的深刻理解和良好的工程实践。从今天开始就把AnalyzeRule用起来让它成为你项目资源健康的守门员彻底告别资源冗余带来的困扰。