Leistungs-Benchmarking in Unity: Wie man anfängt
Als Unity-Entwickler möchten Sie, dass Ihre Benutzer Ihre Spiele gerne spielen und ein reibungsloses Erlebnis auf allen Plattformen genießen können, auf denen sie spielen. Was wäre, wenn ich Ihnen sagen würde, dass wir es gerade einfacher gemacht haben, Leistungsbenchmarks zu erstellen? Wenn Sie lernen möchten, wie man Spiele oder Unity-Tools mit Blick auf die Leistung entwickelt, lesen Sie bitte weiter!
In diesem Beitrag erkläre ich Ihnen, wie Sie einige Unity-Tools verwenden, mit denen Sie auf einfache Weise Performance-Metriken sammeln und Benchmarks erstellen können: den Unity Test Runner, der mit dem Unity Editor geliefert wird, die Unity Performance Testing Extension und den Unity Performance Benchmark Reporter.
Als Unity-Entwickler befinden Sie sich vielleicht in der folgenden Situation: Ihr Projekt lief vor nicht allzu langer Zeit schnell und reibungslos, aber dann wurden eine oder mehrere Änderungen vorgenommen, und jetzt sind die Szenen merklich langsam, die Frames brechen ein, und andere Leistungsprobleme tauchen auf. Es kann schwierig sein, nachzuvollziehen, welche Änderungen zu dem Leistungsrückgang geführt haben.
Wenn Sie ein Unity Partner sind, möchten Sie die Leistungsänderungen in Ihren SDKs, Treibern, Plattformen, Paketen oder anderen Artefakten verstehen. Oder Sie möchten mit Ihren Produkten Leistungskennzahlen über verschiedene Versionen von Unity hinweg sammeln, aber es ist nicht ganz klar, wie Sie dies tun und dann die Vergleiche anstellen sollen.
Dies sind nur einige Beispiele, bei denen die Festlegung von Leistungsmaßstäben wirklich den Tag retten kann. Ich zeige Ihnen jetzt, wie Sie mit dem Sammeln von Leistungsmetriken beginnen, damit Benchmarks erstellen und Veränderungen in den Leistungsmetriken visualisieren können.
Für diese Diskussion werden wir uns den Testcode im UnityPerformanceBenchmark Beispielprojekt für Leistungstests ansehen.
Laden Sie die neueste Version von XRAutomatedTests von GitHub herunter. Sie finden das Projekt UnityPerformanceBenchmark im Unterverzeichnis PerformanceTests.
Das Projekt UnityPerformanceBenchmark enthält eine Vielzahl von Beispielszenen, die wiederum in den Unity Performance Tests mit der Unity Performance Testing Extension verwendet werden.
Als Erstes sehen wir uns an, wie wir Performancetests mit dem Unity Test Runner und der Unity Performance Testing Extension schreiben. Bevor wir fortfahren, möchten wir Ihnen ein paar Hintergrundinformationen zu diesen beiden Tools geben.
Wir verwenden den Unity Test Runner, um unsere Leistungstests durchzuführen. Der Unity Test Runner ist ein in den Unity-Editor integriertes Testausführungs-Framework, mit dem Sie Ihren Code sowohl im Bearbeitungs- als auch im Wiedergabemodus auf Zielplattform-Playern wie Standalone, Android oder iOS testen können. Wenn Sie mit dem Unity Test Runner nicht vertraut sind, lesen Sie die Unity Test Runner Dokumentation.
Die Unity Performance Testing Extension ist ein Paket für den Unity-Editor, das eine API und Testfallattribute bereitstellt, mit denen Sie im Unity-Editor und in den Playern sowohl Unity-Profiler-Marker als auch benutzerdefinierte Metriken, die nicht vom Profiler stammen, abfragen und aggregieren können. Weitere Informationen finden Sie in der Dokumentation zur Unity Performance Testing Extension, aber wir werden uns hier einige Beispiele ansehen.
Die Unity Performance Test Extension erfordert Unity 2018.1 oder höher. Achten Sie darauf, dass Sie Unity Version 2018.1 oder höher verwenden, wenn Sie die Beispielleistungstests im UnityPerformanceBenchmark-Projekt ausführen möchten oder wenn Sie die Unity Performance Test Extension verwenden.
Das Projekt UnityPerformanceBenchmark implementiert die Schnittstelle IPrebuildSetup, eine Unity Test Runner-Funktion, mit der wir eine Setup-Methode implementieren können, die automatisch aufgerufen wird, bevor der Testlauf vom Unity Test Runner ausgeführt wird.
Das erste, was die IPrebuildSetup.Setup-Methode des UnityPerformanceBenchmark-Projekts tut, ist die Analyse der Befehlszeilenargumente auf der Suche nach den Build-Einstellungen des Spielers. Dadurch können wir den Player für unsere Leistungstests flexibel erstellen, indem wir dasselbe Unity-Projekt für verschiedene Plattformen, Rendering-Threading-Modi, Player-Grafik-APIs, Skripting-Implementierungen und XR-aktivierte Einstellungen wie Stereo-Rendering-Pfad und VR-SDKs verwenden.
Daher müssen wir das UnityPerformanceBenchmark-Projekt mit Unity von der Befehlszeile aus öffnen und die Player-Build-Optionen übergeben, die wir verwenden möchten, wenn wir die Tests im Unity Test Runner ausführen.
Beispiel: Starten Sie das UnityPerformanceBenchmark-Projekt von Windows aus, um den Android Player zu erstellen:
Unity.exe -projectPath
C:\XRAutomatedTests-2018.2\PerformanceTests\UnityPerformanceBenchmark
-testPlatform Android -buildTarget Android -playergraphicsapi=OpenGLES3 -mtRendering -scriptingbackend=mono
Hier starten wir Unity unter Windows, um für Android mit OpenGLES3 Grafik-API, Multithreading-Rendering und Mono Scripting Backend zu bauen.
Beispiel: Starten Sie das UnityPerformanceBenchmark Projekt von OSX aus, um den iOS Player zu erstellen
./Unity -projectPath /XRAutomatedTests-2018.2/PerformanceTests/UnityPerformanceBenchmark
-testPlatform iOS -buildTarget iOS -playergraphicsapi=OpenGLES3 -mtRendering -scriptingbackend=mono
-appleDeveloperTeamID=<yourAppleDeveloperTeamID>
-iOSProvisioningProfileID=<yourIosProvisionProfileID>
Hier starten wir Unity auf OSX, um für iOS mit OpenGLES3 Grafik API, Multithreading und Mono Scripting Backend zu bauen. Außerdem stellen wir dem Apple-Entwicklerteam die Informationen für das Bereitstellungsprofil zur Verfügung, die für die Bereitstellung auf einem iOS-Gerät erforderlich sind.
Wenn wir das UnityPerformanceBenchmark-Projekt mit Unity von der Befehlszeile aus öffnen, wie in den obigen Beispielen, befinden sich die Befehlszeilen-Args im Speicher, so dass die IPrebuildSetup.Setup-Methode sie analysieren und zur Erstellung des Players verwenden kann.
Dieser Ansatz des Starts von der Kommandozeile aus ist zwar nicht erforderlich, um Tests im Unity Test Runner auszuführen, aber er ist ein gutes Muster, um zu vermeiden, dass für jede Playerkonfiguration ein eigenes Testprojekt verwendet wird.
Ich habe die Kommandozeilenoptionen zum Öffnen des Projekts oder zum Ausführen der Tests von der Kommandozeile aus im Wiki für das Testprojekt ausführlich beschrieben: So führen Sie die Unity Leistungs-Benchmark-Tests aus. Um mehr darüber zu erfahren, wie wir die Player-Build-Einstellungen im Testprojekt analysieren, sehen Sie sich die Datei RenderPerformancePrebuildStep.cs im Verzeichnis Scripts des Testprojekts UnityPerformanceBenchmark an.
Nachdem wir den UnityPerformanceBenchmark geöffnet haben, müssen wir das Unity Test Runner Fenster im Unity Editor öffnen
- in Unity 2018.1, gehen Sie zu Fenster > Test Runner.
- in Unity 2018.2, gehen Sie zu Fenster > Allgemein > Test Runner.
Das Unity Test Runner-Fenster öffnet sich und sieht wie das folgende Bild aus.
Dies sind unsere Unity Performance-Tests. Wir können sie im Editor ausführen, indem wir die Schaltfläche Ausführen oben links im Fenster verwenden, oder auf dem tatsächlichen Gerät oder der Plattform, indem wir die Schaltfläche "Alle im Player ausführen" oben rechts im Fenster verwenden.
Tipp zur Fehlersuche
Wenn Sie Code in Ihrer IPrebuildSetup.Setup-Methode debuggen möchten
1. Setzen Sie Haltepunkte in Ihrem IPrebuildSetup.Setup Code in Visual Studio
2. Verbinden Sie sich mit dem Unity Editor mit der Visual Studio Tool for Unity Erweiterung
3. Führen Sie Ihre Tests im Editor aus, indem Sie die Schaltfläche "Alle ausführen" oder "Auswahl ausführen" im Unity Test Runner-Fenster verwenden.
An dieser Stelle greift der Visual Studio Debugger auf Ihren Code zu und Sie können ihn nach Bedarf debuggen.
Schauen wir uns ein Beispiel für einen Leistungstest an, damit wir besser verstehen, wie er funktioniert.
Beispiel: Abtasten von Profiler-Markern in einem Unity-Leistungstest
[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);
}In diesem Beispiel heißt unsere Testmethode SpiralFlame_RenderPerformance. Anhand des Methodendekorators [PerformanceUnityTest] wissen wir, dass es sich um einen Unity Performance-Test handelt.
Alle Tests im UnityPerformanceBenchmark-Testprojekt folgen demselben Muster, das wir in dieser Testmethode sehen:
1. Laden Sie die Szene für den Test
2. Setzen Sie die Szene als aktiv, damit wir in der Testmethode mit ihr interagieren können
3. Erstellen Sie ein Testobjekt vom Typ DynamicRenderPerformanceMonoBehaviourTest und fügen Sie es der Testszene hinzu (dies geschieht in der Methode SetupPerfTest<T>)
4. Warten Sie auf einen konstanten Zeitwert, damit sich die Szene nach dem Laden und Hinzufügen des Testobjekts zur Szene "einpendelt", bevor wir mit den Probenmetriken beginnen.
5. Einrichten unserer Profiler-Marker für die Erfassung durch die Performance Test Extension API
6. Teilen Sie dem Leistungstest mit, dass wir bereit sind, mit der Erfassung von Metriken zu beginnen.
7. Geben Sie dann das Testobjekt (ein IMonoBehaviourTest) zurück, um die Metriken während der Rendering-Schleife zu erfassen.
In der Basisklasse RenderPerformanceMonoBehaviourTestBase (diese Klasse erbt von MonoBehaviour) werden auch benutzerdefinierte Metriken (Metriken, die nicht unter einen der Unity Profiler-Marker, Framecount oder Ausführungszeit fallen) erfasst.
Beispiel: Abtasten von benutzerdefinierten Metriken in einem MonoBehaviour-Skript
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
}Im obigen Beispiel erfassen wir FPS, GpuTimeLastFrame (wenn XR aktiviert ist) und die Startzeit der Anwendung (wenn Unity Analytics aktiviert ist und wir mit Unity 2018.2 oder neuer arbeiten, wo die benötigte API verfügbar ist).
Beachten Sie schließlich, dass wir in der Basisklasse RenderPerformanceMonoBehaviourTestBase eine Eigenschaft public bool IsTestFinished implementiert haben, die erforderlich ist, weil unsere RenderPerformanceMonoBehaviourTestBase die Schnittstelle IMonoBehaviourTest implementiert.
Diese Eigenschaft ist wichtig, weil der Unity Test Runner sie verwendet, um zu wissen, wann der Test beendet werden soll. Wenn der Wert wahr ist, endet der Test. Es liegt an Ihnen, die gewünschte Logik zu implementieren, um zu bestimmen, wann der Unity Test Runner die Ausführung des Tests beenden soll.
Beispiel: Benutzerdefinierte Metriken in der Eigenschaft IsTestFinished abfragen
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;
}
}In diesem letzten Beispiel erfassen wir die Anzahl der gerenderten Spielobjekte, Dreiecke und Eckpunkte in der Szene, wenn der Test beendet ist.
Nachdem wir nun einige Beispiele dafür gesehen haben, wie wir die Performance Testing Extension aufrufen, um Metriken abzufragen, lassen Sie uns darüber sprechen, wie wir diese zu Beginn konfigurieren.
Die Measure.*-Methoden nehmen im Allgemeinen eine Struktur als Parameter an, die SampleGroupDefinition genannt wird. Wenn wir eine neue SampleGroupDefinition erstellen, definieren wir einige Eigenschaften für die Proben, die wir sammeln möchten.
Beispiel: Definieren Sie eine neue SampleGroupDefinition für GpuTimeLastFrame, die Millisekunden als Sample-Einheit verwendet, und fassen Sie Samples mit einem Mindestwert zusammen
Nachfolgend finden Sie die SampleGroupDefinition für GpuTimeLastFrame. Auf diese Weise teilen wir der Performance Testing Extension mit, wie sie Proben sammeln und für GpuTimeLastFrame aggregieren soll.
Diese SampleGroupDefinition stammt aus dem Testbeispiel für die Renderleistung einer dynamischen Szene. Daher haben wir uns hier entschieden, unsere Samples anhand des gesammelten Mindestwerts zu aggregieren. Aber warum sollten wir das tun, anstatt ein gängigeres Aggregationsmaß wie den Median oder den Durchschnitt zu verwenden?
Die Antwort ist, dass die Szene dynamisch ist. In einer dynamischen Szene wäre die Verwendung eines Medians oder Durchschnitts unzuverlässig oder inkonsistent für dieselbe Szene, die mit demselben Code ausgeführt wird, da sich die Art des Renderings ändert. Dies ist höchstwahrscheinlich das Beste, was wir tun können, wenn wir ein einzelnes Aggregat für eine Rendering-Metrik in einer dynamischen Szene verfolgen wollen. Wenn wir jedoch eine ähnliche SampleGroupDefinition für unsere statischen Szenen definieren, verwenden wir definitiv eine Median-Aggregation.
new SampleGroupDefinition(GpuTimeLastFrameName, SampleUnit.Millisecond, AggregationType.Min)
Beispiel: Definieren Sie eine neue SampleGroupDefinition für FPS, wobei keine als Stichprobeneinheit verwendet wird, fassen Sie die Stichproben anhand eines Medianwerts zusammen, ein höherer Wert ist besser
Nachfolgend finden Sie die SampleGroupDefinition für FPS (Frames Per Second). FPS hat keine eigene Maßeinheit; es sind einfach FPS, also geben wir hier SampleUnit.None an. Wir verwenden hier einen Median-Aggregationstyp. Da es sich um eine statische Szene handelt, müssen wir uns keine Sorgen um eine unvorhersehbare Rendering-Erfahrung machen. Wir legen explizit einen Schwellenwert von 15% für die Stichprobengruppe fest und übergeben true für das Argument increaseIsBetter, denn wenn FPS zunimmt, ist das eine gute Sache!
Diese letzten beiden Argumente werden gesammelt und in unserer .xml-Datei mit den Leistungstestergebnissen gespeichert, wenn sie über die Befehlszeile ausgeführt werden. Sie können später im Unity Performance Benchmark Reporter verwendet werden, um Benchmarks zu erstellen.
new SampleGroupDefinition(FpsName, SampleUnit.None, AggregationType.Median, threshold: 0.15, increaseIsBetter: true)
Wenn der Test abgeschlossen ist, werden alle zuvor aktivierten metrischen Stichproben von der Erweiterung für Leistungstests aggregiert.
Ich möchte darauf hinweisen, dass wir in unseren Codebeispielen einige verschiedene Unity Performance Testing Extension APIs verwenden, nämlich
- Measure.ProfilerMarkers, und
- Maßnahme.Benutzerdefiniert
Die Unity Performance Testing Extension bietet auch andere Messmethoden, die Ihren speziellen Anforderungen entsprechen, je nachdem, was und wie Sie die Leistung in Unity messen möchten. Zu diesen zusätzlichen Methoden gehören:
- Maßnahme.Methode
- Measure.Frames
- Measure.Scope
- Measure.FrameTimes
Erfahren Sie mehr über die verschiedenen Messmethoden in der Dokumentation der Unity Performance Testing Extension, insbesondere im Abschnitt "Messungen durchführen".
Nachdem wir nun einige Beispiele dafür gesehen haben, wie wir Leistungstests mit dem Unity Test Runner und der Unity Performance Testing Extension schreiben, wollen wir uns nun ansehen, wie wir sie ausführen.
Es gibt zwei Möglichkeiten, wie wir unsere Leistungstests durchführen können
1. Starten Sie Unity über die Befehlszeile mit der Option -runTests. Dies ist die bevorzugte Methode für Leistungstests, da die Unity Performance Test Extension eine Ergebnis-.xml-Datei für uns generiert, die wir im Unity Performance Benchmark Reporter verwenden können, um unsere Ergebnisse anzuzeigen und zu vergleichen.
2. Direkt aus dem Editor heraus. Dies ist ein nützlicher Ansatz, wenn Sie
a. Sie möchten einfach nur die Tests ausführen und die Ergebnisse im Unity Test Runner-Fenster anzeigen, ohne die Ergebnisse für eine spätere Verwendung aufzeichnen zu müssen, oder
b. Sie möchten sicherstellen, dass Ihre Tests ausgeführt werden oder Sie müssen den Testcode debuggen.
Im Folgenden finden Sie zwei Beispiele für die Ausführung von Leistungstests mit Unity Test Runner über die Befehlszeile. Diese Beispiele sollten Ihnen sehr bekannt vorkommen, denn wir bauen auf denselben Beispielen auf, die wir bereits in unserer Diskussion über das Öffnen des UnityPerformanceBenchmark-Projekts von der Kommandozeile aus gesehen haben.
Beispiel: Ausführen der UnityPerformanceBenchmark Leistungstests von Windows gegen einen Android Player
Hier starten wir Unity unter Windows, um für Android mit OpenGLES3 Grafik-API, Multithreading-Rendering und Mono Scripting Backend zu bauen.
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
Beispiel: Ausführen von UnityPerformanceBenchmark Leistungstests von OSX gegen einen iOS Player
Hier starten wir Unity auf OSX, um für iOS mit OpenGLES3 Grafik API, Multithreading und Mono Scripting Backend zu bauen. Außerdem stellen wir dem Apple-Entwicklerteam die Informationen für das Bereitstellungsprofil zur Verfügung, die für die Bereitstellung auf einem iOS-Gerät erforderlich sind.
./Unity -runTests [-batchmode] -projectPath /XRAutomatedTests-2018.2/PerformanceTests/UnityPerformanceBenchmark
-testPlatform iOS -buildTarget iOS -playergraphicsapi=OpenGLES3
-mtRendering -scriptingbackend=mono
-appleDeveloperTeamID=<yourAppleDeveloperTeamID>
-iOSProvisioningProfileID=<IhreIosProvisionProfileID> -testResults /PerfTests/results/PerfBenchmark_Android_OpenGLES3_MtRendering_Mono.xml
-logfile /PerfTests/logs/PerfBenchmark_Android_OpenGLES3_MtRendering_Mono_UnityLog.txt
Für diese beiden Beispiele haben wir drei bis vier neue Befehlszeilenoptionen eingeführt, mit denen wir unsere Tests ausführen können, anstatt nur den Unity-Editor mit den Befehlszeilenargumenten zu öffnen, die der Methode IPrebuildSetup.Setup zur Verfügung stehen.
-runTests
Diese Option teilt dem Unity Test Runner mit, dass Sie Ihre Tests ausführen möchten
-testResults <pathToWritePerformanceTestResultsFile>
Diese Option gibt den Dateinamen und den Pfad zu der .xml-Datei an, in der der Unity Test Runner die Ergebnisse Ihrer Leistungstests speichern soll.
-logfile <pathToWriteUnityEditorLogFile>
Diese Option gibt den Dateinamen und den Pfad zu der Datei an, in die der Unity-Editor sein Logging schreiben soll. Dies ist optional, kann aber bei der Untersuchung von Fehlern und Problemen sehr hilfreich sein, wenn Sie schnell auf die Protokolldatei des Unity Editors zugreifen können.
-batchmode
Mit dieser Option wird der Unity-Editor im Headless-Modus geöffnet. Wir verwenden diese Option, wenn wir nur Leistungstests für Spieler durchführen und das Unity Editor-Fenster nicht geöffnet werden muss. So können Sie bei der Ausführung automatisierter Tests Zeit sparen. Wenn diese Option nicht verwendet wird, wird der Unity-Editor auf dem Bildschirm geöffnet, bevor die Tests ausgeführt werden.
Bei Unity führen wir unsere Leistungstests über die Kommandozeile aus, oft im Batch-Modus, in unserem kontinuierlichen Integrationssystem.
Beispiel: Ausführen der UnityPerformanceBenchmark-Tests über die Befehlszeile
Wenn das Unity Test Runner-Fenster ganz oben geöffnet ist und der PlayMode ausgewählt ist (PlayMode-Tests werden entweder im Build-Player oder im Playmode-Fenster des Editors ausgeführt), haben wir
1. Alle ausführen - Klicken Sie auf diese Schaltfläche, um alle Tests auf der Registerkarte Wiedergabemodus auszuführen.
2. Ausgewählte ausführen - Klicken Sie auf diese Schaltfläche, um den ausgewählten Test oder Knoten und alle darunter liegenden Tests auszuführen.
3. Run all in player - klicken Sie darauf, damit der Unity-Editor den in den Build-Einstellungen konfigurierten Player-Typ erstellt und die Tests dort ausführt
Wichtige Voraussetzung Das Ausführen von Leistungstests vor Version 0.1.50 der Performance Testing Extension im Unity-Editor aus dem Test Runner-Fenster erzeugt keine Ergebnis-.xml-Datei, die für den Unity Performance Benchmark Reporter benötigt wird. Wenn Sie jedoch Version 0.1.50 oder höher der Performance Testing Extension verwenden, wird eine results.xml-Datei in den Projektordner `Assets\StreamingAssets` geschrieben.
Wenn Sie eine Version der Performance Testing Extension verwenden, die älter als Version 0.1.50 ist, und eine .xml-Ergebnisdatei erstellen möchten, nachdem Sie Ihre Leistungstests durchgeführt haben, müssen Sie die Tests ausführen, indem Sie Unity von der Befehlszeile aus mit der Befehlszeilenoption -runTests starten. Wenn Sie Unity mit der Befehlszeilenoption -runTests ausführen, wird der Editor geöffnet und beginnt mit der Ausführung der Tests.
Die Ergebnis-.xml-Dateien enthalten die Ergebnisse und Metadaten der Testläufe, die wir mit dem Unity Performance Benchmark Reporter verwenden werden, um Benchmark-Ergebnisse zu erstellen und mit späteren Testläufen zu vergleichen.
Beispiel: Ausführen von Leistungstests im Unity-Editor
Wenn wir diese Tests aus dem Editor heraus ausführen, können Sie die Gesamtwerte unten im Unity Test Runner-Fenster sehen, indem Sie die einzelnen Tests auswählen.
Beispiel: Anzeigen von Leistungstest-Sample-Aggregationen aus Unity Test Runner
Wenn Sie die Ergebnisse Ihrer Unity Performance-Tests von der Kommandozeile aus sehen möchten, müssen Sie den Unity Performance Benchmark Reporter verwenden (oder einfach die Ergebnis-.xml-Datei öffnen, aber das ist nicht einfach zu lesen).
Lassen Sie uns nun darüber sprechen, wie wir den Unity Performance Benchmark Reporter verwenden können, um die Ergebnisse anzuzeigen und zu vergleichen.
Der Unity Performance Benchmark Reporter ermöglicht den Vergleich von Leistungsmetrik-Baselines und nachfolgenden Leistungsmetriken (wie sie mit dem Unity Test Runner mit der Unity Performance Testing Extension generiert wurden) in einem html-Bericht mit grafischen Visualisierungen.
Der Reporter wurde als .NET Core 2.x-Assembly erstellt, so dass er auf verschiedenen von .NET unterstützten Plattformen (Windows, OSX, etc.) ausgeführt werden kann. Um es auszuführen, müssen Sie daher sicherstellen, dass Sie das .NET Core SDK installiert haben.
Um den Unity Performance Benchmark Reporter auszuführen, rufen Sie die Assembly mit dem Befehl dotnet wie folgt auf:
dotnet UnityPerformanceBenchmarkReporter.dll
--baseline=D:\UnityPerf\baseline.xml
--results=D:\UnityPerf\results --reportdirpath=d:\UnityPerf
Nachdem der Reporter ausgeführt wurde, wird ein Verzeichnis mit dem Namen UnityPerformanceBenchmark erstellt, in dem sich ein HTML-Bericht sowie unterstützende .css-, .js und Bilddateien befinden. Öffnen Sie den HTML-Bericht, um die in den .xml-Ergebnisdateien erfassten Leistungskennzahlen zu visualisieren.
--results
Der Pfad zu einem Verzeichnis, in dem sich eine oder mehrere .xml-Dateien mit Nicht-Basisergebnissen befinden, die in den HTML-Bericht aufgenommen werden sollen.
Mindestens ein --results Wert muss an die UnityPerformanceBenchmarkReporter.dll Assembly übergeben werden. Dies ist das einzige erforderliche Feld.
Diese Befehlszeilenoption kann auch verwendet werden, um den Pfad zu einer einzelnen .xml-Ergebnisdatei anzugeben, die nicht der Baseline entspricht. Außerdem können Sie mehrere Verzeichnisse oder Dateien angeben, indem Sie die Option wie folgt wiederholen:
--results=D:\UnityPerf\results --results=D:\UnityPerf\results.xml
--baseline
Der Pfad zu einer Ergebnis-.xml-Datei, die beim Vergleich mit anderen Ergebnissen verwendet wird.
--reportdirpath
Der Pfad zu einem Verzeichnis, in dem der Reporter den Performance-Benchmark-Bericht erstellen wird. Diese wird in einem Unterverzeichnis von UnityPerformanceBenchmark erstellt.
Wenn der Speicherort des Berichts nicht angegeben wird, wird das Unterverzeichnis UnityPerformanceBenchmark in dem Arbeitsverzeichnis erstellt, in dem die UnityPerformanceBenchmarkReporter.dll aufgerufen wurde.
Lassen Sie uns einige Leistungstestergebnisse mit dem Performance Benchmark Reporter vergleichen.
Beispiel: Experimentieren Sie mit Konfigurationsänderungen in einer VR-aktivierten Gear VR-Szene, um die Bildrate zu verbessern
Ich habe eine Unity-Szene mit den folgenden Komplexitätsmerkmalen.
- 732 Objekte
- 95.898 Dreiecke
- 69.740 Scheitelpunkte
Ich habe einen Unity-Performance-Test mit dieser Szene durchgeführt, um herauszufinden, ob ich mit Multi-Pass-Stereo-Rendering annähernd 60 FPS erreichen kann. Als nächstes habe ich den Performance Benchmark Reporter mit den Ergebnissen meines Tests ausgeführt.
Ich habe festgestellt, dass meine FPS eher bei 30 FPS liegen, also bei der Hälfte von dem, was ich gerne erreichen würde.
Als nächstes werde ich versuchen, Single Pass Multiview Stereo Rendering zu verwenden, um zu sehen, wie nah ich an 60 FPS herankomme. Ich werde meinen Leistungstest mit der geänderten Konfiguration erneut durchführen und dann einen weiteren Unity-Leistungsbenchmark-Bericht erstellen, in dem ich meine ersten Ergebnisse mit den neuen vergleiche.
Es sieht so aus, als ob die Umstellung der Konfiguration auf Single Pass Multiview Rendering unsere FPS auf 37 verbessert hat. Wir müssen immer noch näher an 60 FPS herankommen, wenn wir wollen, dass diese Szene ohne signifikanten Frame-Drop auf Gear VR läuft.
Als Letztes werde ich damit experimentieren, die Anzahl der rotierenden Würfel in meiner Szene zu reduzieren, um zu sehen, ob wir die FPS erhöhen können.
Nach ein paar Versuchen kann ich die Leistung auf ~55 FPS verbessern. Aber ich musste die Anzahl der Objekte in der Szene von 732 auf 31 reduzieren. Das ist eine ganze Menge.
Ich werde auf andere Verbesserungen zurückkommen, die ich zur Leistungsoptimierung vornehmen kann, aber für den Moment werde ich dies als FPS-Basiswert verwenden. Ich werde dies als Maßstab für die Zukunft nehmen und hoffen, dass ich es verbessern kann.
Die Festlegung von Benchmarks kann je nach Projekt viele Dinge bedeuten. In diesem Zusammenhang geht es bei der Durchführung von Leistungstests in Unity darum, eine Basismenge an Ergebnissen zu erstellen, einen Satz von Leistungskennzahlen, mit denen wir spätere Ergebnisse vergleichen können, wenn wir Änderungen vornehmen. Diese werden zu unserem Maßstab.
Im vorigen Abschnitt habe ich eine Konfiguration mit Single Pass Multiview Stereo Rendering für Gear VR und einer geringeren Anzahl von Szenenobjekten gefunden, die zu "akzeptablen" FPS führte. An diesem Punkt beschließe ich, meine Testergebnisse als Maßstab zu nehmen. Lassen Sie uns an einem Beispiel sehen, wie wir diesen Benchmark verwenden können, wenn wir weitere Änderungen an der Player-Konfiguration vornehmen.
Beispiel: Verwenden Sie den Leistungs-Benchmark, um eine Leistungsverschlechterung bei Konfigurationsänderungen zu erkennen.
Ich möchte Antialiasing in meiner Szene aktivieren, um das Erscheinungsbild zu glätten. Die Standard-Qualitätseinstellungen in Unity für Android deaktivieren Antialiasing, aber ich würde gerne sehen, ob wir es aktivieren können und trotzdem eine akzeptable FPS für unsere Gear VR-Szene beibehalten.
Zunächst habe ich den Antialiasing-Wert in meiner Methode IPrebuildSetup.Setup auf 4 gesetzt.
QualitySettings.antiAliasing = 4;
Als nächstes wiederhole ich den Leistungstest von vorhin auf meinem Gear VR-fähigen Android-Telefon. Anschließend verwende ich den Unity Performance Benchmark Reporter, um diesen neuen Durchlauf mit meinen neu erstellten Benchmark-Ergebnissen zu vergleichen.
Aber sehen Sie, mit der Neukonfiguration meines Unity-Players, um Antialiasing auf Stufe 4 zu verwenden, sind meine FPS auf 32 FPS gesunken, was in etwa dem entspricht, wo ich ursprünglich angefangen habe, als ich diese Szene mit 732 Objekten erstellt habe.
Ich möchte mit ein paar niedrigeren Antialiasing-Werten experimentieren, um zu sehen, ob ich einen akzeptablen FPS für die Szene erreichen kann, bevor ich diese Idee aufgeben werde. Also versuche ich es mit Antialiasing auf 2 und dann schließlich auf 1 eingestellt. Die Ergebnisse sehen Sie in der Abbildung unten.
In diesem Rekonfigurations-Szenario konnte ich mithilfe des zuvor erstellten Leistungs-Benchmarks mit Änderungen an meinen Unity-Player-Einstellungen experimentieren und die Auswirkungen auf die Leistung überprüfen, bevor ich sie festlegte.
Obwohl ich mit Antialiasing, das auf 1 eingestellt ist, innerhalb meiner Standardschwelle von 15 % Abweichung für FPS liege, sind die FPS jetzt bei 49, also etwas zu weit von den 60 FPS für meine VR-aktivierte Szene entfernt, die ich gerne erreichen würde. Ich glaube nicht, dass ich mich heute auf diese Änderungen einlassen werde.
Unity legt standardmäßig großen Wert auf hohe Leistung. Aber die Unity Engine ist nur ein Teil dessen, was letztendlich dazu führt, dass die Benutzer Ihre Spiele gerne spielen und ein reibungsloses und leistungsstarkes Erlebnis auf allen Plattformen genießen, auf denen sie spielen. Und SDKs, Treiber oder Unity-Pakete, die gut funktionieren, ohne dass es zu Leistungseinbußen kommt, sind entscheidend für ein großartiges Leistungserlebnis für alle.
Ich habe Ihnen einige Unity-Tools vorgestellt, die es Ihnen erleichtern, Performance-Metriken zu sammeln und damit Benchmarks zu erstellen: die Unity Performance Testing Extension und den Unity Performance Benchmark Reporter. Ich ermutige Sie, auszuprobieren, was sie für Sie und Ihre leistungsorientierten Bemühungen tun können.
Wir haben uns angesehen
- Wie wir den Unity Test Runner verwenden können, um Leistungstests zu schreiben und Profiler und andere Metriken zu testen,
- Einige verschiedene Möglichkeiten, wie wir Leistungstests mit dem Unity Test Runner ausführen können, und
- Wie Sie den Unity Performance Benchmark Reporter verwenden, um Performance-Metriken zu analysieren und zu vergleichen, und zwar Lauf für Lauf, wenn Sie Ihre Performance-Tests verbessern wollen.
Die Festlegung von Basiswerten für diese Metriken und deren Verwendung zur Erstellung eines Benchmarks für Ihre Szenen, Ihr Spiel, Ihr SDK, Ihren Treiber, Ihr Paket oder andere Unity-Integrationen kann ein effektiver Weg sein, um die Auswirkungen Ihrer Änderungen sichtbar zu machen. Viel Glück!
Mein Dank und meine Anerkennung gilt meinen Unity-Kollegen, die mit mir zusammen an dieser Arbeit gearbeitet, Ideen gesammelt, experimentiert, entwickelt und iteriert haben.
- Qi Jiang
- Sakari Pitkänen
- Gintautas Skersys
- Benjamin Smith