unity webgl内存_了解Unity WebGL中的内存
unity webgl内存
Since we shipped Unity WebGL, we have put a lot of effort into optimizing memory consumption. We’ve also been explaining how memory works in WebGL in the manual and in our talks at Unite Europe 2015 and Unite Boston 2015. However, as this continues to be a hot-topic in our conversation with customers, we realized we should talk more about it. Hopefully this post will answer some of the frequently asked question.
自从我们发布Unity WebGL以来，我们已经在优化内存消耗方面投入了大量精力。 在 手册中 以及在 2015年Unite欧洲 和 2015年 Unite波士顿的 演讲中， 我们还一直在解释内存在WebGL中的工作方式 。 但是，由于这一直是我们与客户交谈中的热门话题，因此我们意识到我们应该对此进行更多讨论。 希望这篇文章能回答一些常见问题。
Unity WebGL与其他平台有何不同？ (How is Unity WebGL different from other platforms ?)
Some users are already familiar with platforms where memory is limited. For others, coming from desktop or the WebPlayer, this has never been an issue until now.
一些用户已经熟悉内存受限的平台。 对于其他人，无论是来自台式机还是WebPlayer，到目前为止，这一直不是问题。
Targeting console platforms is relatively easy in this respect, since you know exactly how much memory is available. That allows you to budget your memory and your content is guaranteed to run. On mobile platforms things are a bit more complicated because of the many different devices out there, but at least you can choose the lowest specs and decide to blacklist lower-end devices at the marketplace level.
在这方面，定向控制台平台相对容易，因为您确切知道有多少可用内存。 这样您就可以预算内存，并保证内容可以运行。 在移动平台上，由于 那里存在 许多 不同的设备 ，因此情况 有些复杂 ，但是至少您可以选择最低规格的设备，并决定在市场级别将低端设备列入黑名单。
On the Web, you simply can’t. Ideally, all end-users had 64-bit browsers and tons of memory but that’s far from reality. On top of that, there is no way to know the specs of the hardware your content is running on. You know the OS, Browser and not much more. Lastly, the end-user might be running your WebGL content as well as other web pages. That’s why this is a tough problem.
在网络上，您根本做不到。 理想情况下，所有最终用户都具有64位浏览器和大量内存，但这与实际情况相去甚远。 最重要的是，您无法了解运行内容的硬件规格。 您知道操作系统，浏览器，仅此而已。 最后，最终用户可能正在运行您的WebGL内容以及其他网页。 这就是为什么这是一个棘手的问题。
总览 (Overview)
Here is an overview of memory when running Unity WebGL content in the browser:
这是在浏览器中运行Unity WebGL内容时的内存概述：
This image shows that on top of the Unity Heap, Unity WebGL content will require additional allocations in browser’s memory. That’s really important to understand, so that you can optimize your project and therefore minimize users drop-off rate.
此图显示，在Unity Heap之上，Unity WebGL内容将需要在浏览器的内存中进行其他分配。 理解这一点非常重要，这样您就可以优化您的项目，从而最大程度地减少用户流失率。
As you can see from the image, there are several groups of allocations: DOM, Unity Heap, Asset Data and Code which will be persistent in memory once the web page is loaded. Other ones, like Asset Bundles, WebAudio and Memory FS will vary depending on what’s happening in your content (e.g.: asset bundle download, audio playback, etc.).
从图像中可以看到，有几组分配：DOM，Unity Heap，资产数据和代码，它们将在加载网页后永久保存在内存中。 其他内容(例如资产捆绑包，WebAudio和Memory FS)将根据您内容中发生的情况而有所不同(例如：资产捆绑包下载，音频播放等)。
At loading-time, there are also several browser’s temporary allocations during asm.js parsing and compilation that sometimes cause out-of-memory problems to some users on 32-bit browsers.
在加载时，在asm.js解析和编译期间，还有一些浏览器的临时分配，有时会给32位浏览器上的某些用户造成内存不足的问题。
统一堆 (Unity Heap)
In general, the Unity Heap is the memory containing all Unity-specific game objects, components, textures, shaders, etc.
通常， Unity堆是包含所有特定于Unity的游戏对象，组件，纹理，着色器等的内存。
On WebGL, the size of the Unity heap needs to be known in advance so that the browser can allocate space for it and once allocated, the buffer cannot shrink or grow.
在WebGL上，需要预先知道Unity堆的大小，以便浏览器可以为其分配空间，并且一旦分配，缓冲区就不会缩小或增长。
The code responsible for allocating the Unity Heap is the following:
负责分配Unity堆的代码如下：
|
1 |
buffer = new ArrayBuffer(TOTAL_MEMORY);
|
|
1 |
buffer = new ArrayBuffer ( TOTAL_MEMORY ) ;
|
This code can be found in the generated build.js, and will be executed by the browser’s JS VM.
该代码可以在生成的build.js中找到，并将由浏览器的JS VM执行。
TOTAL_MEMORY is defined by WebGL Memory Size in the Player Settings. The default value is 256mb, but that’s just an arbitrary value we chose. In fact an empty project works with just 16mb.
TOTAL_MEMORY由“播放器设置”中的WebGL内存大小定义。 默认值为256mb，但这只是我们选择的任意值。 实际上，一个空项目仅占用16mb。
However, real-world content will likely need more, something like 256 or 386mb in most cases. Keep in mind that the more memory is needed, the fewer end-users will be able to run it.
但是，现实世界中的内容可能需要更多，在大多数情况下约为256mb或386mb。 请记住，需要的内存越多，最终用户运行它的数量就越少。
源代码/编译后的代码存储器 (Source/Compiled Code memory)
Before the code can be executed, it needs to be:
在执行代码之前，它需要：
downloaded.
已下载。
copied into a text blob.
复制到文本Blob中。
compiled.
编译。
Take into consideration that, each of these steps will require a chunk of memory:
考虑到这些步骤中的每一个都将需要一块内存：
The size of the downloaded buffer and the source code are both the size of the uncompressed js generated by Unity. To estimate how much memory will be needed for them:
下载缓冲区的大小和源代码都是Unity生成的未压缩js的大小。 估计它们将需要多少内存：
make a release build
发布版本
rename jsgz and datagz to *.gz and unpack them with a compression tool
将jsgz和datagz重命名为* .gz并使用压缩工具将其解压缩
their uncompressed size will also be their size in browser’s memory.
它们的未压缩大小也将是它们在浏览器内存中的大小。
The size of the downloaded buffer and the source code are both the size of the uncompressed js generated by Unity. To estimate how much memory will be needed for them:
下载缓冲区的大小和源代码都是Unity生成的未压缩js的大小。 估计它们将需要多少内存：
The size of the compiled code depends on the browser.
编译代码的大小取决于浏览器。
An easy optimization is to enable Strip Engine Code so that your build will not include native engine code that you don’t need (e.g.: 2d physics module will be stripped if you don’t need it). Note: Note: Managed code is always stripped.
一个简单的优化就是启用“剥离引擎代码”，以便您的构建中不包含不需要的本机引擎代码(例如：如果不需要，则将剥离2d物理模块)。 注意：注意：托管代码始终被剥离。
Keep in mind that Exceptions support and third party plugins are going to contribute to your code size. Having said that, we have seen users that need to ship their titles with null checks and array bound