Такой инструмент, как Unity-профайлер, облегчает оптимизацию игры и предоставляет конкретные данные о её производительности. Вы можете получить покадровые показатели, посредством которых выявить проблемные места гораздо легче. Кроме того, профайлер предоставляет информацию об игровой производительности вне редактора.
Инструмент, безусловно, полезный, однако нужно учитывать, что его применение частично сказывается на производительности игры. И, чтобы повысить точность показателей производительности, следует создать билд для нужной платформы, а потом запустить вашу игру на целевом устройстве.
Если мы хотим активировать профайлер в приложении, следует в окне Build Settings (File→Build Settings) включить параметры Autoconnect Profiler и Development Build. После запуска приложения профайлер станет запускаться автоматически. Вдобавок к этому, вы можете подключить профайлер в Profiler Controls, используя выпадающий список в редакторе.
Итак, профайлер предоставит нам информацию о том, сколько времени нужно приложению на рендер каждого кадра, разбив это на память, рендер, работу процессора, физику, аудио, сеть и UI. Однако тут важно заметить, что не стоит сравнивать показания профайлеров разных Unity-версий. Дело в том, что различные архитектуры профайлеров отображают показания по-разному.
ПОВ: Ты моб в Майнкрафт
Выполняем профилирование в редакторе
Нельзя забывать о подводных камнях профилирования в редакторе. Например, большое количество открытых окон может привести к тому, что начнут проскакивать лаги. Мало того, даже рендер в самом редакторе порой даёт о себе знать. Именно поэтому очень важно хотя бы время от времени профилировать ваше приложение на целевом устройстве, не полагаясь лишь на данные из редактора.
Deep Profile
Это режим, в котором происходит отдельная запись вызовов каждого метода, в результате чего обеспечивается чёткое представление дерева методов. Тут следует вспомнить, что, начиная с Unity версии 2017.3, режим Deep Profile работает не только в редакторе, но также на Android и Desktop с применением бэкенда Mono.
Чтобы включить режим Deep Profile, задействуйте такой аргумент командной строки, как -deepprofiling. А если хотите включить данный режим на Android, вам подойдёт аргумент adb.
~$ adb shell am start -n com.company.game/com.unity3d.player.UnityPlayerActivity -e ‘unity’ ‘-deepprofiling’
Профилируем память в редакторе
Процесс профилирования памяти в редакторе полезен для понимания общей модели памяти, однако малополезен для фактических показателей конкретных устройств.
Здесь нужно отметить следующее: — во время выполнения у каждого меша флаг read/write установлен вне зависимости от значения Read/Write Enabled в настройках импорта ассета. В результате удваивается память мешей, отображаемая в профайлере; — процесс профилирования в редакторе отключает сжатие вершин (Vertex Compression); — при выполнении приложения в редакторе формируется больше временных данных в памяти. Тот же GetComponent при отсутствии компонента выделит под него временную память. В итоге Unity может выбросить исключение в редакторе, не сделав это в билде.
Статистика рендера
В Unity существует функция отображения статистики рендера в режиме реального времени (окно Game). Туда включены батчи draw calls, fps, применение VRAM, число вершин и треугольников. Чтобы включить слой статистики, нажмите на кнопку Stats, которая расположена на панели окна Game. Данная статистика поможет вам анализировать батчинг и GPU-производительность на основе количества вызовов отрисовки.
Статистика в окне Game:
Если нужна более детальная статистика рендера по каждому кадру, откройте вкладку рендера в профайлере:
На картинке выше заметно, что пустая сцена имеет пять вызовов SetPass и пять вызовов отрисовки.
На что тут следует обратить внимание: — число вызовов SetPass имеет важную роль, ведь оно плохо влияет на производительность. И число данных вызовов должно быть как можно меньше; — Draw calls (вызовы отрисовки) — параметр менее важный, если приложение не зависит от производительности процессора. Связано это с тем, что вызовы отрисовки выполняются в рендеринговом потоке, запускаемом на процессоре. Для снижения зависимости от производительности процессора можно использовать многопоточный рендеринг.
Вызовы отрисовки
Если говорить о частых вызовах отрисовки с похожими пайплайнами, то они влияют на производительность лучше, чем редкие вызовы с разными пайплайнами. При этом Unity кеширует одинаковые вызовы, в результате чего процесс отрисовки ускоряется. И Unity создаёт разные буферы для разных вызовов, что загружает графическую память.
Graphics Jobs и многопоточный рендер
Graphics Jobs (Player Settings) и многопоточный рендер в большинстве случаев позитивно влияют на производительность, однако в процессе отладки и профилирования ряд показателей может быть «размытым». Если интересует более точное профилирование, вам будет полезно глянуть на оптимизацию графики в Unity.
Кадровый отладчик
Остановить процесс игры на конкретном кадре и пройтись по основным событиям позволяет кадровый отладчик. Посредством его вы сможете проверить, каким образом Unity выстраивает сцену, что позволит вам прикинуть возможные способы оптимизации. Кроме того, отладчик указывает на те GameObject’ы, рендер которых необязателен. В принципе, вы можете отключить эти GameObject’ы, уменьшив количество вызовов отрисовки на один кадр.
Кадровый отладчик не показывает отдельные вызовы отрисовки, как не показывает он и разницу между ними. Зато он показывает сам процесс построения кадра. Лишь нативные GPU-профайлеры дают подробную информацию о вызовах отрисовки (как правило, привязанную ко времени). Ещё отладчик будет полезен при отладке пайплайна и батчинга (в особенности, если вы работаете с Unity UI). Впрочем, подробную информацию лучше смотреть в документации.
Профайлер памяти
Вот пример проекта, где демонстрируется применение профайлера памяти. Кстати, по нему тоже есть прекрасная документация. Ниже представлен снимок с профайлера памяти:
Этот инструмент отслеживает память, которая выделена подсистемами Unity и пользовательскими скриптами (до версии 2017.3). При этом профайлер не способен отслеживать выделение памяти из сторонних инструментов. Зато, начиная с Unity 2017.3, профайлер поддерживает отслеживание управляемых объектов в среде выполнения Mono scripting.
Подробнее о профайлере смотрите в официальной документации. Кстати, есть и толковое видео.
Источник: myunity.dev
Практические рекомендации по повышению производительности вашей игры на Unity. Часть 1
Когда мы делаем игры, мы часто не уделяем должного внимания одному из самых важных аспектов разработки игры — оптимизации. В результате мы получаем лаги и низкий FPS (иногда даже на High-end устройствах, если все совсем уж запущенно). Большинство людей всегда будет рассматривать оптимизацию игры как последний этап, и именно это является первой ошибкой — она всегда должна быть первым пунктом в списке.
Невозможно переоценить привычку при каждой сборке, каждый день, когда вы добавляете новую механику или новую настройку освещения, или какие угодно системы, основанные на физике, в вашу игры, всегда проверять билд, не возникли ли какие-либо проблемы с производительностью из-за этих изменений — это хорошая практика разработки игр.
Если вы не потратите время на оптимизацию производительности с самого начала работы над проектом, на финальном этапе это может вылиться в проблемы для вас и вашей игры. Здесь я хочу поделиться некоторыми мыслями и советами о том, как вы можете повысить производительность вашей игры, основываясь на нескольких практических выводах, которые я извлек из своих ошибок за последние 5 лет.
Профилируйте свою игру
Профайлер (Profiler) — первый в списке и один из моих самых любимых инструментов в Unity для мониторинга производительности игры с целью узнать, что на самом деле вызывает проблемы с производительностью. Он очень полезен для получения подробного представления о том, как ваша игра реагирует на различные изменения в редакторе.
Вы можете найти Profiler в Window->Analysis->Profiler
Он отображает такие категории, как использование CPU и GPU, рендеринг, физику, аудио и многое другое. Мы не можем полагаться на профилирование в редакторе (Editor Profiling), поскольку редактор влияет на производительность проекта во время тестирования, а это может влиять на достоверность информации профилирования. Для получения точных данных профилирования лучше создавать отдельный билд.
Удаленное профилирование (Remote profiling)
Чтобы заставить его работать, вам необходимо установить Android SDK и подключить JDK и USB дебаггинг. Помните, что всегда полезно тестировать, как работает ваша игра, когда речь идет о механике, масштабировании пользовательского интерфейса и т. д. Не говоря уже о тестировании реальной производительности в игре вкупе с вышеперечисленным. Чтобы протестировать реальную производительность игры, вам нужно создать специальный билд для профилирования.
Чтобы подключить Remote Profiler, перейдите в меню Edit > Project Settings > Editor и в разделе Device выберите Any Android Device.
Билд для профилирования
Чтобы убедиться, что Unity имеет доступ к вашему билду, который можно профилировать, вы должны включить “Development build or Deep Profiling Support” и “Auto-connect Profiler” в настройках билда перед его созданием. Это позволяет редактору Unity автоматически подключать ваш билд.
Когда ваша бид будет готов, не закрывая окно Unity Profiler откройте свою игру. Теперь Unity будет автоматически отображать данные о производительности текущего билда игры в окне профайлера.
Узнать о профайлере больше вы можете здесь.
Батчинг GameObject-ов
Батчинг (Batching, или пакетная обработка) — очень хороший метод повышения производительности за счет сокращения количества вызовов Draw, который представляет из себя группирование рендеринга нескольких похожих GameObject-ов в одном вызове draw. Существует два типа методов батчинга: статический и динамический. Для батчинга существуют некоторые ограничения — мы не можем выполнять пакетную обработку skinned мешей, ткани и некоторых компонентов рендеринга.
Статический батчинг
Статический батчинг (Static Batching) используется всякий раз, когда GameObject-ы статические. Такие статические GameObject-ы не должны перемещаться, масштабироваться или вращаться, а также должны использовать один и тот же материал для всех статических GameObject-ов, чтобы батчинг работал.
Если ваши GameObject-ы не взаимодействует с вашим Player или если вы не меняете Transform, то лучше всего использовать статический батчинг для большинства вариантов среды в вашей игре, таких как здания, дороги и т. д.
Динамический батчинг
Динамический батчинг (Dynamic Batching) похож на статический в том, что для GameObject-ов должны использоваться те же материалы, но может группировать движущиеся объекты без необходимости делать их статическими. По сути, Unity может автоматически загружать GameObject-ы в один и тот же вызов отрисовки, если они используют один и тот же материал, но на них накладываются некоторые ограничения динамической пакетной обработки в соответствии с Unity:
- Пакетная обработка динамических GameObject-ов имеет определенные накладные расходы на каждую вершину, поэтому пакетная обработка применяется только к сеткам, содержащим не более 300 вершин и не более 900 атрибутов вершин.
- Если ваш Shader использует Vertex Position, Normal и один UV, вы можете группировать до 300 вершин, но если ваш Shader использует Vertex Position, Normal, UV0, UV1 и Tangent, то только 180 вершин.
- : ограничение количества атрибутов может измениться в будущем.
- GameObject-ы не обрабатываются пакетно, если они содержит зеркальное отражение в transform (например, GameObject A со скейлом +1 и GameObject B со скейлом –1 не могут быть объединены вместе).
- Использование разных экземпляров Material приводит к тому, что GameObject-ы не объединяется в пакет, даже если они по сути одинаковы. Исключение составляет рендеринг Shadow Caster.
- Игровые объекты с картами освещения имеют дополнительные параметры рендеринга: индекс карты освещения и смещение/скейл в карте освещения. Как правило для пакетной обработки, GameObject-ы с динамической картой освещения должны указывать на одно и то же местоположение карты освещения.
- Multi-pass шейдеры исключают батчинг.
- Почти все шейдеры Unity поддерживают несколько источников света при прямом рендеринге, эффективно выполняя за них дополнительные проходы. Вызовы отрисовки для «дополнительных источников света на пиксель» не группируются.
- У Legacy Deferred (предварительный проход света) пути рендеринга динамический батчинг отключен, потому что он должен отрисовывать GameObject дважды.
- Для каждого совместимого типа рендерера Unity собирает весь батч контент в 1 большой Vertex Buffer.
- Рендерер устанавливает состояние материала для батча.
- Unity связывает Vertex Buffer с Graphics Device.
- Для каждого рендерера в батче Unity обновляет смещение в Vertex Buffer, а затем отправляет новый вызов отрисовки.
Запекайте ваше освещение
Грубо говоря, есть три режима освещения: Realtime, Baked и Mixed.
Realtime самый лучший, НО за него приходится платить производительностью. Он вносит прямой свет в сцену и обновляет каждый кадр, когда источники света и игровые объекты перемещаются внутри сцены, обновляя освещение немедленно.
Всякий раз, когда у вас есть возможность запечь (bake) освещение на сцене, обязательно используйте ее, потому что это идеальный вариант для повышения производительности, особенно если вы ориентируетесь на мобильные устройства. Всегда лучше использовать небольшое освещение на сцене, чтобы добиться желаемого вида.
Таким образом, все ваши источники света будут предварительно вычисляться в автономном режиме в процессе под названием Lightmap Baking (запекание). Когда вы устанавливаете GameObject Lightmap Static Flag, Unity запекает информацию о GameObject Light, тенях, отраженном свете и мягких тенях в текстурах, которые касаются вашей сцены. Однако Lightmaps имеет некоторые ограничения, освещение не может обновляться динамически для выбранных вами объектов с Lightmap Static Flag.
Несколько месяцев назад в свободное время я сделал SCIFI сцену, и я думаю, что это лучший пример, показывающий, как работает запеченное освещение. Конечно, я использовал Emission.
Если кого-то интересует обзор создания этой SCIFI сцены, и как я добился этого вида, дайте мне знать, может быть, я мог бы посвятить этому отдельную статью.
Вот видео, если вам интересно!
Используйте отсечения
Это очень хороший способ повысить производительность вашей игры с помощью окклюзии Unity. В целом Occlusion Culling подразумевает, что Unity не будет отображать GameObject-ы, которые полностью скрыты с точки зрения камеры (окклюдированны) другими GameObject-ами.
Чтобы открыть окно Occlusion перейдите в Window->Rendering->Occlusion Culling
Если кого-нибудь заинтересовало то, как я добился такого вида сцены Mystery Forest, дайте мне знать, возможно, я мог бы написать отдельную статью про это.
Вот видео, если вам интересно!
twitter.com/i/status/1096336962259021824
По умолчанию Unity применяет Frustum Culling, что означает, что он отображает только линию обзора камеры, показывая все объекты. Например, если камера смотрит на стену, все объекты за этой стеной также будут визуализированы. Нам это совсем не нужно, поэтому следует добавить в нашу сцену Occlusion Culling.
Вот почему мы должны использовать Occlusion Culling, что означает, что камера будет отображать только стену без объектов за ней.
Источник: habr.com
Как использовать профили в приложении Spring Boot
В этом уроке мы узнаем, как мы можем использовать профили в приложении Spring Boot.
Мы обсудим следующие моменты в этом уроке:
1. Что такое профиль весенней загрузки и почему нам нужно профилирование
2. Как выполнить профилирование в Spring Boot с примером
3. Как установить / изменить профиль по умолчанию
1. Что такое профиль весенней загрузки и почему нам нужно профилирование
Предположим, вы работаете с приложением Spring Boot. Вы протестировали приложение локально на своем компьютере, подключившись к локальной базе данных, которая установлена на вашем компьютере. Теперь вы хотите развернуть это приложение в среде DEV, и у вас также есть сервер базы данных DEV. у вас есть база данных
Теперь, когда вы тестируете приложение локально, в вашем файле application.properties вы бы поместили такие данные, как url базы данных, имя пользователя, пароль для локальной базы данных, которая установлена на вашем компьютере, но как только вы перейдете в среду DEV, вы захотите Ваше приложение для общения с базой данных DEV, а не с локальной базой данных.
Таким образом, вы можете изменить файл application.properties, указав сведения, необходимые для подключения к базе данных DEV, зафиксировать код и развернуть его в DEV, но теперь проблема заключается в том, что этот код будет нормально подключаться к базе данных DEV, но когда вы попытаетесь выполнить этот код из локальной системы, он не будет работать, потому что вы изменили детали базы данных на базу данных DEV.
Итак, еще раз, чтобы заставить его работать на вашем локальном компьютере, вам нужно будет внести изменения в application.properties, которые требуются для локального и выполнения приложения.
Как вы можете видеть, здесь много суеты между местными и DEV.
Теперь представьте, что у вас есть больше сред, таких как ST, ET (QA), PROD, и вам нужно все время вносить изменения вручную. Это будет настоящий кошмар.
Так в чем же решение?
Весенние Профили Загрузки в Спасении!
Spring Boot позволяет вам настроить конфигурацию приложения, чтобы вы могли работать с одним и тем же кодом приложения в разных средах без необходимости вносить изменения.
Spring Boot Profiles позволяет вам настраивать несколько файлов application.properties для каждой среды, так что когда вы находитесь в локальной среде, он будет использовать локальный файл свойств, когда вы находитесь в DEV, он будет использовать файл свойств DEV и так далее, без вас как Программист должен внести какие-либо явные изменения в код.
В общем, если у вас есть свойства приложения, которые различаются в зависимости от среды, вы можете справиться с этим с помощью Spring Profiles.
Выглядит круто. Не правда ли
2. Как выполнить профилирование в Spring Boot с примером
2.1 Следуйте моему посту Как создать проект Spring Boot с помощью Spring Initializer и создать проект Spring Boot с именем «Springbootprofiles». Добавьте только веб-зависимость, так как этого будет достаточно для нашего тестирования.
2.2 В файле приложения .properties, который был автоматически создан Spring intializer, добавьте следующую строку:
application.environment = Это локальная среда
2.3 Запустите приложение, нажав на проект и выбрав Запуск от имени -> Выполнить настройки -> Выполнить
2.4 Проверьте журналы консоли, созданные Spring boot
Вы увидите следующую строку в журналах
2019-07-07 20: 00: 52.147 ИНФОРМАЦИЯ 15560 – [main] cbjsSpringbootprofilesApplication: активный профиль не установлен, откат к профилям по умолчанию: по умолчанию
Что в основном говорит о том, что мы не установили какой-либо профиль явно, поэтому Spring Boot использует профиль по умолчанию, что означает, что Spring Boot использует конфигурации из файла application.properties.
Как мы можем это проверить?
Давайте посмотрим на следующие шаги.
2.5 Создайте контроллер с именем ProfileController.java следующим образом:
Источник: coderlessons.com