Гра, яка видає стабільні 60 fps на Pixel 7, може провалитися до 18 fps на Redmi Note 9 — і це не тому, що телефон «слабкий». Це тому, що Adreno 618 і Mali-G52 по-різному обробляють один і той самий шейдер, і ніхто не перевіряв поведінку на Mali до релізу.
Ми щодня розбираємо такі кейси і знаємо, як перетворити слайдшоу на плавну картинку. За час роботи ми провели тестування понад 50 проєктів — від гіперказуальних до open-world RPG.
Тестування продуктивності графіки — це про розуміння апаратних відмінностей і про те, щоб гра не втрачала аудиторію.
Що входить у роботу
| Етап | Результат |
|---|---|
| Аналіз проєкту та збір білдів | Матриця пристроїв, тестові сценарії |
| Профілювання baseline | Frame time, draw calls, overdraw, memory по кожному пристрою |
| Ітеративна оптимізація | Атласування, LOD, GPU Instancing, occlusion culling, Shader LOD |
| Повторне тестування | Порівняння метрик до/після, виявлення нових проблем |
| Звіт і навчання команди | Документація, логи, доступ до звітів на 2 місяці |
Чому гра гальмує лише на пристроях із Mali GPU?
Архітектура Mali використовує tile-based deferred rendering, за якого overdraw та шейдерні інструкції з високою точністю можуть спричиняти падіння продуктивності. Наприклад, точність mediump у textureCubeLod може тригерити софтверний fallback. Ми виявляємо такі випадки через Mali Graphics Debugger.
Де ховаються реальні проблеми продуктивності
Draw calls і batching. 200 draw calls на мобільному пристрої — червона зона. UI через Canvas у режимі Overlay з кількома дочірніми canvas, кожен з яких робить override sorting, гарантовано розриває всі батчі. Результат: 80 draw calls лише на HUD, які можна звести до 5–8 за правильної ієрархії.
Overdraw. На мобільних GPU (tile-based deferred rendering) overdraw вбиває продуктивність швидше, ніж на десктопних. Рендеринг одного пікселя 4 рази підряд — у 4 рази більше роботи на GPU. Particle systems з Additive blending, UI-шари без culling, прозорі меші — типові джерела. RenderDoc забарвлює overdraw тепловою картою прямо у viewport.
Тепловий тротлінг. Середньобюджетні Android-пристрої через 3–5 хвилин інтенсивної гри знижують тактову частоту CPU/GPU на 20–40% через перегрів. На емуляторі це не відтворюється. Тому тест на sustained performance — лише на реальному залізі, мінімум 20 хвилин ігрової сесії.
Як скласти матрицю пристроїв для тестування?
Тестувати на одному «репрезентативному» пристрої — недостатньо. Мінімальна матриця для мобільного проєкту:
- 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-поведінки.
Чому тест на емуляторі не замінює реальне залізо?
Емулятор не відтворює тепловий тротлінг — він використовує ресурси ПК без обмежень. Крім того, емулятор не емулює tile-based архітектуру Mali та PowerVR, тому overdraw і шейдерні проблеми можуть залишитися непоміченими.
Лише на фізичному пристрої можна заміряти реальний FPS budget, температурні скидання та поведінку акумулятора.
Інструменти та методологія
Основний workflow: Unity Profiler → Frame Debugger → Memory Profiler → платформо-специфічні інструменти.
Unity Profiler дає breakdown CPU по потоках і GPU timeline, але GPU timeline працює коректно не на всіх пристроях. На деяких Android через ADB Profiler показує нулі в GPU блоці. У цьому випадку використовуємо нативні інструменти:
- Adreno GPU Profiler (Qualcomm): деталізована розбивка по стадіях пайплайну, HSR efficiency, shader cycle counts.
- Mali Graphics Debugger (Arm): аналогічно для Mali-архітектур, плюс візуалізація bandwidth.
- Xcode Instruments + Metal Debugger: для iOS/Metal — обов'язковий інструмент.
- RenderDoc — кросплатформний frame capture з повним state inspector для аналізу проблем шейдерів і батчингу.
Для автоматизованого бенчмаркінгу — Unity Performance Testing Package. Дозволяє писати тести, що заміряють метрики (frame time, GC allocations, draw calls) і зберігають baseline.
Як ми це робимо
- Первинний аналіз: вивчаємо білд, визначаємо цільові пристрої, узгоджуємо матрицю.
- Профілювання baseline: на кожному пристрої фіксуємо frame time, draw calls, overdraw, memory.
- Ідентифікація вузьких місць: знаходимо проблемні сцени (початок матчу, вибухові ефекти, відкриті простори).
- Ітеративна оптимізація: атласування текстур, LOD-групи, GPU Instancing, occlusion culling, Shader LOD.
- Повторне тестування: після кожної зміни — замір на всіх пристроях.
- Валідація: перевірка sustained performance (20+ хвилин) і звіт з рекомендаціями.
| Обсяг тестування | Орієнтовні терміни |
|---|---|
| Профілювання однієї сцени, 2 пристрої | 3–5 днів |
| Повне профілювання гри, матриця 6 пристроїв | 2–3 тижні |
| Тестування + оптимізація + валідація | 4–8 тижнів |
Зв'яжіться, щоб обговорити деталі та оцінити ваш проєкт. Отримайте консультацію інженера з досвідом оптимізації під будь-які GPU.
