よって翻訳されました。必要に応じて、コンテンツの保存と分類を行います。ThompsonX測定できなければ、改善はできません。ゲームの実行速度を上げるには、まずパフォーマンスのボトルネックを特定する必要がありますが、その作業は簡単ではありません。アクティビティ内の微妙な違いを把握する必要があります。ツールは、パフォーマンスの改善を目的として急いでいる回避策を回避するための分析情報を提供します。これは本質的には意図的な推測によるものです。各フレームで何を行っているかをより明確に把握でき、この情報を使用してゲームを最適化できます。一定期間のすべてのアクティビティを確認できます。最初はあまりに粒度が良くないので、大変に感じるかもしれません。使用してパフォーマンスを追跡できます。手動でインストルメント化する方法については、後述のセクションをご覧ください)。トレース情報を取得することもできます。デバッグについては今後の記事で取り上げますが、当面はこちらのドキュメントをご覧ください。トレースビューを表示するには、「about:tracing」と入力します。アドレスバーに入力します。type="x-smartling-placeholder"></ph>「about:tracing」と入力します。アドレスバーにトレースツールから、記録を開始し、ゲームを数秒間実行して、トレースデータを表示できます。以下は、データの例です。type="x-smartling-placeholder"></ph>シンプルなトレース結果うん、わかりにくいですね。その読み方を見ていきましょう。各行はプロファイリングされるプロセスを表し、左右の軸は時間を示し、色の付いた各ボックスはインストルメンテーションされた関数呼び出しを示します。さまざまな種類のリソースの行があります。タブ自体を含む)が含まれます。行を特定することです。ポイントを使用してコードを手作業でインストルメント化している場合は、トレースデータを含む行を探す)以外に、アプリケーションを選択する洗練された方法はありません。メインループを実行しているようです。見つけやすくなります。行が引き続き存在する可能性があります。フレームを探していますゲームのトレースツールで正しい行を見つけたら、次のステップはメインループを見つけることです。メインループは、トレースデータ内の繰り返しパターンのように見えます。キーでデータをズームインまたはズームアウトできます。ミリ秒ごとに繰り返されるパターンであることが予想されます。つの実行フレームがあるように見えるゲームがどこで動作しているかがわかれば、各フレームでコードがどのような処理を行っているかを詳しく調べることができます。使用してズームインします。type="x-smartling-placeholder"></ph>実行フレームの詳細この一連のボックスは一連の関数呼び出しを示し、各呼び出しは色付きのボックスで示されます。呼び出したことがわかります。このデータを読み取ると、何が何と呼ばれ、各実行にどのくらいかかったかを完全に把握できます。ここで少し厄介な問題が生じます。ソースコードからの未加工の関数呼び出しです。フレンドリーとは言えません。フレームの全体的なフローを確認することは有用ですが、実際に何が起こっているのかを理解するには、人間が読み取れるものが必要です。console.timeEnd)があります。console.time("update");update();console.timeEnd("update");console.time("render");update();console.timeEnd("render");上記のコードでは、指定されたタグを持つトレースビュー名に新しいボックスが作成されるため、アプリを再実行すると「update」と表示されます。「render」を指定します。ボックスには、各タグの開始呼び出しから終了呼び出しまでの経過時間が表示されます。type="x-smartling-placeholder"></ph>手動で追加されたタグこれを使用して、人が読める形式のトレースデータを作成し、コード内のホットスポットを追跡できます。バウンドなのか、ということです。ロジックを実行します。つのリソース間で作業のバランスがどのようにとれているかを確認する必要があります。いう名前の行を探します。ビジーかどうかを示しています。処理が発生していることがわかります。フレームのほとんどでアイドル状態である非常にシンプルなユースケースを示しています。トレースビューは、ゲームの実行速度が遅く、どのリソースが最大限まで使用しているか不明な場合に役立ちます。線の関連性を確認することが、デバッグの鍵となります。先ほどと同じ例を使って、更新ループに少し処理を追加します。time));console.timeEnd("update");console.time("render");render();console.timeEnd("render");次のようなトレースが表示されます。Hz)かかっていることがわかります。更新ボックスの横にレンダリング機能を表す色付きのボックスが並んでいますが、更新自体がフレームの大部分を占めています。アイドル状態のままであることがわかります。移動してリソースを最大限に活用できます。負荷がかかりすぎる場合はどうでしょうか。シェーダーのコードに処理を追加するとどうなるでしょうか。シェーダーを示します。}}このシェーダーを使用したコードのトレースは、どのようなものになりますか。トレースここでも、フレームの長さに注意してください。フレームレート)です。行はほぼ完全に空になっています。過負荷状態になっています。これは、シェーダーが重すぎることを示しています。更新が観察され、ゲームコードを調べてゲームロジックの最適化または削除を試みたくなるかもしれません。この場合、ゲームループ内のロジックが時間を浪費しているわけではないため、まったく意味がありません。処理を行うと本質的に「解放」状態になるということです。アイドル状態で待機しているため、処理を増やしてもフレームの所要時間に影響しません。実例では、実際のゲームのトレースデータがどのようなものか確認してみましょう。テクノロジーで構築されたゲームの素晴らしい点の一つは、お気に入りのプロダクトで何が起こっているかを確認できることです。プロファイリングできます。取得したトレースの例です。