Моніторинг помилок та креш-репортів у мобільних VR іграх

Моніторинг помилок та краш-репортів у мобільних VR іграх

Мобільний VR—Quest 2/3 standalone, Pico 4, застарілий Cardboard—має специфіку, яка робить моніторинг крешів складнішим, ніж у настільних іграх. Пристрій автономний, логи не видні у реальному часі, користувач не знає, що сталося, а developer console далеко. Якщо в збірку не вбудований crash reporting заздалегідь, після релізу ви працюєте практично сліпо.

Чому стандартний Unity Crash Reporter не працює для VR

Unity Cloud Diagnostics (старий Unity Analytics) та вбудований UnityCrashHandler охоплюють C#-виключення та manageable краші. Але мобільний VR-краш часто відбувається глибше—у native шарі: драйвер GPU, Vulkan runtime, Oculus platform layer. Ці краші приходять як SIGSEGV або SIGABRT з hex-стеком, який без NDK symbolication не читається.

Конкретний приклад: Quest 2, Unity 2022.3 LTS, URP, краш сталася на пристроях з конкретною прошивкою Horizon OS v57. Стек з logcat: #00 pc 0x00000000012abc14 /data/app/com.yourcompany.game/lib/arm64/libunity.so. Без symbol table від відповідної версії Unity це нічого не говорить. З symbol table (лежать на Unity Download Archive для кожної LTS версії)—розкривається у конкретний виклик всередину Vulkan buffer allocation, який сломався через зміну memory limits у Horizon OS v57.

Для IL2CPP-збірок—потрібні .pdb файли або il2cpp_data директорія з білда для правильного symbolication C#-частини стека. Без них Firebase Crashlytics покаже native стек без маппінгу на C#-класи.

Інструменти та налаштування

Firebase Crashlytics—стандарт де-факто для мобільного VR. Інтегрується через Firebase Unity SDK. Потребує google-services.json у проекті та налаштування в launcherTemplate.gradle. Crashlytics автоматично збирає native та managed краші, групує за стеком, показує trending.

Ключові налаштування для Android/Quest: включити android.useNewApkSplitting якщо використовується asset bundling, щоб Crashlytics коректно маппив версії. Завантаження NDK symbols—через Firebase CLI: firebase crashlytics:symbols:upload --app=APP_ID path/to/libil2cpp.so.

Sentry Unity SDK—альтернатива з більш гнучкою on-premise опцією. Корисно для студій з вимогами до зберігання даних у конкретній юрисдикції. Налаштування через Sentry.Init() у першій MonoBehaviour з тегами release та environment—дозволяє фільтрувати краші за версією та каналом (dev/staging/production).

Додатково до crash reporting—custom event logging для відслідковування soft errors: ситуацій, коли крешу нема, але поведінка неправильна. Analytics.CustomEvent("tracking_lost", {"duration": 5.2, "lighting": "low"}) дозволяє бачити паттерни деградації трекингу без краша.

Розбір краш-репортів та встановлення пріоритетів

Після налаштування моніторингу—регулярний цикл розбору. Групування крешів за версією додатку, версією OS, моделлю пристрою. Для Quest—окремої фільтрації за версією Horizon OS: деякі краші появляються строго на конкретній прошивці.

Метрика crash-free rate (% сесій без краша)—головний KPI. Для VR-додатків норма: >99% на підтримуваних пристроях. Якщо нижче 97%—активне розслідування.

Типові причини крешів у мобільному VR:

• Out of memory: 6 GB RAM у Quest 3—звучить багато, але Horizon OS залишає додатку близько 3–4 GB. Утечки native пам'яті, некоректний unload AssetBundle, накопичення texture memory в addressables cache—все це веде до OOM kill.
• Vulkan validation errors у dev-збірках стають крешами у release, якщо GraphicsDeviceType переключений без перевірки сумісності шейдерів.
• Threading violations: зверненням до Unity API з non-main thread без UnityMainThreadDispatcher або аналога.

Вартість розраховується після аналізу проекту та поточного стану моніторингу.