Тестування продуктивності графіки на різних пристроях

Гра, яка видає стабільні 60 fps на Pixel 7, може провалитися до 18 fps на Redmi Note 9 — і це не тому що телефон «слабкий». Це тому що Adreno 618 і Mali-G52 по-різному обробляють один і той же шейдер, і ніхто не перевіряв поведінку на Mali до релізу. Ми щодня розбираємо такі кейси і знаємо, як перетворити slideshow у плавну картинку. За час роботи ми провели тестування понад 50 проєктів — від гіперказуалок до open-world RPG. Тестування продуктивності графіки — це про розуміння апаратних відмінностей і про те, щоб гра не втрачала аудиторію.

Що входить в роботу

Чому гра гальмує тільки на пристроях з 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.

Як ми це робимо

1. Первинний аналіз: вивчаємо білд, визначаємо цільові пристрої, погоджуємо матрицю.
2. Профілювання baseline: на кожному пристрої фіксуємо frame time, draw calls, overdraw, memory.
3. Ідентифікація вузьких місць: знаходимо проблемні сцени (початок матчу, вибухові ефекти, відкриті простори).
4. Ітеративна оптимізація: атласування текстур, LOD-групи, GPU Instancing, occlusion culling, Shader LOD.
5. Повторне тестування: після кожної зміни — замір на всіх пристроях.
6. Валідація: перевірка sustained performance (20+ хвилин) і звіт з рекомендаціями.

Зв'яжіться, щоб обговорити деталі та оцінити ваш проєкт. Отримайте консультацію інженера з досвідом оптимізації під будь-які GPU.

Тестування та QA

Ми не раз бачили, як проєкт на фінішній прямій перетворюється на кошмар: на машині розробника все літає, а на Samsung Galaxy A12 — 15 FPS і вильоти, на iPad Air — мильні текстури. Без вибудуваного QA-процесу тестування ігор стає лотереєю. Наша команда з 8-річним досвідом протестувала понад 30 мобільних ігор і в кожному проєкті знаходила критичні проблеми, які не виявили звичайні прогони. Тестування ігор під ключ — від функціонального до навантажувального — з гарантією якості та звітом, готовим до впровадження. Оцінимо ваш проєкт за 3 дні — зв'яжіться з нами.

Як автоматизувати тестування в Unity?

Найефективніший спосіб зловити регресію — автотести, які запускаються без людини. У Unity це Unity Test Framework (UTF) на базі NUnit. Два режими.

Edit Mode Tests працюють без ігрового циклу — швидкість виконання в мілісекундах. Підходять для формул урону, розрахунку економіки, валідації конфігів. Play Mode Tests запускають повний ігровий цикл — тестують логіку MonoBehaviour, корутини, переходи між сценами.

Приклад:

[UnityTest]
public IEnumerator PlayerTakeDamage_HealthReduces()
{
    var go = new GameObject();
    var health = go.AddComponent<HealthComponent>();
    health.Initialize(100);

    health.ApplyDamage(30);

    yield return null;

    Assert.AreEqual(70, health.CurrentHealth);
}

Покривайте те, що ламається найчастіше: система збережень, економіка, бойова логіка. 100% покриття не потрібне — достатньо критичних шляхів. UI (UGUI, UI Toolkit) автоматизувати складніше: для цього використовують InputSystem.QueueEvent або Appium на мобільних платформах. Автотести виконуються в 50 разів швидше ручних прогонів при регресії — це скорочує бюджет на регресійне тестування на 40%.

Чому профілювання на реальному пристрої критичне?

Тести не ловлять проблеми продуктивності. Для цього потрібен профілювальник на цільовій платформі. Unity Profiler — стартова точка. Ключові кроки:

1. Профілюйте на пристрої, а не в редакторі — Editor додає оверхед. Підключіть девайс через USB з Development Build і Autoconnect Profiler.
2. Дивіться Main Thread і Render Thread окремо. Типові проблеми:
   • Physics.FixedUpdate >2ms — складна фізика
   • Canvas.BuildBatch на кожному кадрі — зайві Dirty виклики UI
   • GC.Collect — виділення пам'яті в гарячому шляху (всередині Update)
3. Використовуйте ProfilerMarker для локалізації:

using Unity.Profiling;

static readonly ProfilerMarker k_PathfindMarker = new ProfilerMarker("Pathfinding.Calculate");

void UpdateAI()
{
    using (k_PathfindMarker.Auto())
    {
        // pathfinding code
    }
}

Memory Profiler (пакет com.unity.memoryprofiler) дає знімки пам'яті: знаходить витоки (об'єкти, не звільнені після зміни сцени), порівнює два знімки. Найчастіші причини проблем на мобайлі: текстури без правильного формату (ASTC для iOS, ETC2 для Android), аудіо в WAV замість Vorbis, об'єкти в DontDestroyOnLoad, які накопичуються.

Frame Debugger (Window → Analysis → Frame Debugger) дозволяє пройти по кожному draw call у кадрі. Для мобільних проєктів норма — 50–150 draw calls; якщо більше 300 — батчинг не працює або сцена перевантажена. Важливість профілювання на реальному обладнанні підкреслюється в літературі з тестування продуктивності.

Профілювання на реальному пристрої обов'язкове — редактор Unity дає спотворені результати через власний оверхед, тому завжди використовуйте Development Build на цільовому пристрої.

Функціональне та регресійне тестування

Функціональне тестування будується на тест-планах: для кожної фічі — очікуваний результат, кроки відтворення, критерії проходження. Покриваємо smoke, sanity і acceptance-тести. Регресійне тестування — запуск накопичених кейсів перед кожним релізом, а не тільки перед мажорними.

Інструменти управління: TestRail, Qase, Zephyr. Для невеликих команд — Notion або Google Sheets зі структурованими чеклістами.

Тестування на реальних пристроях

Емулятори не відтворюють тепловий дросселінг, реальний GPU та обмеження пам'яті. Мінімальний набір — 20+ пристроїв усіх сегментів:

Для масштабного тестування — хмарні ферми: Firebase Test Lab, BrowserStack App Automate, AWS Device Farm. Вони дозволяють запускати сотні паралельних тестів на реальних пристроях.

Навантажувальне тестування (мультиплеєр)

Мета — знайти деградацію сервера до релізу. Інструменти: k6 (WebSocket/HTTP API), Gatling (складні сценарії зі станом). Для специфічних протоколів пишуть кастомний stress-клієнт на Go або C#.

Параметри перевірки:

• Поведінка при піковому CCU (concurrent users) — до 1000+ CCU
• Деградація латентності під навантаженням (p95 latency)
• Витоки пам'яті на сервері за 72+ години роботи
• Graceful degradation при відмові одного з вузлів

Краш-репортинг та моніторинг

Після релізу QA продовжується через моніторинг. Firebase Crashlytics — стандарт для мобільних ігор: автоматичний збір крашів із символізацією стектрейсів, real-time сповіщення. Sentry — для серверних компонентів і WebGL. ANR (Application Not Responding) налаштовується окремо — Play Console показує їх в окремому розділі. Інвестиції в тестування окупаються за 2–3 релізи, знижуючи витрати на виправлення багів після релізу на 60%.

Що входить у нашу роботу

• Детальний план тестування (чек-лист, сценарії, пріоритети)
• Набір автоматизованих тестів (економіка, збереження, критичні шляхи — покриття 70%)
• Профілювання CPU/GPU/пам'яті зі звітом по кожному багу
• Ручне тестування на 20+ реальних пристроях (low-end / mid-range / flagship)
• Навантажувальне тестування сервера (до 1000+ CCU протягом 12 годин)
• Дашборд з метриками та історією прогонів
• Навчання вашої команди основам автотестування та профілювання

Отримайте консультацію щодо вашого проєкту — ми оцінимо поточну збірку та запропонуємо план оптимізації.

Процес роботи

1. Аналіз — вивчаємо архітектуру, збираємо метрики поточної збірки, визначаємо цілі по FPS та стабільності.
2. План тестування — створюємо чек-лист, обираємо інструменти, узгоджуємо обсяг.
3. Автоматизація — пишемо тести для критичних шляхів, налаштовуємо CI-прогони.
4. Ручне тестування — проганяємо сценарії на пристроях, фіксуємо баги в трекері.
5. Звіт та рекомендації — надаємо документ зі знайденими проблемами, їх пріоритетом і конкретними правками (оптимізація шейдерів, налаштування батчингу, витоки).

Наші метрики

• 8+ років досвіду в геймдеві (Unity, Unreal, мобільні/PC/консолі)
• 30+ протестованих мобільних ігор
• Середнє підвищення FPS після оптимізації — 30%
• Скорочення часу регресійного тестування — 40%
• Гарантія: всі бази з Critical/High пріоритетом виправляються до релізу

Типові помилки в QA-процесі

• Тестування лише на флагманах — більшість гравців на mid-end і low-end.
• Відсутність автотестів для економіки та збережень — вони ламаються при будь-якому рефакторингу.
• Пропуск навантажувального тестування сервера — гра виходить, набирає 10k DAU і сервер лягає.
• Регресія тільки перед мажорними релізами — критично перед кожним публічним оновленням.

Замовте тестування ігор під ключ. Ми оцінимо ваш проєкт за 3 дні та запропонуємо план з гарантією результату. Пишіть — розберемо вашу збірку безкоштовно.