Обращал ли внимание на память при оптимизации с профайлером

Работа с памятью в Unity: системный подход к оптимизации

Да, управление памятью – один из фундаментальных и первоочередных аспектов, на которые я обращаю внимание при оптимизации с помощью Unity Profiler. В контексте мобильных устройств и игр с высокой нагрузкой это не просто "хорошая практика", а критически важная задача для стабильного FPS и предотвращения просадок, вызванных сборкой мусора (Garbage Collection, GC). Работа с памятью в Unity – это не только отслеживание утечек, но и контроль частоты и объема аллокаций в куче (heap).

Ключевые инструменты Profiler для анализа памяти

1. Memory Profiler (Deep Profile): Дает полную картину распределения памяти: нативные аллокации движка, управляемый heap, текстуры, меши, аудио и т.д. Позволяет найти самые "прожорливые" ассеты.
2. CPU Profiler (с включенной опцией Deep Profiling или GC Alloc): Самый главный инструмент для борьбы с "мусором". Колонка GC Alloc показывает объем памяти, выделенной в управляемой куче во время конкретного вызова метода. Цель – минимизировать эти аллокации внутри игрового цикла (Update, FixedUpdate, LateUpdate).

Основные источники аллокаций и стратегии их устранения

• Строки (Strings): Классический источник проблем. Конкатенация строк в цикле, частые вызовы ToString() (особенно для векторов, позиций трансформаций), парсинг JSON/XML создают огромное количество мусора.

    **Решение:** Использовать `StringBuilder`, кешировать результаты, использовать `StringComparison.Ordinal` в методах сравнения, избегать дебаг-логов в релизной сборке.

```csharp
// Плохо: аллокация на каждом кадре
void Update() {
    uiText.text = "Score: " + currentScore;
}

// Лучше: обновлять текст только при изменении значения
private int _cachedScore;
void Update() {
    if (_cachedScore != currentScore) {
        _cachedScore = currentScore;
        // Можно использовать StringBuilder или заранее подготовленный формат
        uiText.text = $"Score: {currentScore}"; // Интерполяция создает меньше мусора, чем конкатенация "+", но все же аллоцирует
    }
}
```

• Коллекции (List, Dictionary, Array): Создание новых коллекций внутри часто вызываемых методов, особенно List<T> без указания емкости (capacity), что приводит к многократным переаллокациям и копированию данных.

    **Решение:** Переиспользовать коллекции, использовать пулы (object pooling), задавать начальную емкость, использовать структуры (`struct`) вместо классов (`class`) там, где это уместно (но с осторожностью из-за копирования).

```csharp
// Хорошая практика: переиспользование коллекции
private List<Enemy> _enemiesCache = new List<Enemy>(100); // Предустановленная емкость

void FindAllEnemies() {
    _enemiesCache.Clear(); // Очистка без новой аллокации
    GameObject[] allObjects = GameObject.FindGameObjectsWithTag("Enemy");
    // ... заполнение _enemiesCache
}
```

• LINQ и корутины (yield): Несмотря на удобство, большинство операций LINQ (Where, Select, First) аллоцируют память под итераторы и делегаты. Корутины, в свою очередь, аллоцируют объекты при каждом вызове yield return.

    **Решение:** В высоконагруженных участках кода заменять LINQ на прямые циклы `for`/`foreach`. Для часто запускаемых корутин использовать пуллинг или переходить на UniTask (C# 7.0+ и сторонний плагин), который минимизирует аллокации через использование `ValueTask` и структур.

• Мгновенное создание/уничтожение объектов (Instantiate/Destroy): Это не только аллокации в управляемой куче, но и дорогие нативные вызовы.

    **Решение:** Повсеместное использование **Object Pooling**. Заранее созданный массив переиспользуемых объектов сводит аллокации и сборку мусора к нулю в процессе игры.

• События (Events) и делегаты: Подписка на события через анонимные методы или лямбда-выражения (OnClick.AddListener(() => DoSomething())) может создавать аллокации для замыканий.

    **Решение:** Использовать ссылки на именованные методы.

Рабочий процесс оптимизации

1. Базовая проверка: Запустить Memory Profiler, сделать снимок (snapshot), оценить общий объем, найти крупнейшие ассеты. Возможно, текстура 4K используется для объекта размером в 50 пикселей на экране.
2. Фокус на GC Alloc: Включить GC Alloc в CPU Profiler, проанализировать 30-60 секунд геймплея. Отсортировать по убыванию аллокаций.
3. Прицельная работа: Найти топ-3 метода, генерирующих больше всего мусора, и применить указанные выше стратегии.
4. Проверка на платформе: Профилировать на целевой платформе (Android, iOS), так как аллокации и поведение памяти могут отличаться от редактора.

Вывод: Внимание к памяти – это постоянный процесс, а не разовая акция. Моя цель при профилировании – не просто сделать игру "быстрой", а сделать ее предсказуемой, обеспечивая плавный игровой процесс без "фризов" из-за внезапной работы сборщика мусора. Мониторинг GC Alloc и управление жизненным циклом объектов лежат в основе этого подхода.