自动化的打包策略

• 目录
  1. 逻辑层的异步加载处理策略
  2. 资源管理实现和Addressable API
  3. 统一的缓存管理
  4. 自动化的打包策略

在资源管理，Addressable Assets 一文中，我提到 unity 的 bundle 的释放策略暗含了”不能把很多asset打到一个bundle里“， 具体怎么打包呢？

可能的打包策略分析

1. 只对策划可能会配置到的资源进行打 Bundle

   共用资源会重复在多个 Bundle 里，增大包体大小，运行时内存大小

2. 对每个 unity Assets 里的文件单独打 Bundle

   共用资源不会重复，但碎 bundle 导致整体文件数量很多，运行时会担心文件句柄数不够，同时运行时加载资源可能会慢。

3. 介于 12 之间，把共用资源提取出来打包，如何提取又分 2 种策略

   a. 约定目录，或手动把公共资源标记出来打包。 b. 程序自动提取公共资源。

我们采用的是3.b，3.a 依赖人工持续不停的检查，太苦了。而我发现 unity 虽然提供了各种打 bundle 的工具， 但都没有建议一个完全自动化的打包策略。这里我们提供一下武林的方案。

一种自动提取公共资源来打包的方法

概念上把 bundle 分为 2 类：

1. 是策划直接会用于配置的资源，对策划可见。

   这个根据目录来约定，如果多个 asset 要放到一个 bundle，也根据约定来。

2. 是公共资源，对策划不可见，不能用于配置，目的只是为了减小包体，减小运行时内存。

   这个提取规则是如果我提取了此 asset 到单独 bundle 里能减少多少内存。 （还有个是能减少多少次重复次数，这个只是考虑到可能的 mat 合批带来的 batch 减少）。

就这么个简单规则，可参考 ABMarkDupChecker.cs 细节是我们可在真正打包之前来预估出这个节省的内存，从而直接提取出来。下面附上武林资料片 1 做的一个打包策略 1，2，3 的实际测试结果

可看到我们在 bundle 文件个数和 总 bundle 大小 之间做了个平衡：增加了 1500 个文件，总 bundle 大小增加了 4%

总结

用了这个策略后，程序再也不用纠结哪些资源属于公共资源了。

至此资源系统到此就写完了。