Unity的Scriptable Build Pipeline (SBP) 提供了一种更灵活的构建方式，以package 的形式提供，将一些常用的构建类和接口从C++层移动到了C#层。，与传统的构建接口不同，SBP在构建时并不会生成manifest,而是会在library下生成缓存，实际首次构建时长会比buildpipeline慢一些，但如果再次调用构建接口，就会使用缓存来增量构建，减少构建时长。除此之外，SBP在构建完成后会在AB包目录输出构建步骤的耗时的详细信息和耗时日志，可以用Trace Event Profiling Tool打开， 方便profiler不同的构建步骤。Unity的Scriptable Build Pipeline (SBP) 提供了一种更灵活的构建方式，以package 的形式提供，将一些常用的构建类和接口从C++层移动到了C#层。，与传统的构建接口不同，SBP在构建时并不会生成manifest,而是会在library下生成缓存，实际首次构建时长会比buildpipeline慢一些，但如果再次调用构建接口，就会使用缓存来增量构建，减少构建时长。除此之外，SBP在构建完成后会在AB包目录输出构建步骤的耗时的详细信息和耗时日志，可以用Trace Event Profiling Tool打开， 方便profiler不同的构建步骤。

---

以下是个人总结的一些SBP的优点与缺点。

优点：

良好的设计接口,能更灵活的控制构建过程，例如深度定制AB包构建内容，指定单个Ab包压缩格式、依赖查找回调等。 将构建任务粒度拆分更细，例如压缩、打图集、编译脚本，文件系列化等。为构建并行化为了准备 使用BuildCache，加快构建速度，不同构建机之间可以共享同一份BuildCache 构建更细粒度的步骤profiler

缺点：

Task的设计看起来很美好，但大部份任务并不支持并行化，自定义task的可行性比较低 增量构建不完善，依然有bug,使用buildcache后bug会传播到其它构建线 过度的设计，看似提供了更灵活的接口，实则很难正确的实现这些接口，比如看似可以通过IBundleBuildContent的BundleLayout来控制每个ab包的内容，但由于unity的依赖关系很难从上层应用通过Unity提供的接口计算正确，所以从上层来控制每个ab包的内容基本上不可能 单个ab包的压缩格式通过回调来指定的做法比较不合理，这样做需要用字典来存储每个ab包压缩格式，增加了额外内存和构建时长，同时这样的代码写起来也比较麻烦。一种比较简单的做法是在AssetBundleBuild中增加一个压缩格式参数 Build Cache在Library下占用硬盘空间较大

参考链接

trace-event-profiling-tool