Уровень материала: 🐥 #middle      О реактивном программировании довольно часто упоминается, особенно в чрезмерно динамичном геймдеве. Подход очень легко начать использовать, и на первый взгляд он может показаться очень понятным. Поэтому многие новички любят брать его на вооружение и «прокачивать» свой код повсеместно. Но всё не так просто.      Я встретил хорошее видео, которое доступно поясняет устройство этой технологии. И подготовил несколько тезисов по теме.      YouTube / Dzen      📌 Что такое Rx?      Реактивное программирование — это парадигма, где код строится вокруг потоков данных и их изменений. Вместо ручного обновления состояний мы подписываемся на события (например, нажатие кнопки, изменение здоровья персонажа) и реагируем на них.      Ключевое отличие от обычных событий — это то, что здесь данные образуют поток (Observable), с которым можно взаимодействовать. Например, объединить несколько источников событий и реагировать не на все их события, а только, скажем, на первые N чётных событий, где есть данные X.      🔥 Плюсы Rx:      1. Декларативность: Поток данных позволяет использовать цепочки операторов, которые помогают организовывать логику декларативно (например, через LINQ).      2. Отписки: Все локальные подписки на поток агрегируются в IDisposable-сущность. Соответственно для отписки нужно всего лишь вызвать Dispose и не хранить делегаты, которыми производилась подписка, чтобы ими же потом отписаться.      3. Удобство: Библиотеки имеют много вспомогательных методов и специальных оберток для данных, которые позволяют быстро добавить возможность подписки на изменения.      ⚠️ Минусы Rx:      1. Оверкилл: Избыточное решение для простых единичных событий или асинхронных операций, с которыми нет необходимости работать как с потоком данных.      2. Отладка: Цепочки операторов и иерархию подписок сложно дебажить.      3. Производительность: Зависит от применяемого решения, но Rx имеет свои накладные расходы, пусть и не всегда значительные.      4. Сериализация: Реактивные обёртки для данных могут доставлять неудобства при сериализации данных и передаче по сети.      🛠️ Решения для Rx в Unity:      В Unity долгое время использовался пакет UniRx, но за последние пару лет первенство перешло к R3 от авторов популярного пакета UniTask.      Особенности последнего:      • Новый модный и на активной поддержке (UniRx - всё, и даже автор просит переходить на R3).      • Не ограничивается Unity и поддерживает другие движки.      • Улучшенная производительность и меньше аллокаций.      • Поддержка «покадровых» операций в игровых движках.      • Полноценная поддержка async/await операций «из коробки».      • Улучшен контроль за утечками памяти.     👨‍💻 Моё отношение:    В «юные годы» меня сильно привлекла декларативность, которую даёт Rx. Но, пережив несколько игровых проектов на этой технологии и попробовав разнообразные сценарии, все обозначенные минусы сильно перевесили плюсы. Поэтому вывод, к которому я пришёл, — этого должно быть так же в меру, как и всего остального.    Rx, как, например, не менее популярный Zenject (именно он, не DI в целом), дают слишком широкий простор возможностей и сценариев использования. Это в будущем создаёт разнообразные проблемы и сложности, разрешить которые может оказаться намного сложнее, чем не поддаваться искушению изначально.    Я бы рекомендовал сначала обкатать технологию на пет-проектах всеми возможными способами, прощупать свои личные границы удобства и изучить долгосрочные последствия принятых решений.    А вне «песочницы»: если нормально живётся без Rx — скорее всего, он не нужен. Rx — это, в первую очередь, про потоки данных. Где работа с такими потоками не нужна, запрягать Rx и нет необходимости.    🔩 Частые сценарии использования:    • Необходимость объединения и/или фильтрации событий от разных источников.    • Сложная обработка событий.    • Обработка ввода от игрока.  • Связь визуального слоя с игровыми данными.    • Контроль событий, распределённых во времени (таймеры, задержки и пр.).