Сравнительный анализ производительности в Unity: Как начать
Как разработчик Unity, Вы хотите, чтобы пользователи любили играть в Ваши игры, наслаждаясь плавным ходом на всех платформах, на которых они могут играть. Что, если я скажу Вам, что мы только что упростили создание контрольных показателей производительности? Если Вы хотите научиться разрабатывать игры или инструменты Unity, уделяя особое внимание производительности, читайте дальше!
В этом посте я объясню, как использовать несколько инструментов Unity, которые позволят Вам легко начать собирать показатели производительности и создавать с их помощью бенчмарки: Unity Test Runner, поставляемый вместе с редактором Unity, расширение для тестирования производительности Unity и Unity Performance Benchmark Reporter.
Будучи разработчиком Unity, Вы можете оказаться в следующей ситуации: еще недавно Ваш проект работал быстро и плавно, но затем в него были внесены одно или несколько изменений, и теперь сцены работают заметно медленнее, кадры падают, и возникают другие проблемы с производительностью. Отследить, какие изменения привели к снижению производительности, может быть непросто.
Если Вы являетесь партнером Unity, Вы хотите понять, насколько изменилась производительность Ваших SDK, драйверов, платформ, пакетов или других артефактов. Или Вы хотите собрать показатели производительности различных версий Unity с Вашими продуктами, но не очень понятно, как это сделать, а затем провести сравнение.
Это всего лишь пара примеров, когда установление контрольных показателей производительности может действительно спасти положение. Теперь позвольте мне показать Вам, как Вы можете начать собирать показатели производительности, создавать на их основе контрольные показатели и визуализировать изменения в показателях производительности.
Для этого обсуждения мы рассмотрим тестовый код в образце проекта тестирования производительности UnityPerformanceBenchmark.
Загрузите последнюю версию XRAutomatedTests с GitHub. Вы найдете проект UnityPerformanceBenchmark в подкаталоге PerformanceTests.
Проект UnityPerformanceBenchmark содержит множество примеров сцен, которые, в свою очередь, используются в тестах производительности Unity с помощью расширения Unity Performance Testing Extension.
Прежде всего, мы рассмотрим, как написать тест производительности с помощью Unity Test Runner и расширения Unity Performance Testing Extension. Прежде чем мы продолжим, вот небольшая справочная информация об этих двух инструментах.
Мы используем Unity Test Runner для запуска наших тестов производительности. Unity Test Runner - это система выполнения тестов, встроенная в редактор Unity, позволяющая Вам тестировать свой код как в режиме редактирования, так и в режиме игры на целевых платформах, таких как Standalone, Android или iOS. Если Вы еще не знакомы с Unity Test Runner, ознакомьтесь с документацией по Unity Test Runner.
Расширение для тестирования производительности Unity - это пакет для редактора Unity, который предоставляет API и атрибуты тестовых примеров, позволяющие Вам сэмплировать и агрегировать как маркеры профилировщика Unity, так и непрофилируемые пользовательские метрики в редакторе Unity и игроках. Вы можете узнать больше, изучив документацию по расширению Unity Performance Testing Extension, но здесь мы рассмотрим несколько примеров.
Расширение Unity Performance Test Extension требует Unity 2018.1 или более поздней версии. Обязательно используйте Unity версии 2018.1 или выше, если Вы хотите запустить примеры тестов производительности в проекте UnityPerformanceBenchmark или если Вы используете расширение Unity Performance Test Extension.
В проекте UnityPerformanceBenchmark реализован интерфейс IPrebuildSetup - объект Unity Test Runner, в котором мы можем реализовать метод Setup, автоматически вызываемый перед выполнением теста программой Unity Test Runner.
Первое, что делает метод IPrebuildSetup.Setup проекта UnityPerformanceBenchmark, это разбирает аргументы командной строки в поисках настроек сборки плеера. Это позволяет нам гибко создавать плеер для наших тестов производительности, используя один и тот же проект Unity для различных платформ, режимов потокового рендеринга, графических API плеера, скриптовых реализаций и настроек, поддерживающих XR, таких как путь стерео рендеринга и VR SDK.
Таким образом, нам нужно будет открыть проект UnityPerformanceBenchmark в Unity из командной строки, передав параметры сборки плеера, которые мы хотим использовать при запуске тестов в Unity Test Runner.
Пример: Запустите проект UnityPerformanceBenchmark из Windows, чтобы собрать Android Player:
Unity.exe -projectPath
C:\XRAutomatedTests-2018.2\PerformanceTests\UnityPerformanceBenchmark
-testPlatform Android -buildTarget Android -playergraphicsapi=OpenGLES3 -mtRendering -scriptingbackend=mono
Здесь мы запускаем Unity на Windows для сборки под Android с графическим API OpenGLES3, многопоточным рендерингом и скриптовым бэкендом Mono.
Пример: Запустите проект UnityPerformanceBenchmark из OSX для создания iOS-плеера
./Unity -projectPath /XRAutomatedTests-2018.2/PerformanceTests/UnityPerformanceBenchmark
-testPlatform iOS -buildTarget iOS -playergraphicsapi=OpenGLES3 -mtRendering -scriptingbackend=mono
-appleDeveloperTeamID=<вашAppleDeveloperTeamID>
-iOSProvisioningProfileID=<yourIosProvisionProfileID>
Здесь мы запускаем Unity на OSX для сборки под iOS с графическим API OpenGLES3, многопоточным рендерингом и бэкендом скриптов Mono. Мы также предоставляем команду разработчиков Apple и информацию о профиле инициализации, необходимую для развертывания на iOS-устройствах.
Когда мы открываем проект UnityPerformanceBenchmark в Unity из командной строки, как в примерах выше, аргументы командной строки будут находиться в памяти, чтобы метод IPrebuildSetup.Setup мог их разобрать и использовать для сборки плеера.
Хотя такой запуск из командной строки не является обязательным для запуска тестов в Unity Test Runner, это хороший шаблон, который можно использовать, чтобы избежать использования отдельного тестового проекта для каждой конфигурации игрока.
Я подробно описал опции командной строки для открытия проекта или просто запуска тестов из командной строки на вики для тестового проекта: Как выполнить тесты Unity Performance Benchmark. Чтобы узнать больше о том, как мы разбираем настройки сборки плеера в тестовом проекте, посмотрите файл RenderPerformancePrebuildStep.cs в директории Scripts тестового проекта UnityPerformanceBenchmark.
После того, как мы открыли UnityPerformanceBenchmark, нам нужно открыть окно Unity Test Runner в редакторе Unity Editor
- В Unity 2018.1 перейдите в меню Window > Test Runner.
- В Unity 2018.2 перейдите в меню Окно > Общие > Test Runner.
Откроется окно Unity Test Runner, которое будет выглядеть так, как показано на рисунке ниже.
Это наши тесты производительности Unity. Мы можем запустить их в редакторе с помощью кнопки "Запустить" в верхней левой части окна, или на реальном устройстве или платформе с помощью кнопки "Запустить все в плеере" в верхней правой части окна.
Совет по отладке
Если Вы хотите отладить код в методе IPrebuildSetup.Setup
1. Установите точки останова в коде IPrebuildSetup.Setup в Visual Studio
2. Присоединитесь к редактору Unity с помощью расширения Visual Studio Tool for Unity.
3. Запустите свои тесты в редакторе с помощью кнопки "Run All" или "Run Select" в окне Unity Test Runner.
В этот момент отладчик Visual Studio проникнет в Ваш код, где Вы сможете отлаживать его по мере необходимости.
Давайте рассмотрим пример теста производительности, чтобы лучше понять, как он работает.
Пример: Выборка маркеров профилировщика в тесте производительности Unity
[PerformanceUnityTest]
public IEnumerator SpiralFlame_RenderPerformance()
{
yield return SceneManager
.LoadSceneAsync(spiralSceneName, LoadSceneMode.Additive);
SetActiveScene(spiralSceneName);
// Instantiate performance test object in scene
var renderPerformanceTest =
SetupPerfTest<DynamicRenderPerformanceMonoBehaviourTest>();
// allow time to settle before taking measurements
yield return new WaitForSecondsRealtime(SettleTime);
// use ProfilerMarkers API from Performance Test Extension
using (Measure.ProfilerMarkers(SamplerNames))
{
// Set CaptureMetrics flag to TRUE;
// let's start capturing metrics
renderPerformanceTest.component.CaptureMetrics = true;
// Run the MonoBehaviour Test
yield return renderPerformanceTest;
}
yield return SceneManager.UnloadSceneAsync(spiralSceneName);
}В этом примере наш метод тестирования называется SpiralFlame_RenderPerformance. Из декоратора метода [PerformanceUnityTest] мы знаем, что это тест производительности Unity.
Все тесты в тестовом проекте UnityPerformanceBenchmark следуют той же схеме, которую мы видим в этом методе тестирования:
1. Загрузите сцену для теста
2. Установите сцену как активную, чтобы мы могли взаимодействовать с ней в тестовом методе
3. Создайте тестовый объект типа DynamicRenderPerformanceMonoBehaviourTest и добавьте его в тестовую сцену (это происходит в методе SetupPerfTest<T>)
4. Подождите постоянное значение времени, чтобы сцена "успокоилась" после загрузки и добавления тестового объекта на сцену, прежде чем мы начнем измерять показатели выборки.
5. Настройте маркеры нашего профилировщика для захвата API расширения Performance Test Extension
6. Сообщите тесту производительности, что мы готовы приступить к сбору показателей
7. Затем yield возвращает тестовый объект (IMonoBehaviourTest) для сбора метрик во время цикла рендеринга.
Мы также сэмплируем пользовательские метрики (метрики, которые не попадают в один из маркеров профилировщика Unity, счетчик кадров или время выполнения) в базовом классе RenderPerformanceMonoBehaviourTestBase (этот класс наследуется от MonoBehaviour).
Пример: Выборка пользовательских показателей в сценарии MonoBehaviour
private void Update()
{
if (CaptureMetrics)
{
FrameCount++;
SampleFps();
#if ENABLE_VR
if (XRSettings.enabled)
{
SampleGpuTimeLastFrame();
}
#endif
}
if (IsMetricsCaptured)
{
EndMetricCapture();
}
}
private void SampleFps()
{
Fps = GetFps();
Measure.Custom(FpsSg, Fps);
startFrameCount = Time.renderedFrameCount;
}
private void SampleGpuTimeLastFrame()
{
var gpuTimeLastFrame = GetGpuTimeLastFrame();
Measure.Custom(GpuTimeLastFrameSg, gpuTimeLastFrame * 1000);
}
public void EndMetricCapture()
{
CaptureMetrics = false;
#if UNITY_ANALYTICS && UNITY_2018_2_OR_NEWER
Measure.Custom(startupTimeSg, appStartupTime);
#endif
}В примере выше мы фиксируем FPS, GpuTimeLastFrame (если включена функция XR) и время запуска приложения (если включена функция Unity Analytics и мы работаем на Unity 2018.2-или более новой версии, где доступно необходимое нам API).
Наконец, обратите внимание на то, что в том же базовом классе RenderPerformanceMonoBehaviourTestBase мы реализовали свойство public bool IsTestFinished. Мы обязаны реализовать это свойство, поскольку наш RenderPerformanceMonoBehaviourTestBase реализует интерфейс IMonoBehaviourTest.
Это свойство важно, поскольку программа Unity Test Runner использует его, чтобы знать, когда остановить тест. Когда его значение становится истинным, тест заканчивается. Вы сами должны реализовать нужную логику, чтобы определить, когда Unity Test Runner должен прекратить выполнение теста.
Пример: Выборка пользовательских метрик в свойстве IsTestFinished
public bool IsTestFinished
{
get
{
bool isTestFinished = false;
if (IsMetricsCaptured)
{
Measure.Custom(objCountSg, RenderedGameObjects);
Measure.Custom(trianglesSg, Tris);
Measure.Custom(verticesSg, Verts);
isTestFinished = true;
}
return isTestFinished;
}
}В этом последнем примере мы фиксируем количество отрисованных игровых объектов, треугольников и вершин в сцене на момент завершения теста.
Теперь, когда мы увидели несколько примеров того, как мы обращаемся к расширению Performance Testing Extension для получения образцов метрик, давайте поговорим о том, как мы их настраиваем для начала.
Методы Measure.* обычно принимают в качестве параметра структуру, называемую SampleGroupDefinition. Когда мы создаем новую SampleGroupDefinition, мы определяем некоторые свойства образцов, в сборе которых мы заинтересованы.
Пример: Определите новую SampleGroupDefinition для GpuTimeLastFrame, используя миллисекунды в качестве единицы выборки, агрегируйте выборки по минимальному значению
Ниже приведен пример определения группы для GpuTimeLastFrame. Так мы сообщаем расширению Performance Testing Extension, как собирать образцы и агрегировать их для GpuTimeLastFrame.
Эта SampleGroupDefinition взята из примера теста производительности рендеринга динамической сцены, поэтому здесь мы решили объединить наши образцы, используя минимальное собранное значение. Но почему мы должны делать именно так, а не использовать более распространенную меру агрегирования, например, медиану или среднее?
Ответ: потому что сцена динамична. В динамичной сцене использование медианного или среднего агрегирования будет ненадежным или непоследовательным для одной и той же сцены, запущенной с одним и тем же кодом, учитывая меняющийся характер рендеринга. Скорее всего, это лучшее, что мы можем сделать, если хотим отследить один агрегат для метрики рендеринга в динамической сцене. Однако, когда мы определяем аналогичный SampleGroupDefinition для наших статичных сцен, мы определенно используем медианное объединение.
new SampleGroupDefinition(GpuTimeLastFrameName, SampleUnit.Millisecond, AggregationType.Min)
Пример: Определите новую SampleGroupDefinition для FPS, используя none в качестве единицы выборки, агрегируйте образцы, используя медианное значение, увеличение значения лучше
Ниже приведен образец определения группы для FPS (Frames Per Second). У FPS нет отдельной единицы измерения; это просто FPS, поэтому здесь мы указываем SampleUnit.None. Здесь мы используем медианный тип агрегации; это статичная сцена, поэтому нам не нужно беспокоиться о непредсказуемом рендеринге. Мы явно устанавливаем порог в 15% для группы выборки и передаем true для аргумента increaseIsBetter, потому что, если FPS увеличивается, это хорошо!
Эти два последних аргумента собираются и сохраняются в нашем файле результатов тестирования производительности .xml при запуске из командной строки и могут быть позже использованы в Unity Performance Benchmark Reporter для создания контрольных показателей.
new SampleGroupDefinition(FpsName, SampleUnit.None, AggregationType.Median, threshold: 0.15, increaseIsBetter: true)
Когда тест завершается, все образцы метрик, которые мы включили ранее, затем агрегируются Расширением тестирования производительности.
Хочу заметить, что в наших примерах кода мы используем несколько различных API расширения Unity Performance Testing Extension, а именно
- Measure.ProfilerMarkers, и
- Measure.Custom
Расширение для тестирования производительности Unity предоставляет и другие методы измерения, которые могут удовлетворить Ваши конкретные потребности в зависимости от того, что и как Вы хотите измерить в Unity. Эти дополнительные методы включают:
- Measure.Method
- Measure.Frames
- Measure.Scope
- Measure.FrameTimes
Узнайте больше о различных методах измерения в документации по расширению Unity Performance Testing Extension, а именно в разделе "Проведение измерений".
Теперь, когда мы рассмотрели несколько примеров того, как писать тесты производительности с помощью Unity Test Runner, используя расширение Unity Performance Testing Extension, давайте посмотрим, как их запускать.
Существует два основных способа выполнения тестов производительности
1. Из командной строки запустите Unity с опцией -runTests. Этот способ предпочтителен для тестов производительности, поскольку расширение Unity Performance Test Extension создаст для нас файл результатов .xml, который мы можем использовать в Unity Performance Benchmark Reporter для просмотра и сравнения наших результатов.
2. Непосредственно из редактора. Такой подход будет полезен, если Вы
a. Просто хотите запустить тесты и просмотреть результаты в окне Unity Test Runner без необходимости сохранять результаты для последующего использования, или
b. Хотите проверить, будут ли выполняться Ваши тесты, или Вам нужно отладить тестовый код.
Вот два примера того, как запускать тесты производительности с помощью Unity Test Runner из командной строки. Эти примеры должны выглядеть очень знакомо, потому что мы основываемся на тех же примерах, которые мы видели ранее, когда обсуждали открытие проекта UnityPerformanceBenchmark из командной строки.
Пример: Запуск тестов производительности UnityPerformanceBenchmark из Windows в Android Player
Здесь мы запускаем Unity на Windows для сборки под Android с графическим API OpenGLES3, многопоточным рендерингом и скриптовым бэкендом Mono.
Unity.exe -runTests [-batchmode] -projectPath
C:\XRAutomatedTests-2018.2\PerformanceTests\UnityPerformanceBenchmark -testPlatform Android -buildTarget Android -playergraphicsapi=OpenGLES3 -mtRendering -scriptingbackend=mono -testResults
C:\PerfTests\results\PerfBenchmark_Android_OpenGLES3_MtRendering_Mono.xml -logfile
C:\PerfTests\logs\PerfBenchmark_Android_OpenGLES3_MtRendering_Mono_UnityLog.txt
Пример: Запуск тестов производительности UnityPerformanceBenchmark из OSX против iOS Player
Здесь мы запускаем Unity на OSX для сборки под iOS с графическим API OpenGLES3, многопоточным рендерингом и бэкендом скриптов Mono. Мы также предоставляем команду разработчиков Apple и информацию о профиле инициализации, необходимую для развертывания на iOS-устройствах.
./Unity -runTests [-batchmode] -projectPath /XRAutomatedTests-2018.2/PerformanceTests/UnityPerformanceBenchmark
-testPlatform iOS -buildTarget iOS -playergraphicsapi=OpenGLES3
-mtRendering -scriptingbackend=mono
-appleDeveloperTeamID=<вашAppleDeveloperTeamID>
-iOSProvisioningProfileID=<yourIosProvisionProfileID> -testResults /PerfTests/results/PerfBenchmark_Android_OpenGLES3_MtRendering_Mono.xml
-logfile /PerfTests/logs/PerfBenchmark_Android_OpenGLES3_MtRendering_Mono_UnityLog.txt
В обоих примерах мы ввели три-четыре новых параметра командной строки, которые помогут нам запустить наши тесты вместо того, чтобы просто открыть Unity Editor с аргументами командной строки, доступными в методе IPrebuildSetup.Setup.
-runTests
Эта опция сообщает программе Unity Test Runner, что Вы хотите запустить свои тесты
-testResults <pathToWritePerformanceTestResultsFile>
Эта опция указывает имя и путь к файлу .xml, в который Unity Test Runner должен сохранять результаты Ваших тестов производительности.
-logfile <pathToWriteUnityEditorLogFile>
Эта опция указывает имя файла и путь к файлу, в который редактор Unity должен записывать свои логи. Это необязательно, но может оказаться очень полезным при расследовании сбоев и проблем, если Вы сможете быстро получить доступ к файлу журнала Unity Editor.
-batchmode
Эта опция заставит редактор Unity открываться в режиме без головы. Мы используем эту опцию, когда проводим только тесты производительности игроков и нет необходимости открывать окно Unity Editor. Это поможет сэкономить время при выполнении автоматизированных тестов. Если эта опция не используется, редактор Unity откроется на экране перед выполнением тестов.
В Unity мы запускаем наши тесты производительности из командной строки, часто в пакетном режиме, в нашей системе непрерывной интеграции.
Пример: Запуск тестов UnityPerformanceBenchmark из командной строки
Когда окно Unity Test Runner открыто сверху и выбран режим PlayMode (тесты в режиме PlayMode запускаются либо в плеере сборки, либо в окне режима воспроизведения редактора), у нас есть
1. Запустить все - нажмите эту кнопку, чтобы запустить все тесты на вкладке PlayMode
2. Запустить выбранный - нажмите эту кнопку, чтобы запустить выбранный тест или узел и все тесты под ним.
3. Запустить все в плеере - нажмите эту кнопку, чтобы редактор Unity создал тип плеера, указанный в настройках сборки, и запустил тесты в нем.
Важное требование Выполнение тестов производительности до версии 0.1.50 расширения Performance Testing Extension в редакторе Unity Editor из окна Test Runner не приведет к созданию файла результатов .xml, необходимого для Unity Performance Benchmark Reporter. Однако если Вы используете версию 0.1.50 или более позднюю версию расширения Performance Testing Extension, файл results.xml будет записан в папку проекта `Assets\StreamingAssets`.
Если Вы используете версию расширения Performance Testing Extension более раннюю, чем версия 0.1.50, и хотите создать файл результатов .xml после проведения тестов производительности, Вам необходимо запустить тесты, запустив Unity из командной строки с опцией -runTests. Однако помните, что когда Вы запускаете Unity с опцией командной строки -runTests, редактор откроется и начнет выполнять тесты.
Файлы результатов .xml будут содержать результаты и метаданные, полученные в ходе тестирования, которые мы будем использовать в Unity Performance Benchmark Reporter для создания эталонных результатов и сравнения с последующими тестами.
Пример: Запуск тестов производительности в редакторе Unity
Если мы запускаем эти тесты из редактора, то суммарные значения можно увидеть в нижней части окна Unity Test Runner, выбрав каждый тест.
Пример: Просмотр агрегаций образцов тестов производительности из Unity Test Runner
Если Вы хотите увидеть результаты выполнения тестов производительности Unity из командной строки, Вам нужно воспользоваться программой Unity Performance Benchmark Reporter (или просто открыть файл результатов .xml, но это не самое простое чтение).
После этого давайте перейдем к обсуждению того, как мы можем использовать Unity Performance Benchmark Reporter для просмотра и сравнения результатов.
Unity Performance Benchmark Reporter позволяет сравнивать базовые показатели производительности и последующие показатели производительности (созданные с помощью Unity Test Runner с расширением Unity Performance Testing Extension) в html-отчете с графической визуализацией.
Репортер построен как сборка .NET Core 2.x, поэтому он совместим для работы на различных платформах, поддерживающих .NET (Windows, OSX и т.д.). Поэтому, чтобы запустить его, Вам необходимо убедиться, что Вы установили .NET Core SDK.
Выполнение отчета Unity Performance Benchmark означает вызов сборки с помощью команды dotnet, как показано ниже:
dotnet UnityPerformanceBenchmarkReporter.dll
--baseline=D:\UnityPerf\baseline.xml
--results=D:\UnityPerf\results --reportdirpath=d:\UnityPerf
После запуска репортера будет создана директория с именем UnityPerformanceBenchmark, в которой будет находиться html-отчет и вспомогательные файлы .css, .js и изображения. Откройте html-отчет, чтобы просмотреть визуализацию показателей производительности, записанных в файлах результатов .xml.
-результаты
Путь к директории, в которой находится один или несколько файлов .xml с небазовыми результатами, которые будут включены в html-отчет.
В сборку UnityPerformanceBenchmarkReporter.dll должно быть передано хотя бы одно значение --results. Это единственное обязательное поле.
Этот параметр командной строки также можно использовать для указания пути к одному файлу результатов .xml, не относящемуся к базовой линии. Кроме того, Вы можете указать несколько каталогов или файлов, повторив опцию следующим образом:
--results=D:\UnityPerf\results --results=D:\UnityPerf\results.xml
-базовый уровень
Путь к файлу результатов .xml, который будет использоваться при сравнении других результатов.
--reportdirpath
Путь к директории, в которой отчетчик создаст отчет об эталоне производительности. Он создается в подкаталоге UnityPerformanceBenchmark.
Если местоположение отчета не указано, подкаталог UnityPerformanceBenchmark будет создан в рабочей директории, из которой был вызван UnityPerformanceBenchmarkReporter.dll.
Давайте сравним некоторые результаты тестов производительности с помощью Performance Benchmark Reporter.
Пример: Экспериментируйте с изменениями настроек в сцене с Gear VR для улучшения частоты кадров
У меня есть сцена Unity со следующими характеристиками сложности.
- 732 предмета
- 95 898 треугольников
- 69,740 вершин
Я запустил тест производительности Unity для этой сцены, выбирая метрики, которые помогли бы мне понять, смогу ли я поддерживать 60 FPS при использовании многопроходного стерео рендеринга. Далее я запустил Performance Benchmark Reporter с результатами моего теста.
Я обнаружил, что мой FPS ближе к 30 FPS, что в два раза меньше того, что я хотел бы иметь.
Далее я собираюсь попробовать использовать Single Pass Multiview Stereo Rendering, чтобы посмотреть, насколько близко к 60 FPS я смогу приблизиться. Я повторно проведу тест производительности с измененной конфигурацией, а затем создам еще один отчет Unity Performance Benchmark Report, сравнив первые результаты с новыми.
Похоже, что переключение конфигурации на Single Pass Multiview рендеринг улучшило наш FPS до 37. Нам все еще нужно приблизиться к 60 FPS, если мы хотим, чтобы эта сцена работала без значительного падения кадров на Gear VR.
Последнее, с чем я собираюсь поэкспериментировать, это уменьшить количество вращающихся кубов в моей сцене, чтобы посмотреть, сможем ли мы увеличить FPS.
После нескольких попыток мне удается повысить производительность до ~55 FPS. Но мне пришлось уменьшить количество объектов в сцене с 732 до 31. Это довольно много.
Я еще вернусь к другим улучшениям, которые я могу сделать для оптимизации производительности, но пока я собираюсь использовать это в качестве базового показателя FPS. В дальнейшем я буду использовать его в качестве эталона, надеясь улучшить его, если смогу.
Установление контрольных показателей может означать множество вещей в зависимости от Вашего проекта. В данном контексте, выполняя тесты производительности в Unity, мы говорим об установлении базового набора результатов, набора показателей производительности, с которыми можно сравнивать последующие результаты по мере внесения изменений. Они становятся нашим эталоном.
В предыдущем разделе я пришел к конфигурации с использованием однопроходного многоракурсного стерео рендеринга для Gear VR и уменьшенного количества объектов сцены, что позволило получить "приемлемый" FPS. В этот момент я решаю использовать результаты своих тестов в качестве эталона. Давайте посмотрим пример того, как мы можем использовать этот эталон при внесении дальнейших изменений в конфигурацию игрока.
Пример: Используйте бенчмарк производительности, чтобы обнаружить снижение производительности при изменении конфигурации
Я бы хотел включить сглаживание в моей сцене, чтобы сгладить внешний вид. Настройки качества по умолчанию в Unity для Android отключают сглаживание, но я хотел бы посмотреть, сможем ли мы включить его и сохранить приемлемый FPS для нашей сцены Gear VR.
Сначала я установил значение сглаживания в методе IPrebuildSetup.Setup на 4.
QualitySettings.antiAliasing = 4;
Далее я повторил тест производительности, проведенный ранее, на своем телефоне Android с поддержкой Gear VR. Затем я использую программу Unity Performance Benchmark Reporter, чтобы сравнить этот новый запуск с моими новыми результатами бенчмарков.
Но посмотрите, после перенастройки моего проигрывателя Unity на использование сглаживания на уровне 4, мой FPS упал до 32 FPS, то есть примерно до того уровня, с которого я начинал, когда создавал эту сцену с 732 объектами.
Я бы хотел поэкспериментировать с несколькими меньшими значениями сглаживания, чтобы посмотреть, смогу ли я восстановить приемлемый FPS для сцены, прежде чем отказаться от этой идеи. Итак, я попробовал сглаживание, установив значение 2, а затем, наконец, 1. Результаты показаны на изображении ниже.
В этом сценарии изменения конфигурации, используя эталон производительности, который я установил ранее, я смог поэкспериментировать с изменениями в настройках плеера Unity, а затем проверить их влияние на производительность, прежде чем принять решение.
Несмотря на то, что я нахожусь в пределах стандартного 15% порога отклонения для FPS, используя сглаживание, установленное на 1, FPS сейчас составляет 49, что немного далеко от 60 FPS для моей сцены с поддержкой VR, которые я хотел бы получить. Я не думаю, что приму эти изменения сегодня.
Unity уделяет большое внимание отличной производительности по умолчанию. Но движок Unity Engine - это лишь часть того, что в конечном итоге приводит к тому, что пользователи любят играть в Ваши игры, наслаждаясь плавностью и высокой производительностью на всех платформах, на которых они могут играть. А SDK, драйверы или пакеты Unity, например, которые работают отлично, не вызывая регресса производительности, очень важны для общего отличного опыта работы с производительностью для всех.
Я познакомил Вас с парой инструментов Unity, которые облегчают сбор показателей производительности и создание эталонов: Unity Performance Testing Extension и Unity Performance Benchmark Reporter. Я рекомендую Вам поэкспериментировать с тем, что они могут сделать для Вас и Ваших усилий, направленных на повышение производительности.
Мы рассмотрели
- Как мы можем использовать Unity Test Runner для написания тестов производительности, чтобы проверить профилировщик и другие метрики,
- Некоторые различные способы выполнения тестов производительности с помощью Unity Test Runner, а также
- Как использовать Unity Performance Benchmark Reporter для анализа и сравнения показателей производительности, как начать тестирование производительности.
Установление базовых показателей для этих параметров и их использование для создания эталона для Ваших сцен, игр, SDK, драйверов, пакетов или других интеграций Unity может стать эффективным способом начать отслеживать влияние Ваших изменений. Удачи!
Большое спасибо и благодарность моим коллегам по Unity за их помощь в работе, мозговые штурмы, эксперименты, разработку и итерации этой работы вместе со мной.
- Ци Цзян
- Сакари Питкянен
- Гинтаутас Скерсис
- Бенджамин Смит