WebGL
Q1：現在、H5ゲームに変換する必要があるSpineを使用した2Dプロジェクトがありますが、Unityを使用してWebGLプロジェクトを直接に開発する場合、パフォーマンスに関する注意事項を教えてください。
問題主はモバイルデバイスでこのプロジェクトを実行したいようです。私たちのプロジェクト（レース類）は、直接にUnity 5を使用してページゲームバージョンに変換しようとしましたが、PCプラットフォームで実行していました。モバイルプラットフォームでは、他の人のプロジェクトを簡単に了解しました。当時に出た結論は、モバイルプラットフォームはハイレベルおよびミドルレベルのパフォーマンスに耐えません。これは自分でテストしていません。
私たちのプロジェクトがUnity5からPCページツアーへの変更過程に踏んだピットをリストして挙げます、参照してください。
1）WebGLはマルチスレッドとC＃ネットワークをサポートしていません。代わりに、CoroutineとWebsocketを使用できます。
2）一部のCoroutineの使用方法に問題があります。While（1）ような関数を使用して、アセットの読み込みが完了する前に待ちます。それは、他のプラットフォームでは問題ありませんが、WebGLでは、おそらくWebGLで無限ループが発生します。WebGLがマルチスレッドをサポートしていないことは原因かもしれません。
3）ゲームがアセットをロードする過程中に、占有メモリが増えると、時々にメモリがオーバーフローすることがあります。これは主に、アセットが最適化されていませんから。成熟なページゲームチームと連絡した時、相手はページゲームのメモリが256MBを超えてはならず、アセットのロードとリリースを注意深く制御する必要があると提案しました。
4）LZ4圧縮形式を使用することをお勧めします。WebGLはマルチスレッドをサポートしていませんから、LZMA圧縮されたBundleはメインスレッドが解凍中の遅い状況を引き起こします。
5）単一アセットのサイズは大きすぎないようにする必要があります。1MB未満に制御し、アセットをできるだけパッケージ化することをお勧めします。そうしないと、ロード時間が長すぎて体験に影響します。
5）単一アセットのサイズは大きすぎないようにする必要があります。1MB未満に制御し、アセットをできるだけパッケージ化することをお勧めします。そうしないと、ロード時間が長すぎて体験に影響します。
6）WebGLは中国語の入力をサポートしていません。ネイティブな方法で中国語の入力を実現しました。
7）PC端末で一部のブラウザはサポートしていません。テストしたサポートされているブラウザは次のとおりです。
●Google Chrome 9+
●Mozilla Firefox 4+
●Safari 5.1+（Mac OS Xシステムのみ、Windowsを除く）
●Opera 12 Alpha+
●IE9 +、ただしIEはWebGLをサポートしていませんが、プラグインIEWebGLをダウンロードしてインストールできます
8）アセットがインスタンス化されて使用されていない場合、エディターでクラッシュすることはありませんが、PCパッケージとエクスポートされたWebGLバージョンの両方がクラッシュします。
Monoメモリ
Q2：理論的には、Monoメモリは可能な限り小さく（UWAは40MB以内で制御することをお勧めします）、割り当て頻度は可能な限り低くします。では、一回のより大きなメモリ割り当てと頻度の高い（例えば毎フレーム）小さなメモリ割り当て、どちらがパフォーマンスへの影響は大きいですか？一回GCの時間コストは、全体的なMonoサイズに影響を受けますか、それともMono内引用されたオブジェクトの数量に影響を受けますか？簡単に言うと、フレームごとに割り当てられる小さなメモリと一回のより大きなメモリ割り当て、どちらの最適化作業を優先する方がいいですか？GCがマシンの発熱への影響は大きいですか？
①
フレームごとに割り当てられた小さなメモリの最適化を優先します。これはGCに大きな影響を与えます。 頻繁なGCは、実行のスムーズさにより大きな影響を与えます。全体から言うと、GCがパフォーマンスへの影響は大きくなく、一般的なオーバーヘッド（レンダリングモジュール、UIモジュールなど）よりもはるかに小さくなります。
一回の大きいMonoメモリ割り当てに対しては、2MB以上の割り当てを注意する必要があります。合理性を確認し、出来る限りに8MB以上の割り当てを避けます。最もめんどくさい問題はMonoメモリのピーク値を伸ばし、下がることはできないことです。
②
Monoメモリのピークは高く、最大の影響は、Monoメモリの占有量を上がり、Monoがシステムに申し込んだメモリは増加するだけであるということです。率直に言って、ゲームのメモリ使用量は増加しており、メモリの少ないデバイスではクラッシュしやすいというリスクがあります。
③
GC時間コストは必ず影響を受けます。現在、IL2CPPであろうとMonoであろうと、GCは世代別ではありません。つまり、リサイクル時にすべてのノードがトラバースされます。
アセット管理
Q3：コードをどのように分離しますか？ 複数の部門が一緒にゲームプロジェクトにアクセスする必要があるから、ソースコードを保護するために、技術以外の部門がゲームプロジェクトで暗号化されたDLLファイルのみを取得できることが望まれます。
最初の考えは、各部門が同じゲームプロジェクトを取り、その中、技術部門がソースコードを直接取得し、他の部門がDLLファイルを受け取り、技術部門がプログラムを書いて、DLLを生成して、他の部門に更新させるというものでした。ただし、UnityのスクリプトコンポーネントはGUID + FileIDの形式であるため、ソースコードを取る同僚が異なるスクリプトを持つなら異なるGUIDを得ますが、DLLを取る同僚は全員同じGUIDを手に入れます。その結果、異なる部門が同じプロジェクトで制作することはできなくなりました。
現在のやり方は、一つのコンパイルプロジェクトを別に作成して各プラットフォームに対応するDLLファイルを生成しますが、これはより面倒です。
PS：モジュールが分離されている場合でも、DLLをインポートすることはいくつかのcsファイルを更新することより時間をかかります。何かいい方法ありませんか？
①
私たちの会社では、これは部門の要件次第です。
1）アート部門は、常にUnityで効果をデバッグする必要があるため、この部門に暗号化されたDLLプロジェクトのみを提供し、ディレクトリを指定して対応するアセットを提出します。ツール操作のヒントも作成します。
2）企画部門に対して、Unityで効果を調整することは役割ではありません（これも会社次第です）から、ローカルLuaコードをロードできるexeパッケージを提供できます。運営部門に配置コードを提供させ、この部分のコードを企画さんに開放します、それともツールでexeにパッケージします。
一時的にこれだけ考えられます、参照してください。
②
「モジュールが分離されている場合でも、DLLをインポートすることはいくつかのcsファイルを更新することより時間をかかります。」これは多分、問題主はAssemblyInfoを付いていません。UnityがAPIをスキャンすることを導きます。このドキュメントを参照できます。
https://github.com/pangweiwei/slua/blob/master/Assets/Slua/Editor/LuaCodeGen.cs#L544
みんな全員が同じUnityバージョンを使ったら、スピードは速くなります。
もう一度PS、現在、一部のコードのためにそうなん面倒な方法を使うことは本当に低効率です。
③
ビジネスロジックが全てLuaにある場合は、Luaのbytecodeを暗号化することを選択できます。
ビジネスロジックもC＃で書いた場合は、暗号化しないことを選択できます。
実には、今の時代に、コードはそれほど価値がありません。 DLLを使用すると、他の部門の使用に面倒なところを増加させます。
アセット管理
Q4：複数の異なるシェーダーが同じcgincファイルを引用する場合、実際に何回コンパイルされますか？
①
私の理解では、cgincが含まれています。これは、コンパイラの前処理をコピーしてShaderファイルに貼り付けるのと同じで、cgincファイルは存在しないと認められます。だから、このcgincを含むShaderファイルがいくつかあり、何度かコンパイルします。
②
Cgincは単なるコード欠片です。Shaderが特定のcgincを使用すると、内部に対応する関数を抽出し、precompileの時に作業を完了します。だから、異なるシェーダーが同じcgincファイルを引用する場合、コンパイルでは、cgincファイル全体がコンパイルに参加するのではなく、シェーダーで使用されるコードの一部がコンパイルされます。
アニメーション
Q5：一つのアニメーションイベントに別のアニメーションオブジェクトをインスタンス化したところ（Animatorを使用）、インスタンス化されたオブジェクトが直接アニメーションを開始しなく、先にデフォルト姿態を示して、次のフレーム後からアニメーションを始めました。 これにどう対処するか？
アニメーションイベントは、アニメーションシステムが当該フレームのアニメーション計算（Animation Evaluation）を行った後にアクティベーションします。アニメーションイベントにアニメーションオブジェクトをインスタンス化する場合、このオブジェクトのanimatorは当該フレームでアニメーション計算を行いません、次のフレームまで待機します。アニメーションシステムがアニメーション計算を実行します。解決策は、アニメーションオブジェクトをインスタンス化した後にAnimator.Update（0）をコールすることです。
UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析と最適化ソリューション及びコンサルティングサービスを提供している会社でございます。
UWA公式サイト：https://jp.uwa4d.com
UWA公式ブログ：https://blog.jp.uwa4d.com