あなたの世界を管理する
テストと最適化
最適化ガイド
14min
- ZEPETOは、世界で使用されるリソースをメモリにプリロードするように構成されています。
- 世界の1.7.0に基づくと、最低仕様のデバイスはiPhone 8（2GB RAM）とGalaxy S8（4GB RAM）です。
- したがって、2GBを超えないようにする必要があります。
- 最低仕様の機器は後で変更される可能性があります。
- マルチプレイヤーの世界の場合、各キャラクターがメモリを持っているため、最大人数を考慮してメモリを管理する必要があります。
- ZEPETOが公式に提供する公式のランタイムプロファイラーを使用してください。
📘 以下のガイドを参照してください。 [ランタイムプロファイラ]
VS Codeをスクリプトエディタとして使用している場合、プラグインを通じてローカル開発環境サーバーのCPU使用率、メモリ使用率などのさまざまなパフォーマンス指標を確認できます。
📘 UnityでVS Codeをスクリプトエディタとして設定する方法については、以下のガイドを参照してください。
1) VSCode画面の左側にある[拡張機能]パネルで、JavaScriptプロファイル用のFlame Chart Visualizerを検索してインストールします。
- プラグインによってチェックされたローカル開発環境のパフォーマンス指標は、実際のサービス環境と異なる場合があります。これを使用して、ワールドマルチプレイヤーサーバーロジックの概算パフォーマンストレンドと潜在的なパフォーマンス問題を理解してください。
- VS Codeの作業ディレクトリがワールドプロジェクトに設定されていない場合、プラグインは正しく動作しません。[Explorer]パネルで正しいプロジェクトフォルダーを選択してください。
2) VS Codeの[Run and Debug]パネルに移動し、デバッグタイプをZepeto Multiplay Scriptに変更します。
3) Unity画面の再生ボタンを押してワールドを実行し、VS Codeの[デバッグ開始]ボタンを押してランタイムデバッグを開始します。
[実行とデバッグ]パネルでマルチプレイヤーサーバーのパフォーマンス指標をリアルタイムで確認できます。
👍 ヒント
- [実行とデバッグ]パネルのパフォーマンスチャートの表示切替ボタンをクリックすることで、以下のパフォーマンス指標を追加できます。
- CPU使用率
- 使用ヒープ
- 合計ヒープ
- 常駐セットサイズ
- 外部メモリ
- ArrayBufferメモリ
以下の基準に従って最適化を行い、リリースされたワールドが最小仕様で動作することを確認してください。
- 最小仕様のデバイス（2GB RAM搭載）は、次の条件でクラッシュします：
- ランタイムプロファイラー > 割り当てられたメモリが550MBを超えた場合、平均して。
- ワールドが実際に動作しているとき、ワールドリソースだけでなく、さまざまなプロセスもメモリ内で動作しているため、割り当てられたメモリにいくらかのスペースを残すことをお勧めします。
- マルチプレイヤーワールドの場合、キャラクターごとにメモリが割り当てられるため、最大プレイヤー数に基づいてメモリを管理する必要があります。
- ZEPETOキャラクターごとの平均メモリ：35MB
- ZEPETOキャラクタータイプのマネキンを使用すると、1人のZEPETOキャラクターが入るときと同じメモリを占有します。
- 最適化のために、可能であればシンプルタイプのマネキンを使用することをお勧めします。
- 平均280MBで、最大8人が入るとき。
- これらは平均値です。可能であれば、実際に最大人数が入る前に割り当てられたメモリをテストしてください。
- 最大FPS制限は30FPSです。
- パッケージの容量は最大1GByteに制限されています。
- World 1.8.0によって提供されるクロスワールド移動機能を使用すると、容量の部分を間接的に解決できます。
- Unityの最適化に関する情報を参照してください。
- 未使用のパッケージフォルダーと未使用のファイルを削除してください。
- プロジェクト内のオブジェクトの数と地形内の木/プールの数を調整してください。
- コルーチンの使用：yieldはガベージを生成しませんが、新しいwaitForSecondsを作成するとガベージが生成されます。したがって、オブジェクトを作成して使用してください。
- Update( )内で、毎フレーム呼び出す必要のない部分を置き換えて、nフレームごとに呼び出せるようにします。
- Awake( )、OnEnable( )、Start( )内で重いロジック関数を呼び出すのを避けてください。
- 空の関数であってもUpdate( )やLateUpdate( )を残すのを避けてください。
- ランタイムでコンポーネントを追加するのを避けてください。必要な場合は、プレハブをインスタンス化する方が効率的です。
- GameObject.Find、GameObject.GetComponent、Camera.mainは高コストなので、Update()から呼び出さず、必要な場合はStart()から呼び出してください。
- Instantiateとdestroyはガベージを生成し、ガベージコレクションがプロセスを遅くします。代わりに、プールを使って再利用を試みてください。
- Renderer.materialは可能な限りRenderer.sharedMaterialを使用して、バウンドオブジェクトのマテリアルにアクセスしてください。新しいコピーを作成して返すのは高コストです。
- 目的に応じてキャンバスを分割し、使用しないキャンバスを非表示に設定します。
- GraphicRaycasterを制限し、Raycast Targetをクリアします。キャンバスからGraphicRaycasterを削除し、ボタンなどの個々の要素にGraphic Raycasterを別々に挿入します。
- テキストや画像にRaycast Targetが必要ない場合は、削除します。
- 動的UIでない限り、Layout Groupsの使用は避けます。アンカーを使用して整理します。
- 大きなリストやグリッドビューはコストがかかるため、使用を避けます。
- フルスクリーンUIを使用する際は、このキャンバス以外はすべて隠します。これにより、カメラが3Dシーンをレンダリングする必要がなくなります。また、不必要なキャンバスも隠れます。
- フルスクリーンUIを使用する際は、Application.targetFrameRateを下げます。60fpsで更新する必要はありません。
- World Spaceを使用するキャンバスのレンダーカメラに空白のスペースを残さず、使用するカメラで埋めます。
- 空白を残すと、Unityが自動的にcamera.mainを埋めます。
- 音声クリップをモノラルに変更する。
- WAVファイルの使用を可能にします。圧縮された音楽ファイルは、ビルド時に解凍され、その後再圧縮されます。このプロセス中に音楽ファイルの品質が劣化します。
- クリップを圧縮し、圧縮ビットレートを下げる。
- Vorbisを使用するファイルを大部分使用し、短い音をADPCMに変更する。
- 22,050 Hzを超えないようにする。
- 適切なロードタイプを選択する。
- サイズが200 kb以下の音楽ファイルは、ロード時に解凍する。
- サイズが200 kb以上の音楽ファイルは、メモリ内で圧縮されたままにする。
- 大きなファイルとバックグラウンドミュージックをストリーミングに設定する。
- ミュートされた音楽ファイルは、単に音量をゼロにするだけでは終了しないので、必ず破棄されることを確認する。
