Тестування продуктивності графіки на різних пристроях
Гра, яка видає стабільні 60 fps на Pixel 7, може впасти до 18 fps на Redmi Note 9 — і не тому що телефон «слабкий». Це тому що Adreno 618 та Mali-G52 по-різному обробляють один і той же шейдер, і ніхто не перевіряв поведінку на Mali перед релізом. Тестування продуктивності графіки — це про розуміння апаратних різниць та про те, щоб гра не стала slideshow на пристроях, які займають 30% вашої цільової аудиторії.
Де приховуються реальні проблеми продуктивності
Draw calls та batching. 200 draw calls на мобільному пристрої — це червона зона. Але сам по собі лічильник нічого не говорить про причину. UI через Canvas в режимі Overlay з кількома дочірніми canvas, кожен з яких робить override sorting — це гарантований розрив усіх батчей. Unity не може об'єднати в один batch елементи з різних canvas override. Результат: 80 draw calls тільки на HUD, які інженер міг би звести до 5–8 при правильній ієрархії.
Overdraw. На мобільних GPU (tile-based deferred rendering: Adreno, Mali, PowerVR) overdraw убиває продуктивність швидше, ніж на десктопних. Рендеринг одного пікселя 4 рази підряд — це в 4 рази більше роботи на GPU. Particle systems з Additive blending, UI-шари поверх один одного без culling, прозорі меші — типові джерела overdraw. Unity Frame Debugger показує послідовність draw calls, але RenderDoc дає наочніше: він окрашує overdraw тепловою картою прямо в viewport.
Тепловий троттлінг. Середньобюджетні Android-пристрої через 3–5 хвилин інтенсивної гри знижують тактову частоту CPU/GPU на 20–40% через перегрів. На емуляторі це не відтворюється ніяк. Тому тест на sustained performance — тільки на реальному залізі, і не 30 секунд, а мінімум 20 хвилин ігрової сесії.
Інструменти та методологія
Основний workflow: Unity Profiler → Frame Debugger → Memory Profiler → платформо-специфічні інструменти.
Unity Profiler дає breakdown CPU по потокам (Main Thread, Render Thread, Job Worker) та GPU timeline — але GPU timeline працює коректно не на всіх пристроях. На деяких Android через ADB Profiler показує нулі в GPU блоці. У цьому випадку використовуємо нативні інструменти:
- Adreno GPU Profiler (Qualcomm): детальний розбив по стадіям пайплайна, HSR (Hidden Surface Removal) ефективність, shader cycle counts
- Mali Graphics Debugger (Arm): аналогічно для Mali-архітектур, плюс bandwidth візуалізація
- Xcode Instruments + Metal Debugger: для iOS/Metal — обов'язковий інструмент, без альтернатив
- RenderDoc: кросс-платформенний frame capture з повним state inspector — використовуємо для аналізу проблем шейдерів та батчингу незалежно від платформи
Для автоматизованого бенчмаркингу — Unity Performance Testing Package (com.unity.test-framework.performance). Дозволяє писати тести, які замірюють конкретні метрики (frame time, GC allocations, draw calls) та зберігають baseline для порівняння між білдами.
На практиці: для мобільної гри з відкритим світом ми виявили через Mali Graphics Debugger, що кастомний шейдер води використував textureCubeLod з precision mediump, що на Mali-G76 дав артефакти семплювання та тригарив fallback на software path — fps в зоні води просідав з 45 до 22. Заміна на textureCubeLod з precision highp усунула артефакти, але добавила 8% навантаження. Підсумкове рішення — спрощений шейдер води для пристроїв з Mali через Quality Settings та platform-specific material override.
Матриця пристроїв для тестування
Тестувати на одному «репрезентативному» пристрої — недостатньо. Мінімальна матриця для мобільного проекту:
Low-end (target floor): Qualcomm Snapdragon 460/Adreno 610, Mali-G52, 3 GB RAM. Нижня межа, на якій гра повинна працювати прийнятно.
Mid-range (основна аудиторія): Snapdragon 700-серія/Adreno 618-619, Mali-G76, 4–6 GB RAM.
High-end (флагман): Snapdragon 8 Gen 2, Apple A16, 8+ GB RAM.
iOS окремо: iPhone SE 2 (A13), iPhone 12 (A14), iPhone 14 Pro (A16) — три покоління, три різні Metal-поведінки.
Процес
Починаємо з профілювання baseline на кожному рівні матриці. Фіксуємо frame time, draw calls, overdraw, memory. Визначаємо проблемні сцени/ситуації (зазвичай це початок матчу, вибухові ефекти, відкриті простори).
Далі — ітеративна оптимізація: атласування текстур, LOD-групи, GPU Instancing для повторюючихся мешей, occlusion culling, Shader LOD. Після кожної зміни — повторний замір на реальних пристроях.
| Обсяг тестування | Орієнтовні терміни |
|---|---|
| Профілювання однієї сцени, 2 пристрої | 3–5 днів |
| Повне профілювання гри, матриця 6 пристроїв | 2–3 тижні |
| Тестування + оптимізація + валідація | 4–8 тижнів |
Вартість розраховується після аналізу проекту та необхідної матриці пристроїв.