測定器によるプロファイリング

エンタープライズ・サポート・チームでは、多くのiOSプロジェクトを見ています。iOSの開発では、開発者がゲームを動かしてみて「なんでこんなに動作が遅いんだ？世の中にはパフォーマンスを分析するための素晴らしいツールがいくつかあるが、その中でも特に優れているのがInstrumentsだ。自分の課題を見つけるための使い方を知るには、続きを読む！

InstrumentsやXCodeのデバッグツールを使用するには、iOSビルドターゲット用にUnityプロジェクトをビルドする必要があります（開発ビルドとスクリプトデバッグオプションのチェックは外してください）。次に、XCodeプロジェクトをリリースモードでコンパイルし、iOSデバイスにデプロイします。

Instrumentsを起動したら（再生ボタンを長押しするか、Products>Profileを選択）、Time Profilerを選択します。プロファイリングの実行を開始するには、アプリケーションセレクタからビルドしたアプリケーションを選択し、赤いRecordボタンを押します。Instrumentsが接続されたiOSデバイス上でアプリケーションが起動し、Time Profilerがテレメトリーの記録を開始します。テレメトリーは、インストルメンツのタイムライン上に青いグラフで表示されます。

P.S.コール階層を整理するには、[Details]ペインの左下にある[Call Tree]ボタンを押してオプションを表示し、[Flatten Recursion]と[Hide System Libraries]を選択します。

メソッドコールのリストは、Instrumentsウィンドウの詳細セクションに表示されます。各トップレベルのメソッド呼び出しは、アプリケーション内のスレッドを表す。

一般的に、メイン・メソッドは、すべてのマネージド・コードが含まれているため、関心のあるすべてのホットスポットの位置となる。

mainメソッドを展開すると、メソッド呼び出しの深いツリーが得られる。大きく分けると、2つの方法がある：

• startUnity]と[UnityLoadApplication]（これらのメソッド名はALL CAPSで表示されることがあります）。
• PlayerLoop

[startUnity]は、Unityエンジンの初期化に費やされたすべての時間を含むため、興味深い。その下にUnityLoadApplicationというメソッドがある。起動時間をプロファイリングできるのはUnityLoadApplicationの下です。

アプリケーションのタイムスライスができたら、プロファイラを一時停止し、ツリーの展開を開始する。ツリーを下っていくにつれて、左側の列のミリ秒単位の時間が短くなっていくのがわかるだろう。探しているのは、大幅な時間短縮をもたらすアイテムだ。ここはパフォーマンスのホットスポットになるだろう。一度見つかれば、コードベースに戻り、時間がかかっている原因を突き止めることができる。それは完全に必要な作業であったり、遠い過去に本番前のコードをハッキングして本番プロジェクトに持ち込んだり、あるいは......まあ......本当にいろいろな理由が考えられる。このホットスポットをどのように修正するかは、コードベースを誰よりもよく知っているあなた次第だ。

インストゥルメントを使えば、広範囲に分散しているパフォーマンス・シンクを探すこともできる。つまり、単一の大きなホットスポットがない代わりに、コードベースのさまざまな場所で数ミリ秒のロスタイムとして現れるようなものだ。これを行うには、Instrumentsのシンボル検索ボックスにファンクション名の一部または全部を入力します（⌘Fを押すか、EditメニューのFind/Find...をクリックすると表示されます）。ゲームプレイのスライスをプロファイリングする場合は、PlayerLoopを展開し、その下にあるすべてのメソッドを折りたたむ。起動時間をプロファイリングする場合は、UnityLoadApplicationを展開し、その下のメソッドを折りたたみます。PlayerLoopまたはUnityLoadApplicationに費やされた時間の合計を見て、self列にあるミリ秒数を差し引くことで、特定の操作で浪費されたミリ秒の合計数を大まかに見積もることができます。

一般的な探し方

• "box("、"box"、"box" - これらは、C#の値のボックス化が行われていることを示す。
• 「Concat" - 文字列の連結は、しばしば簡単に最適化される。
• "CreateScriptingArray" - 配列を返すすべてのUnity APIは、配列の新しいコピーを割り当てます。これらのメソッドの呼び出しを最小限に抑える。
• 「反省」-反省は遅い。これを使って反射によるロスタイムを見積もり、可能な限り排除する。
• "FindObjectOfType" - FindObjectOfTypeや他の遅いUnity APIへの繰り返しの呼び出しや不必要な呼び出しを見つけるために使用します。
• 「Linq"-Linqクエリの作成と破棄で失われる時間を調べ、ホットスポットを手動で最適化したメソッドに置き換えることを検討する。

CPU時間のプロファイリングだけでなく、Instrumentsではメモリ使用量のプロファイリングも可能です。InstrumentsのAllocationsプロファイラには、アプリケーションのメモリ使用状況を詳細に表示する2つのプローブがあります。アロケーション・プローブは、特定の時間帯にメモリ内に常駐しているオブジェクトを検査することができる。VM Trackerプローブは、iOSがアプリケーションの強制終了のタイミングを判断するために使用する主要な指標である、ダーティ・メモリ・ヒープ・サイズの監視を可能にする。

InstrumentsでAllocationsプロファイラを選択すると、両方のプローブが同時に実行されます。いつものように、赤い録画ボタンを押してプロファイリングを開始する。

アロケーション・プローブを正しくセットアップするには、以下の設定が正しいことを確認してください。ウィンドウの下部で、「Allocation Lifespan」（中央のオプション）が「Created & Persistent」に設定されていることを確認します。Recording Options（Fileメニュー）で、Discard events for freed memoryがチェックされていることを確認する。

メモリーの動作を調べるのに最も便利なのは、Statistics（統計情報）表示であり、Allocations（割り当て）プローブを使用するときのデフォルト表示である。タイムラインが表示される。推奨される設定で使用すると、グラフには、現在まだ生きているメモリ割り当ての時間と大きさを示す青い線が表示される。このグラフを見ることで、テスト中のシナリオを繰り返し実行し、実行の間に青い線が生きていないことを確認するだけで、長く生き続けるメモリーやリークしたメモリーを監視することができる。

もう一つの便利な表示は、コールツリー表示である。アロケーションが実行されたコード行と、そのコード行が担当したメモリ消費量が表示される。このように、「詳細」の右をクリックすることで表示を変更することができる：

下の図を見ると、テスト対象のアプリケーションの総メモリ使用量の約25％がシェーダーのみに起因していることがわかる。シェーダーの位置がローディングスレッドにあることから、これらはデフォルトのUnityプロジェクトにバンドルされている標準的なシェーダーで、アプリケーションの起動時にロードされるのでしょう。

これまでと同様、ホットスポットを特定したら、それをどうするかはプロジェクト次第だ。

そうだ。インストゥルメントの簡単なガイド。1000語でA-Teamへの言及はなし。前回のようなトラブルは避けたい。著作権違反は公式にはNot Funny™である。

エンタープライズ・サポート・チームはこれらのガイドをさらに作成中で、今後数ヶ月のうちにベスト・プラクティス・ガイドの完全版を掲載する予定です！

私たちは計画がまとまるのが大好きだ。