Тестирование производительности графики на различных устройствах

Тестирование производительности графики на различных устройствах

Игра, которая выдаёт стабильные 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) efficiency, shader cycle counts.
• Mali Graphics Debugger (Arm): аналогично для Mali-архитектур, плюс visualisation 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. После каждого изменения — повторный замер на реальных устройствах.

Стоимость рассчитывается после анализа проекта и требуемой матрицы устройств.