Что такое Draw Call (Batches) и почему они убивают производительность

Когда Unity рисует сцену, она не “стримит картинку”, а отдельно отрисовывает каждый объект.

Перед каждым рендером процессор говорит видеокарте:

“Вот меш, вот материал, вот позиция - рисуй”

Такая команда называется Draw Call.
Если у тебя на сцене 100 объектов - будет 100 Draw Calls.
И каждое обращение CPU → GPU стоит времени.

Почему это проблема

Видеокарта отлично справляется с рендером, но процессор задыхается, когда надо постоянно передавать команды.
Чем больше объектов и материалов - тем выше нагрузка на CPU, и тем ниже FPS.

Как сократить Draw Calls

Согласитесь - было бы эффективнее один раз передать информацию о многих объектах со сцены, а не передавать её маленькими кусочками.
В Unity есть такой механизм. Это называется Batching.
Делится на два вида:

1. Static Batching - для неподвижных объектов.
Если у тебя есть объекты на сцене, которые не будут двигаться (стены, окружение, декор) - отмечай их галочкой Static. Найти её можно в верхнем-правом углу в инспекторе объекта.
Unity объединит их в один большой меш на этапе сборки сцены.

2. Dynamic Batching - для подвижных.
Включается в Edit → Project Settings → Player → Other Settings → Dynamic Batching.
Автоматически будет работать для всех остальных объектов, не попавших в Static Batching. Наиболее эффективен для маленьких объектов.

Главное условие работы batching’а

Объекты должны использовать один и тот же материал.
Если у каждого свой - batching не сработает.
Поэтому, одна из твоих задач - сократить количество используемых материалов.
Конечно, оставить один материал на всю игру невозможно - но это и не требуется.

Как проверить количество Draw Calls

В Game View → Stats смотри строчку Batches.
Это количество вызовов после всех оптимизаций.

Ориентиры, рекомендуемые Unity:

До 200 Draw Call - для мобильных
До 2000 Draw Call - для ПК

Итог

Draw Calls - количество "приказов" от CPU на GPU отрисовать объект.
Меньше приказов = меньше лагов и больше FPS.

Для уменьшения - сокращение количества материалов, использование Static Batching для неподвижных объектов, Dynamic Batching - для подвижных.

🚀 Пост Guru Unity: @Minerope

🧹 Сборщик мусора в Unity - как оптимизировать?

Продолжаем тему оптимизаций и сегодня поговорим о сборщике мусора.

Сборщик мусора (GC) - это система, которая освобождает память, когда объект больше не используется.
Проблема в том, что во время сборки мусора игра фризится - GC останавливает всё, чтобы убрать неиспользуемые объекты.
Поэтому, ваша цель - уменьшить количество мусора и управлять сборкой вручную, когда это безопасно.

1️⃣ Включите инкрементальный GC

Unity поддерживает Incremental GC. В таком случае сборка мусора выполняется не целиком, а частями - по кадрам.
Так фризы становятся почти незаметными.
Включается в Project Settings → Player → Other Settings → Configuration → Incremental GC.

2️⃣ Собирайте мусор вручную в удобные моменты

Вместо того, чтобы GC отрабатывал в важные моменты геймплея - можно самому вызвать сборку в визуально простые моменты игры, где фризы экрана будут незаметны.
Обычно это экраны пауз - часто они статичные, или имеют простую анимацию.

Вызов сборки мусора:

GC.Collect();

3️⃣ Не используйте конкатенацию строк в циклах или Update

Каждая конкатенация строки == новый объект и мусор для сборки. Если цикл состоит из 16 итераций - будет создано 16 строк, что окажет большую нагрузку на GC.

Плохо:

string ConcatExample(string[] stringArray) {
    string result = "";

    for (int i = 0; i < stringArray.Length; i++) {
        result += stringArray[i]; // каждый раз - новый объект
    }

    return result;
}

Хорошо:

private StringBuilder _sb = new StringBuilder(16);

string ConcatExample(string[] stringArray) {
    _sb.Clear();

    for (int i = 0; i < stringArray.Length; i++) {
        _sb.Append(stringArray[i]); // используем StringBuilder - так создадим только один объект строки
    }

    return _sb.ToString();
}

4️⃣ Кешируйте строки

Типичная ошибка - обновление текста при любом обновлении счётчика или постоянно в Update.
Кешируйте текст и обновляйте только при изменении значения.

Плохо:

    public Text scoreBoard;
    public int score;
    
    void Update() {
        string scoreText = "Score: " + score.ToString(); // создаём новый объект каждый кадр
        scoreBoard.text = scoreText;
    }

Хорошо:

    public Text scoreBoard;
    public string scoreText;
    public int score;
    public int oldScore;
    
    void Update() {
        if (score != oldScore) {
            scoreText = "Score: " + score.ToString(); // создаём новые объект, только если значение изменилось
            scoreBoard.text = scoreText;
            oldScore = score;
        }
    }

5️⃣ Используйте NonAlloc-версии методов

Многие API в Unity создают мусор: Physics.OverlapSphere, Physics.Raycast и т.д.

Иногда есть версии с суффиксом NonAlloc:

Physics.OverlapSphereNonAlloc(position, radius, colliders);

При написании своих методов - следуйте той же идее: не создавайте новые массивы, если можно переиспользовать старые.

💡 Вывод и дополнительные материалы

Оптимизация GC - это не сложно.
Главное - избегать лишних аллокаций и управлять сборкой в удобные моменты.
Чем меньше мусора вы создаёте, тем плавнее идёт игра.

Статья от Unity по оптимизации GC
Профайлинг GC от GameDevGuru

🚀 Пост Guru Unity: @Minerope

Как проходит типичное техническое собеседование Unity-разработчика

Привет! За свою карьеру я прошёл более 15 собеседований, и сейчас расскажу про наиболее частую структуру.

1. Самопрезентация

После короткого смолтока вас попросят рассказать о себе.
Это не просто формальность - по вашему рассказу формируется первое впечатление.

Расскажите:
• над какими проектами работали
• за что отвечали
• какие задачи решали и чем гордитесь

Совет: запишите рассказ на аудио и послушайте. Поймёт ли человек, который впервые вас видит, чем вы занимались и в чём ваша ценность? Можно отправить запись другу для проверки.

После этого интервьюер может уточнить детали из резюме или спросить о вещах, которые вы не упомянули.

2. Технический блок

Здесь проверяют ваши знания по C# и Unity. Список тем зависит от компании, но чаще всего спрашивают:

1. Устройство памяти в C#. Отличия поведения ссылочных и значимых типов.
2. Garbage Collector - что это такое, как работает.
3. Отличия классов и структур. Ограничения структур. Boxing & Unboxing.
4. Коллекции и алгоритмы. Как "под капотом" работают стандартные коллекции, оценка сложности (Big O) операций с этими коллекциями (добавление, удаление, обращение). Могут затронуть популярные алгоритмы сортировки и обхода графа.
5. Асинхронность и многопоточность в C#
6. Блок Unity. Спрашивают что-то из перечисленного: Addressables / Оптимизации / Шейдеры и графический пайплайн / Сборка билда / Клиент-серверное взаимодействие / Unit тесты / Полезный стек - UniTask, Zenject, R3

Подсказка: читайте описание вакансии - по нему можно понять, на чём будет акцент.

3. Вопросы по процессам

В этом блоке собеседующие проверят ваши софт скиллы, используя вопросы о вашем поведении в команде.

Примеры вопросов:
• Как проводите code review?
• Как оцениваете время на выполнение задач?
• Что делаете, если ТЗ неполное?
• Как решаете конфликты?
• Что вас мотивирует в работе?
• Что делаете, если не успеваете в дедлайн?

4. Live-coding

Редкая практика, но бывает - примерно в 1 из 5 собеседований.
Вам дают задачу, вы демонстрируете экран и решаете её в реальном времени.

Примеры задач:
• Алгоритм нахождения матчей на match-3 поле;
• Обход графа;
• Проектирование - например, реализовать инвентарь или отревьюить код.

5. Ваши вопросы

Возможно, это будет неожиданностью - но по этому блоку вас продолжают оценивать.

Необходимо показать, что не просто вы пришли ради денег, а подходите к выбору компании осознанно, настроены на долгосрочное сотрудничество, хотите принести им пользу.

Хорошие вопросы:
• Как проходит онбординг новых сотрудников?
• Как часто проводятся performance review и что учитывается?
• Какие направления развития у компании сейчас в приоритете?
• Есть ли менторство или обмен опытом внутри команды?
• Есть ли единые стандарты кодстайла и архитектуры?
• Как работаете с техдолгом - планово или “по ходу”?
• Используете ли собственные фреймворки / пайплайны?
• По каким метрикам оцениваете успех проекта - доход, удержание, отзывы игроков?
• Какие ближайшие планы на развитие проекта?

🚀 Пост Guru Unity: @Minerope

MV* паттерны в Unity: разложим по полочкам

На собеседовании нас просят рассказать о каждом из них, правильно расположив стрелочки на схеме взаимодействия классов.
Но если отбросить всю эту теорию, смысл у них один - разделить ответственность между слоями кода.

И в этом посте я раскрою этот смысл, чтобы стало понятно зачем использовать эти паттерны, без необходимости запоминать куда стрелочки на схеме смотрят.

Принцип, из которого выросли все MV*

Любой UI или игровой экран можно разложить на три слоя:

1. Бизнес-логика (Model) - хранит и обрабатывает данные.
Пример: здоровье персонажа, инвентарь, внутренняя экономика.

2. Презентация (View) - показывает игроку информацию.
Пример: полоска HP, надписи, окна, анимации.

3. Связующее звено (Controller / Presenter / ViewModel) - решает, когда и что обновить.

Главная идея MV* - разные причины для изменений должны быть в разных местах.

Так, если мы поменяем бизнес-логику, то не придётся изменять код UI.
И наоборот - сменили виджет отображения UI (с текстового поля со значением процентов на полоску здоровья с конкретными значениями) - вся игровая логика здоровья осталась нетронутой.

Пример без разделения:

public class Health : MonoBehaviour
{
    [SerializeField] private TMP_Text _text;
    [SerializeField] private Image _bar;

    private float _hp = 100;

    public void TakeDamage(float dmg)
    {
        _hp -= dmg;
        _text.SetText($"{_hp}");
        _bar.fillAmount = _hp / 100;
    }
}

Пока одна панель - всё ок.
Но потом приходит геймдизайнер и говорит:

“Добавь полоску над персонажем и окно статистики.”

И ты полностью переписываешь компонент, уничтожая старую логику.
Каждое новое изменение = переписывание и логики хп, и его отображения.

Чтобы избежать постоянного переписывания UI кода, необходимо создать:

1. HealthModel, в которой будет находиться бизнес-логика
2. HealthView, который будет заниматься отображением (UI)
3. HealthPresenter, который связывает Model и View. Например, просто слушает события из Model и вызывает методы по обновлению View

В таком случае, если хочешь добавить вторую полоску здоровья - просто сделай второй HealthView и подпиши его на ту же модель.
Старый код останется полезным, и его можно будет использовать для других задач.

Посмотреть изменённый код можно тут

Смысл, который стоит запомнить

MV* - паттерн не ради паттерна.
Он необходим, чтобы изолировать причины изменений и отображение изменений.

И когда завтра геймдизайнер захочет 3 разных шкалы HP, ты просто подключишь новые View — без изменения логики HP и переписывания старого кода View.

🚀 Пост Guru Unity: @Minerope