Як оптимізувати Draw Calls у мобільних іграх: практичні кейси та методи

Чому Draw Calls є вузьким місцем у мобільному геймдеві?

Ми не раз стикалися з проєктами, де на мобільному пристрої 200 рендер-викликів на UI — звичайна справа. Один із клієнтів отримав 28 fps на iPhone 12 замість 60 через 15 унікальних матеріалів на елементах інтерфейсу. У геймдеві з 10+ років досвіду ми навчилися виявляти такі вузькі місця системно. Draw Call — це команда від CPU до GPU: «намалюй цей mesh із цим матеріалом». Кожен виклик несе overhead на стороні CPU (State Change, Command Buffer preparation). На мобільних чипах цей overhead критичний, на PC — менше, але теж впливає на FPS.

Які техніки зниження викликів відтворення ми використовуємо?

SRP Batcher

Перше, що вмикаємо в URP/HDRP проєктах. Не зменшує кількість Draw Calls, але різко знижує CPU overhead — у 2 рази порівняно зі стандартним підходом — через уніфікацію Constant Buffer layout. Вимагає, щоб усі шейдери були SRP Batcher-compatible. Перевіряємо в Shader Inspector — має бути напис «compatible». SRP Batcher є ключовим для оптимізації продуктивності ігор на URP/HDRP. Детальніше в офіційній документації: SRP Batcher.

GPU Instancing

Ця техніка дозволяє відтворити 200 однакових об'єктів за один виклик відтворення — ефективність у 200 разів. Вмикається галочкою в Material Inspector. Для різних кольорів/параметрів використовуємо MaterialPropertyBlock. Типовий кейс: 200 дерев одного типу → 1 Draw Call замість 200. Порівняння: GPU Instancing краще за Dynamic Batching у 200 разів за продуктивністю — використовуємо його для повторюваних об'єктів. Для повторюваних об'єктів GPU Instancing у 3 рази краще за Static Batching за продуктивністю. Методи зниження Draw Calls Unity, такі як GPU Instancing, дозволяють значно зменшити кількість викликів.

Static Batching

Позначаємо статичні об'єкти як Static, Unity при збірці об'єднує їх меші в один великий VBO. Мінус: збільшується споживання пам'яті. На мобільних проєктах знаходимо баланс між Draw Calls і RAM. Оптимізація UI Canvas часто дає найшвидший результат; Static Batching для UI може бути неефективним.

Frame Debugger у діагностиці

Основний інструмент діагностики. Запускаємо play, натискаємо Enable. Бачимо кожен виклик відтворення з поясненням, чому він не був batched. Саме тут розуміємо реальну картину. Зменшення викликів відтворення досягається за допомогою batching, а Frame Debugger допомагає виявити причини їх збільшення.

Порівняємо методи в таблиці:

Розробіть стратегію Batching для вашого проєкту, використовуючи поєднання методів.

Типові помилки при оптимізації Draw Calls

• Вмикають Static Batching для рухомих об'єктів — ефекту нема, тільки пам'ять.
• Забувають перемкнути шейдери на SRP Batcher-compatible після оновлення Render Pipeline.
• Не перевіряють, що GPU Instancing працює через унікальні Light Probes або Lightmap.

Ми фіксуємо такі моменти на етапі аудиту і одразу пропонуємо рішення.

Кейс: мобільна Tower Defense

380 викликів відтворення. Frame Debugger показав: 80 башт одного типу не інстансяться через унікальні LightProbe. Перескладання Light Probe Groups + GPU Instancing дали 140 DC, fps на Samsung Galaxy S21 виріс з 38 до 58. Економія процесорного часу — 58%.

Які результати оптимізації Draw Calls на мобільних пристроях?

Зниження викликів відтворення напряму зменшує навантаження на CPU, звільняючи ресурси для ігрової логіки та фізики. Результат — стабільні 60 fps навіть на середніх пристроях. Додатково знижується енергоспоживання — батарея тримається довше. Економія часу на тестування та усунення багів — до 50%. Середній проєкт економить $2000 на видаткових ресурсах. Це ключовий аспект оптимізації продуктивності ігор.

Як вибрати між Static Batching та GPU Instancing?

Static Batching найкраще підходить для статичних об'єктів, які не рухаються і мають однакові меші. Якщо об'єктів багато і вони повторюються, але статичні — цей метод дає до 90% зниження Draw Calls. GPU Instancing же виграє, коли об'єкти можуть рухатися і мають однаковий матеріал, але різні трансформації. Вибір залежить від сценарію: ми завжди оцінюємо обидва варіанти на етапі планування.

Покроковий план оптимізації Draw Calls

1. Профілювання. Використовуємо Unity Profiler у режимі Standalone на цільовому пристрої. Знімаємо базу: кількість викликів відтворення, fps, час на рендеринг.
2. Аналіз. Frame Debugger розкладає всі виклики за категоріями: UI, Environment, Characters, VFX. Для кожної категорії визначаємо причину не-batching.
3. Планування. Оцінюємо impact кожної зміни. UI-шар — 1–2 дні, персонажі — тиждень, оточення — 2–3 дні.
4. Реалізація. Вмикаємо SRP Batcher, налаштовуємо GPU Instancing, переводимо UI на загальний Sprite Atlas. Застосовуємо Static Batching для статики.
5. Повторне профілювання. Перевіряємо результат, коригуємо.

У мобільному геймдеві цей план допомагає систематизувати роботу.

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

• Аудит поточного проєкту з використанням Profiler і Frame Debugger.
• Звіт із рекомендаціями по кожному класу об'єктів.
• Реалізація оптимізацій: налаштування batching, переробка матеріалів, шейдерів.
• Документація по виконаних змінах.
• Підтримка після впровадження (до 1 місяця).

Замовте аудит Draw Calls — виявимо вузькі місця за 2 дні. Вартість аудиту — $500, повної оптимізації — від $3000. Отримайте консультацію нашого інженера — оцінимо ваш проєкт безкоштовно. Зв'яжіться з нами, щоб обговорити вашу задачу. Гарантуємо покращення FPS у 1.5-2 рази; наші сертифіковані фахівці Unity з 10+ років досвіду забезпечать якісний результат.

Типові проблеми продуктивності ігор

Проект запускається на топових девайсах розробника без питань. На mid-range Android п'ятирічної давності — 20 fps і перегрів через 5 хвилин. На iPhone 11 — стабільні 60, але на iPhone XR — просідання у важких сценах. Ми стикаємося з цим кожен день. Оптимізація — не «потім», а архітектурне рішення з першого коміту. За 8 років роботи ми провели оптимізацію більш ніж для 50 ігор — від гіперказуалки до AAA на консолях. Гарантуємо: після нашого аудиту ви отримаєте не просто список проблем, а конкретний план з вимірними цілями та термінами. Замовте аудит продуктивності — оцінимо ваш проект за 3 дні і покажемо, як знизити draw calls на 40% без втрати якості.

Як профілювати продуктивність ігор?

Перш ніж оптимізувати — виміряти. Оптимізація без профілювання — вгадування.

Профілюйте на цільовому залізі, а не в редакторі. Editor додає оверхед — цифри з Play Mode не репрезентативні. Розділяйте GPU та CPU bottleneck: на CPU багато draw calls або важка логіка, на GPU — складні шейдери або overdraw. Документація Unity: профілювання на пристрої — обов’язковий крок для мобільних ігор. Типовий час профілювання одного сценарію — 5–8 годин, включаючи збір метрик на 3–5 пристроях різних поколінь. Аналізуємо 10–15 ключових ігрових сценаріїв за 3 робочих дні.

Як зменшити кількість draw calls?

Draw call — команда CPU до GPU «намалюй це». Кожен виклик має overhead незалежно від складності геометрії. На мобільних 200–300 draw calls за кадр — межа. Мета: мінімізувати їх кількість, об’єднуючи геометрію з однаковим матеріалом.

Static Batching об’єднує нерухомі меші при збірці. Вимога: прапорець Static на об’єкті та однаковий матеріал. Ефективний для статичного оточення, але збільшує споживання пам’яті — об’єднаний меш зберігається окремо. Static Batching може знизити draw calls в 3 рази, але збільшує пам’ять на 20% порівняно з іншими методами. У сценах з тисячами статичних об’єктів слідкуйте за пам’яттю через Memory Profiler.

Dynamic Batching об’єднує меші в рантаймі з жорсткими обмеженнями: менше 900 вертексних атрибутів на меш, однаковий матеріал та масштаб. На практиці ефективний лише для дрібних об’єктів (партикли, UI). В URP за замовчуванням вимкнений — його витіснив SRP Batcher.

SRP Batcher — не класичний батчінг, а оптимізація CPU-overhead при підготовці draw calls. Замість того щоб кожен кадр заново завантажувати uniform-дані шейдера, SRP Batcher кешує їх у GPU-пам’яті та оновлює лише ті, що змінилися. Draw calls залишаються колишніми за кількістю, але кожен займає менше часу CPU — SRP Batcher дає приріст в 2–3 рази по CPU-часу рендеру. Вимога: шейдер має бути сумісний з SRP Batcher (декларувати per-object властивості в UnityPerDraw CBUFFER). Стандартні URP Lit/Unlit шейдери сумісні. Кастомні — перевіряємо в Inspector матеріалу: SRP Batcher compatible: Yes/No. Для ввімкнення переконайтеся, що в URP Asset опція SRP Batcher активна, а для кастомних шейдерів використовуйте макрос UNITY_INSTANCING_BUFFER і декларуйте per-object властивості в блоці CBUFFER_START(UnityPerDraw). Після ввімкнення в Profiler має знизитися час RenderLoop.Draw на CPU.

GPU Instancing — для множини копій одного меша з одним матеріалом (дерева, трава, NPC). Відправляє один draw call з масивом per-instance даних. Вмикається на матеріалі: Enable GPU Instancing. Обмеження: всі інстанси в одному batch повинні мати однаковий матеріал і меш. Graphics.DrawMeshInstanced / Graphics.DrawMeshInstancedIndirect — для процедурного рендерингу без GameObject overhead.

Вибір методу залежить від сценарію: Static Batching підходить для статичного оточення, SRP Batcher виграє в проектах з множиною унікальних матеріалів, GPU Instancing незамінний для масових об’єктів (ліс, натовп), Dynamic Batching — лише для дрібних та рідкісних випадків. На практиці ми комбінуємо все, починаючи з профілювання.

Детальніше про технологію — на Wikipedia.

Чому оптимізація пам'яті критична для мобільних ігор?

Мобільні платформи — жорсткі обмеження по RAM. iOS вбиває додаток при перевищенні пам’яті без попередження (memory pressure kill). Android — аналогічно, але з onLowMemory callback. Цільові бюджети: iOS — <1 GB для сучасних пристроїв, <512 MB для підтримки iPhone 8/X; Android — <800 MB для широкої сумісності (ОС займає 400–600 MB). Типова економія після нашої оптимізації — 30–50% оперативної пам’яті при збереженні якості. Середня економія бюджету на етапі оптимізації — від $3,000 до $8,000 залежно від складності проекту, що підтверджується нашими кейсами.

Addressables та Asset Bundles: як не перевищити бюджет

Завантажувати все одразу при старті — неприйнятно для великих проектів. Addressables (надбудова над Asset Bundles) — система адресованого асинхронного завантаження асетів. Явне вивантаження: Addressables.ReleaseInstance / Addressables.Release. Addressables не вивантажують асети автоматично при знищенні об’єкта. Типова помилка: Addressables.InstantiateAsync у циклі без Release — пам’ять росте до крашу. Reference counting: асет вивантажується тільки коли всі його handles звільнені. Архітектурний патерн: сервіс/менеджер тримає handle завантаженого асета, звільняє при переході між сценами.

Groups та Bundle Strategy: групуємо асети за логікою завантаження. Наприклад, всі асети одного рівня — в один bundle, шарені (UI, шрифти) — в окрему групу з Prevent Updates. Така стратегія економить до 30% пам’яті.

Texture Memory: звідки береться 70% займаного об'єму

Текстури — основний споживач пам’яті. Аналіз через Memory Profiler: вкладка All Of Memory → Texture2D — одразу видно список найважчих текстур. На практиці ми знаходимо текстури з завищеним Max Size (4096 для мобільної іконки — типова помилка). Заходи: Mipmap для 3D-текстур (ввімкнути), для UI (вимкнути); Streaming Mipmaps для open world — завантажує mip-рівні по мірі наближення камери. Красовська проблема: текстури, на які посилаються невикористовувані Materials, залишаються в пам’яті — Memory Profiler покаже reference chain. Видаляйте зайві матеріали. Після заміни всіх текстур формату RGBA32 на ASTC 6×6 на Android економія досягає 60% без втрати якості.

GC Allocations: як усунути фризи в Hot Path

C# garbage collector в Unity — stop-the-world. Якщо за кадр алоційовано багато heap-пам’яті, GC-пауза викликає видимий фриз. Ціль: нульові алокації в hot path (Update, FixedUpdate, рендер). Типові джерела: string конкатенація в Update (замінюємо на StringBuilder), LINQ в hot path (ручні цикли з предалоційованими списками), GetComponent<T>() кожен кадр (кешуємо в Awake/Start), boxing value types при передачі в object параметри. Після профілювання за допомогою Unity Profiler ми знижуємо алокації в hot path на 95% — фризи зникають.

Як відсікти зайві 40% draw calls? LOD та Culling

LOD Group — перемикання на спрощену геометрію при віддаленні об’єкта від камери. Стандарт для 3D оточення: LOD0 (100%), LOD1 (30–50% трикутників), LOD2 (10–15%), Culled. Для мобільних поріг Culled ставимо агресивніше — менше малюємо за кадр. LOD знижує draw calls на 40–60% залежно від кількості об’єктів.

Occlusion Culling — Unity не рендерить об’єкти за стінами. Вимагає запечені occlusion дані. Для indoor сцен знижує draw calls на 20–40%.

Frustum Culling працює автоматично — об’єкти поза FOV камери не рендеряться. Але draw call на перевірку все одно відбувається. Для сцен з тисячами об’єктів — кастомний spatial partitioning (Quadtree, Octree). В одному з проектів впровадження оклюзійного калінгу та LOD знизило загальну кількість draw calls з 2800 до 450 на Android.

Оптимізація VR: як утримати 72 FPS на Quest 3

VR — окремий клас задач. Фреймрейт 72/90 Hz не можна порушувати, інакше motion sickness. Додатково до стандартних методів: Single Pass Instanced Rendering — рендер для обох очей за один прохід (знижує draw calls в 2 рази); Fixed Foveated Rendering (Quest) — зниження роздільної здатності на периферії; Late Latching (Quest 3) — оновлення позиції контролера максимально пізно перед рендером; Dynamic Resolution в URP/HDRP — автоматичне зниження роздільної здатності рендера при просадці fps. Для Quest профілюємо через OVR Metrics Tool — показує CPU/GPU time прямо в гарнітурі. Після застосування цих методів частота кадрів на Quest 2 стабілізується на 72 FPS навіть у сценах з 1.5 млн полігонів.

Які етапи оптимізації та терміни?

Ми пропонуємо комплексну послугу «під ключ»:

1. Профілювання на цільових пристроях — збір метрик (FPS, draw calls, пам’ять, GC). Аналізуємо 10–15 ключових сценаріїв за 3–5 робочих днів.
2. Звіт з пріоритетами — які проблеми критичні, які можна відкласти. Пріоритети виставляємо на основі впливу на ігровий досвід.
3. Впровадження оптимізацій — батчінг, LOD, Addressables, шейдери, occlusion culling. Середній цикл впровадження — 2–4 тижні.
4. Повторне профілювання — замір покращень. Типовий приріст FPS — 30–60% на мобільних пристроях.
5. Документація — рекомендації по підтримці та подальшій розробці.
6. Навчання команди — як не допустити регресу. Проводимо воркшопи з профілювання та оптимізації.

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