谈一谈Unity 的 Scriptable Build Pipeline

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

标签: none