На Android mid-range пристрої GPU Profiler показує 18 мс на кадр при цільових 16.6 мс — гра не тримає 60 FPS. Комбінація з 340 draw calls, overdraw-важких ефектів та текстур 2048×2048, які на екрані займають 64×64 пікселі — кожен фактор окремо терпимий, разом — катастрофа.
Чому оптимізація графіки для мобільних платформ потребує комплексного підходу?
Мобільні GPU — tile-based: вони розбивають кадр на тайли та рендерять послідовно. Це робить їх чутливими до overdraw та fill rate. На відміну від десктопу, де immediate mode GPU прощає більше, на мобільному пристрої кожен зайвий draw call або піксельний шейдер б'є по продуктивності. Ми об'єднуємо профілювання, стиснення текстур, налаштування батчингу та шейдерів в єдиний процес — інакше результату не буде.
Як виміряти та скоротити draw calls?
Draw Call — це команда CPU відмалювати групу трикутників з певними налаштуваннями. Кожен draw call потребує синхронізації CPU-GPU та передачі даних. На мобільних пристроях з tile-based GPU (PowerVR, Mali, Adreno) це дорожче, ніж на десктопних immediate mode GPU.
Інструменти: Unity Profiler (GPU Usage), Frame Debugger, а для детального аналізу — RenderDoc на Android або Xcode Instruments на iOS. GPU Profiler прямо в редакторі показує кількість batch'ів та SetPass calls. Хороша ціль для мобільного проекту — до 100 draw calls на кадр, реалістична для mid-core — 150–200.
Основні джерела зайвих draw calls:
- Static Batching об'єднує статичні об'єкти з однаковим матеріалом в один mesh при старті сцени. Умова: об'єкти мають бути помічені Static в Inspector та використовувати однаковий Material — один асет матеріалу, не однакові налаштування. Якщо у двох об'єктів Material з ідентичними параметрами, але це різні Material Instance — батчинг не працює.
- GPU Instancing масштабується краще при великій кількості копій одного об'єкта (дерева, каміння, вороги одного типу). Dynamic Batching для дрібних об'єктів (до 900 вершин) працює автоматично, але на практиці його вимикають заради Instancing.
- Canvas Overlay режим в uGUI: Canvas в Screen Space - Overlay рендериться поверх всього, і кожна зміна в будь-якому UI-елементі помічає весь Canvas Dirty, перераховує mesh та робить окремий draw call. Для UI з анімованими елементами обов'язково розносити статичні та динамічні елементи по різних Canvas'ам.
Як текстури впливають на продуктивність мобільних ігор?
Мобільні пристрої використовують Unified Memory Architecture: GPU та CPU ділять одну пам'ять. 512 MB RAM — не рідкість для бюджетних Android-пристроїв. Некомпресована RGBA32 текстура 2048×2048 = 16 MB. 10 таких текстур на рівні = 160 MB лише на текстурах.
Формати стиснення з апаратною підтримкою — оптимізація графіки
| Формат | Біт на піксель | Підтримка |
|---|---|---|
| ETC2 без альфи | 4 bpp | Android, iOS (через ASTC?) |
| ETC2 з альфою | 8 bpp | Android |
| ASTC 4×4 | 8 bpp | iOS, Android (Adreno 400+, Mali G7x+) |
| ASTC 6×6 | 3.5 bpp | iOS, Android (нові) |
| ASTC 8×8 | 2 bpp | iOS, Android (високе стиснення) |
| DXT5 (BC3) | 8 bpp | PC |
ASTC — найкращий варіант для iOS та сучасних Android (Adreno 400+ серії, Mali G7x та вище). На старих Android пристроях з OpenGL ES 2.0 ASTC не підтримується — потрібен ETC2 fallback. Unity дозволяє задати різні формати для різних платформ через Texture Importer.
Міпмапи — обов'язкові для 3D-об'єктів, не потрібні для UI. Міпмап додає 33% до розміру текстури в пам'яті, але для UI-елементів, які завжди рендеряться в нативному роздільній здатності, це марна витрата. Перевіряємо через Texture Importer → Generate Mipmaps → вимкнути для всіх UI-спрайтів.
В одному з проектів — мобільна 3D стратегія — при запуску кампанії гра падала з OOM на пристроях з 512 MB RAM. Memory Profiler показав 380 MB лише на текстурах. Аудит виявив: 60% текстурного бюджету займали текстури terrain та environment у форматі RGBA32 без стиснення (розробник вимкнув стиснення на етапі прототипування і забув повернути), ще 15% — UI-текстури з увімкненими міпмапами. Рішення: переведення всіх terrain/environment текстур в ASTC 6×6, UI-текстури в ASTC 8×8 без міпмапів, для ефектів з альфою — ASTC 4×4. Підсумок: 142 MB. OOM-кріші припинилися, звільнилося 240 MB для ігрової логіки та звуку.
Чому overdraw особливо критичний на мобільних GPU?
Overdraw — це рендеринг одного пікселя кілька разів. Напівпрозорі партикули, складні постпроцесингові ефекти, перекривні UI-елементи — все це overdraw. На tile-based мобільних GPU overdraw особливо дорогий: кожен раз, коли тайл пам'яті читається та записується повторно, це додаткова робота.
Візуалізувати overdraw в Unity: Scene View → Render Mode → Overdraw. Білі плями — проблема. Особливо стежимо за particle systems — партикли часто рендерять десятки напівпрозорих квадів поверх один одного в одній точці.
Для партикульних систем: обмежувати Max Particles, використовувати непрозорі або cutout шейдери де це візуально допустимо (cutout дорожчий за прозорий по fill rate, але дешевший по overdraw у глибину), сортувати партикли по Sorting Layer щоб мінімізувати перетин з геометрією.
Для шейдерів: прості Unlit шейдери в 3–5 разів дешевші за Lit на мобільних пристроях. Для декорацій дальнього плану, тіней на землі, billboard-об'єктів Unlit достатній. Lit шейдер з per-pixel lighting лише для ближнього плану та ключових об'єктів.
Які інструменти використовувати для профілювання?
Починаємо з Unity Profiler підключеним до пристрою через USB (Build → Development Build + Autoconnect Profiler). GPU Usage Profiler показує час рендера за категоріями. Frame Debugger — детальний розбір draw calls. Memory Profiler — знімок пам'яті з розбивкою за категоріями.
Для Android додатково: Android GPU Inspector (AGI) для пристроїв з Adreno, Mali Performance Counters для Mali GPU. Вони показують fill rate utilization, texture bandwidth та cache hit rate — метрики, недоступні в Unity Profiler. Перевірити підтримку ASTC на пристрої можна через SystemInfo.SupportsTextureFormat(TextureFormat.ASTC_6x6).
| Задача | Терміни |
|---|---|
| Аудит продуктивності + звіт з рекомендаціями | 2–5 днів |
| Оптимізація текстур та матеріалів (одна сцена) | 3–7 днів |
| Комплексна оптимізація графіки (весь проект) | 2–6 тижнів |
| Оптимізація під конкретний мінімальний пристрій | 1–3 тижні |
Що входить у нашу роботу з оптимізації?
- Детальний аудит продуктивності з повним звітом та рекомендаціями
- Пережатитя текстур з вибором оптимальних форматів для кожної платформи
- Налаштування батчингу, інстансингу та шейдерів
- Профілювання та усунення вузьких місць (draw calls, overdraw, memory)
- Консультація та навчання команди замовника
- Гарантія результату: FPS та стабільність на цільових пристроях
Ми більше 5 років займаємося оптимізацією мобільних ігор, реалізували 20+ проектів на Unity та Unreal Engine. Зв'яжіться з нами для аудиту вашого проекту. Замовте оптимізацію та отримайте стабільний FPS на цільових пристроях.