一、编辑器：打包
1、使用ScriptableObject配置打包规则
- 分包方式可以随着项目迭代灵活调整，只要不改底层的设定，就不用动代码
- 将部分流程控制的接口，以虚方法的形式放到ScriptableObject里，可以给项目提供一定的拓展性，又不用主动向ABMgr传递对象或者做额外的配置。（由ABMgr主动寻找规则配置的ScriptableObject）
2、用Pipeline的结构，处理打包规则的解析（生成AssetBundleBuild列表）
- 后置Pipe可以选择在前置Pipe结果的基础上进行修改，也可以完全丢弃前面的结果。效果同装饰者模式。
- 可以很大程度上保证【开闭原则】
- 规避新增需求时到处插入修改代码
二、运行时：加载&使用
1、兼容AB包的循环引用问题
以目录为单位的打包方式，在资源放置不当的时候，比较容易出现AB包循环引用问题。研发阶段，经常出现发版后由于循环引用导致的卡死问题，要浪费不少时间定位、修改、重新出包（特别时半夜出版，遇到这个问题极其恶心！！）。
为了不在节点出浪费时间，决定从程序上允许循环引用的存在。但是规范上还是不允许，发现问题后仍然需要相关人员进行解决，只是不在发版的当口处理。
2、支持异步加载转同步完成
通常我们要求所有资源都应该采用异步加载的方式；或者先异步预加载再同步使用。但总有一些情况需要真正的同步加载，从业务使用上无法保证同步、异步只存在一个。所以要在同步加载的时候，将当前存在的异步加载请求立刻完成，返回给同步请求使用。（Unity不允许同一个AB包被同时加载两次）
3、支持取消加载
从业务角度，我们希望玩家不被加载卡住操作。比如：玩家做了一个需要加载较长时间的操作，玩家应该可以退出系统放弃这个操作，而不是必须等待加载完成。Unity底层没有相关的支持，只能自己在框架里做。
4、支持延迟卸载
- 延迟卸载的主要意义是，避免一个资源刚卸载马上又加载，浪费性能（IO、内存、发热、时间）
- 延迟卸载要放在底层支持，用一个模块进行统一的管理，不要让业务来关注这个事情（特殊业务有特殊需求，也应该有可操作的支持）
5、以资源名为Key，用双缓存的方式记录已加载的资源
我允许不同类型的资源重名，定位资源就需要名+类型两个信息。大多数情况下名字跟资源是一对一的，少数情况下才会出现一对多。为了同时兼顾内存与查找效率，建立双缓存。多数情况，只需要一次查找就定位到资源；少数情况，需要追加一个小规模的遍历。
6、支持模拟模式加载资源
- 研发阶段频繁打AB包会浪费大量时间，所以要支持直接加载资源的方式跑游戏（模拟模式）
- 加载方式差异应当放在底层处理、切换，业务层不应该对这件事有感知
- 为了方便在编辑器下，快速切换加载模式测试不同的问题，用ScriptableObject提供配置切换
- AB包模式与模拟模式相互独立，不应该有相互依赖
