构建WebGL目标时的内存考量

Memory Considerations when targeting WebGL

构建WebGL目标时的内存考量

Memory in Unity WebGL can be a constraining factor restricting the complexity of the content you can run, so we would like to provide some explanation on how memory is used in WebGL.

对于Unity WebGL来说,内存限制了所运行内容的复杂度。下面我们将解释一下在WebGL中内存是如何被使用的。

Your WebGL content will run inside a browser, so any memory has to be allocated by the browser within the browser’s memory space. The amount of available memory can vary a lot depending on the browser, OS and device used. Determining factors include whether the browser is a 32 or 64 bit process, whether the browser uses separate processes for each tab or has your content share a memory space with all other open tabs, and how much memory the browser’s JavaScript engine requires to parse your code.

因为WebGL内容是运行于浏览器当中的,所以其所需内存都是从浏览器内存空间里分配的。根据所用浏览器、操作系统和设备的不同,WebGL内容可用的内存可能会差别很大。决定因素包括:浏览器是32位的还是64位的,浏览器为每个标签页使用独立的进程还是让WebGL内容和其它标签页使用共享的内存,以及浏览器JavaScript引擎解析WebGL内容代码需要多少内存。

There are multiple areas where Unity WebGL content will require the browser to allocate significant amounts of memory:

在以下几个方面,Unity WebGL内容要求浏览器分配大量内存:

Unity Heap

Unity堆内存

This is the memory Unity uses to store all it’s state, managed and native objects and currently loaded assets and scenes. This is similar to the memory used by Unity players on any other platform. You can configure the size of this in the Unity WebGL player settings (But for faster iteration, you can also edit the TOTAL_MEMORY value written to the generated html file). You can use the Unity Profiler to profile and sample the contents of this memory. This memory will be created as a TypedArray of bytes in JavaScript code, and requires the browser be able to allocate a consecutive block of memory of this size. You will want this space to be as small as possible (so that the browser will be able to allocate it even if memory is fragmented), but large enough to fit all the data required to play any scene of your content.

对于这些内存,Unity用于存储其所有状态、托管的原生对象和当前加载的资源场景。这类似于Unity播放器在其他任何平台上所使用的内存。可以在Unity WebGL播放器设置中配置该内存的大小(为了快速迭代,也可以编辑已写入生成的html文件的TOTAL_MEMORY值)。您也可以使用Unity Profiler对该内存的内容进行抽样和调试。该内存以JavaScript代码的TypedArray字节形式被创建,并要求浏览器能够按其大小分配连续的内存块。我们希望该空间尽可能小(这样当内存零碎时浏览器仍然能够分配该空间),但仍足以容纳播放任何内容场景时所需的数据。

Asset Data

资源数据

When you create a Unity WebGL build, Unity will write out a .data file containing all the scenes and assets needed for your content. Since WebGL does not have a real file system, this file will be downloaded before your content can start, and the uncompressed data will be kept in a consecutive block of browser memory for the whole time your content is run. So, to keep both download times and memory usage low, you should try to keep this data as small as possible. See the documentation page on Reducing File size for information on how to optimize the build size of your assets.

当您创建Unity WebGL构建时,Unity将会输出一个.data文件,其包含WebGL内容所需的所有场景和资源。由于WebGL没有真实的文件系统,所以在开始运行内容之前,.data文件需要先被加载,同时,在内容运行的所有时间里,这些未压缩的文件将一直被保存在连续的浏览器内存块里。为了降低下载时间和内存占用,您应该让这些数据尽可能小。请参见文档降低文件大小,获得优化资源构建大小的相关信息。

Another thing you can do to reduce load times and the amount of memory used for assets is to pack your asset data into AssetBundles. By doing so, you get full control of when your assets need to be downloaded, and you can unload them when you no longer need them, which will free any memory used by them. Note that AssetBundles will be loaded directly into the Unity heap and will not result in additional allocations by the browser (unless you use Asset Bundle Caching using WWW.LoadFromCacheOrDownload, which is using a memory-mapped Virtual File System, backed by the browser’s IndexedDB).

有另外一个方法可以降低资源的加载时间和内存占用,其是将资源数据打包进AssetBundles。这样做,您便能完全控制什么时候加载资源,以及在不需要的时候卸载它们以释放它们所占用的内存。请注意,AssetBundles会被直接加载到Unity堆内存中,而不会造成浏览器的额外内存分配(除非您通过WWW.LoadFromCacheOrDownload使用Asset Bundle Caching技术,该技术采用了基于浏览器索引数据库的内存映射虚拟文件系统)。

Memory needed to parse the code

解析代码所需的内存

Another issue related to memory is the memory required by the browser’s JavaScript engine. Unity will emit very large files of millions of lines of generated JavaScript code, which is an order of magnitude larger than common uses of JavaScript code in browsers. Some JavaScript engines may allocate some rather large data structures to parse and optimize this code, which may results in memory spikes of up to several Gigabytes of memory when loading the content in some cases. We expect that future technologies like WebAssembly will eventually eliminate this problem, but until then, the best advise we can give is to do what you can to keep the size of the emitted code low. See the comments on distribution size here for more information on how to do that.

跟内存相关的另一个问题是浏览器JavaScript引擎所需的内存。Unity会生成包含数以百万行JavaScript代码的非常大的文件,其数量级比浏览器里通常运行的代码量可要大得多。一些JavaScript引擎会分配相当大的数据结构以解析和优化这些代码,某些情况下可能导致加载内容时内存峰值上升到几千兆字节。我们希望未来诸如WebAssembly之类的技术能最终解决这个问题。但在那之前,我们能给的最好建议是尽您所能以降低发行的代码量。请点击这里以查看跟发布大小相关的评论,获得解决问题的更多信息。

Dealing with memory issues

应对内存问题

When you see an error related to memory in a Unity WebGL build, it is important to understand whether it is the browser which is failing to allocate memory or if the Unity WebGL runtime is failing to allocate a free block of memory within the pre-allocated block of the Unity heap. If the browser is failing to allocate memory, then it may help to try to reduce the size used by one or more of the memory areas above (for instance by reducing the size of the Unity heap). On the other hand, if the Unity runtime is failing to allocate a block inside the Unity heap, you may want to increase the size of that instead.

当您在Unity WebGL构建当中看到内存相关的错误,区分以下两点很重要,是浏览器无法分配内存,还是Unity WebGL运行时无法在预先分配好的Unity堆内存块中分配空闲内存。如果是浏览器无法分配内存,那么尝试降低以上内存区域所使用的大小可能会有帮助(比如降低Unity堆内存的大小)。另一方面,如果是Unity运行时无法在Unity WebGL堆内存中分配内存块,则可以相应增加堆内存的大小。

Unity will try to interpret error messages to tell which of the two it is (and provide suggestions on what to do). Since different browsers may report different messages, that is not always easy, however, and we may not be interpreting all of them. When you see a generic “Out of memory” error from the browser, it is likely to be an issue of the browser running out of memory (where you might want to use a smaller Unity heap). Also, you may sometimes see browsers simply crashing when loading Unity content without showing a human-parseable error message. This can have many reasons, but is frequently caused by JavaScript engines requiring too much memory to parse and optimize the generated code.

Unity会尝试分析浏览器错误信息以告诉您是以上两个错误当中的哪个(并给出怎么应对的建议)。因为不同浏览器可能会报不同的错误信息,所以有时分析很困难,无法完全分析。当您看到浏览器产生“内存不足”之类的错误时,可能是浏览器内存用光造成的问题(这时您可能想使用小一些的Unity堆内存)。此外,您有时会碰到加载Unity内容时浏览器直接崩溃,而没有显示可阅读的错误信息。有很多可能原因,但通常是因为JavaScript引擎需要过多的内存以分析和优化产生的代码所导致的。

Garbage Collection considerations

垃圾回收机制考量

When you allocate managed objects in Unity, they will need to be garbage collected when they are no longer used. See our documentation on automatic memory management for more information. In WebGL, this is the same. Managed, garbage collected memory is allocated inside the Unity heap.

对于Unity中的托管对象,当它们不再被使用时,需要做垃圾回收处理。请查看文档自动内存管理,获取更多信息。在WebGL中,也有同样的机制。托管的垃圾回收内存分配于Unity堆内存中。

One distinction in WebGL, however, concerns the points in time when garbage collection (GC) can take place. To perform garbage collection, the GC would normally need to pause all running threads and inspect their stacks and registers for loaded object references. This is not currently possible in JavaScript. For this reason, the GC will only run in WebGL in situations where the stack is known to be empty (which is currently once after every frame). This is not a problem for most content which deals with managed memory conservatively and has relatively few GC allocations within each frame (you can debug this using the Unity profiler).

WebGL中的一个区别在于垃圾回收(GC)发生的时间点。为了实施垃圾回收,GC通常需要暂停所有运行中的线程、检查堆栈和注册已加载的对象引用。而目前这在JavaScript中还不能实现。由此,仅当堆栈为空(目前在每一帧后有一次)的时候GC才会在WebGL中运行。对于保守处理托管内存和在每帧中GC分配相对较少的大多数WebGL内容,这不是问题(您可以使用Unity分析器进行调试)。

However, if you had code like the following:

然而,如果您的代码看起来如下:

string hugeString = "";

for (int i = 0; i < 100000; i++)

{

hugeString += "foo";

}

, then this code would fail running on WebGL, as it would not get a chance to run the GC between iterations of the loop, to free up memory used by all the intermediate string objects - which would eventually cause it to run out of memory in the Unity heap.

则该代码在WebGL中将无法运行。因为在for循环中没有机会运行垃圾回收机制以释放所有中间字符串对象所使用的内存——这些字符串对象最终会导致代码用光Unity堆内存。

链接:

https://docs.unity3d.com/540/Documentation/Manual/webgl-memory.html

时间: 2024-10-26 21:55:19

构建WebGL目标时的内存考量的相关文章

自制编程语言crowbar(v0.1)构建解析器时分配内存

crowbar中第一次申请内存是在生成解析器的时候: /* interface.c */CRB_Interpreter *CRB_create_interpreter(void) { MEM_Storage storage; CRB_Interpreter *interpreter; storage = MEM_open_storage(0); interpreter = MEM_storage_malloc(storage, sizeof(struct CRB_Interpreter_tag)

new对象数组时的内存布局

[cpp] view plain copy #include <iostream> #include <limits> using namespace std; #define SAFE_DELETE(x) \ { \ if (NULL != (x)) \ { \ delete (x); \ (x) = NULL; \ } \ } #define SAFE_DELETE_ARY(x) \ { \ if (NULL != (x)) \ { \ delete[] (x); \ (x) 

java获取运行时虚拟机内存情况

/** * 获取系统内存使用情况 * * @return 包含最大内存, 使用内存, 剩余内存的map对象 */ @Override public Map getXtncSyqk() { Map map = new HashMap(); long maxMem = Runtime.getRuntime().maxMemory()/1024/1024; long freeMem = Runtime.getRuntime().freeMemory()/1024/1024; long usedMem

tomcat启动时JVM内存大小,以免出现内存溢出

问题: 主要是2个内存溢出的错误. 首先是:java.lang.OutOfMemoryError: Java heap space 其次是:java.lang.OutOfMemoryError: PermGen space 最终解决办法[我是4G内存,请适当修改大小]: [Windows]在catalina.bat的第一行增加: set JAVA_OPTS=-Xms512m -Xmx900m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSiz

程序编译后运行时的内存分配

原文地址不详,我的转载的来源:http://blog.sina.com.cn/s/blog_5420e0000101a0w1.html 一.编译时与运行时的内存情况 1.编译时不分配内存 编译时是不分配内存的.此时只是根据声明时的类型进行占位,到以后程序执行时分配内存才会正确.所以声明是给编译器看的,聪明的编译器能根据声明帮你识别错误. 2.运行时必分配内存 运行时程序是必须调到"内存"的.因为CPU(其中有多个寄存器)只与内存打交道的.程序在进入实际内存之前要首先分配物理内存. 3.

一起talk C栗子吧(第一百三十三回:C语言实例--创建进程时的内存细节)

各位看官们,大家好,上一回中咱们说的是从内存角度看进程和线程的例子,这一回咱们说的例子是:创建进程时的内存细节.闲话休提,言归正转.让我们一起talk C栗子吧! 看官们,我们都知道使用fork函数可以创建一个新的进程,今天我们一起说一下使用该函数创建进程时内存的一些细节问题.我们介绍的的重点还是内存布局中的四个分区. 1.在父进程中使用fork时,会创建一个新的进程,我们叫它子进程,子进程有自己的内存空间: 2.子进程的内存空间中没有代码区,子进程和父进程共享代码区: 3.子进程的内存空间中拥

一起talk C栗子吧(第一百三十四回:C语言实例--创建线程时的内存细节)

各位看官们,大家好,上一回中咱们说的是"创建进程时的内存细节"的例子,这一回咱们说的例子是:创建线程时的内存细节.闲话休提,言归正转.让我们一起talk C栗子吧! 看官们,我们在前面章回中介绍过创建线程的例子,创建线程时使用的函数是pthread_create.今天我们一起说一下使用该函数创建线程时内存的一些细节问题.我们介绍的的重点还是内存布局中的四个分区.这点和前一回中介绍创建进程时内存细节的思路相同. 1.在主线程中使用pthread_create函数可以创建一个新线程,我们叫

objective-c启用ARC时的内存管理

PDF版下载:http://download.csdn.net/detail/cuibo1123/7443125      在objective-c中,内存的引用计数一直是一个让人比较头疼的问题.尤其是当引用计数涉及到arc.blocks等等的时候.似乎ARC的出现只是让我们解放了双手,由于底层实现依然依赖引用计数,所以开启ARC后,只有对引用计数机制更加了解,才能避免Cycle Retain.Crash等问题的出现. 但是由于使用ARC可以显著提高编码效率,所以建议尽量启用arc,本文内容也将

当执行构建步骤“qmake”时

有时我们在导入别人的QT项目时,点击编译,会提示“构建***项目发生错误,当执行构建步骤“qmake”时”,这是因为我们在导入项目的时候没有指定qt版本的原因,只需选择项目选项,如下图 然后选择相应的qt版本,并把构建目录改成你现在用的目录就可以了.