Unity3d上のWebGL-プロジェクトをビルドする際の12の問題

少し前まで、Unityはベータ版からWebGL用のプロジェクトを作成する機能を持ち出しました。 このプラットフォームで大規模なゲームプロジェクトを組み立てた経験を共有しています。

免責事項：この記事は、似たようなことをする人のみを対象としています-非常に技術的であり、Unity固有の用語を使用しています。

1.リフレクションによるタイプのロード

最初の問題：この単純なコードは正しく動作しません：

var type = Type.GetType("TypeName"); 

動作しますが、型は正しくない「空」を返します。 この型を使用すると問題が発生します-ほとんどすべてのメソッドが空の値を返します。 すべてを正しくするには、次のように書く必要があります。

  var assembly = Assembly.Load("Assembly-CSharp"); //   assembly var type = assembly.GetType("TypeName"); 

ここでは、これが予想される動作であると述べられています。

2.動的なリソースの読み込み

Resources.LoadまたはResources.LoadAllメソッドを使用すると、次の問題が発生します。 これらのメソッドは途方もなく長く機能します。 シングルスレッドブラウザの場合、これは簡単に重要になります。 これらのメソッドおよび同様のメソッドを使用した動的リソースのロードは、まったく使用しない方がよいでしょう。 可能な場合は、静的に変更する必要があります（事前に必要なプレハブへのリンクを配置します）。 プロジェクトの読み込み時間の差は10秒に達しました。

3.ファイルシステムの同期

ファイルシステムを使用する場合、ブラウザに組み込まれたデータベースのラッパーとして実装されていることを知っておく必要があります。 しかし、最も重要なことは、ブラウザーが直接javascriptコマンドによってのみこのデータベースと同期されることです。

 FS.syncfs(false,function (err) { //alert('syncing fs'); }); } 

呼び出さないと、ブラウザをオフにした後、データが保存されない場合があります。 次のように呼び出すことができます。

1）これをWebGLテンプレートに追加します：

 <script type = "text/javascript" language = "javascript" > function SyncFiles() { FS.syncfs(false,function (err) { //alert('syncing fs'); }); } </script> 

2）c＃から呼び出します：

 private void Sync() { #if UNITY_WEBGL Application.ExternalCall("SyncFiles"); #endif } 

4. WebGLの初期化とシェーダーのコンパイル

アプリケーションの起動時に、WebGLの初期化にはかなりの時間がかかる場合があります。 これは非常に重要です。なぜなら、この時間は、スクリプトが連続して実行される合計時間でブラウザーに考慮されるためです（Firefoxでは、デフォルトでは10秒です）。

WebGLを初期化する主な時間は、シェーダーのコンパイルです。 さらに、ステージ上またはシーンから参照されるプレハブ内にあるシェーダーのみがコンパイルされます。 （私のように）さまざまなソースからさまざまなアセットをゲームに取り込んだ場合、シェーダーが大量になり、そのコンパイルに10秒以上かかることがあります。

何をする必要がありますか？

1）プロジェクトで使用されるさまざまなシェーダーの数を最小限にします。 多くの場合、プロジェクトでは、購入したさまざまなアセットから取得したほぼ同じシェーダーを使用します。

2）これで十分でない場合、一部のアセットを動的にロードされたリソースまたはバンドルに転送する必要があります。 はい、静的ロードよりも長くなります。 ただし、動的なロードを遅延させてアセットをパーツにロードすると、各パーツのロードに正確に10秒しかかかりません。 その結果、合計読み込み時間が長くなります。 ただし、少なくともブラウザは、ハングしたスクリプトを停止するためのプレーヤーの侵入を提供することを停止します。

どのシェーダーがどのアセットで使用されているかを理解するには、スクリプトを書くのが便利です。

5. Firefoxキャッシュ

ローカルサーバーとFirefoxを使用してプロジェクトをデバッグする場合、ブラウザーがWebGLプロジェクトの一部を誤ってキャッシュするという事実に遭遇します。

シナリオは次のとおりです。

バージョン1を作成して実行します。動作します。 次に、バージョン2を作成します。起動すると、理解できないエラーが発生してクラッシュします。

次の場所でFFキャッシュを手動でクリーニングすることで処理されます。

1）C：\ Users \ {NAME} \ Application Data \ Mozilla \ Firefox \ Profiles \ {PROFILE NAME} \ storage \ temporary \

ここでは、すべてをすべて削除できます。

2）C：\ユーザー\ {名前} \アプリケーションデータ\ Mozilla \ Firefox \プロファイル\ {プロファイル名} \ストレージ\デフォルト\

ここでは、サイトのみを削除する必要があります。 例えば

「Http +++ 127.0.0.1 + 7888」

注：これは、HTTPサーバーで作業している場合にのみ発生します。 ファイルからプロジェクトを開始する場合、各ファイルパスのキャッシュが異なるため、エラーは発生しません。 ただし、サーバーの場合、パスに関係なく1つのキャッシュ。

6.スクリプトが長時間応答しません。 やめて？

Firefoxはほぼ確実にこれについて尋ねます。 プロジェクトが大きい場合は、何度か尋ねることがあります。

この問題の一部は、WebGLの初期化に関する段落で説明しました。 ただし、WebGLプロジェクトがどのように読み込まれ、フリーズされたスクリプトを撮影するかどうかをブラウザが考慮する時間を理解することが重要です。

スタートアップステージ：

1）ブラウザがサーバーからデータをダウンロードしています。 ここでは何も加速できませんが、今回はブラウザが制限しません。

2）データの圧縮解除が進行中です。

例：

解凍リリース/ 100msでw69.memgz。 gzip圧縮を使用してファイルをホストするようにWebサーバーを構成する場合、この遅延を削除できます。 UnityLoader.js：1：775
解凍されたリリース/ 391msでw69.jsgz。 gzip圧縮を使用してファイルをホストするようにWebサーバーを構成する場合、この遅延を削除できます。 UnityLoader.js：1：775
2764msで解凍されたリリース/ w69.datagz。 gzip圧縮を使用してファイルをホストするようにWebサーバーを構成する場合、この遅延を削除できます。

説明からわかるように、適切なサーバー構成を使用すると、解凍はその場で行われ、この時間はゼロになります。 いずれにせよ、それも制限されていません。

3）Asm.jsがコンパイルされています。

正常にコンパイルされたasm.jsコード（合計コンパイル時間9088ms、キャッシュに保存）1 56937f89-a8fd-4b65-94aa-453e33be78d8

ゲームコードはまだ開始されていないため、5〜10秒かかりますが、ブラウザに限定されません。

4）そして、ゲームコードが始まります

また、ブラウザーの観点から見ると、Unityコード（WebGL初期化など）はゲーム自体のコードと変わりません。 さらに、それらは1つのピースで連続して実行されます。 したがって、WebGLの初期化とユーザーコードは10秒で渡されます。 WebGLの初期化時間は通常、優れたコンピューターでは4〜5秒以上短縮できないことを考慮すると、リスクを回避し、ユーザーコードの初期化時間を最小限に抑えることをお勧めします。 理想的には、彼は何もするべきではありません。 しかし、ゲームを初期化する方法は？ 延期することができます。 たとえば、次のように：

  void Awake() { DontDestroyOnLoad(gameObject); StartCoroutine(Init()); } IEnumerator Init() { yield return new WaitForSeconds(0.1f); //  } 

ポイントは、すぐに制御をブラウザに戻し、0.1秒でコードを実行することです。 このようなトリックの後、ブラウザは再び10秒のカウントダウンを開始します。 したがって、初期化が長い場合は、同じ方法で部分に分割し続けることができます（ただし、初期化を減らすことをお勧めします-ユーザーは待つのを嫌います）。

最後に、連続スクリプト実行の10秒の制限は、初期化中だけでなく適用されます。

7.バンドルの使用

アセットバンドルを使用する場合、ゲーム自体と同じサーバーからダウンロードする必要があることに注意することが重要です。 そうしないと、単一オリジンポリシーに違反するため機能しません。

2番目のポイントは、ロード後のバンドルの解凍の遅延を回避するために、バンドルの作成時にgz（デフォルト）ではなくlz4を使用することをお勧めします。

 // ChunkBasedCompression (   lz4) BuildPipeline.BuildAssetBundles (outputPath, BuildAssetBundleOptions.ChunkBasedCompression, EditorUserBuildSettings.activeBuildTarget); 

8. 512 mbの制限

私のマシンでは、ブラウザはゲームに512MB以上を割り当てることができませんでした。 マシンには多くのメモリがありますが。 WebGLでコンパイルされたゲームに512MB以上のメモリを割り当てる必要はないと思います。 そして、ゲーム自体はそれが十分であるように行われる必要があります。 理想的には、通常はデフォルトで256MBのままにします。

9.ストリップエンジンコード

ストリップエンジンコードはビルド設定のチェックマークであり、Unityはアセンブリから未使用のシステムスクリプトを破棄します。
これにより、アセンブリの総体積を大幅に削減できます。 ここでの問題は、一部のコードがバンドルに入るアセットによってのみ使用される場合、それもスローされることです。 そして、最終アセンブリは機能しません。 そして例外は絶対に理解できないでしょう。

結論：

1）理解できない例外が発生した場合は、このチェックマークを外して収集してみてください。
2）コード内のバンドルのアセットに必要なスクリプトを直接使用するか、特別なUnity機能であるlink.xmlファイルを使用できます。

10.開発者ビルド-高速ビルドはありません！

開発者ビルドをビルドする場合、クイックビルドと高速実行のいずれかを選択できます。 実際、高速アセンブリはほぼ同じ（膨大な）時間を要し、同時に、メモリ不足のために大規模なプロジェクトではまったく機能しないことがよくあります。 使わないほうがいい

11.クランチテクスチャ

WebGLのプロジェクトでは、常にクランチテクスチャを使用します。 そうしないと、ゲームのボリュームがWebアプリケーションに対して不当に大きくなります。
各テクスチャのタイプを手動で設定しないために、この手法を使用できます（OnPostprocessTextureメソッドをオーバーロードする必要があります）。

しかし、12番目の問題はありません。「12個の問題」は11個よりも適切に聞こえます。

2017年6月1日からの更新：

まだ12番目の問題があります。 UnityプラグインとWebGLプラグイン間で文字列パラメーターを渡すことに関連付けられています。 Unityからwebglに文字列を渡すことはうまく機能しています。 しかし、反対に-常にではありません。
Unityは、次のようなスニペットの使用を推奨しています。

var buffer = _malloc（val.length + 1）;
writeStringToMemory（val、buffer）;

ここで、valはjavascriptの文字列です。
これは、文字列の長さがその中のバイト数と一致する限り機能します。 行に非バイト文字（ロシア語など）が見つかるとすぐに、このコードにより、割り当てられたメモリの外側に書き込みが行われます。これは、任意の場所でアプリケーションがランダムにクラッシュすることで表されます。

そのため、文字列がlatin1の文字のみを使用するようにエンコードを使用するか、文字列内の文字ではなくバイト数を使用するようにこのスニペットを書き換えます。