# Лекция 2: Архитектура памяти и производительность в Unreal Engine: от UObject до инкрементального GC

**Unreal Engine** представляет собой не просто игровой движок, а комплексную среду выполнения реального времени, архитектура которой построена вокруг объектной модели на базе **UObject**. Для разработчика критически важно понимать, как эта модель управляет памятью и какие ценой достигается высокая производительность в проектах AAA-класса.

В основе системы лежит иерархия: **UObject** является базовым классом для всех управляемых объектов, **AActor** — для объектов, которые могут быть размещены в мире, а **ActorComponent** — для модульных блоков функциональности, прикрепляемых к акторам . Все UObject'ы находятся под управлением сборщика мусора (Garbage Collector), реализующего алгоритм **"пометить-и-подмести" (mark-sweep)**. В отличие от нативных C++ объектов, где разработчик несет полную ответственность за ручное управление памятью, UObject'ы автоматически отслеживаются через систему ссылок и метаданных (FName, Outer), что неизбежно увеличивает потребление памяти .


![Alt](unr.png)
### Таблица 1. Сравнение подходов к управлению памятью в Unreal Engine
| Тип объектов | Управление | Преимущества | Недостатки |
| -------- | -------- | -------- | -------- |
| **UObject (управляемые)** | Автоматическое (GC) | Безопасность ссылок, подсчет ссылок, интеграция с редактором | Накладные расходы памяти, возможные фризы |
| **Нативные C++ объекты** | Ручное (new/delete) | Максимальная производительность, контроль над аллокацией | Риск утечек и висячих ссылок (dangling pointers) |

Ключевая проблема классического GC в играх — это **фризы (hitches)**, возникающие при анализе достижимости (reachability analysis), когда сборщик останавливает мир для сканирования всех объектов. Начиная с UE5, движок предлагает экспериментальное решение — **инкрементальный GC**. Эта функция позволяет разнести анализ достижимости на несколько кадров, устанавливая мягкий лимит времени на кадр (например, 2 мс через параметр `gc.IncrementalReachabilityTimeLimit`) .

Инкрементальный режим использует **барьер записи (write barrier)** через умный указатель `TObjectPtr`. При присвоении значения свойству `UPROPERTY` во время сборки мусора объект немедленно помечается как достижимый. Однако важно знать ограничение: технология не является полностью потокобезопасной и рекомендуется к применению в однопоточных сборках (например, на выделенных серверах) .

Для снижения нагрузки на GC инженеры применяют **пулинг объектов (Object Pooling)**. Вместо постоянного спавна и уничтожения снарядов или врагов, пул предварительно создает фиксированное количество экземпляров, активируя и деактивируя их по мере необходимости. Это позволяет избежать дорогостоящих операций создания/уничтожения и сопутствующих пиков процессорной активности, расплачиваясь за это резервированием памяти .

Понимание этих механизмов позволяет разработчику осознанно проектировать игровую логику: избегать избыточного использования `Tick` в пользу событийной модели, применять пулы для часто спавнящихся объектов и настраивать параметры сборки мусора (например, в `DefaultEngine.ini` через `gc.AllowIncrementalReachability=1`) для достижения плавного геймплея без вычислительных выбросов .