Unity 近期发布了最新的云端分布式算力方案（点击回看），能够帮助开发者利用云算力和云存储赋能开发过程。在技术开放日现场，Unity 技术专家为大家简单介绍了云开发技术框架、RoadMap，以及现有云能力：云烘焙，云打包，云端资源格式转换等。

本文节选了部分精彩内容，完整内容已上传至 Unity 社区中的技术专栏。滑至文末，点击“阅读原文”，即可跳转至技术专栏学习：

https://developer.unity.cn/projects/openday-kevin

非常高兴今天在这里和大家分享我们在做的 Unity 云端分布式算力方案，这其实是一个大计划的前身，我们想用云来赋能开发者，满足他们对于高算力、高存储的需求。

我们做这件事的时候，先定义了一些 Workflow。比如游戏制作过程中，会有烘焙、光照贴图、还需要去做打包 Assetbundle、导入资源或者资源格式转化这些事情；在工业领域，可能需要兼容各种各样的数据格式，然后借助 Unity 做一些 3D 的交互。这些事在日常工作中都是比较耗时的，如果都在一个本地的端上面做的话，就会比较有局限性。所以我们首先定义了 Workflow，无论用户以什么样的方式使用 Unity，我们都能够以非常模块化的方式给予云端方面的支持。

未来我们希望达到的是我们针对云以及云对端的赋能，让大家在更丰富的终端做开发。比如现在我们只支持在 PC 的 Windows 和 MAC 还有 Linux 上做开发，但是将来如果真的那些比较重计算的这些消耗我们端能力的事情能够被云赋能的话，其实有机会我们可以支持大家在更多的终端去做开发。

其实这和现在很火的 Metaverse 也是相关的。Metaverse 一定是支持任意端链接进入的虚拟世界，因此创作者也需要在任意端上做开发。不同的终端有不同的限制，比如有的终端 GPU 相对较弱，那么创作工具该如何解决这种问题，这是我们在思考的。如果能够突破终端限制，我们就可以真正做到随时随地创作。

现在 Unity 一直在更新版本，添加新功能，如果未来都可以通过云服务的方式让大家使用 Unity 的话，那么就没有版本这个说法了，因为创作者总是会第一时间自动体验到云端上最新版本的功能和服务。从而做的 Version-Less。

云服务也有利于促进团队合作，因为它对需求的响应是非常快的。如果大家在使用云端分布式烘焙解决方案时遇到了问题并反馈给我们，我们修改后，大家会立刻就能使用修改后的版本，因为它本身是一个云端的服务。

还有可扩展性，其实我们在国内就是要做一个跨云平台的事情，让开发者能够触达更多的云资源，甚至我们可以支持你做私有云的部署服务。

这个就是我们目前的一个架构，如果你们使用 Unity 的 XR Framework 的话会对这张图非常熟悉。这其实体现的是一个理念：把 Unity 定义的生产流程当中会用到的能力进行标准化，并提供给开发者，然后开发者基于我们封装的标准化流程做相应的生产流程，然后我们再去应对不同厂商它们在 IaaS 层的差异。

工作流方面的话，引擎这边就会在底层的基础能力上去提供标准化的创作管线，比如之前分享过的数字人生产流程，从扫描的数字人到建模、然后面部驱动、渲染、毛发、皮肤等一系列的流程。然后用户可以按照工作流的逻辑和能力，自己进行定制化开发或删减，做各种拓展。Unity 之前做的大世界方案也被拓展成了生产流程，之后我们也会在这些不同的生产流程上面做更多的迭代，并分享给开发者。

这里简单讲一下我们在云端目前做了一些什么事情。

除了云端分布式算力方案，还有对象存储的桶的能力，这项功能在最新的 Unity 长期支持版里已经可以使用了。这个能力允许开发者非常方便地把资源存在云端/本地，不管是在开发阶段还是运行期，实际上我们是封装了对象存储器所有的 API，直接生效给到你，然后开发者再去存。

然后基于对象存储器的能力和云函数能力我们做了几个功能，就是 lightmap baking， Asset Bundel Build，然后 asset 的导入，这些都是对现有生产流程的加强。然后还有就是 BIM 数据的 convert，把 BIM 的数据变成 Unity 能识别的数据，这是一个新的功能。还有今年 Instant Game，也是基于云端能力实现的。我们未来还会接着做的一些新功能。

实际上我们自己已经可以在云端协同地去做一些事情了，现在我们做的是把这些能力封装成组件分享给开发者，一旦他们有类似的需求，就能直接使用我们提供的组件。这些组件有的是云上面的概念，我们就把它封装成了 Event System 的方式，然后我们基于此做了一些功能，比如云端分布式渲染系统。

Unity 也在做多机协同渲染。其实之前 Unity 有做过一个 Cloud Rendering 的东西，但是它就是比较初级的状态，现在我们实际上是在它的基础上去做分布式的渲染，把我们的渲染任务分到很多渲染节点上面，然后再由一堆逻辑服务器去更新自己的逻辑，就是这样一个事情。

因为我们对象存储的地方已经做了一个封装，然后再有 Event 的话，我们其实就可以在云上做一个类似于 Asset brower 的东西，这样子的话可以让我们的开发者非常方便地去搜索资源，即便这个资源不在本地。

基于这些，我们设想未来把这些能力都集中到引擎里，比如让大家可以在云端与 HDRP 集成，然后让 HDRP 进行分布式渲染，同时物理模拟过程也可以考虑做分布式。

这里想单独介绍一下 Auto Streaming，简单来说，这个 Auto Streaming 就是帮助大家减少首包大小的。

它解决了两个问题。首先是安装，当首包小到一定程度的时候你就可以用很多方式把游戏分享出去，比如说像以前 Unity 做的 Instant Game 的方式，或者预先把 Unity 足够小的首包合进某一个 super app 这种方式来做到。而且足够小的首包就意味着秒启动，如果每个包下载数量低于 40 兆，就可以在 CDN 的加持下做到很快的下载，然后秒开。给到你的应该是一个类似于云游的体验。

Auto Streaming 的 APK 可以实现渐进式的加载过程，会从不清晰的状态慢慢到清晰状态。这个也是 Auto Streaming 的一个小小的副作用，但是你享受的是一个 Native APP 的体验。而且无论是从分发上还是启动上，它跟几个 G 的包体提供的体验相差无几。

这个图也已经展示过了，实际上这个功能我们还在不断地迭代，它现在已经可以把包体压缩得比这个更小。

然后我们现在能够提供的 Streaming 资源只有 texture、mesh，未来还会有 audio、font、animation 做上。其实我们分析过，就是哪些东西它占包体比较大我们就会先做哪些，把它做到很小，这个过程全部都在引擎里进行，所以对于开发者来说是无感的。它相较于我们用 addressable system 的区别是在于，你可能需要用到你的 code 去适应 Addressable system 的 API。但是你用 Auto Streaming 的话，它是在引擎里面帮你把这些事情做了。

Asset bundle 是把大一些的资源分离出来，在该处留下一个占位符。随着相应的 code 在引擎上被触发，我们会从 CCD 上下载对应的东西，加载出来。

这个是我们目前已经合作的平台，这证明了这个东西它是可以集成到一个 Super APP 里面的，就像刚才我说那样的，它其实做到了手包减小之后，它还可以做到免安装。一个 2G 的游戏要集成到某一个平台那是不可能的，但是如果是一个十几兆的首包，它其实是可以做到的。

Auto Streaming 现在已经有很多 CP 厂商他们自己基于我们提供的技术，直接把游戏转成了 Instant Game，所以它已经是一个日趋成熟的产品。

Unity Instant Game 产品详情页：

这是这个产品的交流群，大家如果想加入的话可以扫描。

接着讲云端分布式解决方案的事情，就是我们做了一个分布式的烘焙，这个其实是用到了云函数和刚才讲的对象存储。第一个版本我们做的是 Enlighten 的，因为大家可能用 Unity 的都知道，就是很早以前 Unity 关于 realtime GI 都是用 Enlighten。后来有一段时间我们自己开发了一个 progressive，然后最近 2021 版 Enlighten 又回来了。我们现在第一个先用 Enlighten 做分布式烘焙，如果 progressive 有需求的话，我们也会把它排上进度。

简单讲一下云烘焙的一些概述，还有它的一些特点。

现在大家都在做大世界场景的游戏，烘焙就是一个问题，耗时是绝对的。云烘焙的理念其实很简单，就是在 Unity 里面，我们在烘焙的时候实际上我们会把场景做一些处理，其实在这个过程当中你不用担心你的场景数据传到云上去会泄露一些资产，其实我们传上去的是 enlighten 数据格式的 binary，然后传上去之后去做光线的计算。

所以这个过程你可以理解成，我们把起始资产传上去，然后拿到的是已经烘焙好的光照贴图的一些中间结果，最后我们会在边缘端去合成光照贴图，所以基本上不会发生你的数字资产在云端被泄露的情况。而且一开始我们的 demo 就是巨大的，所以我们轻易不会有这种担心。

云烘焙的成本非常低。首先它在云上是分布式的，就是你可以用很多机器去帮你做协同的烘焙。然后它是基于云函数的，所以成本可控。现在每个云厂商都各有不同，有些云厂商可以是以 100 毫秒的粒度计费，有些可以 10 毫秒。成本计算就是你用多少是多少。而且它在云端是一个多进程，多机协同的，所以无论是从运算能力还是内存上面都是更有优势的。最后就是免部署，因为它是一个云函数嘛。

它的使用方式也非常简单，打开 Unity 编辑器，勾选 Lighting 面板 Enlighten 模式下的 Cloud Bake 即可完成部署。所以它对于你的开发体验完全没有影响的，它只是单纯地用云来协助了你的开发过程。

我们自己做了一个场景测试，可以看到提升还是非常明显的，基本上烘焙的大多数阶段的任务都放云上去了，熟悉 enlighten 的开发者会知道 enlighten 的各个环节的并发度和场景高度相关，像我们这个测试场景有一些任务并发度不高，考虑到上传下载的时间收益就有限，但也有一些任务并发度非常高的，比如 light transport 等，这种任务传到云上它的收获就会非常的大，所以整体收益其实也是蛮可观的。云上机器和本地机器对比，但其实我认为不用关注云上的机器，因为我们本身是云函数，所以厂商分配什么机器给你其实你都不用在意，你只需要云函数可以运行你的云任务就可以了。

本文转载自unity公众号