AssetBundel打包策略

打包策略

1.处理共用的资源，对于共用的资源我们不希望把他打进多个用它的包，例如资源bc共用a，那么我会先用BuildPipeline.PushAssetDependencies()把a放入堆栈，然后打a包，再打b和c，这样打b或c时如果堆栈中已经有了a，那么a的资源不会被打入bc，而是在b和c中建立一个到a的关联，这样我们在加载b时，先加载好a的包，加载b的包就能把b加出来了。但是假设如果这个程序里只有b依赖a，而没有其他任何资源依赖a，我们就完全可以把ab合在一个包里。

问题最复杂的地方在于对于一个大型工程，资源成千上万，依赖关系复杂，我们需要确定一个规则，哪些包可以打在一起，哪些要使用依赖，并给一个正确的push pop堆栈的顺序。看到一些项目需要配置表什么的，那个太不智能，我们的方法就是在打包之前遍历所有资源（所有是指除了代码的所有，包括模型 贴图 场景 shader 配表所有偶有）及其依赖关系，然后会生成几颗树（一个树林）的结构，这个结构里，父节点对子节点存在着依赖关系，然后我们会进一步精简这颗树，因为如果不精简就变成每个资源打一个包，会存在太多的包，我们迭代的把单节点的链条合并到其父节点中，并且消除树中的冗余路径，如a-》b-》c同a-》c同时存在时，我们会消除a-》c这个依赖。最终我们得到一个合并了节点的一些树，然后大体按照从树叶到树根的顺序用pushpopo打包（总的原则就是依赖的包一定要先在栈里，用完还要及时出栈，不然会影响打包速度）

2.加快每次打包的速度，对于大型工程，每次打包的资源非常多，如果每次都全部重大，很耗时间，于是我们做了一套增量的打包，每次打包会记住md5，下次打这个资源时会查看他是否改动，对于没改动的资源就不重新打，当然这个是否改动不是只简单的看他的MD5是否改变，可能这次他的依赖关系变了，那么和包的内容也会变，所以还要考虑依赖的改变等情况。

3.在线更新，我们需要在每次打包后生成每个版本的所有包的信息，这样才能为用户正确的在线更新新的包下来，基本上会比较用户本地的包和最新服务器上的包的情况，启动游戏前更新到最新