关于 AssetBundle 合并依赖压缩方式的疑问

Creator 3.x
#1
  • Creator 版本： 3.6.3
  • 目标平台： 微信小游戏

如果给某个 AssetBundle 的压缩方式设置为“合并依赖”，那么在生成的 config.json 文件中会包含一个 packs 字段，其中每个 pack 包含一定数量的资源。

  1. 这些 packs 是以什么样的规则生成的？有详细点的说明吗？
  2. 实际测试时发现，在某一个 pack 中居然会包含上万个资源（项目中的总资源数量也就1万多），感觉非常不合理，项目中并没有很复杂的依赖关系，照说不应该出现上万个资源在一个 pack 中的情况。

上述 config.json 文件见附件（已删除了 paths 字段）config.5bb6b.json.zip (1.8 MB)

#2

packs 大部分来说，是根据依赖关系来生成的，比如 A 资源依赖 B 资源，B 资源依赖 C，则 A 和 B 和 C 在打包的时候会合并。在这个规则之外，还按照类型对数据量比较小的资源进行了合并，比如所有的 Texture2D 类型会 pack 在一起，所有的 ImageAsset 类型会合并在一起。大概是这么个规则

#3

规则之外将所有 Texture2D 类型会 pack 在一起，所有的 ImageAsset 类型会合并在一起，这个规则其实是有问题的，问题如下：
1、项目中图片资源上万个，按这种方式，就会出现基本所有图片的 Texture2D 类型被打在一个 pack json下、所有 ImageAsset 类型被合并在一个 pack json 下，加载某个图片资源，assetManager 的 _files 下就有上万个图片 json 数据，大多数图片并不会被用到
2、当一个图片 Asset 资源被释放后，当重新加载该图片时，由于 _files 中取不到该资源 json 信息，需要再下载整个 pack json(大几百k，实际一个文件的 json 信息就几十字节)，并解析 json
3、只要项目自己有实现内存资源的释放机制，就会出现 pack json 会频繁出现下载解析 json 的操作

#4

你说的这个情况是的，之前这么设计应该是出于 texture 的复用率太高了，如果按照依赖扫描的形式来分组，可能出现多个组中都会包含相同数据，如果不按照依赖来扫描，又会导致细碎散文件过多，导致加载缓慢的问题。

#5

开发的时候，是不是预置体上的图片，用代码形式动态加载，就可以避免这些问题。我看现在公司很多东西都是代码加载出来，然后设置上去。以前我做的时候，是把各种东西摆好到预置体。

#6

同样的合并依赖，发现ios和android 的相同ab包，pack的资源不一致，导致文件个数不一致，这怎么破。这样热更新不就不能使用一个相同的资源了吗，你们有没有碰到过