Профилирование памяти в Unity

Профилирование памяти полезно для тестирования на ограничениях памяти аппаратной платформы, уменьшения времени загрузки и сбоев, а также для совместимости вашего проекта со старыми устройствами. Это также может быть актуально, если вы хотите улучшить производительность ЦП/ГП, внося изменения, которые фактически увеличивают использование памяти. Это в значительной степени не связано с производительностью во время выполнения.

Существует два способа анализа использования памяти в вашем приложении в Unity.

Модуль профайлера памяти: Это встроенный модуль профайлера, который предоставляет основную информацию о том, где ваше приложение использует память.

Пакет профайлера памяти: Это пакет Unity, который вы можете добавить в свой проект. Он добавляет дополнительное окно профайлера памяти в редактор Unity, которое вы затем можете использовать для более детального анализа использования памяти в вашем приложении. Вы можете сохранять и сравнивать отдельные графики для поиска утечек памяти, а также просматривать структуру памяти для выявления проблем с ее фрагментацией.

С помощью этих встроенных инструментов вы можете отслеживать использование памяти, находить области приложения, где использование памяти выше ожидаемого, и находить и улучшать фрагментацию памяти.

Понимание и планирование ограничений памяти целевых устройств критически важно для многоплатформенной разработки. При проектировании сцен и уровней придерживайтесь бюджета памяти, установленного для каждого целевого устройства. Установив ограничения и рекомендации, вы можете гарантировать, что ваше приложение будет хорошо работать в рамках аппаратных спецификаций каждой платформы.

Вы можете найти спецификации памяти устройства в документации для разработчиков. Например, консоль Xbox One ограничена 5 ГБ максимальной доступной памяти для игр, работающих на переднем плане, согласно документации.

Также может быть полезно установить бюджеты контента для сложности мешей и шейдеров, а также для сжатия текстур. Все это влияет на то, сколько памяти выделяется. Эти бюджетные цифры могут быть использованы в процессе разработки проекта.

Определите физические ограничения ОЗУ

Каждая целевая платформа имеет ограничение по памяти, и как только вы его узнаете, вы можете установить бюджет памяти для вашего приложения. Используйте профайлер памяти, чтобы посмотреть на захваченный слепок. Строка «Возможности аппаратного обеспечения» (см. изображение выше) показывает размеры физической оперативной памяти (ОЗУ) и видеопамяти (VRAM). Эта цифра не учитывает тот факт, что не вся это пространство может быть доступно для использования. Тем не менее, это дает полезную ориентировочную цифру для начала работы.

Хорошая идея — сопоставить аппаратные спецификации целевых платформ, так как цифры, отображаемые здесь, могут не всегда показывать полную картину. Аппаратное обеспечение комплектов для разработчиков иногда имеет больше памяти, или вы можете работать с аппаратным обеспечением, имеющим унифицированную архитектуру памяти.

Определите аппаратное обеспечение с наименьшими спецификациями по ОЗУ для каждой поддерживаемой вами платформы и используйте это для принятия решения о бюджете памяти. Помните, что не вся эта физическая память может быть доступна для использования. Например, консоль может иметь гипервизор, работающий для поддержки старых игр, которые могут использовать часть общей памяти. Подумайте о проценте (например, 80% от общего объема) для использования. Для мобильных платформ вы также можете рассмотреть возможность разделения на несколько уровней спецификаций, чтобы поддерживать лучшее качество и функции для тех, у кого более мощные устройства.

Как только вы определите бюджет памяти, подумайте о том, чтобы установить бюджеты памяти для каждой команды. Например, ваши художники окружения получают определенное количество памяти для использования для каждого уровня или сцены, которая загружается, команда звука получает выделение памяти для музыки и звуковых эффектов и так далее.

Важно быть гибким с бюджетами по мере продвижения проекта. Если одна команда значительно укладывается в бюджет, выделите излишки другой команде, если это может улучшить области игры, над которыми они работают.

Как только вы решите и установите бюджеты памяти для ваших целевых платформ, следующим шагом будет использование инструментов профилирования, чтобы помочь вам отслеживать и контролировать использование памяти в вашей игре.

Модуль профайлера памяти предоставляет два представления: Простое и Подробное. Используйте Простое представление, чтобы получить общее представление об использовании памяти для вашего приложения. При необходимости переключитесь на Подробное представление, чтобы углубиться дальше.

Простое

Общая зарезервированная память — это «Общая отслеживаемая память Unity». Она включает в себя память, которую Unity зарезервировала, но в данный момент не использует (это значение — Общая используемая память).

Показатель используемой системной памяти — это то, что ОС считает используемым вашим приложением. Если это значение когда-либо отображает 0, имейте в виду, что это указывает на то, что счетчик профайлера не реализован на платформе, которую вы профилируете. В этом случае лучшим индикатором, на который можно полагаться, является Общая зарезервированная память. Также рекомендуется переключиться на инструмент профилирования нативной платформы для получения подробной информации о памяти в таких случаях.

Чтобы выяснить, сколько памяти используется вашим исполняемым файлом, DLL и виртуальной машиной Mono, цифры по кадрам не подойдут. Используйте детальный снимок, чтобы углубиться в такой разбор памяти.

Примечание: Дерево ссылок в детальном представлении модуля профилировщика памяти показывает только нативные ссылки. Ссылки от объектов типов, наследующих от UnityEngine.Object, могут отображаться с именем их управляемых оболочек. Однако они могут отображаться только потому, что под ними есть нативные объекты. Вы не обязательно увидите ни одного управляемого типа. Возьмем, к примеру, объект с Texture2D в одном из его полей в качестве ссылки. Используя этот вид, вы также не увидите, какое поле содержит эту ссылку. Для такого рода деталей используйте пакет профилировщика памяти.

Чтобы определить на высоком уровне, когда использование памяти начинает приближаться к бюджетам платформы, используйте следующий расчет "на салфетке":

Используемая память системы (или общая зарезервированная память, если использованная память системы показывает 0) + приблизительный запас неучтенной памяти / Общая память платформы

Когда эта цифра начинает приближаться к 100% бюджета памяти вашей платформы, используйте пакет профилировщика памяти, чтобы выяснить, почему.

Многие функции модуля профилировщика памяти были заменены пакетом профилировщика памяти, но вы все равно можете использовать модуль для дополнения ваших усилий по анализу памяти.

Например:

• Чтобы обнаружить выделения GC: Хотя они отображаются в модуле, их легче отследить с помощью Project Auditor или глубокого профилирования.
• Чтобы быстро посмотреть на использованный/зарезервированный размер кучи
• Анализ памяти шейдеров

Не забывайте профилировать на устройстве с наименьшими характеристиками для вашей общей целевой платформы при установке бюджета памяти. Тщательно следите за использованием памяти, учитывая ваши целевые ограничения.

Обычно вы захотите профилировать, используя мощную систему разработчика с большим объемом доступной памяти (важно иметь место для хранения больших снимков памяти или быстро загружать и сохранять эти снимки).

Профилирование памяти - это совершенно другая задача по сравнению с профилированием ЦП и ГП, так как оно может привести к дополнительным накладным расходам на память. Вам может потребоваться профилировать память на более мощных устройствах (с большим объемом памяти), но особенно следите за пределом бюджета памяти для устройств начального уровня.

Пункты, которые следует учитывать при профилировании использования памяти:

• Настройки, такие как уровни качества, графические уровни и варианты AssetBundle, могут иметь различное использование памяти на более мощных устройствах. Например:
• Уровень качества и графические настройки могут повлиять на размер RenderTextures, используемых для теневых карт.
• Масштабирование разрешения может повлиять на размер экранных буферов, RenderTextures и эффектов постобработки.
• Настройка качества текстур может повлиять на размер всех текстур.
• Максимальный LOD может повлиять на модели и многое другое.
• Если у вас есть варианты AssetBundle, такие как HD (высокое разрешение) и SD (стандартное разрешение), и вы выбираете, какой из них использовать в зависимости от характеристик устройства, вы также можете получить разные размеры активов в зависимости от того, на каком устройстве вы профилируете.
• Разрешение экрана вашего целевого устройства повлияет на размер RenderTextures, используемых для эффектов постобработки.
• Поддерживаемый графический API устройства может повлиять на размер шейдеров в зависимости от того, какие варианты из них поддерживаются или нет API.
• Наличие многоуровневой системы, использующей различные настройки качества, настройки графического уровня и вариации Asset Bundle, - отличный способ нацелиться на более широкий спектр устройств, например, загружая версию AssetBundle с высоким разрешением на мобильном устройстве с 4 ГБ и версию стандартного разрешения на устройстве с 2 ГБ. Тем не менее, учитывайте вышеуказанные вариации в использовании памяти и обязательно тестируйте оба типа устройств, а также устройства с различными разрешениями экрана или поддерживаемыми графическими API.

Примечание: Редактор Unity, как правило, всегда будет показывать больший объем памяти из-за дополнительных объектов, загружаемых из редактора и профайлера. Он может даже показать память активов, которая не будет загружена в память в сборке, например, из Asset Bundles (в зависимости от режима симуляции Addressables) или спрайтов и атласов, или для активов, показанных в инспекторе. Некоторые из цепочек ссылок также могут быть более запутанными в редакторе.

Профайлер памяти в настоящее время находится в предварительном просмотре для Unity 2019 LTS или новее, но ожидается, что он будет подтвержден в Unity 2022 LTS.

Одним из больших преимуществ пакета Профайлер памяти является то, что, помимо захвата нативных объектов (как это делает модуль Профайлер памяти), он также позволяет вам просматривать Управляемую память, сохранять и сравнивать снимки, а также исследовать содержимое памяти еще более подробно, с визуальным разбиением использования вашей памяти.

Снимок показывает распределение памяти в движке, позволяя вам быстро определить причины чрезмерного или ненужного использования памяти, отслеживать утечки памяти или видеть фрагментацию кучи.

После установки пакета Профайлер памяти откройте его, нажав Окно > Анализ > Профайлер памяти.

В верхней панели меню Профайлера памяти вы можете изменить целевой выбор игрока и захватить или импортировать снимки.

Примечание: Профилируйте память на целевом оборудовании, подключив Профайлер памяти к удаленному устройству с помощью выпадающего списка выбора цели. Профилирование в редакторе Unity даст вам неточные данные из-за накладных расходов, добавленных редактором и другими инструментами.

Слева от окна Профайлера памяти находится область Workbench. Используйте это для управления и открытия или закрытия сохраненных моментальных снимков памяти. Вы также можете использовать эту область для переключения между представлениями Одинарных и Сравнительных снимков.

Подобно Анализатору профилей, Профайлер памяти позволяет загружать два набора данных (моментальные снимки памяти) для их сравнения. Это особенно полезно при изучении того, как использование памяти увеличивалось со временем или между сценами, и при поиске утечек памяти.

Профайлер памяти имеет несколько вкладок в основном окне, которые позволяют вам углубиться в моментальные снимки памяти, включая Сводка, Объекты и Распределения, и Фрагментация. Давайте рассмотрим каждую из этих опций подробнее.

Выберите этот вид, когда хотите получить быстрый обзор использования памяти проекта. Он также содержит полезные и важные показатели, связанные с памятью, для захваченного моментального снимка памяти. Это идеально подходит для быстрого взгляда на то, что происходит в момент, когда был сделан снимок.

Представление «Деревянной карты» отображает разбивку памяти, используемой Объектами, в виде графической Деревянной карты, в которую вы можете углубиться, чтобы узнать, какие Объекты потребляют больше всего памяти.

Под представлением «Деревянной карты» находится отфильтрованная таблица, которая обновляется для отображения списка объектов в выбранных ячейках сетки.

Деревянная карта показывает память, относящуюся к Объектам, как Нативным, так и Управляемым. Память Управляемых Объектов, как правило, значительно меньше, чем память Нативных Объектов, что затрудняет ее обнаружение в представлении карты. Вы можете увеличить масштаб Деревянной карты, чтобы посмотреть на них, но для проверки меньших объектов таблицы обычно предоставляют лучший обзор. Щелчок по ячейкам в Деревянной карте отфильтрует таблицу ниже по типу секции и/или выберет конкретный интересующий объект в таблице.

Вы можете отследить, какие элементы ссылаются на объекты в этом списке и, возможно, в каких полях классов Управляемых находятся эти ссылки, выбрав строку таблицы или ячейку сетки Деревянной карты, представляющую ее, а затем проверив раздел «Ссылки» в боковой панели «Детали». Если боковая панель скрыта, вы можете сделать ее видимой с помощью кнопки переключения в верхней правой части окна панели инструментов.

Примечание: Деревянная карта показывает только Объекты в памяти. Это не полное представление отслеживаемой памяти. Это важно понимать, если вы заметите, что числа в Обзоре использования памяти не совпадают с общим объемом отслеживаемой памяти.

Это происходит из-за того, что не вся нативная память связана с Объектами. Она также может состоять из не связанных с Объектами Нативных Аллокаций, таких как исполняемые файлы и DLL, NativeArrays и так далее. Даже более абстрактные концепции, такие как «Зарезервированное, но неиспользуемое пространство памяти», могут влиять на общую сумму Нативных Аллокаций.

Представление объектов и распределений показывает таблицу, которую можно переключить для фильтрации на основе готовых выборок, таких как Все объекты, Все нативные объекты, Все управляемые объекты, Все нативные распределения и другие.

Вы можете переключить нижнюю таблицу, чтобы отобразить объекты, распределения или области памяти в выбранном диапазоне. Как отмечалось для представления Tree Map, не вся память связана с объектами, поэтому страницы Все области памяти и Все нативные распределения могут предоставить более полное представление о вашем использовании памяти, где области памяти также включают зарезервированную, но в настоящее время неиспользуемую память.

Используйте это в своих интересах при оптимизации использования памяти и стремлении упаковать память более эффективно для аппаратных платформ, где бюджеты памяти ограничены.

Загрузите снимок профайлера памяти и пройдите через представление Tree Map, чтобы проверить категории, упорядоченные от наибольшего к наименьшему по размеру занимаемой памяти.

Активы проекта часто являются крупнейшими потребителями памяти. Используя представление таблицы, найдите объекты текстур, сетки, аудиоклипы, рендер-текстуры, шейдеры и предварительно выделенные буферы. Все они являются хорошими кандидатами для оптимизации памяти.

Утечка памяти обычно происходит, когда:

• Объект не освобождается вручную из памяти через код
• Объект остается в памяти из-за непреднамеренной ссылки

Режим сравнения профайлера памяти может помочь найти утечки памяти, сравнивая два снимка за определенный период времени.

Распространенный сценарий утечки памяти в играх Unity может произойти после выгрузки сцены.

Пакет профайлера памяти имеет рабочий процесс, который проводит вас через процесс обнаружения этих типов утечек с использованием режима сравнения.

С помощью дифференциального сравнения нескольких снимков памяти вы можете определить источник непрерывных распределений памяти в течение времени жизни приложения.

В следующих разделах перечислены некоторые советы, которые помогут определить управляемые распределения кучи в ваших проектах.

Модуль профайлера памяти в профайлере Unity представляет управляемые распределения на кадр с помощью красной линии. Это должно быть 0 большую часть времени, поэтому любые пики в этой линии указывают на кадры, которые вы должны исследовать на предмет управляемых распределений.

Представление «Временная шкала» в модуле «Профайлер использования ЦП» показывает распределения, включая управляемые, розовым цветом, что облегчает их обнаружение и фокусировку на них.

Стеки вызовов распределения предоставляют быстрый способ обнаружения управляемых распределений памяти в вашем коде. Они предоставят вам детали стека вызовов с меньшими накладными расходами по сравнению с тем, что обычно добавляет глубокий профайлинг, и их можно включить на лету, используя стандартный профайлер.

Стеки вызовов распределения по умолчанию отключены в профайлере. Чтобы включить их, нажмите кнопку «Стеки вызовов» на основной панели инструментов окна профайлера. Измените представление «Детали» на «Связанные данные».

Примечание: Если вы используете более старую версию Unity (до поддержки стеков вызовов распределения), то глубокий профайлинг — это хороший способ получить полные стеки вызовов, чтобы помочь найти управляемые распределения.

Выборки GC.Alloc, выбранные в иерархии или сырой иерархии, теперь будут содержать свои стеки вызовов. Вы также можете увидеть стеки вызовов выборок GC.Alloc в подсказке выбора на временной шкале.

Представление «Иерархия» в профайлере использования ЦП позволяет вам щелкать по заголовкам столбцов, чтобы использовать их в качестве критериев сортировки. Сортировка по GC Alloc — отличный способ сосредоточиться на них.

Аудитор проекта — это экспериментальный инструмент статического анализа. Он выполняет много полезных задач, несколько из которых выходят за рамки этого руководства, но он может создать список каждой строки кода в проекте, которая вызывает управляемое распределение, не запуская проект. Это очень эффективный способ находить и исследовать такие проблемы.

Unity использует сборщик мусора Бёма-Демерса-Вайзера, который останавливает выполнение вашего программного кода и возобновляет нормальное выполнение только после завершения своей работы.

Будьте внимательны к ненужным распределениям в куче, которые могут вызывать всплески GC.

• Строки: В C# строки являются ссылочными типами, а не типами значений. Это означает, что каждая новая строка будет выделена в управляемой куче, даже если она используется только временно. Сократите ненужное создание или манипуляцию строками. Избегайте разбора строковых файлов данных, таких как JSON и XML, и храните данные в ScriptableObjects или в таких форматах, как MessagePack или Protobuf. Используйте класс StringBuilder, если вам нужно строить строки во время выполнения.
• Вызовы функций Unity: Некоторые функции API Unity создают выделения в куче, особенно те, которые возвращают массив управляемых объектов. Кэшируйте ссылки на массивы, а не выделяйте их в середине цикла. Также воспользуйтесь определенными функциями, которые избегают генерации мусора. Например, используйте GameObject.CompareTag вместо того, чтобы вручную сравнивать строку с GameObject.tag (так как возвращение новой строки создает мусор).
• Упаковка: Избегайте передачи переменной типа значения вместо переменной типа ссылки. Это создает временный объект, и потенциальный мусор, который с ним приходит, неявно преобразует тип значения в объект типа (например, int i = 123; object o = i). Вместо этого постарайтесь предоставить конкретные переопределения с типом значения, который вы хотите передать. Генерики также могут быть использованы для этих переопределений.
• Корутины: Хотя yield не производит мусор, создание нового объекта WaitForSeconds делает это. Кэшируйте и повторно используйте объект WaitForSeconds, а не создавайте его в строке yield, или используйте yield return null.
• LINQ и регулярные выражения: Оба из них генерируют мусор из-за упаковки за кулисами. Избегайте LINQ и регулярных выражений, если производительность является проблемой. Пишите циклы for и используйте списки в качестве альтернативы созданию новых массивов.
• Общие коллекции и другие управляемые типы: Не объявляйте и не заполняйте список или коллекцию каждый кадр в Update (например, список врагов в определенном радиусе от игрока). Вместо этого сделайте список членом MonoBehaviour и инициализируйте его в Start. Просто очищайте коллекцию с помощью Clear каждый кадр перед использованием.

Сборка мусора по времени, когда это возможно

Если вы уверены, что заморозка сборки мусора не повлияет на конкретный момент в вашей игре, вы можете вызвать сборку мусора с помощью System.GC.Collect.

Смотрите Понимание автоматического управления памятью для примеров того, как использовать это в своих интересах.

Используйте инкрементный сборщик мусора, чтобы разделить нагрузку на GC

Вместо того чтобы создавать одно длинное прерывание во время выполнения вашей программы, инкрементная сборка мусора использует несколько коротких прерываний, которые распределяют нагрузку по многим кадрам. Если сборка мусора вызывает нерегулярную частоту кадров, попробуйте этот вариант, чтобы увидеть, может ли он уменьшить проблему с пиками GC. Используйте анализатор профиля, чтобы проверить его пользу для вашего приложения.

Обратите внимание, что использование GC в инкрементном режиме добавляет барьеры чтения-записи к некоторым вызовам C#, что приводит к некоторым накладным расходам, которые могут составить ~1 мс на кадр накладных расходов вызова скрипта. Для оптимальной производительности идеально, чтобы не было GC Allocs в основных игровых циклах, чтобы вам не нужен был инкрементный GC для плавной частоты кадров и чтобы скрыть GC.Collect там, где пользователь этого не заметит, например, при открытии меню или загрузке нового уровня.

Чтобы узнать больше о Профайлере памяти, ознакомьтесь со следующими ресурсами:

• Документация по Профайлеру памяти
• Улучшите использование памяти с помощью Профайлера памяти в Unity учебник
• Профайлер памяти: Инструмент для устранения проблем, связанных с памятью сессия Unite
• Работа с Профайлером памяти сессия Unity Learn