Unity Profiler を使ってアプリケーションをプロファイルする場合、データを記録する方法は主に 3 つあります。
アプリケーションの正確なタイミングを得るための最良の方法は、アプリケーションを公開する予定のエンドプラットフォームでプロファイルすることです。これにより、アプリケーションのパフォーマンスに影響を与えるものに関する、正確なタイミングを知ることができます。
ただし、アプリケーションのパフォーマンス要素を向上させたいと思うたびにアプリケーションをビルドすると時間がかかります。そこで、アプリケーションのパフォーマンスを素早く評価するために、エディターの再生モードで直接プロファイルすることができます。再生モードでのプロファイルは、実際のデバイス上でのアプリケーションのパフォーマンスを正確に反映するものではありませんが、最初にエンドプラットフォーム上でプロファイルした後に加えた変更によって、アプリケーションのパフォーマンスが改善されたかどうかを素早くチェックするのに便利なツールです。
Unity エディターは、再生モードで動作するときにアプリケーションと同じリソースを使用するため、アプリケーションのパフォーマンスに影響を与える可能性があります。そのため、エディターを個別にプロファイルして、使用するリソースを決定することもできます。これは、映画制作など、再生モードで使用するために設計されたアプリケーションの場合に特に有効です。
ターゲットのリリースプラットフォームでアプリケーションをプロファイルするには、ターゲットデバイスをネットワークに接続するか、ケーブルでコンピューターに直接接続します。また、IP アドレスを使ってデバイスに接続することもできます。アプリケーションは、Development Build としてのみのプロファイルできます。これを設定するには、Build Settings (メニュー: File > Build Settings) に移動し、アプリケーションのターゲットプラットフォームを選択し、Development Build の設定を有効にします。この設定を有効にすると、プロファイラーに関連する 2 つの設定 Autoconnect Profiler と Deep Profiling Support が利用可能になります。
Autoconnect Profiler 設定を有効にすると、Unity エディターはビルド処理中にビルドプレイヤーに IP アドレスをベイクします。プレイヤーを起動すると、ベイクした IP アドレスのエディターのプロファイラーに接続を試みます。
さらに、Deep Profiling Support 設定を有効にすると、ビルドされたプレイヤーの起動時に Unity が ディーププロファイリング を実行します。つまり、プロファイラーは、ProfilerMarker で明示的にラップされたコードのタイミングだけでなく、コードのすべての部分をプロファイルします。これは、アプリケーションの起動時間を詳細にプロファイルするのに便利です。ただし、これは、ビルドにわずかな負荷を加えます。
プロファイラーを使用して、アプリケーションを実行しているプラットフォームに手動で接続するには、Attach to Player ドロップダウンで設定します。Autoconnect Profiler が無効になっている場合のみ、この操作を行うことができます。
Attach to Player ドロップダウンに表示されるプラットフォームは、以下の条件を満たしている必要があります。
Attach to Playe ドロップダウンに Unity がネットワーク経由または直接接続によって検出したすべての Unity プレイヤーが表示されます。これらのプレイヤーは、Player Name (プレイヤー名) と、プレイヤーを実行している Product Name (例えば、“iPhonePlayer (My iPhone)” のようなプロダクト名) によって識別できます。
プレイヤーの IP アドレスを使って直接プレイヤーに接続することもできます。これを行うには、Attach to Player メニューを選択し、ドロップダウンで <Enter IP> を選択します。表示されたダイアログボックスで、接続したいプレイヤーの IP アドレスとポート(必須ではありません) を入力します。
アプリケーションのプロファイリング情報を収集するには、ドロップダウンメニューからプレイヤーを選択し、Record をクリックします。
アプリケーションの実行中に継続的にデータを収集するには、Player Settings の Run In Background 設定を有効にします (Edit > Project Settings > Player > Resolution and Presentation)。この設定を有効にすると、バックグラウンドでアプリケーションを実行し続ける場合でもプロファイラーはデータを収集します。これを無効にすると、プロファイラーは、 アプリケーションがアクティブなウィンドウで実行されている場合にのみデータを収集します。
Attach to Player ドロップダウンには、プレイヤーに関する情報を検索するために使用できる検索フィールドがあります。Player Name またはデバイスカテゴリ (例えば、Remote) を使って検索できます。カテゴリで検索すると、そのカテゴリーに属するすべてのデバイスが表示されます。
開発プレイヤーの名前を選択すると、プロファイラーに表示されます。
各コラムには、情報がある場合は、以下のような情報が表示されます。
プロパティ | 説明 |
---|---|
Player Name | アプリケーションを実行しているデバイスの名前。 この名前を変更するには、 Edit > Preferences > Analysis > Profiler に移動して、 Custom Connection ID フィールドに希望の名前を入力します。 また、 -connection-id 引数を使用して、コマンドラインからプレイヤーを起動するときに、一揃いの Player Name を設定することもできます。このプロパティのカテゴリの詳細は、プレイヤー名のデバイスカテゴリ を参照してください。 |
Product Name | これは、Project > PlayerSettings で設定したフィールドの値です。 |
IP | プレイヤーの IP アドレス。 |
Port | プレイヤーのポート。 |
Player Name カテゴリには、特定のデバイスタイプに関する情報を表示する以下のカテゴリがあります。
プロパティ | 説明 |
---|---|
Play Mode | 再生モードでアプリケーションをプロファイルする場合は、このプロパティを選択します。 |
Edit Mode | このプロパティを選択すると、Unity エディターをプロファイルします。 |
Local | このリストには、ローカルマシン、Unity エディター、スタンドアロンプレイヤーで動作しているあらゆるデバイスが含まれます。 また、ホストマシンにケーブルで物理的に接続されているプレイヤーの情報も表示されます。 |
Remote | このセクションは、ローカルネットワーク上で動作しているデバイスの情報を表示します。 このセクションは、Unity がローカルネットワーク上で動作しているリモートデバイスを検出した場合にのみ表示されます。 |
Connections without ID | このセクションは、Unity が Unity 2021.2 より古いプレイヤーを実行しているデバイスを検出した場合にのみ表示されます。 これらのプレイヤーには、Product Name、IP、または Port 情報がありません。 |
Direct Connection | このオプションを使うと、特定の IP とポートの組み合わせに接続できます。このカテゴリには、直近に接続した IP が表示されます。 |
プラットフォームを Unity Profiler に接続したときの動作は、プラットフォームごとに異なります。以下のセクションでは、各プラットフォームに共通する動作について説明します。
WebGL でも Unity プロファイラーを使用できますが、エディターを使用して WebGL で構築されたプレイヤーにアタッチすることはできません。これは、WebGL は WebSockets を通信に使用しているため、ブラウザー側の受信を許可しないためです。実行中のプレイヤーにアタッチするには、Build Settings (File > Build Settings) の Autoconnect Profiler チェックボックスを有効にする必要があります。Unity は WebGL のドローコールをプロファイルできません。
iOS デバイスと Android デバイスはどちらも、ネットワークを通じてリモートプロファイリングをサポートしています。ファイアウォールを使用している場合は、ファイアウォールの設定でポート番号 54998 から 55511 が開放されていることを確認します。これらは、Unity がリモートプロファイリングに使用するポートです。
リモートプロファイリングを設定すると、Unity エディターがデバイスに自動接続しない場合があります。これが発生した場合は、手動でプロファイラーの接続を開始できます。これを行うには、Profiler ウィンドウの Attach to Player ドロップダウンで適切なデバイスを選択します。
ターゲットデバイスを直接コンピューターに接続して、ネットワークや接続の問題を回避することもできます。
iOS デバイスでリモートプロファイリングを有効にするには、以下の手順を実行します。
Android デバイスは、Wi-Fi と Android Debug Bridge (adb) の 2 種類のリモートプロファイリング方法をサポートしています。
Wi-Fi プロファイリングは、以下の手順で行います。
ノート: デバイスの検出が正常に機能するためには、Android デバイスとホストコンピューター (Unity エディターを実行中) は、両方とも同じサブネット上になければなりません。
Android Debug Bridge (adb) プロファイリングは、以下の手順で行います。
Build & Run を選択すると、Unity エディターはアプリケーションのために自動的に adb トンネルを作成します。別のアプリケーションをプロファイルしたい場合や adb サーバーを再起動した場合は、このトンネルを手動で設定する必要があります。これを行うためには、ターミナル/コマンドウィンドウを開き、以下のコマンドを入力します。
エディターからアンドロイドへ USB ケーブルで接続している場合
adb forward tcp:34999 localabstract:Unity-{insert bundle identifier here}
Android からエディターへ USB ケーブルで接続している場合
adb reverse tcp:34998 tcp:34999
Android ビルドでディーププロファイリングを使用するには、Android Player Settings (Edit > Project Settings > Player > Android > Other Settings) で Mono Scripting Backend 設定を有効にし、以下を入力して adb コマンドでゲームを開始します。
~$ adb shell am start -n {ここにバンドルの識別子を入れる}/com.unity3d.player.UnityPlayerActivity -e 'unity' '-deepprofiling'
Unity では ChromeOS デバイスを自動検出できません。接続を開始するには、IP アドレスによって Android Debug Bridge (adb) を通してデバイスに接続してから、Attach to Player のドロップダウンから <Enter IP>
を選択し、デバイスの IP アドレスを入力します。接続したら、通常通りアプリケーションをプロファイルします。
Profiler ウィンドウを使用してエディターでアプリケーションの実行とプロファイリングを行う場合、結果は、ターゲットプラットフォームで実行したときのアプリケーションの動作の近似にすぎません。これは、再生モードはエディターと同じプロセスで実行されるため、アプリケーションの CPU、GPU、メモリ使用を Unity から完全に分離することができないからです。これにより、結果のプロファイリングデータがさらに歪められます。
より適切なプロファイル結果を得るには、常にターゲットデバイス上でアプリケーションをプロファイルし、エディターでのプロファイリングは、すでにデバイス上で特定された問題を素早く繰り返す目的でのみ行ってください。
また、再生モードでプロファイルしたりエディターをプロファイルして、アプリケーションのパフォーマンスとは関係のない問題 (ロード時間が長くなったり、エディターが反応しなかったりしてイテレーション時間が遅くなっていないかなど、プレイモードでのアプリケーションのパフォーマンスが悪くなっていないかなど) を特定することができます。
エディターでプロファイリングを行う際には、プレイモードを最大サイズで開き、エディターウィンドウの数を減らすようにしてください。これにより、他のエディターウィンドウがレンダリングスレッドや GPU の時間を消費しないため、パフォーマンスデータに影響を与えることがなくなります。プレイモードが最大サイズで表示されていると、ターゲットデバイスの解像度に近い状態でアプリケーションを実行するため、フィルレートに関連する問題のようなパフォーマンス問題に直接影響します。
プロファイラーのデフォルトのターゲットは再生モードで、エディターが再生モードを実行しているときのアクティビティを記録します。再生モードでのプロファイリングは、プレイヤーをリビルドすることなく迅速な変更をテストするのに便利ですが、アプリケーションのターゲットプラットフォームやデバイス上でのビルドを検証する代わりに使用すべきではありません。これは、再生モードがエディターと同じアプリケーションとメインスレッドで実行されているため、再生モードでプロファイルすると、UI、インスペクター、シーンビューレンダリング、アセット管理などのエディターのシステムが、アプリケーションのパフォーマンスとメモリーのプロファイリングの測定値に影響を与えるからです。
再生モードで効果的にプロファイリングを行うためには、定期的にアプリケーションのビルドを作成し、さまざまなターゲットデバイス (高スペックのデバイスと低スペックのデバイスの両方) にデプロイし、これらのデバイス上でアプリケーションのテストとプロファイリングを行う必要があります。これらのデバイスでアプリケーションのパフォーマンス問題が確認されたら、問題の領域を絞り込みます。
その後、再生モードでアプリケーションをプロファイルし、アプリケーションに変更を加えたら、素早くプロファイリングを繰り返します。ターゲットデバイス上のアプリケーションをプロファイルして得た情報を利用して、再生モードでプロファイルした後に同様の動作があるかどうかを確認できます。その後、アプリケーションに変更を加え、再生モードで再度プロファイルすれば、変更による効果をすぐに確認することができます。変更結果に満足したら、アプリケーションをビルドしてターゲットデバイスに再度デプロイし、変更内容を検証します。
再生モード中にエディターが作成するプロファイリングデータのノイズや誤解を招く測定値を減らすために、CPU と GPU のプロファイラーモジュールは、そのタイミングを PlayerLoop で発生するものと EditorLoop で発生するものに分けています。Unity は、これらのタイプのプロファイラーサンプルに PlayerLoop と EditorLoop のマーカー を割り当てます。
プロファイラーが再生モードをターゲットにする場合、PlayerLoop 内で発生したタイミングサンプルのみを収集します。
Unity は、CPU Profiler モジュールチャート で、EditorLoop のサンプルを Others として分類します。その結果、EditorLoop のサンプルがそのカテゴリ内で最大の割合を占めています。もし、この時間のエディターのアクションや、Others カテゴリの詳細な内訳を見たい場合は、代わりに Profiler のターゲットを Editor に変更してください。
重要: Deep Profiling を使用し、再生モードをターゲットにすると、PlayerLoop と EditorLoop の両方で発生するすべての関数の呼び出しにパフォーマンス上の影響を与えます。これは、Deep Profiling がドメインの再ロード時にスクリプトのメソッド呼び出しの最初と最後にフックするためで、どの部分が PlayerLoop から呼び出されないかを検出しないからです。EditorLoop で発生するメソッドの呼び出しは、サンプル作成のオーバーヘッドを完全には発生させませんが、サンプルを発行すべきかどうかをチェックするため、小さいながらもオーバーヘッドを発生させます。
Profiler のターゲットを Editor に変更すると、以前は EditorLoop マーカーの下に隠れていたすべてのサンプルが、それぞれのカテゴリに表示されます。これは、CPU Profiler モジュールの詳細ペインとチャートの情報が大きく変わることを意味します。
エディターの起動時間をプロファイルするには、コマンドラインオプション -profiler-enable
でエディターを起動します。
Profiler ウィンドウがエディターのパフォーマンスに与える影響を軽減するために、Profiler ウィンドウを独自のプロセスで開く スタンドアロンプロファイラー を使用することができます。これは、プロファイリングの対象としてエディターを選択する場合や、アプリケーションのディーププロファイリング を行う場合に特に便利です。なぜなら、通常、Profiler ウィンドウ自体が、パフォーマンスデータを歪める可能性のあるリソースを使用しているからです。
アプリケーションのプロファイルをする際、プロファイリングセッションの一貫性を確保し、Unity が使用するプロセスがプロファイリングデータに影響を与えないようにするために、いくつか気を付ける点があります。