claireyuancy
自增加unity WebGL平台以来。Unity的开发团队就一直致力于优化WebGL的内存消耗。

我们已经在Unity使用手冊上有对于WebGL内存管理的详尽分析,甚至在Unite Europe 2015与Unite Boston 2015两届大会上,也有专题对其进行深入的解说。然而,这方面的内容依然是用户讨论的热门话题,因此我们意识到应当分享很多其它。希望本文能回答一些被频繁咨询的问题。
 
Unity WebGL与其他平台有何不同?
一些用户已经熟悉了部分内存有所限制的的平台。而对于其他如桌面和WebPlayer平台。到眼下为止内存还不是问题。

在内存方面,主机平台相对其他平台较为简单。由于您能够准确的知道内存是怎样使用的。

这同意您能够非常好的管理内存,并保证您的游戏内容完美执行。

在移动平台,内存管理变的有些复杂,由于设备种类繁多。但至少您能够选择最低标准的设备,并依据市场情况忽视那些相较于该标准更为的低端设备。

在网页平台,就没有那么轻松了。理想情况下,全部终端用户都拥有64位浏览器和大量内存。但事实却相距甚远。首先。您无法通过不论什么方法知道,正执行您的内容的硬件规格。其次。除了用户的操作系统和浏览器外,您并不知道其他信息。最后。终端用户可能像执行其他网页一样执行您的WebGL内容。

因此这是一个很复杂的问题。

概览

下图是在浏览器上执行Unity WebGL内容时的内存概览:



上图展示了Unity 堆,Unity WebGL内容将须要向浏览器请求额外分配的内存。这是理解WebGL内存管理的重点。从而让您优化项目得以将用户流失率降至最低。

正如上图所看到的。存在几组内存分配:DOM,Unity堆,资源数据和代码,这些内容都会在网页载入时持久存在于内存中。而其他诸如 Asset Bundles, WebAudio 和 Memory FS 何时载入则取决于您的内容执行情况。

(比如:Asset Bundle下载,音频播放等等)

在载入期间, 一些浏览器在asm.js解析和编译时会产生暂时内存分配。这偶尔也会导致部分使用32位浏览器的用户出现内存溢出的问题。

Unity堆

通常来说。Unity堆是指包括了全部Unity特有的游戏对象、组件、纹理、着色器 等等的内存块。

在WebGL平台,Unity堆的大小须要提前获知。浏览器才干对此分配空间。而且内存空间一旦分配,就无法改变内存缓冲区大小。

负责Unity 堆内存分配的代码例如以下:

1.buffer = new ARrayBuffer(TOTAL_MEMORY);

这段代码能够在所生成的build.js中找到。并通过浏览器的JS虚拟机来运行。



TOTAL_MEMORY 是在Player Settings 中的WebGL Memory Size中设置的总内存。默觉得256MB,但这是我们任意设定的值,其实。一个空项目执行仅需16MB。

然而。真实世界中游戏内容可能会须要很多其它的内存空间。大部分情况下都须要256或者386MB。请记住。项目须要的内存越多。可以执行它的终端用户就越少。



源码/编译代码内存

在代码能够被运行之前,它须要例如以下步骤:

  • 下载
  • 拷贝到一个文本域
  • 编译

请谨慎考虑,上述的每个步骤都将请求大量内存。

由于:

  • 下载缓冲区是暂时的。可是源码和编译代码将持久存在于内存中。
  • 下载缓冲区和源码大小,都是Unity所生成的未压缩的js大小。

    依照下面步骤,您能够估算它们须要多少内存:

    • 构建一个公布版本号。

    • 将jsgz 、datagz重命名为*.gz文件,并通过压缩工具对它们进行解包。
    • 解压缩后的大小就是它们在浏览器内存中的大小。


  • 编译代码的大小取决于浏览器。



优化内存的一个简单方法是启用Strip Engine Code。这样您公布的版本号将不包括那些不必需的原生引擎代码(比如:假设不须要2D物理模块,它将被剥离)。

请注意:托管代码一定会被剥离。

千万要记住。异常捕捉和第三方插件也将添加代码大小。

正如之前所说,我们已经注意到用户须要加入空值检查和数组边界检測的代码,但不希望完整的异常检測支持会带来过多的内存(及性能)消耗。

要实现这点,您能够通过编辑器脚本传递 
–emit-null-checks 和 –enable-array-bounds-check 到il2cpp,比如

PlayerSettings.SetPropertyString("additionalIl2CppArgs", "--emit-null-checks --enable-array-bounds-check");

最后请记住,构建开发版本号产生的代码尺寸更大,由于它不曾缩减。这不是问题,毕竟终于交给用户的会是公布版。

资源数据

在其他平台上,一个应用能够简单地訪问位于固定存储空间(硬盘。闪存等等)的文件。而在网页平台上这是不可能的,由于出于安全考虑,网页平台无法訪问真正的文件系统。

因此。Unity WebGL 数据(.data文件)一旦被下载,就会永远存储在内存中。

这样做的缺点就是它相对其他平台将须要很多其他的内存(比如5.3中.data文件以lz4压缩的形式存储在内存中)。比如,下图是分析器显示的一个项目生成了约40MB的数据文件(在256MB Unity堆的设置下):



.data 文件里包括了什么?它是Unity所生成的文件集合,包括下面内容:data.unity3d (全部的场景,它们依赖于Resources目录中的资源和全部内容),unity_default_resources和少量引擎所需的小文件。



为了知晓资源的准确总大小。您须要在公布至WebGL平台后查看Temp\StagingArea\Data文件夹下的data.unity3d (Temp文件夹将会在Unity编辑器关闭时被删除)。另外,您也能够通过查看UnityLoader.js 中的DataRequest差值得知素材资源的准确大小。

new DataRequest(0, 39065934, 0, 0).open(\'GET\', \'/data.unity3d\');
(这段代码依据Unity版本号不同,写法可能有些差别——演示样例是Unity 5.4)

内存文件系统
尽管不存在真实的文件系统,正如前文所述,您的Unity WebGL内容仍然能够读写文件。相对于其他平台的主要差别在于。WebGL平台的文件输入/输出操作实际上都是对内存的读/写操作。非常重要一点是,这个内存文件系统并不存在于Unity 堆中。因此,它将须要额外的内存。

比如,以下这个输出数组到文件的演示样例:

var buffer = new byte [10*1014*1024];

File.WriteAllBytes(Application.temporaryCachePath + "/buffer.bytes", buffer);

这个文件将会被写入到内存中,而且在浏览器的分析器也能够查看到。




请注意:Unity堆的大小为256MB。

相同,Unity的缓存系统依赖于文件系统,所以WebGL平台整个缓存存储也是在内存中进行的。这意味着像PlayerPrefs和缓存的Asset Bundles也会被持久化到内存中,而不存在于Unity堆中。

Asset Bundles

降低WebGL平台内存消耗的最佳方法之中的一个是使用Asset Bundles (假设您对Asset Bundles不熟悉。请查阅Unity使用手冊或通过教程学习)。然而,依据使用方式不同。它们将会对内存消耗带来巨大影响(Unity堆中和堆外都会受此影响),这将有可能导致您的内容无法执行在32位浏览器上。

假设真的须要使用Asset Bundle,您会将全部资源打包到一个单独的Asset Bundle吗?

千万别这么做。即使那样可能会降低网页载入期间的压力。您仍然须要下载(极可能无比巨大的)Asset Bundle。从而导致内存使用高峰。来看看下载AB前的内存使用情况。


如您所见,256MB被分配给Unity堆。

下图是没有经过缓存的Asset Bundle下载:


如今看到的是额外的缓存,大约与硬盘中的Asset Bundle(约65mb)大小同样,它是通过XHR分配的。这仅仅是一个暂时缓存。但它将导致连续几帧的内存高峰。直至垃圾收集器启动。

怎样最小化内存高峰?为每一个资源创建一个Asset Bundle?想法不错。但明显不合实际。



其实。对于怎样做可以降低内存高峰并没有普遍的标准,这取决于您项目的实际需求。

最后,在资源使用完成后记得通过AssetBundle.Unload卸载Asset Bundle。

Asset Bundle缓存

Asset Bundle缓存与其他平台一样。您仅仅须要使用WWW.LoadFromCacheOrDownload。它们最大的差别就是内存消耗。

在Unity WebGL中。AB缓存依赖于IndexedDB。IndexedDB是由眼下内存文件系统所支持的emscripten编译器实现。

下图使用LoadFromCacheOrDownload下载Asset Bundle的内存使用情况:



如您所见。Unity堆使用了512MB,并额外分配了约4MB的内存。



下图是载入Asset Bundle后的内存情况:


额外须要的内存跳到了约167mb。这是该Asset Bundle所需的额外内存(压缩包约为64mb)。下图是js虚拟机垃圾收集器启动后的内存情况:


能够看到如今有了一些改善。但仍需约85mb的内存,当中大部分内存用于将Asset Bundle缓存到内存文件系统。这些内存即使卸载了Asset Bundle也不会回收。另一点非常重要。当玩家第二次在浏览器中执行游戏时。这些内存会被马上载入,甚至在载入Asset Bundle之前。



下图是Chrome的内存截图以供參考:


相同,在Unity堆外还有其他缓存相关的暂时内存分配,以供Asset Bundle系统使用。坏消息是近期我们发现它比预想的更大。好消息是它将在未来的Unity 5.5 Beta 4,5.3.6 Patch 6和5.4.1 Patch 2中得以修复。



对于更早的Unity版本号,万一您的Unity WebGL内容已经上线或即将公布。而您又不想升级项目,一个高速的变通方法是通过编辑器脚本的设置下面属性:

PlayerSettings.SetPropertyString("emscriptenArgs", " -s MEMFS_APPEND_TO_TYPED_ARRAYS=1", BuildTargetGroup.WebGL);

最小化Asset Bundle缓存内存消耗的长远解决方式是,使用WWW构造器替代LoadFromCacheOrDownload()。或者您使用新的UnityWebRequest API 时。调用UnityWebRequest.GetAssetBundle()不要带有哈希或版本号參数。

其次是在XMLHttpRequest层使用替代的缓存机制。绕过内存文件系统,将下载的文件直接存储到indexedDB中。我们已经开发了这种工具并公布在Asset Store中。您能够免费将它用于您的项目,也能够自己定义以满足特殊需求。

Asset Bundle压缩

Unity 5.3和5.4均支持LZMA和LZ4两种压缩方式。然而,即使使用LZMA(默认)压缩相对于LZ4或未压缩下载的包更小,但它在WebGL平台上还是有些缺点:它会导致明显的执行延迟,而且须要很多其它的内存。因此强烈建议使用LZ4或者未压缩的格式(实际上,Unity 5.5的WebGL平台将不再支持对Asset Bundle的LZMA压缩)。为了弥补相比LZMA压缩的下载尺寸过大,您可能希望使用gzip/brotli来压缩Asset Bundle,并配置到您的服务端。



查阅Unity使用手冊以获得很多其它关于Asset Bundle压缩的信息

网页音频

音频在Unity WebGL上的实现方式有所不同。这对内存意味着什么?

Unity将会在JavaScript中创建特定的AudioBuffer的对象。以便它们能够通过WebAudio进行播放。



因为WebAudio缓存位于Unity堆外。因此无法通过Unity 分析器进行跟踪分析。您须要使用浏览器专用的工具。来查看音频使用了多少内存。示比例如以下(火狐浏览器, about:memory page):


考虑到那些Audio Buffers保存的是未解压的数据,其可能不适用于大型音频片段资源(比如:背景音乐)。对于那些资源。你可能希望自己编写js插件。以便使用<audio>标签。

这样的方式下音频文件会保持压缩,因此须要的内存更少。

FAQ

问:降低内存使用的最佳实践是什么?
答:概括例如以下:

  • 降低Unity堆的大小
  • 尽可能保持“WebGL Memory Size”足够小
  • 降低代码量
  • 启用Strip Engine Code
  • 禁用异常检測
  • 避免使用第三方插件
  • 降低数据大小
  • 使用Asset Bundles
  • 使用Crunch纹理压缩

问:是否存在可以决定最小WebGL Memory Size的策略?

答:有。最佳策略是使用内存分析器。分析您的内容实际所需的内存大小。然后据此改变WebGL Memory Size。

以空项目为例。内存分析器告诉我们总的使用量仅为16mb(这个值可能在不同Unity版本号上有所不同):这意味着仅仅须设置WebGL Memory Size大于16MB就可以。当然,内存的总使用量将会根据您的内容而有所不同。

然而,假设由于某些原因无法使用分析器,能够简单地通过不断地降低WebGL Memory Size 值,直到发现您的内容真正所须要的最小内存使用量为止。

另外很值得注意的是。不论什么不是16的倍数的值都将被自己主动的四舍五入(在执行时)为下一个16的倍数,这是Emscripten编译器所要求的。

WebGL Memory Size(MB)设置将决定生成的html中TOTAL_MEMORY(bytes)的值。




所以。为了在不又一次构建项目的前提下,重复測试内存堆的值,推荐使用更改html的方式。一旦您通过此方式发现适合的值,仅仅需在Unity项目设置中更改WebGL Memory Size就可以。



最后,记住Unity的分析器将占用一些来自Unity堆的内存,所以在使用分析器时可能须要添加WebGL内存大小。

问:执行时发生内存溢出。怎样修复?

答:这取决于是Unity,还是浏览器的内存溢出。

这个错误信息将会指出问题所在以及解决的方法:“假设您是该内容开发人员,请在WebGL设置中为您的应用分配很多其它(或更少)的内存。”此时您能够据此调整WebGL内存大小设置。

然而还有非常多能够解决内存溢出的方法。

假设出现下面错误信息:


除了消息内容,您还能够尝试降低代码和数据的大小。

这是由于当浏览器载入网页时。它将试图为一些内容寻找空余的内存。当中最重要的是:代码。数据。Unity堆和被编译的asm.js。

它们可能相当大,尤其是数据和Unity堆内存。这对32位浏览器来说可能是问题。



在一些样例中。虽然存在足够多的空余内存,浏览器仍将载入失败。由于内存是碎片化的。这就是为什么有时候您的内容可能在重新启动浏览器之后,能够成功载入的原因。

还有一种情况是。当Unity 内存溢出时提示下面信息:


在这样的情况下,您须要优化您的Unity项目。



问:怎样衡量内存消耗?

答:为了分析内容所使用的浏览器内存,能够使用火狐浏览器的内存工具或Chrome堆快照。但它们不会显示WebAudio内存使用情况,因此还能够获取火狐浏览器的about:memory页面快照,然后通过搜索“webaudio”找到。

假设您须要通过JavaScript分析内存,请尝试使用window.performance.memory(仅仅支持Chrome)。



使用Unity分析器測量Unity堆内存使用。但请注意。您可能须要添加WebGL的内存大小,以便可以使用分析器。

此外,我们一直在致力于开发一个新的工具,以便您能分析公布版本号:构建WebGL版本号。然后訪问http://files.unity3d.com/build-report/就可以使用该工具。

尽管这在Unity5.4下已经可用,但请您注意,这还是正在开发中的功能,而且随时会更改或被删除。但至少如今能够使用它达到測试的目的。

问:WebGL Memory Size的最小值与最大值是多少?

答:16MB是最小的,最大是2032MB,然而我们通常建议保持在512MB下面。

是否可能出于开发目的而须要分配超过2032MB的内存?

这是一个技术上的限制:2048MB(或很多其它)将会超出TypeArray所用的32位有符号整型的最大值。而TypeArray被用于在JavaScript中实现Unity堆。

问:为何Unity 堆大小不可改变?

答:我们一直在考虑使用Emscripten编译器标志ALLOW_MEMO

分类:

技术点:

相关文章: