Рекомендации по производительности для Unity

Статья
03/21/2023

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

Недавно мы выпустили приложение Quality Fundamentals, которое позволяет решить распространенные проблемы с производительностью, проектированием и средами для приложений HoloLens 2. Это приложение отлично подходит для демонстрации приведенного ниже содержимого.

Скачать приложение Quality Fundamentals

Использование рекомендуемых параметров проекта Unity

Самый важный шаг при оптимизации производительности приложений смешанной реальности в Unity — использовать рекомендуемые параметры среды для Unity. В этой статье содержится информация о самых важных конфигурациях сцены для создания производительных приложений смешанной реальности. Некоторые из этих рекомендаций отдельно выделены ниже.

Профилирование с помощью Unity

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

Для Unity доступна замечательная документация по следующим темам:

Профилирование GPU

Профилировщик Unity

Подключив профилировщик Unity и добавив профилировщик GPU с помощью действия Add Profiler (Добавить профилировщик) в верхнем правом углу, в средней области профилировщика вы увидите, сколько времени тратится на работу центрального и графического процессоров. Это позволяет разработчику быстро получить приближенные сведения о требованиях приложения к ЦП или GPU.

ЦП и GPU в Unity

Примечание

Чтобы использовать профилирование GPU, необходимо отключить задания графики в параметры проигрывателя Unity. Дополнительные сведения см. в описании модуля профилировщика использования GPU для Unity.

Отладчик фреймов Unity

Еще одним функциональным и ценным инструментом для работы является отладчик фреймов Unity. Он позволяет хорошо понять, что GPU делает в каждым фрейме. Следует обращать внимание на дополнительные целевые объекты отрисовки и команды blit для копирования между ними, так как на HoloLens они очень дороги. В идеале для HoloLens не следует использовать целевые объекты отрисовки вне экрана. Они обычно добавляются при включении дорогостоящих функций отрисовки (например, MSAA, HDR или полноэкранных эффектов, таких как цветение), которые следует избегать.

Наложение частоты кадров HoloLens

На странице System Performance (Производительность системы) портала устройств есть полезная сводка по производительности ЦП и GPU устройства. Здесь можно включить параметры Display frame rate counter in headset (Счетчик частоты кадров отображения в гарнитуре) и Display frame rate graph in headset (График частоты кадров отображения в гарнитуре). Эти параметры активируют счетчик и график частоты кадров соответственно, что позволяет моментально оценить работу любого запущенного на устройстве приложения.

PIX

Для профилирования приложений Unity также можно использовать PIX. Кроме того, доступны подробные инструкции по использованию и установке PIX для HoloLens 2. В сборке разработки области, которые отображаются в отладчике фреймов Unity, также доступны в PIX для более подробного просмотра и профилирования.

Примечание

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

UnityEngine.XR.XRSettings.renderViewportScale = 0.7f;

Рекомендации по производительности ЦП

Ниже приводятся более подробные рекомендации по производительности, которые особенно касаются разработки на C# в Unity.

Кэширование ссылок

Мы рекомендуем кэшировать ссылки на все важные компоненты и игровые объекты во время инициализации, так как повтор вызовов функций, например GetComponent<T>() и Camera.main, требует больше ресурсов памяти чем хранение указателя. . Camera.main фактически использует FindGameObjectsWithTag() для выполнения ресурсоемкого поиска объекта камеры в графе сцены по тегу MainCamera.

using UnityEngine;
using System.Collections;

public class ExampleClass : MonoBehaviour
{
    private Camera cam;
    private CustomComponent comp;

    void Start() 
    {
        cam = Camera.main;
        comp = GetComponent<CustomComponent>();
    }

    void Update()
    {
        // Good
        this.transform.position = cam.transform.position + cam.transform.forward * 10.0f;

        // Bad
        this.transform.position = Camera.main.transform.position + Camera.main.transform.forward * 10.0f;

        // Good
        comp.DoSomethingAwesome();

        // Bad
        GetComponent<CustomComponent>().DoSomethingAwesome();
    }
}

Примечание

Отказ от использования GetComponent(string)
При использовании GetComponent() существует несколько разных перегрузок. Важно всегда использовать реализации на основе конкретных типов, но не перегрузку поиска на основе строк. Поиск по строке в сцене значительно дороже, чем поиск по типу.
(Хорошо) Component GetComponent(Type type)
(Хорошо) T GetComponent<T>()
(Плохо) Component GetComponent(string)>

Отказ от дорогостоящих операций

Отказ от использования LINQ

Хотя запросы LINQ могут быть очень понятыми и простыми для чтения и записи, обычно они требуют больше ресурсов для вычислений и хранения по сравнению с использованием написанных вручную алгоритмов.
```
// Example Code
using System.Linq;

List<int> data = new List<int>();
data.Any(x => x > 10);

var result = from x in data
             where x > 10
             select x;
```
Распространенные API Unity

Некоторые API Unity при всей очевидной пользе могут быть достаточно ресурсоемкими. Большинство из них выполняют поиск соответствующих игровых объектов по всему графу сцены. Обычно этих операций можно избежать, кэшируя ссылки или создав компонент управления игровыми объектами для отслеживания ссылок во время выполнения.
```
    GameObject.SendMessage()
    GameObject.BroadcastMessage()
    UnityEngine.Object.Find()
    UnityEngine.Object.FindWithTag()
    UnityEngine.Object.FindObjectOfType()
    UnityEngine.Object.FindObjectsOfType()
    UnityEngine.Object.FindGameObjectsWithTag()
    UnityEngine.Object.FindGameObjectsWithTag()
```

Примечание

Удалите все SendMessage() и BroadcastMessage() любой ценой. Эти функции работают на три порядка медленнее, чем прямые вызовы функций.

Остерегайтесь упаковки-преобразования

Концепция упаковки-преобразования очень важна в языке и среде выполнения C#. Так называют процесс создания переменных со ссылочным типом в виде оболочек для переменных со значениями типа, такими как char, int, bool и т. д. Если переменная со значением типа "упакована", она помещается в объект System.Object, который хранится в управляемой куче. Для нее выделяется память и ее нужно обрабатывать сборщиком мусора после освобождения. Такие процессы выделения и освобождения ресурсов приводят к снижению производительности, а во многих случаях их можно убрать или легко заменить на менее дорогостоящую альтернативу.

Чтобы избежать упаковки, убедитесь, что переменные, поля и свойства, в которых хранятся числовые типы и структуры (включая Nullable<T>), строго типизированы как конкретные типы, такие как int, float? или MyStruct, вместо использования объекта. Если эти объекты помещаются в список, обязательно используйте строго типизированный список, например List<int>, а не List<object> или ArrayList.

Пример упаковки-преобразования в C#
```
// boolean value type is boxed into object boxedMyVar on the heap
bool myVar = true;
object boxedMyVar = myVar;
```

Повторяющиеся пути кода

Нужно уделять особое внимание всем повторяющимся функциям обратного вызова Unity (т. е. обновления), которые выполняются много раз за секунду и (или) кадр. Любые дорогостоящие операции в этом коде будут иметь огромное и стабильное влияние на производительность.

Пустые функции обратного вызова

Несмотря на внешнюю безобидность приведенного ниже кода приложения, эти пустые обратные вызовы могут быть очень ресурсоемкими, особенно учитывая, что каждый скрипт Unity выполняет автоматическую инициализацию с помощью метода Update. Unity придется постоянно переключаться между неуправляемой и управляемой частью кода, то есть между кодом UnityEngine и кодом приложения. Такое переключение контекста на этой границе требует много ресурсов, даже если не выполняется никаких действий. Это особенно проблематично, если приложение использует сотни игровых объектов, компоненты которых имеют повторяющиеся пустые обратные вызовы Unity.
```
void Update()
{
}
```

Примечание

Update() служит самым ярким примером этой проблемы с производительностью, но некоторые другие повторяющиеся обратные вызовы Unity могут оказаться не менее или даже более серьезными, как например следующие: FixedUpdate(), LateUpdate(), OnPostRender(), OnPreRender(), OnRenderImage() и т. п.

Однократное выполнение операций для каждого кадра

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

а) Мы рекомендуем выделить один отдельный класс или службу, чтобы обработать Raycast для взгляда на сцену и повторно использовать полученный результат во всех остальных компонентах сцены, не повторяя идентичные операции Raycast для каждого компонента. В некоторых приложениях нужно выполнять Raycast из разных позиций или с разными LayerMask.
```
    UnityEngine.Physics.Raycast()
    UnityEngine.Physics.RaycastAll()
```
б) Избегайте операций с методом GetComponent() в повторяющихся обратных вызовах Unity, таких как Update(), используя кэширование ссылок в Start () или Awake().
```
    UnityEngine.Object.GetComponent()
```
в) Мы рекомендуем по возможности создавать экземпляры всех объектов при инициализации и применять пулы объектов для повторного использования игровых объектов в ходе работы приложения.
```
    UnityEngine.Object.Instantiate()
```
Отказ от использования интерфейсов и виртуальных конструкций

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

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

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

Прочее

Физика

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

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

Сфера < Капсула < Коробка <<< Сетка (выпуклая) < Сетка (невыпуклая)

Дополнительные сведения см. в статье с рекомендациями по обработке физики в Unity.
Анимации

Избавьтесь от анимации простоя, отключив компонент Animator (отключение объекта Game не дает такого эффекта). Избегайте шаблонов разработки, в которых аниматор в цикле постоянно присваивает значение одному параметру. Такой метод создает значительную нагрузку на ресурсы без видимого эффекта в приложении. Дополнительные сведения доступны здесь.
Сложные алгоритмы

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

Рекомендации по производительности GPU

Дополнительные сведения об оптимизации отрисовки графических объектов в Unity см. здесь.

Пропуская способность и скорость заливки

При отрисовке кадра на GPU возможности приложения ограничены пропускной способностью памяти или скоростью заливки.

Пропускная способность памяти — это скорость операций чтения и записи из памяти, которую может обеспечить GPU.
- В Unity измените параметр Texture Quality (Качество текстур) в меню Edit>Project Settings>Quality Settings (Правка — Параметры проекта — Параметры качества).
Скорость заливки — это число пикселей, которое может отрисовывать GPU в секунду.
- В Unity используйте свойствоXRSettings.renderViewportScale.

Рекомендуется включить общий доступ к буферу глубины , чтобы оптимизировать стабильность голограммы. При включении репроецирования на поздних этапах с помощью этого параметра рекомендуется выбрать 16-разрядный формат глубины вместо 24-разрядного . 16-разрядные буферы глубины существенно снизят нагрузку на пропускную способность (передачу данных) для буфера глубины, а значит и энергопотребление. Это может быть большим улучшением как в плане снижения энергопотребления, так и в плане производительности. Но использование 16-разрядного формата глубины может иметь два неприятных последствия.

Z-конфликт

Снижение четкости по глубине при 16-разрядном буфере повышает вероятность Z-конфликтов по сравнению с 24-разрядными буферами. Чтобы избежать таких артефактов, измените ближнюю и дальнюю отсекающие плоскости для камеры Unity с учетом снижения разрешения. Для приложений на основе HoloLens дальняя плоскость обрезки в 50 м вместо стандартного для Unity значения 1000 м обычно полностью устраняет Z-конфликты.

Отключение буфера трафаретов

Если Unity создает текстуру отрисовки с 16-разрядной глубиной, буфер трафаретов не создается. Выбор 24-разрядного формата глубины, как описано в документации по Unity, приведет к созданию 24-разрядного Z-буфера и 8-разрядного буфера трафарета (если 32-разрядная версия применима на устройстве (например, HoloLens), что обычно бывает).

Отказ от полноэкранных эффектов

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

Оптимальные параметры освещения

Глобальное освещение в реальном времени в Unity дает потрясающие визуальные результаты, но требует довольно ресурсоемких вычислений. Мы рекомендуем отключать глобальное освещение в реальном времени для всех сцен Unity. Для этого нужно в разделе Window>Rendering>Lighting Settings> (Окно > Отрисовка > Параметры освещения) снять флажок Real-time Global Illumination (Глобальное освещение в реальном времени).

Более того, мы рекомендуем отключить все тени, так как они требуют дополнительных ресурсов GPU для сцены Unity. Тени можно отключать отдельно для каждого источника света или глобально через параметры качества.

Выберите Edit>Project Settings (Редактировать > Свойства проекта), затем категорию Quality> (Качество) и укажите вариант Low Quality (Низкое качество) для платформы UWP. Можно также отдельно указать для свойства Shadows (Тени) значение Disable Shadows (Отключить тени).

С моделями в Unity рекомендуется использовать просчитанное освещение (baked lighting).

Уменьшение количества многоугольников

Количество полигонов можно снизить следующими способами:

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

Общие сведения о шейдерах в Unity

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

Выберите нужный ресурс шейдера или материал, затем в верхнем правом углу окна Inspector (Инспектор) выберите значок шестеренки и действие Select Shader (Выбрать шейдер).
После выбора ресурса шейдера нажмите кнопку Compile and show code (Компилировать и показать код) в окне Inspector (Инспектор).
После компиляции найдите раздел статистики в области результатов, где отображается число разных операций для вершинных и пиксельных шейдеров (учтите, что пиксельные шейдеры часто называют фрагментными).

Оптимизация пиксельных шейдеров

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

Таким образом, фрагментные шейдеры не только выполняют больше операций, чем вершинные (из-за сложных вычислений освещения) но и почти всегда применяются к более крупному набору данных. Например, при размере экрана 2000 на 2000 пикселей фрагментный шейдер будет выполнен 2000 × 2000 = 4 000 000 раз. При отрисовке для двух глаз это число удваивается, так как работают сразу два экрана. Если приложение смешанной реальности использует несколько проходов, полноэкранные эффекты постобработки или отрисовку нескольких сеток в пределах одного пикселя, это количество еще значительно увеличится.

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

Альтернативы стандартному шейдеру Unity

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

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

Предварительная загрузка шейдера

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

Ограничение перерисовки

В Unity можно отобразить перерисовку сцены, переключившись на меню режима отрисовки в верхнем левом углу представления сцены и выбрав параметр Overdraw (Перерисовка).

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

Производительность при запуске

Мы рекомендуем начать работу приложения с небольшой сцены, а затем загружать остальную часть с помощью SceneManager.LoadSceneAsync . Это позволит приложению максимально быстро перейти к интерактивному состоянию. При активации новой сцены создается пиковая нагрузка на ЦП, что может привести к подвисанию или отрывистому отображению содержимого. Для обхода этой проблемы можно установить для параметра загружаемой сцены AsyncOperation.allowSceneActivation значение False, затем дождаться полной загрузки сцены, очистить экран и вернуть этому параметру значение True для завершения активации сцены.

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

Рекомендации по производительности для Unity

Использование рекомендуемых параметров проекта Unity