6月8日，Unity技能敞开日（Unity Open Day）正式在北京举行，会上来自Unity的技能专家、完美国际《诛仙手游》客户端负责人、《放置少女》技能专家、FunPlus 引擎技能负责人等嘉宾，将带来关于游戏管线烘托，功用优化、技能落地等实用技能同享。

　　在活动中，Unity我国引擎底层架构技能主管赵亮以“Unity小游戏开发简介”为题进行了精彩的同享。

　　小游戏是一种嵌在宿主运用内部，无需下载安装，能够即点即玩的游戏产品办法。在国内小游戏用户的规划巨大，在移动游戏商场里是一个不小的占比，大约占了20%左右，因而Unity也在逐步加大关于移动端小游戏的支撑。

　　首要，咱们介绍一下当时干流的小游戏渠道，以及他们选用的技能计划。接下来介绍一下即点即玩小游戏需求用到的资源流式加载，然后，咱们别离介绍两种小游戏技能计划，一种是Native Instant Game，另一种是WebGL，最终咱们介绍一下咱们未来的作业方向。

　　现在，咱们国内有许多小游戏渠道，有微信、QQ、抖音、头条、快手，还有Oppo、Vivo、华为、荣耀、支付宝、淘宝、百度、233乐土，在这儿咱们简略介绍一下比较具有代表性的两个渠道：微信、抖音以及他们选用的技能计划。

　　微信是从2017年12月开端发布一个叫《跳一跳》的小游戏然后开端迸发，这儿有一些揭露的数据。2019年1月起开发者数量就现已超越10万，2019年5月份的时分用户过亿，在2021年的时分，听说流水过千万的产品现已超越了50款。

　　这张图上面展现了微信小游戏的品类，跟着时刻的开展趋势，咱们能够看出，小游戏品类近年逐步从超休闲向中重度开展，例如像MMO、战略类的游戏也开端往小游戏渠道上来。

　　咱们能够重视一下微信的揭露课，上面有一些开发者同享了运用Unity去开发小游戏的经历。在上一季有《我叫MT2》的同享，这一季还会有《小小蚁国》的事例同享。

　　在抖音的渠道上面，巨量管用调研发现，小游戏的受欢迎程度仅次于App游戏，一起小游戏用户规划较大，特征也比较显著，大多是这种18-40岁的年青男性比较多，消费才能仍是能够的。

　　然后在宿主运用中去完成一个即点即玩的小游戏，现在首要有两种技能计划，一种是依据浏览器的内核，运用Web Assembly再加上WebGL的计划，另一种是在安卓上完成的这个Native Instant Game。

　　WebGL计划的一起支撑iOS、安卓两个操作体系，大部分的小游戏渠道都选用了这个计划。Native Instant Game只是能支撑安卓体系，不过它有它的长处，它的长处是游戏的质量能够比美原生App，现在抖音、头条、快手现已集成了这个计划，支付宝也在集成的过程中。

　　前面说到了小游戏从超休闲往中重度不断开展，小游戏顶用到的财物的越来越多，有一些小游戏财物打包之后有几百兆，乃至1G以上，所以说小游戏其实越来越不小了。为了让玩家能够即点即玩，削减等候下载的时刻，需求对这个资源进行按需的、流式的下载跟加载。

　　关于一个游戏开发者来说，办理好这个资源的流式加载，仍是需求投入不少的开发时刻。因而，咱们在引擎侧开发了这个Autostreaming的功用，让引擎底层主动的去向理好这个流式加载。

　　这儿咱们简略介绍一下这个Autostreaming的主动流式加载的作业原理。这个Editor里边，咱们供给了东西，能够在打包的时分主动别离出重度资源，例如像Texture、Mash、Audio、Animation等，这些资源会被布置到云上面去。在别离出重度资源之后，游戏的首包A/B包会大大减小，因而，能够让小游戏快速的下载、加载。

　　在游戏运转的时分，引擎会依据需求主动从云上去下载资源，开发者不必修正游戏的逻辑，能够像平常相同同步的去Instant一个profile。然后，这些Texture、Mash会在一个后台行列里主动的被下载跟加载。

　　在这儿，咱们以一款线上的WebGL小游戏为事例，看一看这个Autostreaming的作用。首要，咱们能够看到首包中的数据削减了许多，从42M降到了6.8M，因而大大削减了发动的耗时，从40秒降到了不到八秒，用户打的A/B也减小了一些。

　　在这个事例里边，由于咱们只挑选了一部分贴图做Autostreaming。所以减肥的程度还不是很大，另一处很重要的收益来自于内存，内存占用削减了75M，这个内存关于WebGL在iOS渠道上是很宝贵的，后边咱们会具体的聊这一点。减小的原因，首要是被剥离的重度资源有的愈加合理的生命周期，没有敞开Autostreaming，这些纹路、加载后等仍然会占用一部分内存。

　　例如首包的内存，还有A/B没有被Unload之后的内存，这是WebGL渠道一个比较特别的当地，它没有一个实在的文件体系，只需一个内存中的文件体系，所以说一个文件进来之后，就得先放到内存里边去，跟咱们在原生的App上不相同，原生的App这个文件仍是一个文件，你在读的时分只是每次会读取一块，咱们只需用一个内存缓存放到一个窗口就能够去拜访这个文件。

　　接下来咱们先简略介绍一下Native Instant Game的一个计划。它的长处很显着，它能够直接对标原生的App，跟原生的App功用是相同的，体会也是相同的，支撑多线也支撑Vulkan。原声App用的插件它也都能够用，它能够选用同步的办法去拜访沙盒中的文件，拜访的功率比较高，一起占的内存也比较少，它以一个独立的紫禁城运转在沙河之中，不会搅扰宿主的运转，引进一些安稳性或许是安全的问题。

　　关于Native Instant Game，咱们供给了完好的提审、发布、更新计划，所以关于移动游戏开发者来说，适配Native Instant Game的本钱很低，只需做好资源的流式加载，不需求再做一些额定的适配与功用优化。

　　这儿有一张截屏，来自抖音渠道上面的一个小游戏叫做《古玩便是玩》，它的原料质量比较高，咱们早年也测验将这款游戏配套到WebGL渠道，那个画质的下降仍是比较显着的。所以说，这也便是Native Instant Game的一个长处。

　　当然，讲了这么多长处，它的缺陷也比较显着，便是他现在没办法支撑iOS这个渠道，iOS渠道仍是很重要的，所以微信没有集成这个计划，字节和快手这些渠道挑选另一个战略，便是两个计划都支撑，在iOS上运用WebGL的计划，在安卓上，既支撑WebGL，也支撑Native Instant Game。

　　所以有些游戏想寻求功用天花板更高的话，就能够Native Instant Game，假设它是寻求受众更多，我的游戏质量还没到达这个功用天花板的上限，那我能够选用WebGL的一个计划去做。

　　这张图上面咱们简略介绍一下Native Instant Game的作业原理，咱们首要把每个小游戏都要运用到的这种运转实库、默许资源打包在一起，作为一个同享的引擎包，便利这个宿主App提早准备好，然后削减每个小游戏发动时分等候下载的时刻。这个同享的引擎包大约有9Mb，具体包含了这些东西，有运转时库运例如像Unity.so、Mono.os这种东西，还有一些通用的.Nel的dll、System.dll、Unity Engine.dll这种东西，然后还有Unity default resource.

　　有了这个同享的引擎包之后，开发者对小游戏渠道进行打包的时分，这个游戏根本上打包成两部分就能够了。首要是一个很小的首包，根本上在5~10M左右，能够便利小游戏快速的下载跟加载。它里边首要包含这个游戏自身的逻辑，以及一些第三方的SO插件。

　　另一部分便是游戏发动之后的流式加载资源，当用户运用前面说到的Autostreaming东西，Unity Editor会主动拆分出这些比较重度的资源布置到这个UOS上面去，UOS今日上午咱们搭档应该介绍过。

　　一起，咱们会生成一个描绘文件，里边包含了游戏的称号，首包的UAL地址、引擎的UAL地址，以及这些文件的Jersey信息。这个信息能够供给给宿主的客户端加载一个小游戏的时分去运用，也能够供这个开发者去向渠道去提审，他只需提审这个Jersey文件就好了，然后渠道能够经过这个Jersey文件知道你是哪一个游戏。

　　当宿主的客户端挑选去发动一个小游戏的时分，他会依据刚刚说到的Jersey文件里边的描绘，下载到游戏的首包，然后还有前面说到的这个同享的引擎包，宿主一般都会提早下载解压准备好。然后，客户端把这个首包解压到小游戏对应的这个文件夹里边去，然后经过一个很小的Instant Game Launching发动这个小游戏就好了。

　　所以说，宿主的App它集成了这个Native Instant Game的才能，对宿主APK添加其实是很小的，由于这个Instant Game Launch自身并不大，逻辑不杂乱。然后当unity小游戏运转的时分，他会依据自己的需求，主动的从云端去下载这些所需的资源。这个是针对Autostreaming的状况，假设不是Autostreaming，那用户就要需求自己去下载。

　　接下来咱们就更为具体的介绍一下WebGL的计划，它的计划长处很显着，支撑安卓也支撑iOS，可是WebGL计划约束许多，在这儿咱们会用更多的篇幅来介绍WebGL。

　　首要，咱们来看一看渠道的特色。这个WebGL在iOS渠道上的时分，内存非常受限，等级低机不能超越1G的内存，高档机上限大约在1.4G左右，一旦超越这个约束很或许就会触发操作体系的Out for memory然后迫使这个进程重启。从CPU这边的功用来看的话，WebGL的运转功率比原生的app要慢三倍左右，它现在只支撑单线程，不支撑多线程，所以WebGL小游戏的CPU功用比原生的app要低不少。

　　在图形API上面，它只支撑WebGL1和WebGL2，所以说有一些高档特性跟优化没办法运用，例如computer shader这种。刚刚前面也说到，它没有文件体系，所以需求更大的内存去模仿文件体系，这也导致Unitycrash机制遭到很大影响，crash文件无法被同步拜访。

　　由于这个CPU测功用比较弱，在iOS受骗这个游戏杂乱度进步，核算量增大的时分，手机很简略过热。关于网络API它也有约束，它只支撑websocket，所以说这一点需求开发者进行适配，由于以上这几种约束，导致它能运用的插件也比较有限。还有一点，iOS对WebGL渠道的支撑也不尽善尽美，咱们常常需求为iOS渠道做一些特别的优化，写一些特别的workround。

　　总的来说，关于WebGL计划的话，iOS渠道的问题比安卓渠道的问题要更多一些，因而在接下来咱们更多的都重视在iOS渠道上，怎样去profile与优化小游戏，只需iOS渠道优化好了，之后安卓渠道根本上问题不大。

　　这儿咱们就运用一个事例，别离打包成一个原生的app跟一个WebGL的小游戏往来不断比照内存、CPU、GPU的差异，咱们测验运用的手机是一个iphone12。咱们先看一下内存，左面是原生App，右边是iOS上WebGL小游戏，咱们能够看到总的内存占用多了450M左右，然后增大的当地一个是WASM的加载与编译，占到了370M，然后还有WASM heap里边有一些Unallocated的当地多出来90M，然后File System多了60M。

　　WASM的加载与编译首要是由于除了WASM文件自身之外，浏览器的内核在代码编译履行的时分也会发生更多的内存耗费，相关的缓存、GIT的优化都会运用比较多的内存。假设一个WASM是30M，它加载进来之后或许会有300M，涨了十倍左右。

　　然后多出来的是WASM heap中心的Unallocated部分，WASM heap的巨细，它是从一个预设值开端，然后以必定的步长去逐步扩容，但这个扩容的办法比较傻，它需求仿制整个areabuffer，所以说在它扩容的时分，会发生一个很高的内存峰值。假设咱们从400M扩容到500M，意味着在扩容的时分，400M也在500M也在，一共会有一个900M的峰值。

　　所以说咱们在这儿就主张开发者，依据这个游戏实践的内存峰值，在开端的时分，设一个比较大的预设值，但这样会带来另一个问题，便是它一般在尾部会有一段没有分配的当地，也便是咱们看到的这90M的当地。然后是文件体系会多运用内存，这个是刚刚说到的，浏览器的一个沙盒机制，导致这个WebGL无法拜访本地的文件，它为了浏览器的安全，只能便是说运用javascript加inndexDB去模仿文件体系。WASM去拜访javascript、javascript再去拜访inndexDB，在这儿的话便是说，它不能够像Native的文件体系那样直接运用一小块内存，然后逐步的去拜访一个大的文件。

　　还有一处值得咱们留意的当地，便是mono heap和Emspripten malloc分配的这个闲暇空间，在WebGL上面mono heap是由Auto CPP去分配办理，其他的native内存包含引擎的native heap或许第三方库都是由Emspripten malloc来分配办理，这两个厌烦的当地是，它们都是只增不减而且彼此独立，闲暇的空间无法同享，所以说咱们要留意操控各自的峰值，谁的峰值高了都不可，由于他高了之后，他降下来之后空余出来的内存，假设mono heap空出来了之后，Emspripten那儿就用不到。

　　最终，咱们看到WebGL这边比较原生的app也有一部分当地内存占用有削减。比较显著的是这个native heap的IL2Cpp Runtime，从101M降到了35.3M。这儿首要是由于咱们针对WebGL渠道做了优化，后边会比较具体的介绍这一块的东西。Asset相关的部分也有下降，由于咱们资源紧缩格局进行了调整，还有一些差异就来自于引擎底层的内存分配器，在不同的渠道上面行为跟战略有些不相同。

　　看完内存之后，咱们先来看一下CPU。从之前在网上面看他人的Benchmark研讨便是说webassembly的履行功率大约是原生app的三分之一左右，咱们也拿了一款实在的小游戏做了测验，在iphone12上测的。

　　从这个timeline profile咱们能够看出来，原生App每帧耗时大约是在3.5毫秒左右，WebGL小游戏耗时需求到十个毫秒，所以整体看来，WebGL小游戏的CPU功用跟原生app比较确实是差了三倍，印证了之前Benchmark的成果。

　　再往后咱们看一下GPU的比照，这边的话，去除这个空白网页自身的GPU耗费，关于一个游戏，WebGL跟原生app的GPU功用距离其实不算大，比较较CPU跟内存，GPU这一块咱们能够假定以为WebGL小游戏的GPU才能跟原生app根本差不多。

　　然后简略介绍一下，WebGL小游戏的开发或许是移植，近几年现已有许多的成功事例，所以说新进来的开发者不必很忧虑，这边之前现已有许多咱们的经历在里边，或许之前踩过的坑都现已处理好了。咱们Unity这边有一个官方的qq群，咱们有爱好的话能够加进来。微信他们由于支撑WebGL小游戏也要支撑Unity，所以他们也整理了很翔实的教程，前面说到，他们揭露课上也有一些开发者同享了一些运用unity开发小游戏的一些经历。

　　为了减轻WebGL渠道这些约束对小游戏开发的影响的，咱们在引擎侧也做了许多的优化跟改进。咱们优化了内存的占用、制作的功率、测验进一步给引擎代码减肥，咱们也在不断的优化小游戏的发动速度。

　　接下来咱们来看一下在内存方面咱们做过的优化作业，首要一个是IL2CPP的运转时内存占用，咱们这块优化的比较多，一个事例便是咱们从64M一向降到了33M，然后咱们还优化了DynamicVBO pool的复用机制，能够削减粒子体系这些内存占用，咱们这边测验的一个事例的是从59M降到了38M。后边说到了一些代码轻量化或许是资源裁剪也会协助削减运转时的内存占用。

　　这儿咱们来具体介绍一下IL2CPP运转时的内存优化。首要，咱们来剖析一下IL2CPP运转时首要的内存开支，从这个表格里边咱们能够看出来，它首要是三块内容，一个是Metadata，这个是咱们在运转时构建的元数据结构，里边首要是一些IL2CPPClass还有它的一些成员变量，第二个是global-metadata.dat，这个是咱们打包时生成的元数据序列化文件，在WebGL渠道上面会被完好的下载到内存中心来，再然后是一个哈希表，这个哈希表是用来加速元数据拜访。

　　现在，咱们优化首要是针对Metadata部分，这儿选用的办法是针对IL2CPP的Class，还有它的一些成员变量进行推迟加载。这个成员变量里边首要是Methodinfo占比最大，在IL2CPP之前的完成傍边，在运用到某个类型的时分，咱们就把这个类型彻底的给初始化了，包含它所有的函数、接口、作业、特点、虚表这些东西，可是后来剖析发现，脚本代码在运转中心一般只会用到很少的一部分原数据，只需在一些反射或许是虚函数调用的时分才会拜访。

　　这儿有一个比如，咱们有一个数组类型，它有155个办法，25个虚函数，完成了六个接口，但实践运转中心，只会用到其间很小的一部分，所以说咱们的优化思路便是，去推迟加载这些元数据，实在比及运用的时分才会去初始化、分配内存。

　　总归，右边的图咱们能够看出来，这儿除了Fields之外的其他信息都能够进行推迟加载。Fields信息便是说，在构建这个目标实例的时分就需求，由于他决议了这个目标实例的内存布局。咱们这儿推迟加载的力度根本上就能够准确到诸个办法。推迟加载也会带来一个比较小的开支，便是说它拜访之前需求做一次非空的判别，咱们现在还没有profile出来这会带来一些功用回退。

　　在这儿，咱们拿两个实践事例来比照一下优化前和优化后的内存占用，能够看到，第一个事例是从63.8降到了33M，第二个是从11M降到了6.5M。除了咱们刚刚说到的Metadata内存下降之外，咱们能够看到便是说这个Hashtable也降了。

　　除了上面说的内存优化之外，咱们在制作这边也做了许多优化作业，在WebGL2上面，咱们刚刚说到它不支撑computer shader，所以说GPU skinning不能运用，咱们在这儿经过transform feedback支撑了GPU Skinning，在咱们的测验事例中把这个帧率从15帧进步到了24帧。

　　然后咱们还优化了Shader Compiler，能够把non-const global的变量移到这个函数集中心。很奇怪的是这样移过来之后，咱们的帧率能够从23帧说到了55帧。还有这种像Immediate Const Buffer的转化，咱们把它实名成const，而且赋予一个初始值，然后就能够把这个帧率从32fps升到37fps，这都是一些实践作业过程中发现的这些细节的当地。

　　这儿面咱们还供给了一个装备的max vislble light值，之前的默许值设成32，但32这个值太大了，把它改成16乃至更小的值之后，功用会有很大的提高。

　　前面还说到了iOS渠道对WebGL的支撑不行好，所以说针对iOS渠道咱们也做了一些特别的walkround，优化了urpbatch在iOS上的行为，防止运用过多uniform变量，不然iOS设备上的功用会急剧下降，然后在iOS14.x-15.4版别上有一个bug，所以说针对这些版别咱们关于同一个canvas不去同享IB和VB，这样能够改进UI这边的烘托功用。

　　这儿介绍一下咱们在WebGL2上面经过这个transform feedback来完成的GPU skinning，在这儿咱们能够看到，翻开了GPU skinning后每一帧的耗时，咱们能够看到上面的数字，左面是每帧的耗时，中心是近期它耗时的最小值，右边是近期耗时的最大值，咱们只重视左面这个数字就好了。左面是敞开了transform feedback的GPU skinning之后，均匀每帧大约在42毫秒，假设没有敞开它，每帧需求耗费大约67毫秒。

　　接下来咱们来看一下引擎代码的轻量化，早年面的内存剖析咱们知道30M的一个WASM加载的时分会占300多兆的内存，所以说咱们期望生成的WASM越小越好。之前Unity裁剪的办法有这种Managed Code Strip、Engine Code Strip，它们是经过静态剖析依靠的办法去做strip，然后以函数为颗粒度，咱们在这儿会愈加深化的去剖析，咱们生成的WASM代码，看看除了这两个Strip之外，是不是还有更多的优化空间。

　　这儿咱们剖析了两个事例，他们游戏的WASM指令数大约都是在1200万左右。能够看得出来都IL2CPP在里边占了大头到达60%，引擎的c++代码大约占了40%左右。咱们依照模块进行排序，能够看到其间比较重的模块有physx、Particle System、Sqlite、Mecanim这些。

　　现在经过剖析发现的问题有像这个事例二，它是一个消除类的游戏，没有运用到许多physx的仿真，只是只是在UI上运用了physx的射线检测，然后又由于这个原因，引进了一个巨大的physx库，这是很不合理的。然后咱们还发现这个WASM里边有许多模板翻开的代码，便是说拿空间换时刻，在某些渠道上面或许是比较不错的战略，但关于WebGL这个渠道，咱们内存特别严重，所以在这个渠道上不是一个好的战略，针对WebGL渠道不运用这么多的模板。

　　所以现在，咱们针对这个代码裁剪作为作业，便是把一部分的模板改成了函数参数，不去给它进行翻开，然后的话用宏去除掉一些WebGL项目顶用不到的模板跟函数，例如像Sqlite，还有physx的一部分功用，以及像computer shader的这种现在不支撑的东西也能够把它先踢出去，未来咱们还会持续去整理发动流程、主循环里边这些不必要的过程。还有便是IL2CPP代码的生成占了60%，这一块咱们要探究怎样去把这个东西优化掉一些。

　　现在咱们看一下加速发动速度，这儿咱们首要做了两件作业，一个是说跟渠道协作，让渠道去供给一个中文字体，这样就防止了每个小游戏里边都自己需求打包一个中文字体，这能够节约5M到10M左右的下载时刻。还有，咱们能够动态的去裁剪这个unity default resource，由于default resource里边的些资源不见得每个小游戏都得用，现在看来，关于大部分游戏咱们能够把default resource从3.5M降到400K左右。咱们之前还测验过经过WASM snapshot的办法进行加载，不过这个计划咱们还没跑通。

　　接下来聊一下未来作业的方向，接下来咱们首要的有两块东西，一个是多线程，还有一个是WebGPU，除了这些之外咱们还会再探究一些像webAssembly上面的SIMD支撑，然后乃至测验让WebGL渠道也去支撑burst。

　　Unity其完成在就现已能够翻开WebG的多线程，从浏览器中截下来的profile能够看到，翻开的多线程之后，这些job从主线程搬运到了Webwork上面。

　　然后这儿仍是针对之前那个测验事例测验运用多线程，在运用多线毫秒降到了每帧耗费大约是在38-40毫秒。

　　可是现在Unity的多线程完成的还不行安稳、不行完善。例如切换场景的时分或许会Crash，咱们现在还不支撑Render THread，由于这个Web worker拜访不了DOM，然后之前咱们也能够讲到，翻开了多线程之后，左面这个内存添加了，从1.25G增到了1.69G，内存添加的比较凶猛。然后还有一个约束，现在WebGL的多线程只能支撑native代码还不支撑C#代码，这些都是咱们未来尽力处理的问题。

　　然后便是WebGPU，本年四月份的时分，然后Chrom的113就现已支撑WebGPU，咱们现在正在集成，一边集成一边研讨怎样去重构咱们的GFS device接口层使它愈加接近于现代图形API，从更多发挥出WebGPU的功用优势，今日就介绍到这儿，谢谢咱们。