Unity WebGL のメモリは、実行できるコンテンツの複雑さを制限する制約要因になる可能性があります。そのため、ここでは WebGL でメモリがどのように使われるかについて説明します。
WebGL のコンテンツはブラウザー内で実行されます。そのため、メモリはすべてブラウザーによってブラウザー内部のメモリ空間に割り当てられることになります。利用可能なメモリの総量は使用しているブラウザー、OS、デバイスによって大きく変動する可能性があります。決定要因には他にもブラウザーが 32 ビット 64 ビットのどちらか、ブラウザーがタブごとに分離したプロセスを使用するのか、それとも開かれているタブがすべて同じメモリ空間を共有するのか、ブラウザーの JavaScript エンジンがゲームのコードを変換するのにどれだけのメモリを要するか、などがあります。
Unity WebGL コンテンツがブラウザーに著しく大きなメモリの割り当てを必要とするエリアが、複数あります。
これは、すべての状況、マネージオブジェクトやネイティブオブジェクト、現在読み込まれているアセットやシーンを Unity が保存するためのメモリです。他のプラットフォームで Unity プレイヤーが使用するメモリと似ています。メモリのサイズは Unity WebGL Player 設定で設定することができます。Unity Profiler を用いて、このメモリのコンテンツを検証したりサンプリングすることもできます。このメモリは、JavaScript コードのバイトの TypedArray として作成され、ブラウザーはこのサイズの連続したメモリのブロックを割り当てる必要があります。このスペースはできるだけ小さい方がいいですが (メモリが断片化されていても、ブラウザが割り当てることができるように)、コンテンツのシーンの再生に必要なすべてのデータに対応できる大きさが必要です。
Unity WebGL のビルドを作成する際、 Unity はコンテンツに必要なすべてのシーンとアセットを持つ .data ファイルを書き出します。WebGL には実際のファイルシステムがないため、このファイルはコンテンツの開始前にダウンロードされ、コンテンツが実行されている間はずっと非圧縮状態のデータがブラウザーメモリの連続したブロックに保持され続けることになります。そのためダウンロード時間とメモリ使用量の削減を両立するには、このデータをできる限り少なくするよう心掛けるといいでしょう。アセットのビルドサイズを最適化する方法についての情報は ファイルサイズの削減 を参照してください。
読み込み時間とメモリ使用量を減らすために他にできることは、アセットデータを アセットバンドル にまとめることです。そうすることでアセット読み込みのタイミングを完全に管理することができ、必要なくなったタイミングで破棄して使用されていたメモリを解放することもできます。 AssetBundle は直接 Unity ヒープに読み込まれ、ブラウザーによる追加の割り当てが発生することはありません。(WWW.LoadFromCacheOrDownload を使用して AssetBundle をキャッシングする場合はこの限りではありません。WWW.LoadFromCacheOrDownload は、ブラウザーの IndexedDB によるメモリにマッピングされた仮想ファイルシステムを使用するためです。)
Unity WebGL ビルドでメモリ関係のエラーが出た場合、ブラウザーがメモリの割り当てに失敗しているのか、Unity WebGL ランタイムが Unity ヒープの事前に割り当てられたブロック内で空いているブロックへの割り当てに失敗しているのかを理解することが重要です。ブラウザーがメモリの割り当てに失敗している場合、例えば Unity ヒープのサイズを削減するなどして、上記のメモリエリアのサイズ削減を試みるといいかもしれません。一方で、 Unity ランタイムが Unity ヒープ内のブロックへの割り当てに失敗している場合、逆にそのサイズを増やすといいかもしれません。
Unity は、エラーメッセージが上のどちらなのかを理解しようと試みます (そしてどうしたらいいかを提案します)。ブラウザーごとにメッセージの表示方法が違うため、常に簡単というわけではなく、すべてを理解できないかもしれません。“Out of memory” (メモリ不足) エラーがブラウザーで表示された場合、実行中のブラウザーがメモリ不足の問題を抱えている可能性があります (この場合 Unity ヒープのサイズを小さくするといいかもしれません)。また、 Unity コンテンツを読み込んでいるときに、人間に理解可能なエラーメッセージの表示なしにブラウザーがクラッシュする場合があります。これには多くの理由が考えられますが、よくあるものとしては JavaScript エンジンが生成されたコードをパースし、最適化するためにあまりに多くのメモリが必要だということです。
サーバーはコンテンツの Large-Allocation http ヘッダーを生成することがあります。これはサポートされているブラウザー (現在 Firefox のみ) にメモリが必要としているものを伝え、分割されていないメモリ空間で新しい処理を発生させたり、大きなメモリ割り当てが成功するように雑多な作業を行ったりします。こうすることにより、特に 32 ビットブラウザーで Unity ヒープを割り当てようとするときに、ブラウザーがメモリ不足になる問題を解決できます。
Unity にマネージオブジェクトを割り当てる場合、使われなくなったものはガベージコレクトされる必要があります。詳しい情報はドキュメントの automatic memory management を参照してください。 WebGL でも同じことが言えます。マネージオブジェクト、ガベージコレクトされたメモリともに Unity ヒープ内に割り当てられます。
しかし、WebGL で気を付けなければいけないのは、ガベージコレクション (GC) を実行するタイミングに注意が必要なことです。ガベージコレクションを実行するために、通常 GC はすべてのスレッドの実行を一時停止し、スタックを精査し読み込み済みオブジェクトの参照を登録します。これは現在の JavaScript では不可能なことです。このため WebGL で GC はスタックが空になった場合にのみ実行されます（現在これは毎フレーム後に 1 度行われます）。この仕様はほとんどのマネージメモリを保守的に扱うコンテンツでは問題になりません。そして、相対的に多めの GC 割り当てがフレームごとに行われます (Unity プロファイラーを用いてデバッグすることができます)。
ただし、次のコードは WebGL での実行に失敗します。なぜなら、ループの反復の間に GC を実行する機会がなく、すべての中間の文字列オブジェクトによって使用されているメモリ (最終的には、Unityヒープのメモリが不足する原因になります) を解放するためです。
string hugeString = "";
for (int i = 0; i < 100000; i++)
{
hugeString += "foo";
}
2018–08–23 修正されたページ