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 で明示的にラップされたコードのタイミングだけでなく、コードのすべての部分をプロファイルします。これは、アプリケーションの起動時間を詳細にプロファイルするのに便利です。ただし、これは、ビルドにわずかな負荷を加えます。
Build Settings で Autoconnect Profiler の設定を有効にしていない場合、アプリケーションを実行しているプラットフォームに手動で接続することができます。アプリケーションがプレイヤーで実行されている間は、Profiler ウィンドウの Attach to Player ドロップダウンにプレイヤーが表示されます。Attach to Player ドロップダウンには、ローカルネットワーク上で動作しているすべての Unity プレイヤーが表示されます。これらのプレイヤーは、その種類と、それを実行しているホスト名 (例えば “iPhonePlayer (Toms iPhone)” など) で識別できます。
プレイヤーの IP アドレスを使って直接プレイヤーに接続することもできます。これを行うには、Attach to Player メニューを選択し、ドロップダウンで <Enter IP> を選択します。ダイアログボックスが表示されるので、接続したいプレイヤーの IP アドレスとポート(必須ではありません) を入力します。
アプリケーションのプロファイル情報の収集を開始するには、ドロップダウンメニューからプレイヤーを選択して Record をクリックします。アプリケーションの実行中に継続してデータを収集するには、Player Settings (Edit > Project Settings > Player > Resolution and Presentation) で Run In Background の設定を有効にします。この設定を有効にすると、アプリケーションをバックグラウンドで実行したままにしていても、Profiler はデータを収集します。無効にすると、アプリケーションがアクティブなウィンドウで実行されているときにのみ、プロファイラーはデータを収集します。
プラットフォームを 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 では Chrome OS デバイスを自動検出できません。接続を開始するには、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 が使用するプロセスがプロファイリングデータに影響を与えないようにするために、いくつか気を付ける点があります。