Попков.md 5.4 KB
Лекция 2: Архитектура памяти и производительность в Unreal Engine: от UObject до инкрементального GC
Unreal Engine представляет собой не просто игровой движок, а комплексную среду выполнения реального времени, архитектура которой построена вокруг объектной модели на базе UObject. Для разработчика критически важно понимать, как эта модель управляет памятью и какие ценой достигается высокая производительность в проектах AAA-класса.
В основе системы лежит иерархия: UObject является базовым классом для всех управляемых объектов, AActor — для объектов, которые могут быть размещены в мире, а ActorComponent — для модульных блоков функциональности, прикрепляемых к акторам . Все UObject'ы находятся под управлением сборщика мусора (Garbage Collector), реализующего алгоритм "пометить-и-подмести" (mark-sweep). В отличие от нативных C++ объектов, где разработчик несет полную ответственность за ручное управление памятью, UObject'ы автоматически отслеживаются через систему ссылок и метаданных (FName, Outer), что неизбежно увеличивает потребление памяти .
Таблица 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) для достижения плавного геймплея без вычислительных выбросов .