quest-perf

Quest のパフォーマンス：予算、誤解、キャプチャ

Horizon OS でのパフォーマンス改善は、キャプチャを取らずに最適化するか、キャプチャを読み違えるかのどちらかで失敗します。このスキルでは、まず後者を解消します。プラットフォームで最もよく引用される数値である GPU% は、まさに重要な場面で誤解を招くためです。

製品全体のロードマップやステージ監査には quest-lifecycle を使用してください。単一の技術タスクは、この担当のまま進めます。存在しない場合は、現在のステージ、その根拠、次の前提条件をその場で示してください。

レンダリングパイプラインの選択や、タイル、レンダーパス、ジオメトリ、オーバードロー、アセットのコスト調査には references/mobile-rendering.md を読んでください。

予算は目標ではなく期限です

リフレッシュレート	フレームあたりの時間
72 Hz	13.9 ms
90 Hz	11.1 ms
120 Hz	8.3 ms

CPU、レンダースレッド、GPU、コンポジターの処理はパイプラインを形成し、フレーム間で並行して実行されることがあります。独立した CPU/GPU のサンプルを、汎用的なフレーム時間の計算式として単純に合計せず、クリティカルパスと同期を期限に照らして比較してください。提出に間に合わない場合は再投影が実行されることがあり、目に見えるアーティファクトは動き、深度、選択したランタイムパスによって異なります。

GPU% の誤解と 50% のしきい値

アプリが半分のレートに落ちると、GPU は早く処理を終えてアイドル状態になるため、アプリが確実に GPU バウンドであるにもかかわらず、使用率は低下します。

FPS=36/72  Stale=36  GPU%=0.65  App=18.05ms

• FPS=36/72 — 半分のレートです。表示される各フレームは 2 回表示されます。
• App=18.05ms — フレームあたりの実際の GPU 時間です。13.9 ms の予算を超えています。
• GPU%=0.65 — 倍増した 27.8 ms の間隔で測定されています。そのため、アプリに必要なのは「35% の余裕」ではなく、23% の削減であるにもかかわらず、65% と表示されます。

ルール：App をミリ秒単位でリフレッシュレートの予算と比較してください。GPU% を信頼するのは、飽和に近い場合に限ります。 半分のレートから復帰するには、GPU の処理を 1 回のリフレッシュ間隔内に収める必要があります。つまり、半分のレート時には使用率を 約 50% 未満にする必要があります。

App が予算内なのに Stale がゼロでない場合は、トレースで CPU の提出、同期、コンポジターのタイミングを調べてください。この症状だけで CPU がボトルネックだとは断定できません。上記の半分のレートの例は、記載されたメトリクスの定義が正しく、意図的な SpaceWarp モードが使われていないことを前提としています。まず両方を確認してください。

測定したボトルネックに合わせて対策を選ぶ

マルチビュー、レンダー スケール、フォービエーション、レイヤー、アセット、シェーダー、再投影の選択には references/rendering-playbook.md を読んでください。それぞれの実験について、前提条件、視覚的な失敗例、対象デバイスでの根拠が記載されています。

1. Dynamic Resolution — エンジン／SDK がサポートする制御方法でレンダー スケールを調整してください。OS が有効にすると決めつけず、実際の動作を確認してください。
2. Foveation — 固定フォービエーションと視線追跡型を区別し、サポートされているレベルと品質をテストしてください。単純なシェーダーでも、FFR を使わない場合より FFR を使った場合のほうが高コストになることがあります。
3. Refresh rate — 代表的なワークロードを維持できるレートを要求してください。レートが自動的に変わると約束せず、実際のランタイムと熱の動作を確認してください。
4. Application SpaceWarp — アーティファクトとレイテンシーのテストを伴う、深度／モーションベクターのサポート対象インテグレーションです。自動的な救済策でも、一定の改善率が保証されるものでもありません。

キャプチャの流れ — 各ツールで分かること

質問	ツール	方法
フレームが欠落しているか、欠落している場合はどこか	logcat VrApi の統計情報（FPS、Stale、App、GPU%）	metavr log / adb logcat
ヘッドセット内でリアルタイムに数値を確認する	OVR Metrics Tool（ovrmetric APK）	metavr tools install ovrmetric を実行し、オーバーレイを有効にします
CPU と GPU、スレッドのタイムライン、停止箇所	Perfetto	metavr MCP の start_perfetto_capture → stop_perfetto_capture → analyze_trace、または同等の CLI コマンド
CPU を消費している C/C++ 関数	simpleperf	実行中のパッケージに対して Android NDK の simpleperf を使用します
GPU を消費している描画呼び出し、シェーダー、レンダリングステージ	RenderDoc Meta fork	metavr tools install renderdoc を実行します。描画呼び出しトレース、レンダリングステージトレース、Vulkan シェーダー統計を取得します

Meta はこのうち 2 つのタスクスキル、hz-perfetto-debug と hz-simpleperf-debug に加え、オンデバイスの一般的なデバッグ用に hz-vr-debug を提供しています。これらがインストールされている場合、このスキルが 何を測定するか を判断し、各スキルがツールを操作します。

references/capture-playbook.md には、別のエージェントが対応できるレポートを作成するために 取得すべき内容を含め、具体的な手順が記載されています。

方法 — 2 回目のキャプチャを比較可能にする

1. 実機のヘッドセットでリリースビルドを使って再現します。シミュレーターでの実行 （xrsim、spatialsim）で確認できるのは、シミュレーションでサポートされている動作であり、ヘッドセットのパフォーマンスではありません。
2. ほかのことを確認する前に、リフレッシュレートと、それに応じたフレーム時間の予算を記録します。
3. メニューではなく、アプリの最も負荷が高いシーンでキャプチャします。
4. 変更するのは1 つだけにし、再キャプチャして、印象ではなく App のミリ秒値を比較します。
5. キャプチャ前後の App、Stale、シーン、ビルド ID の組み合わせを プロジェクト独自のメモに記録します。キャプチャのないパフォーマンスに関する主張は、単なる意見です。

デバッグを一巡余計にさせる落とし穴

• 熱でスロットリングされたヘッドセットでは比較が無効になります。 長時間のセッションでは状態が変化するため、冷却するか、数値とともに温度状態を記録してください。
• 開発モードのオーバーレイとログ出力はフレームを消費します。 オフにして測定し、ほかの方法では取得できない数値を読む場合に限ってオンにします。
• カウンターの意味はキャプチャ／ランタイムモードによって異なります。 古いフレーム数を処理落ちやパイプライン遅延として解釈する前に、タイムスタンプと再投影の状態を確認してください。
• 描画呼び出しは CPU の負荷であり、フィルレートは GPU の負荷です。 フィルレートがボトルネックのフレームでは、描画呼び出しを減らしても何も変わりません。そのため、まずキャプチャが必要です。
• WebXR には独自のカウンターがあります — ブラウザーのドキュメントに描画呼び出しのメトリクスがあります。ネイティブ向けのアドバイスを Web ビルドに適用する前に、quest-webxr を参照してください。

フレーム時間の予算、65%／18.05 ms の計算例、回復の仕組みは、 2026-09-20 に documentation/native/android/os-missed-frames.md から確認しました。 metavr docs search "missed frames" で再確認してください。

トリガー

ここに誘導されるその他のフレーズ：「ヘッドセットをプロファイルする」／「профилировать шлем」、「アプリが熱い」／ 「шлем греется」、「ジャダー」／「джаддер」、「GPU がボトルネック」／「упёрлись в GPU」、「perfetto trace」／ 「трейс perfetto」、「simpleperf」、「RenderDoc」、「OVR Metrics」、「stale frames」、「SpaceWarp」、 「フォービエイテッドレンダリング」／「фовеальный рендеринг」、「72 Hz 対 90 Hz」。