asmdef в Unity - что это и зачем они вообще нужны

Что такое сборка?

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

Наверняка в IDE вы видели кучу сборок:

• Assembly-CSharp
• Assembly-CSharp-Editor
• Zenject
• Zenject-Editor

Это сборки, которые Unity создаёт самостоятельно. Часть из них есть в любом проекте, часть добавляется вместе с добавленными плагинами и пакетами.

Создание asmdef в Unity - это способ создать такую сборку вручную самостоятельно.
Своя DLL внутри проекта, со своими зависимостями, границами и правилами доступа.

Зачем вообще создавать asmdef?

1. Улучшение архитектуры

Без создания сборок весь ваш код хранится в одной большой стандартной сборке.
Но на самом деле в любом проекте есть отдельные логические модули.
Говоря о матч-3 проекте - есть модуль обработок платежей, UI модуль, Gameplay модуль, Core модуль, модуль Unit тестов, модуль инфраструктуры проекта (конфиги, сохранения)

Храня всё в одной сборке - легко нарушить эти разделения. Например, модуль обработки платежей может использовать Match3 модуль.
Хотя, если подумать - зачем ему это?

Используя asmdef ты начинаешь явно описывать зависимости:

• UI знает про Core
• Gameplay знает про Core
• Core ни про кого не знает

В итоге:

• Код становится менее связным
• Модуль реально можно вынести в другой проект
• Появляется ощущение «архитектуры», понимания проекта, а не свалки скриптов

2. Улучшение работы редактора

Без asmdef: изменил любой .cs файл → Unity перекомпилирует весь проект
С asmdef: изменил файл → перекомпилируется только сборка, в которой он лежит

В больших проектах это ощущается особенно сильно. Загрузки редактора будут раздражать намного меньше.

Как создать asmdef?

ПКМ в Project → Window Create → Assembly Definition

Далее необходимо его настроить. В Inspector укажи зависимости на другие сборки.
Для UI - на TextMeshPro. Для Core - на UniTask. Для Gameplay - на Core.

Используй здравый смысл, а не просто выдавай ссылки на всё подряд.

Наставление

asmdef - это сложно.

Ты почти гарантированно столкнёшься с:

• циклическими зависимостями
• ситуациями «почему этот класс теперь не виден»
• болью при рефакторинге
• ощущением, что раньше было проще

Но именно через это:

• приходит понимание архитектуры
• появляется мышление модулями
• происходит переход от «просто пишу код» к осознанной разработке

И это поможет тебе вырасти в Senior разработчика.

Заключение

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

Но если проект живёт больше пары месяцев и ты хочешь, чтобы он не развалился - рано или поздно asmdef дадут большие бенефиты.

И лучше начать использовать их рано и осознанно.

🚀 Пост Guru Unity: @Minerope

🚀 Новый год с YeaHub: готовимся к 2026 году вместе!

Дорогие айтишники, коллеги, друзья!

2025 год был непростым: рынок был медленным и непредсказуемым, вакансий было мало, конкуренция высокая. Но мы все это пережили — и получили важный урок: лучшее время действовать — сейчас.

На горизонте 2026 года есть позитивные сигналы:
— Ключевая ставка снижается, найм постепенно размораживается.
— Оптимизации и сокращения будут уходить в прошлое.
— Рынок станет более прозрачным и предсказуемым, но конкуренция останется высокой.

Что это значит для нас с вами:
— Адаптация и постоянное развитие становятся ключом к успеху.
— Тесты, резюме, навыки и нетворкинг — важнее, чем когда-либо.

YeaHub в 2026 году будет помогать вам побеждать рынок:
— 100+ новых собеседований уже в январе, с регулярным добавлением новых.
— Сервис лайвкодинга — решайте реальные задачи с собеседований.
— Новые сервисы и продукты: тесты с вариантами ответов, статьи, роадмапы и курсы.

К команде YeaHub присоединились новые бекендеры, аналитики, а также AQA и QA-специалисты. Мы выходим из бета-режима, выстроили основные процессы разработки и контроля качества и теперь фокусируемся на стабильности, масштабировании и высоком качестве платформы.

Поддержите нас и зафиксируйте текущие тарифы:
— Новые выгодные тарифы на 3 и 12 месяцев уже доступны.
— Цены вырастут в 2 раза к запуску лайвкодинга — зафиксируйте их заранее.

👉 Членство YeaHub

Вместе мы будем действовать, готовиться и побеждать рынок. Каждый ваш выбор, каждая подписка — это поддержка YeaHub и возможность создавать ещё больше полезного контента и сервисов для вашей подготовки.

Всем офферов ✊🏻💪

Что такое Zenject и зачем он нужен?

Zenject - легковесный фреймворк для dependency injection, специально сделанный для Unity, чтобы упростить доставку объектов в нужные части кода.

Для этого Zenject использует контейнер (он же DiContainer). Это объект, который хранит все биндинги, создаёт объекты (при желании) и предоставляет одну и ту же зависимость в разные места.

Для того, чтобы настроить Zenject используется Context. Это ассет, который преднастраивает контейнер, зависимости которого интегрируются в Unity.

Контекст бывает двух видов:
- SceneContext - для зависимостей контекста сцены.
- ProjectContext - для глобальных зависимостей.

Сам биндинг зависимостей происходит в классе, который наследуется от Installer и MonoInstaller. Мы переопределяем метод InstallBindings и прописываем условия внедрения зависимостей. InstallBindings - это место, где стоится граф зависимостей. По сути, он является нашим Composite Root.

using UnityEngine;
using Zenject;

public class GameInstaller : MonoInstaller
{
    public GameObject enemyPrefab;
    public SomeComponent sceneComponent;

    public override void InstallBindings()
    {
        // привязать интерфейс к реализации как синглтон
        Container.Bind<IGameService>().To<GameService>().AsSingle();

        // привязать конкретный инстанс (например, инспекторный компонент)
        Container.BindInstance(sceneComponent).AsSingle();

        // фабрика для создания врагов из префаба
        Container.BindFactory<Enemy, Enemy.Factory>()
                 .FromComponentInNewPrefab(enemyPrefab);

        // пул для часто создаваемых объектов (с использованием poolable API)
        Container.BindMemoryPool<Bullet, Bullet.Pool>()
                 .WithInitialSize(20)
                 .FromComponentInNewPrefab(bulletPrefab);
    }
}

После настройки биндингов, мы можем спокойно получить зависимость. Например, как получить этот биндинг:

Container.Bind<IGameService>().To<GameService>().AsSingle();

Использовать атрибут [Inject].

using UnityEngine;
using Zenject;

public class GameView : MonoBehaviour
{
    private IGameService _gameService;

    [Inject]
    public void Construct(IGameService gameService)
    {
        _gameService = gameService;
    }

    private void Start()
    {
        _gameService.StartGame();
    }
}

Таким образом, просто указав интерфейс и его реализацию, у нас прокидывается нужная зависимость. И не нужно использовать сложные шаблоны проектирования, всё работает под капотом.

Детально про возможности Zenject можно прочитать в официальной документации. Она довольно понятным языком описывает все возможности Zenject, в том числе и за пределами биндинга (фабрики, пулы, сигналы, код которых указан выше). Но я предпочитаю использовать только DI, чтобы не сильно зависеть от этого фреймворка.

Ссылка на документацию: https://github.com/modesttree/Zenject

🚀 Пост Guru Unity: @Minerope

Что такое реактивное программирование и причём здесь R3?

Реактивное программирование - это парадигма, в котором вместо того, чтобы напрямую связывать объекты, мы реагируем на изменения и уведомляем объекты о них. Объекты в свою очередь сами решают, что с этой информацией делать. Уведомление происходит с помощью потока событий. Сам поток событий представляет из себя некоторый менеджер событий, на который можно подписаться и отписаться.

Пример. У нас есть здоровье персонажа. Где оно хранится? Например, у Player, который при нанесении урона его дёргает и меняет его стейт.
В реактивном программировании, вместо того, чтобы хранить здоровье и дёргать его каждый раз, мы отправляем уведомление в поток событий, который уже в свою очередь уведомляет здоровье о том, что ему был нанесён урон. Таким образом, теперь Player и Health не связаны напрямую. Изменения происходят через поток событий.

Если вы посмотрите на свой ООПшный код, то вы возможно увидите, что множество действий у вас происходит в рантайме и на них необходима реакция. У вас есть объект, который получает ссылку на другой объект для подписки. Этого можно избежать, передавая потоки событий вместо самих объектов. Таким образом, мы отказываемся от прямого контроля в пользу обмена данных через потоки событий.

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

Для это используются:

ReactiveProperty<T> - это свойство, за которым непосредственно ведётся наблюдение. Если его значение изменилось - об этом отправляется уведомление.

var health = new ReactiveProperty<int>(100);
health.Subscribe(value => Debug.Log($"HP: {value}")); // логика, которая будет происходить при изменении
health.Value -= 10; // автоматически уведомит подписчиков

Observable<T> - это абстракция потока событий.

Он сам по себе ничего не хранит, а лишь сообщает: «произошло событие - вот данные».
На Observable можно подписаться, применить к нему операторы (фильтрация, трансформация, объединение потоков) и в итоге получить реакцию в нужном месте кода.

Простой пример:

Observable.EveryUpdate()
    .Where(_ => Input.GetKeyDown(KeyCode.Space))
    .Subscribe(_ => Jump());

Здесь:

• EveryUpdate() - поток событий, который срабатывает каждый кадр
• Where - фильтрация
• Subscribe - реакция

Никаких Update, флагов и проверок по всему коду.

Чем R3 отличается от простых ивентов?

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

С реактивщиной вы можете легко:

• объединять потоки
• трансформировать данные
• ограничивать частоту событий
• отменять цепочки событий

Например обработать событие когда hp стало 0, но только один раз:

health
    .Where(hp => hp <= 0)
    .Take(1)
    .Subscribe(_ => Die());

Без R3 такой код будет намного длиннее и грязнее.

Контроль жизненного цикла - R3 умеет автоматически отписываться от событий вместе с GameObject:

health
    .Subscribe(_ => HandleHalthChange())
    .AddTo(this);

GameObject уничтожился - подписка тоже. Без утечек и забытых отписок.

Когда R3 реально удобен?

• UI (биндинги, состояния, реакция на данные)
• игровые состояния (HP, статы, бафы, дебафы)
• ввод (Input, тайминги, кулдауны)
• асинхронщину и цепочки событий

То есть там, где:

• много изменений во времени
• много зависимых реакций
• хочется меньше связности

Итог

R3 - это инструмент, который:

• снижает связность
• упрощает работу с событиями
• делает код декларативным
• заставляет думать потоками, а не состояниями

Если сказать просто - то это как LINQ в C#. Вы можете фильтровать коллекции самостоятельно, написав огромные циклы for. Но вам предоставлен инструмент с готовыми методами, который позволяет писать более декларативно, писать "что именно нужно сделать", а не "как сделать то, что нужно".

Ссылка на репозиторий R3 с документацией и инструкцией по установке

🚀 Пост Guru Unity: @Minerope

Разбор вопроса с собеседований "Как работает Garbage Collector?"

Частый вопросы - и довольно стандартный ответ "Он проверяет, ссылается ли что-то на объект. Если нет, то ставит в очередь на удаление".
Но есть более каверзный вопрос, который в последнее время спрашивают довольно часто "Если у нас есть объект A, который ссылается на объект B и объект B, который ссылается на объект A - удалит ли GC эти объекты?".
Казалось бы, всё очевидно. Если GC действительно работает исключительно по ссылкам, то при такой циклической зависимости, у нас объекты не удалятся.
Оказывается нет, потому что GC работает не только по ссылкам, но и по корням.

Корни - это точки входа для поиска живых объектов: локальные переменные в стеке, регистры, статические поля, GC-handle’ы и т.п. GC начинает обход именно от этих корней и идёт по outgoing ссылкам (от объекта к тем, на кого он ссылается). Если никакой корень не ведёт к группе объектов, то эта группа останется не посещённой и будет считаться мусором - даже если внутри группы объекты сильно ссылаются друг на друга.

Раскроем детальнее, что такое outgoing и incoming ссылки.

Outgoing ссылки - это ссылки, которые объект хранит в своих полях/элементах массива и которыми он указывает на другие объекты.
Пример:

class Node { public Node Other; public string Name; }

var a = new Node();
var b = new Node();
a.Other = b;  // это outgoing ссылка из a на b
a.Name = "A";  // это поле - не ссылка (если бы Name был object/классом, это был бы outgoing)

Incoming ссылки - это ссылки на сам объект, которые хранят другие объекты или корни.
Пример:

class Owner { public Target T; }
class Target { }

var owner = new Owner();
var t = new Target();
owner.T = t;  // здесь owner.T - incoming ссылка для объекта t

Корни - это набор входных точек в граф объектов (локальные переменные, регистры, статические поля, GC-handles, очередь финализаторов и т.д.). GC начинает обход от этих точек и помечает всё достижимое. То, до чего не дошёл - считается недостижимым и может быть собран.

GC начинает с корней и идёт по outgoing ссылкам: он посещает объект, смотрит его поля (outgoing) и переходит к объектам, на которые они указывают. GC не перебирает incoming ссылки напрямую - он просто обнаружит incoming, когда придёт по outgoing ссылке от некоторого уже помеченного объекта.
Поэтому зацикл A и B (A.Outgoing -> B и B.Outgoing -> A) без корней останется непомеченным: у GC нет входной точки, чтобы пойти по outgoing к этим объектам.

Таким образом, ответ - да. GC соберёт эти объекты.

🚀 Пост Guru Unity: @Minerope