🧹 Сборщик мусора в 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

Структура кадра в Unity и почему это важно

Сегодня разберём благодаря каким операциям мы получаем картинку в юнити, что такое Performance Bottleneck и как эти знания помогут оптимизировать вашу игру.

Что такое кадр и как он формируется

Наверняка, каждый знаком с понятием FPS.
Если игра работает на 60 FPS - это 60 циклов формирования кадра в секунду.

Каждый кадр - это последовательность операций, где участвуют:
• CPU - выполняет код Unity и ваш код, готовит геометрию кадра.
• GPU - получает подготовленные данные и рендерит финальное изображение.

Загвоздка - CPU и GPU не могут работать параллельно

GPU не может начать раскрашивать картинку, геометрия которой ещё не подготовлена от CPU. И наоборот - CPU не может начать работать над следующим кадром, пока GPU не раскрасила прошлый.

Это видно на приложенной схеме - у CPU присутствует блок "Wait", так как GPU ещё занимается прошлым кадром. В это время CPU просто простаивает.

Такая ситуация называется Performance Bottleneck

Performance bottleneck - это компонент (CPU или GPU), который ограничивает FPS. У нас есть "затык" в одном из компонентов.

Неопытный разработчик захочет оптимизировать игру, не разберётся в "затыке" производительности и пойдёт оптимизировать CPU (код или геометрию сцены).
Если bottleneck в GPU - весь эффект оптимизаций будет в увеличении ожидания от CPU.

• Было: CPU — 10 мс работы + 10 мс ожидания GPU.
• Стало: CPU — 8 мс работы + 12 мс ожидания GPU.

CPU стал работать быстрее, но FPS не вырос, потому что настоящая проблема - GPU.
Если оптимизировать не тот компонент, результат будет нулевым.

Зачем это знать

Перед любыми оптимизациями нужно определить:

• упираетесь вы в CPU или в GPU,
• какое именно место внутри них тормозит: логика, физика, UI, рендер, память.

Так вы сможете реально оптимизировать свою игру и не терять время зря.

В следующих постах от Guru разберём работу с Profiler и научимся определять Performance Bottleneck

🚀 Пост Guru Unity: @Minerope