八、将组打包到 AssetBundle 中

在选择如何将组中的资产打包到 AssetBundle 中时，您有几个选项：

• 您可以将分配给一个组的所有 Addressables 打包在一个包中。这对应于“Pack Together”捆绑模式。有关详细信息，请参阅高级组设置。
• 您可以将分配给一个组的每个 Addressable 单独打包到它自己的包中。这对应于“单独打包”捆绑模式。有关详细信息，请参阅高级组设置。
• 您可以将共享同一组标签的所有 Addressables 打包到它们自己的包中。这对应于“按标签打包”捆绑模式。有关详细信息，请参阅高级组设置。

场景资产始终与组中的其他可寻址资产分开打包。因此，一个包含场景和非场景资产混合的组在构建时总是会产生至少两个包，一个用于场景，一个用于其他所有内容。

当您选择单独打包每个 Addressable 时，标记为 Addressable 的文件夹中的资产和复合资产（如 Sprite Sheets）将得到特殊处理：

• 标记为可寻址的文件夹中的所有资产都打包在同一个文件夹中（文件夹中单独标记为可寻址的资产除外）。
• 可寻址 Sprite Atlas 中的 Sprite 包含在同一个包中。

有关详细信息，请参阅内容打包和加载设置。

笔记

当许多人在同一个项目上工作时，将许多资产放在同一个组中会增加版本控制冲突的可能性。

选择将您的内容打包成几个大包还是许多小包，可能会产生两种极端的后果：

捆绑包过多的危险：

• 每个包都有内存开销。这与该页面上概述的许多因素有关，但简而言之，这种开销可能很大。如果您预计内存中会同时加载 100 个甚至 1000 个包，这可能意味着内存消耗量非常可观。
• 下载包有并发限制。如果您同时需要 1000 个捆绑包，则无法同时下载它们。将下载一些数字，当它们完成时，将触发更多数字。在实践中，这是一个相当小的问题，小到你经常会被下载的总大小所限制，而不是它被分成多少包。
• 捆绑信息会使目录膨胀。为了能够下载或加载目录，我们会存储有关您的捆绑包的基于字符串的信息。价值 1000 束的数据会大大增加目录的大小。
• 重复资产的可能性更大。假设两种材质被标记为可寻址，并且每种材质都依赖于相同的纹理。如果它们在同一个包中，那么纹理将被拉入一次，并被两者引用。如果它们在单独的包中，并且纹理本身不是可寻址的，那么它将被复制。然后您需要将纹理标记为可寻址，接受复制，或者将材料放在同一个包中。有关更多信息，请参阅Asset 和 AssetBundle 依赖项。

束太少的危险：

• UnityWebRequest（我们用来下载）不会恢复失败的下载。因此，如果正在下载一个大包并且您的用户失去连接，则一旦他们重新获得连接，下载就会重新开始。
• 物品可以从捆绑包中单独装载，但不能单独卸载。例如，如果一个包中有 10 个材料，加载所有 10 个，然后告诉 Addressables 释放其中的 9 个，所有 10 个都可能在内存中。有关详细信息，请参阅内存管理。

随着项目规模的扩大影响规模

随着您的项目变得越来越大，请关注资产和捆绑包的以下方面：

• 总包大小：Unity 历史上不支持大于 4GB 的文件。这已在最近的一些编辑器版本中得到修复，但仍然存在问题。建议将给定捆绑包的内容保持在此限制以下，以实现跨所有平台的最佳兼容性。
• Bundle layout at scale：内容构建生成的 AssetBundle 数量与这些 bundle 的大小之间的内存和性能权衡会随着项目变大而变化。
• Bundle dependencies：加载 Addressable 资产时，也会加载其所有 bundle 依赖项。创建可寻址组时，请注意资产之间的任何引用。有关更多信息，请参阅Asset 和 AssetBundle 依赖项。
• 影响 UI 性能的子资产：这里没有硬性限制，但是如果你有很多资产，并且这些资产有很多子资产，最好关闭子资产显示。此选项仅影响数据在“组”窗口中的显示方式，不影响您在运行时可以加载和不能加载的内容。该选项位于工具>显示精灵和子对象地址下的组窗口中。禁用此功能将使 UI 更具响应性。
• Group hierarchy display：另一个有助于缩放的 UI-only 选项是Group Hierarchy with Dashes。这在顶级设置的检查器中可用。启用此功能后，名称中包含破折号“-”的组将显示为好像破折号代表文件夹层次结构一样。这不会影响实际的组名，也不会影响事物的构建方式。例如，名为“xyz”和“xyw”的两个组将显示为好像在名为“x”的文件夹中有一个名为“y”的文件夹。该文件夹内有两组，称为“xyz”和“xyw”。这不会真正影响 UI 的响应速度，而只会使浏览大量组的集合变得更加容易。