Як оптимізувати 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+ років досвіду забезпечать якісний результат.