分布式架构

分布式架构对团队的帮助主要针对大体量的项目，例如，数万或更多的资产的时候。对于相对独立不带依赖的资产，可以按使用时机拆分为不同的构建单元，按需分批次提交，减少算力浪费导致打包等待时间。

例如，配置文件和美术资产通常没有引用关系，而修改配置的次数可能是修改资产的次数的数倍，这时候可以为配置文件和美术资产分别创建独立的打包配置。再例如，UI和场景如果没有交叉引用，也可以分别创建独立的打包配置。依此类推，角色模型动画贴图、粒子特效等可以遵循没有交叉引用的创建独立打包配置，来优化打包速度。

在生产环境中，通常配置文件单独打包可能只需要 3-5 分钟升至更快，而混合美术资产打包可能需要 10 分钟或者更久，通过分而治之的概念，可以有效减少不必要的打包等待时间，1 次打包节省 5 分钟，1 天打包 3 次，1 个月下来 22 天可以节省 5 ✖ 3 ✖ 22 = 330 分钟，持续下来，可以节省多少人力支出了都在其次，关键是团队可以把更多的时间花在内容创作上。

显然，分布式架构对大体量项目的资产打包带来的助力是可以预见的，只要在制作上，尽可能把对象引用改成路径引用，就可以最大化的释放分布式架构的对打包提速的助力。而有交叉引用的也应该尽可能解除引用关系（对象引用的可以改成路径引用），不仅方便分批按需打包（减少开发人员的等待时间），而且更方便按需加载（创造更好的用户体验）。

另外，分而治之不仅可以加快打包速度，其实，还可以把出问题的地方局限化。毕竟，分布式架构之后，可以改了什么才打什么，没改的不用打包，哪怕构建管线有坑，不打包，自然不会受影响。

尽管分布式打包需要规避交叉引用的问题，但是 xasset 已经准备了检查引用的工具来帮助团队排查问题，如下图：

使用编辑器菜单 xasset/Builds 可以打开这个工具，点击 Find References 就能检查不同打包配置之间是否有交叉引用，如果没有问题，会提示暂无异常，而一旦发现问题，会将有问题的检查结果准确的输出到本地，如下图：

了解分布式架构的动机和限制后，就可以开始准备打包了。