|
|
@@ -0,0 +1,20 @@
|
|
|
+# Лекция 2: Архитектура памяти и производительность в Unreal Engine: от UObject до инкрементального GC
|
|
|
+
|
|
|
+**Unreal Engine** представляет собой не просто игровой движок, а комплексную среду выполнения реального времени, архитектура которой построена вокруг объектной модели на базе **UObject**. Для разработчика критически важно понимать, как эта модель управляет памятью и какие ценой достигается высокая производительность в проектах AAA-класса.
|
|
|
+
|
|
|
+В основе системы лежит иерархия: **UObject** является базовым классом для всех управляемых объектов, **AActor** — для объектов, которые могут быть размещены в мире, а **ActorComponent** — для модульных блоков функциональности, прикрепляемых к акторам . Все UObject'ы находятся под управлением сборщика мусора (Garbage Collector), реализующего алгоритм **"пометить-и-подмести" (mark-sweep)**. В отличие от нативных C++ объектов, где разработчик несет полную ответственность за ручное управление памятью, UObject'ы автоматически отслеживаются через систему ссылок и метаданных (FName, Outer), что неизбежно увеличивает потребление памяти .
|
|
|
+
|
|
|
+![Изображение: диаграмма иерархии классов Unreal Engine (UObject -> AActor, UActorComponent). Ключевые слова для поиска: "Unreal Engine UObject hierarchy diagram"]()
|
|
|
+### Таблица 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`) для достижения плавного геймплея без вычислительных выбросов .
|
