#Собес #git
🤔 Что делает команда git stash?

💬 Кратко:
Команда git stash сохраняет текущие незавершённые изменения в специальное место (стек), чтобы вы могли переключиться на другую ветку или выполнить другие действия. Эти изменения можно позже восстановить с ПОМОЩЬЮ git stash apply или git stash pop .

📌 Полный разбор + примеры использования — на платформе:
👉 Перейти к разбору

📣 Хочешь получать больше таких разборов?
Подпишись на наш главный канал

❗ С чего начать? → Всё самое важное здесь

Guru Unity at YeaHub | ОЛЕГ МИРОШКИН 🖥

Всем привет!

Я начал путь в геймдеве с зарплаты $400 и за три года дорос до 5000€. Работал над мидкор ПК-играми, мобильными матч-3 и автобаттлером с аудиторией 100 млн+ игроков.
Сотрудничал с командами из России, Кипра и США.

Сейчас я ментор по Unity-разработке, помогаю новичкам войти в индустрию, а действующим специалистам вырасти в доходе.
В 2025 году 9 моих учеников получили офферы на 120 000 ₽ – 300 000 ₽.

Доказываю, что в геймдеве деньги есть👍

А здесь, на YeaHub, я отвечаю за контент по Unity!

📱 Мой блог в Telegram

📱 Мой YouTube канал

А ещё подписывайтесь на другие каналы Экосистемы YeaHub

Проект YeaHub:

🚀 YeaHub | 🖥 GitHub | ✈ Telegram

🎵 TikTok | 📹 YouTube | 👥 Чат

Что такое 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