Если коротко:
Профилирование VR-проекта начинают с Development Build на целевом устройстве и записи стабильного сценария. Сначала сопоставляют CPU frame time, GPU frame time, FPS и частоту дисплея, чтобы определить ограничивающую сторону. Затем CPU Usage раскрывает дорогие вызовы и потоки, GPU Usage — графическую нагрузку, а Frame Debugger показывает последовательность draw calls и состояние рендеринга. После одного изменения тот же сценарий измеряют повторно.
Unity VR profiling нужно начинать не с случайного пика в Editor, а с повторяемой записи на целевой гарнитуре. Редактор разделяет PlayerLoop и EditorLoop, но всё равно использует ресурсы компьютера и не воспроизводит тепловые ограничения standalone-устройства. Поэтому Play Mode подходит для быстрой проверки гипотезы, а итог подтверждает build на устройстве.
1. Зафиксируйте сценарий и бюджет
Выберите сцену, устройство, разрешение, refresh rate и одинаковый маршрут: например, запуск, 30 секунд движения и один тяжёлый эффект. Время кадра вычисляется как 1000 / частота, Гц: при смене частоты меняется и допустимый предел. Универсального бюджета «для любого VR» нет.
Соберите Development Build с Autoconnect Profiler, подключите гарнитуру и откройте Window → Analysis → Profiler. Deep Profiling добавляет overhead, поэтому включайте его только для локального поиска. Сохраните первый capture как reference.
2. Определите CPU- или GPU-bound кадр
Сначала смотрите не средний FPS, а CPU и GPU frame time на проблемном участке. Если graphics time упирается в бюджет, вероятно ограничение на GPU. Если GPU укладывается, а кадр опаздывает, исследуйте main thread, render thread, jobs и ожидания CPU. Один показатель загрузки в процентах не заменяет timings.
На Meta Quest OVR Metrics Tool показывает refresh rate, FPS, App GPU Time, CPU/GPU level, throttling и stale frames через overlay или CSV. Не сравнивайте захваты при разных performance levels как равные.
3. Разберите CPU в Unity Profiler
В CPU Usage выберите медленный frame и раскройте Timeline. Ищите самый длинный участок PlayerLoop, затем проверяйте Scripts, Physics, Animation, Rendering и GarbageCollector. Hierarchy агрегирует стоимость marker, но может скрыть последовательность потоков.
Проверяйте серию кадров. Частые причины — работа каждого GameObject в Update, синхронная загрузка, выделения памяти и ожидание render thread. После одной правки повторите тот же сценарий.
4. Разберите GPU и rendering
GPU Usage показывает категории графической работы, если backend и устройство отдают нужные timestamps. Дорогой кадр проверяйте по теням, прозрачности, post-processing, разрешению render target и сложности shaders. Отсутствие GPU timing не доказывает отсутствие GPU-ограничения — используйте платформенный profiler.
Frame Debugger замораживает кадр и позволяет пройти draw calls по порядку. Он полезен, чтобы увидеть лишние проходы, повторный draw объекта, shadow maps, неподходящий batching и состояние render target. Это инспектор состава кадра, а не точный секундомер: стоимость подтверждают Unity Profiler или GPU-инструменты платформы.
5. Повторите измерение
После правки соберите ту же конфигурацию и повторите маршрут:
- проверьте частоту дисплея и отсутствие throttling;
- сравните CPU/GPU time и пропущенные frame;
- убедитесь, что выигрыш сохраняется на нескольких запусках;
- сохраните build, Project Settings и capture рядом с результатом.
Исходную сцену настройте по руководству OpenXR для VR, а архитектуру объектов сверьте с XR Interaction Toolkit. Профилирование заканчивается повторным тестом, где кадр укладывается в бюджет выбранной частоты.