Tiefgehende Analyse des Adaptive-Performance-Systems in der mobilen Spieleentwicklung mit der Unity-Engine

Im modernen Ökosystem der mobilen Spieleentwicklung hat das geometrische Wachstum der Hardware-Kapazitäten den Weg dafür geebnet, Spiele, die grafische Grenzen sprengen, auf tragbaren Geräten auszuführen. Mobile Plattformen verfügen jedoch im Gegensatz zu Desktop- oder Konsolensystemen über keine aktiven Kühlmechanismen (Lüfter oder Flüssigkeitskühlsysteme). In einer System-on-Chip-Architektur (SoC) befinden sich die Zentraleinheit (CPU), die Grafikprocessing-Einheit (GPU), Speichercontroller und Netzwerkmodule auf engstem Raum von wenigen Millimetern zusammen.¹ Der kontinuierliche Betrieb dieser Komponenten bei hohen Taktfrequenzen (Clock Speed) führt unvermeidlich zur Erzeugung enormer Mengen an Abwärme.

Wenn die Temperatur des Geräts kritische Schwellenwerte erreicht, aktiviert das Betriebssystem einen Schutzmechanismus namens „Thermal Throttling“ (Thermisches Drosseln), um die Hardware vor physischen Schäden zu schützen und eine Zersetzung der chemischen Struktur des Akkus zu verhindern.² Dieser Mechanismus senkt die Taktfrequenzen von CPU und GPU plötzlich und aggressiv. Aus Sicht der Spieleentwickler bedeutet dies plötzliche Einbrüche der Bilder pro Sekunde (FPS), erhöhte Eingabeverzögerungen (Input Lag) und eine vollständige Beeinträchtigung des Spielerlebnisses.³ Genau an diesem Punkt setzt das Unity Adaptive-Performance-System (Anpassbare Leistung) an, das als Brücke zwischen Software und Hardware fungiert und darauf abzielt, dass sich die Spielengine proaktiv an die thermischen Dynamiken des Geräts anpasst. Dieser Bericht untersucht die Anatomie von Konfigurationswarnungen, die während des Entwicklungsprozesses häufig auftreten, ausgehend von der zugrunde liegenden Architektur des Adaptive-Performance-Pakets, Skalierungsalgorithmen, Integrationsstrategien und den bereitgestellten Optimierungsvorteilen mit akademischer und professioneller Tiefe.

Die Hauptursachen für die Warnung „Adaptive Performance Settings“ und Konfigurationslösungen

Wenn ein neues mobiles Projekt in der Unity-Game-Engine gestartet oder ein bestehendes Projekt für die Kompilierung auf mobilen Plattformen (Android, iOS) konfiguriert wird, erscheint häufig die folgende Warnung oder eine ähnliche Meldung auf dem Konsolenbildschirm: „No Adaptive Performance provider package installed. Adaptive Performance requires a provider to get information during runtime. Please install a provider such as Adaptive Performance Samsung (Android) from the Adaptive Performance Settings“.⁴ Der Hauptgrund für diese Warnung, die die Entwicklungsprozesse von Entwicklern verlangsamt, ist das Funktionsprinzip des modularen Paketverwaltungssystems und der Hardwareschicht (Hardware Abstraction Layer) von Unity.

Wenn Unity ein Projekt mit Vorlagen wie „Mobile 2D“, „Mobile 3D“ oder „Universal Render Pipeline (URP)“ erstellt, enthält es das Adaptive-Performance-Basispaket bereits als vorinstalliert (Pre-installed) im Projekt.⁵ Das Basispaket besitzt jedoch von sich aus keine nativen Bibliotheken, die Daten von der Hardware des Geräts lesen oder in das Betriebssystem eingreifen können. Damit das Paket funktionsfähig wird, muss ein modulspezifischer „Provider“ (Anbieter), der für das Zielbetriebssystem (Android usw.) oder die Testumgebung bestimmt ist, dem Projekt hinzugefügt und konfiguriert werden.⁶ Wenn das Anbietermodul fehlt, kann das Basispaket zur Laufzeit (Runtime) nicht auf die Hardwaresensoren zugreifen und löst diese Warnung aus, um den Entwickler zu informieren. Die Lösung der Warnung und die Konfigurationsschritte weisen je nach Zielplattform der Entwicklung und verwendeter Unity-Version erhebliche methodische Unterschiede auf.

Die Lösung für diese während des Entwicklungsprozesses auftretende Warnung sollte plattformbasiert angegangen werden. Da die Zugriffsberechtigungen von Betriebssystemen auf Hardware-APIs unterschiedlich sind, unterscheiden sich auch die von Unity angebotenen Lösungen.

ZielplattformTechnische Ursache der WarnungAnzuwendende LösungsmethodikAndroidDas native Plugin für die Kommunikation mit ADPF oder dem Samsung GameSDK ist im Projekt nicht vorhanden.Über den Unity Package Manager muss das Adaptive Performance Android Provider-Paket oder, falls ein gerätespezifisches Ziel vorliegt, das Samsung (Android) Provider-Paket installiert werden.⁶ Anschließend muss der entsprechende Provider im Menü Edit > Project Settings > Adaptive Performance aktiviert werden.iOS (Apple)Es ist kein offizieller, von Unity unterstützter Hardware-Anbieter (Provider) für Adaptive Performance im iOS-Ökosystem verfügbar.⁴Wenn der Mobile-Eigenschaftssatz zum Projekt hinzugefügt wird, wird Adaptive Performance als Abhängigkeit (Dependency) geliefert und kann nicht entfernt werden. Für iOS-Kompilierungen ist diese Warnung harmlos und kann ignoriert werden oder das Mobile-Modul kann aus dem Paketmanager entfernt werden, um die Abhängigkeit zu trennen.⁴Desktop-Editor (PC/Mac)Auf Windows- oder macOS-Betriebssystemen sind keine für Mobilgeräte spezifischen Thermosensoren und SoC-Architekturen vorhanden.Um mobile Bedingungen auf dem Entwicklungscomputer zu simulieren, muss der Simulator (Desktop) Provider installiert und ein virtuelles thermisches Umfeld mithilfe des Device Simulator-Fensters erstellt werden.²Unity 6 (Build Profiles)Bei den mit Unity 6 eingeführten Build-Profilen (Build Profiles) wurde die profilbezogene Konfiguration zusätzlich zu den Adaptive-Performance-Einstellungen des Hauptprojekts vergessen.Im Menü File > Build Profiles muss für die ausgewählte Plattform auf die Schaltfläche Add Settings > Adaptive Performance Settings geklickt und ein Provider zugewiesen werden. Das Nicht-Hinzufügen dieser Einstellungen in den Versionen Unity 6.000.x führt zu dem Fehler „No default loader found“.⁹

Diese Warnung ist im Wesentlichen kein Kompilierungsfehler (Compile Error), sondern eine Benachrichtigung über ein fehlendes Optimierungspotenzial. Der Entwickler kann diese Warnung ignorieren und das Spiel auf dem Gerät ausführen; in diesem Fall läuft das Spiel jedoch völlig blind in Bezug auf den thermischen Zustand der Hardware und wird unweigerlich den unerbittlichen thermischen Drosselungseingriffen des Betriebssystems ausgesetzt sein.

Die Architektur des Adaptive-Performance-Systems und das Provider-Ökosystem (Anbieter)

Adaptive Performance baut eine bidirektionale Kommunikationsbrücke zwischen den Entscheidungsfindungsmechanismen der Spiele-Engine und der physischen Hardware auf. Die Datenerfassungsschicht dieser Architektur wird von Providern (Anbietern) gebildet. Da die stark fragmentierte Struktur des Android-Ökosystems die Verwendung einer einzigen Hardware-API auf allen Geräten unmöglich macht, überwindet Unity dieses Problem mit spezifischen Anbietern, die in verschiedene Hardware-Frameworks (Frameworks) integriert sind.

Integration des Android Dynamic Performance Framework (ADPF)

Unitys grundlegendes „Android Provider“-Modul basiert auf der Android Dynamic Performance Framework (ADPF)-Architektur, die von Google mit dem Android 12-Betriebssystem und späteren Versionen eingeführt wurde.² ADPF ist ein revolutionäres API-Set, das einen direkten Dialog zwischen Spielen und dem thermischen Management des Betriebssystems ermöglicht. Bei herkömmlichen Ansätzen versucht das Betriebssystem zu erraten, wie viel Rechenleistung welcher Frame des Spiels benötigt, und diese Schätzungen führen häufig zur Zuweisung falscher CPU-Taktfrequenzen.

Der Unity Adaptive Performance Android Provider sorgt hingegen über die „Performance Hint API“ (Performance-Hinweis-Schnittstelle) für einen kontinuierlichen Datenstrom zum Betriebssystem.⁶ Immer wenn ein Frame gerendert wird, meldet die Engine dem ADPF-System die Zielzeit für diesen Frame (z. B. 16,6 Millisekunden, wenn 60 FPS angestrebt werden) sowie die tatsächliche Zeit (Actual Duration), die CPU und GPU benötigt haben, um diesen Frame fertigzustellen.⁶ Dank dieser präzisen Feedback-Schleife erhöht das Android-Betriebssystem die Frequenz der CPU-Kerne nur so weit, wie es das Spiel benötigt. Wenn sich das Gerät erwärmt, sendet das Betriebssystem thermische Warnungen an Unity zurück, sodass die Grafikskalierer innerhalb der Engine eingreifen, bevor es zu einer Verlangsamung auf Hardwareebene kommt.⁶ Die stabile Version 1.2 und höhere Versionen des Android Providers (Versionen, die über die Einschränkung des Pixel-Geräts hinausgehen) werden ab Adaptive Performance 5.0 und Unity 2021.3 unterstützt.⁶

Samsung GameSDK und spezifische Hardware-Optimierungen

Da Samsung einen der größten Marktanteile im Android-Ökosystem besitzt, bietet das Unternehmen eine angepasste Hardwareschnittstelle namens GameSDK an, um die Grenzen seiner eigenen Hardware weiter auszureizen. Der Adaptive Performance Samsung (Android) Provider von Unity ermöglicht es, Metriken zu gewinnen, die über die Standard-ADPF-Funktionen hinausgehen und tief in die Samsung-SoCs eintauchen.²

Der Samsung-Anbieter deckt eine riesige Palette von Geräten ab, die über das Betriebssystem Android 10 und höher verfügen und GameSDK 3.2 sowie neuere Versionen unterstützen. Dieser Abdeckungsbereich erstreckt sich von Einsteigergeräten bis hin zu Flaggschiff-Geräten und bietet Entwicklern ein sehr breites Optimierungsfeld.

Unterstützte Samsung Galaxy-SerienModelle (GameSDK 3.2+ / Android 10+)Galaxy S-SerieS9, S10e, S10, S10+, S10 Lite, S20, S20+, S20 Ultra, S20 Lite, S21, S21+, S21 Ultra, S22, S22+, S22 Ultra¹³Galaxy Note-SerieNote9, Note10, Note10+, Note10 Lite, Note20, Note20 Ultra¹³Galaxy Z (Faltbare) SerieZ Fold2¹³Galaxy A-SerieA10s, A11, A21s, A31, A41, A50s, A51, A51 5G, A71, A71 5G, A80, A8 2018, A9 2018, A90 5G¹³Galaxy Xcover-SerieXcover 4s, Xcover Pro¹³

Einer der wichtigsten Hardware-Vorteile, die diese Geräte bieten, ist die Technologie der „Variablen Bildwiederholfrequenz“ (Variable Refresh Rate - VRR).¹³ Die VRR-Unterstützung kann derzeit aktiv auf den Geräten Galaxy S20, S21, S22 und Note 20 genutzt werden.¹³ Wenn Adaptive Performance erkennt, dass das Gerät seine Grenzen erreicht hat, und beschließt, die FPS-Value des Spiels beispielsweise von 60 auf 45 zu senken, sendet es einen Befehl an die Samsung VRR-API, um auch die physische Bildwiederholfrequenz des Bildschirms auf 45 Hz zu senken.¹⁶ Diese Synchronisierung verhindert Bildschirmrisse (Screen Tearing), verhindert einen unnötigen Stromverbrauch des Bildschirm Panels und leistet einen wesentlichen Beitrag dazu, dass das Gerät schneller abkühlt. Darüber hinaus bietet der Samsung-Anbieter auf Geräten mit GameSDK 3.5 (Android 12) und höher Zugriff auf „Cluster Info“-Daten, die die Lastverteilung der großen und kleinen Kerne in der big.LITTLE-Architektur des Prozessors anzeigen.¹³

Thermische Metriken und Engpass-Erkennungsalgorithmen (Bottleneck)

Die Ingenieurskunst hinter der Fähigkeit von Adaptive Performance, proaktive Optimierungen anzubieten, basiert auf Sensoranalysesystemen, die kontinuierlich Daten sammeln. Die zur Laufzeit des Spiels erstellte IAdaptivePerformance-Schnittstelle (Interface) liest Datensätze aus der Hardware in zwei Hauptkategorien: Thermisches Zustands-Feedback (Thermal State Feedback) und Frame-Timing. Anhand dieser Daten wird entschieden, welches Element zu diesem Zeitpunkt die Leistung am meisten einschränkt (Engpass).

Thermisches Feedback und Warnstufen

Der thermische Zustand des Geräts wird nicht nur anhand eines einfachen Celsius-Messwerts bewertet. Die thermischen Dynamiken werden anhand von drei verschiedenen, normalisierten und analytisch verarbeiteten Metriken überwacht ²:

Die erste Metrik, TemperatureLevel (Temperaturstufe), ist ein Gleitkommawert (Float), der zwischen 0,0 und 1,0 normalisiert ist (0,0 entspricht der Standard-Raum-/Betriebstemperatur, 1,0 dem absoluten maximalen thermischen Schwellenwert).² Entwickler können diesen Wert verwenden, um dem Spieler den Erwärmungszustand des Geräts als grafischen Balken in der Benutzeroberfläche des Spiels anzuzeigen oder ihre eigene maßgeschneiderte Optimierungslogik zu erstellen.

Die zweite und prädiktivere Metrik, TemperatureTrend (Temperaturtrend), ist ein Wert zwischen -1,0 und 1,0,

der die mathematische Ableitung der Temperatur, also die Änderungsgeschwindigkeit, darstellt. 2 Ein Wert von 1,0 weist darauf hin, dass sich das Gerät extrem schnell erwärmt, während der Wert 0 anzeigt, dass die Temperatur stabil geblieben ist, und -1,0 bedeutet, dass eine aggressive Kühlungsphase eingeleitet wurde. Damit das System diese Trends erkennt und einen gültigen Mittelwert bildet, ist in der Regel ein Analyseprozess von etwa zehn Sekunden erforderlich. 2 Die dritte und kritischste Metrik ist eine kategorische Klassifizierung namens WarningLevel (Warnstufe), die die Reaktion des Betriebssystems auf den thermischen Zustand bestimmt. 2

Warnstufe (WarningLevel)BetriebssystemstatusReaktion von Adaptive Performance in der Spiele-EngineNoWarning (0)Das Gerät befindet sich in optimalen Temperaturen. Es findet keinerlei thermische Drosselung statt. Dem Spiel wird erlaubt, mit der höchsten angezielten Auflösung, Bildrate und visuellen Qualität gerendert zu werden. 2ThrottlingImminent (1)Die thermische Kapazität läuft voll. Das Betriebssystem hat die Hardwarefrequenzen noch nicht gesenkt, aber die Gefahr steht kurz bevor. Proaktive Eingriffe beginnen. Skalierer mit geringeren visuellen Auswirkungen (z. B. Verkürzung der Schattenreichweite) werden aktiviert, um zu verhindern, dass das Gerät in die nächste Phase übergeht. 2Throttling (2)Die Hardware hat eine kritische Temperatur erreicht, und das Betriebssystem hat die CPU/GPU-Taktfrequenzen aggressiv gesenkt, um sich selbst zu schützen. Die Rechnung für die aggressivste Optimierung wird präsentiert. Die Ziel-Bildrate (Target FPS) wird drastisch gesenkt, die Haupt-Renderauflösung eingeschränkt und radikale Kompromisse eingegangen, damit das Gerät zur Normaltemperatur zurückkehren kann. 2

Frametiming und Engpass-Erkennung (Bottleneck)

Dass ein Spiel keine Bildrate von 60 Bildern pro Sekunde erreicht, kann an mehreren hardwarebedingten Unzulänglichkeiten liegen. Herauszufinden, ob das Problem auf eine unzureichende Grafikkarte (GPU) oder auf einen erschöpften Rechenbedarf des Hauptprozessors (CPU) zurückzuführen ist, ist die erste Regel der Optimierung. Adaptive Performance verfolgt hierzu in jedem Frame die Daten averageFrameTime (durchschnittliche Gesamtframezeit) und averageGpuFrameTime (durchschnittliche GPU-Laufzeit). Die CPU-Zeit von 17 umfasst Prozesse wie das Ausführen der Spiellogik durch den Unity Main Thread und das Vorbereiten der Daten durch den Render Thread für den Versand an die GPU (Draw Call Batching usw.). 17 Als wichtiger Detailpunkt sind in der Messung der CPU-Zeit weder Blockaden auf Betriebsebene noch Leerlauf- oder Wartezeiten (idle/wait times) enthalten, in denen die CPU auf die Beendigung der GPU-Arbeit wartet. 17 Infolge der Analyse dieser Zeiten ordnet das System den aktuellen Leistungsengpass (PerformanceBottleneck) einer von vier Kategorien zu: ● CPU: Ingame-Algorithmen für künstliche Intelligenz, komplexe physikalische Berechnungen oder eine übermäßige Anzahl an Objektinstanzierungen (Instantiation) überlasten den Prozessor. 20

● GPU: Mehrschichtige Transparenzeffekte (Overdraw), das Lesen hochauflösender Texturen sowie schwere Post-Processing-Effekte (wie SSAO oder Bloom) schränken die Grafikeinheit ein. 22

● TargetFrameRate (Fillrate): Das System hat die Zielbildrate bereits erreicht, es liegt keinerlei hardwarebedingte Drosselung vor und das System reicht aus, selbst wenn es unter seinem Leistungspotenzial betrieben wird. 2.

● Unknown: Hierbei handelt es sich um Übergangssituationen, in denen die Ursache der Verzögerung nicht eindeutig ermittelt werden kann.

Entwickler können das Ereignis PerformanceStatus.PerformanceBottleneckChangeEvent abonnieren (über ein Delegate-Pattern), um Zeitpunkte zu erfassen, in denen sich der Engpass-Status zur Laufzeit ändert, und entsprechende algorithmische Reaktionen darauf ausführen. 23 Wenn sich der Engpass beispielsweise plötzlich auf die CPU verlagert, kann die Rechenlast auf dem Prozessor sofort verringert werden, indem die Abtastrate des Sichtfelds (Raycast) für Einheiten der künstlichen Intelligenz in einer offenen Welt von 60 Mal pro Sekunde auf 15 Mal pro Sekunde reduziert wird.

Entscheidungs- und Ausführungs-Engine: Indexer und Scaler

Der Mechanismus, der das autonome Funktionieren des Adaptive-Performance-Systems ermöglicht, beruht auf dem reibungslosen Zusammenspiel zweier Hauptkomponenten: dem „Indexer“ als Gehirn und den „Scalers“ (Skalierern) als ausführenden Organen.

Der Indexer-Mechanismus

Der Indexer ist der zentrale Koordinator, der die vom Gerät empfangenen komplexen thermischen Trends und Engpassdaten kontinuierlich durch einen mathematischen Filter leitet, um den aktuellen „Qualitätsindex“ des Spiels zu berechnen. 19 Die Hauptaufgabe des Indexers besteht darin, visuelle Unstimmigkeiten (Oszillationen) zu verhindern, indem die Spielqualität bei jeder kleinen Temperatur- oder FPS-Schwankung in der Hardware nicht ständig verändert wird. Um diese Stabilität zu gewährleisten, können in den Project Settings Thermal Action Delay (thermische Aktionsverzögerung) und Performance Action Delay (Leistungsaktionsverzögerung) in Sekunden definiert werden. 23 Selbst wenn das System einen Engpass erkennt, stellt es während dieser definierten Verzögerungszeit sicher, dass der Zustand von Dauer ist, trifft danach eine Aktionsentscheidung und sendet ein Signal an die verbundenen Skalierer, die Qualität zu verringern (StateAction.Decrease). 23

Mathematische und visuelle Auswirkungsanalyse der Scalers (Skalierer)

Scaler sind Skripte, die spezifische Eigenschaften der Render Pipeline oder der Physik-Engine von Unity zur Laufzeit (Runtime) verändern. 19 Die Standardstufe (Level) jedes Scalers ist Null. Mit jedem „Qualität verringern“-Signal vom Indexer erhöht sich dieses Level; je höher das Level ist, desto geringer wird das Detail der durch den Scaler gesteuerten Eigenschaft. 19 Wann und in welcher Reihenfolge die Scaler aktiviert werden, wird über eine dreidimensionale Entscheidungsmatrix festgelegt 19 :

1. Engpass-Ziel (Targeting Bottleneck): Sollte die Analyse ergeben haben, dass es sich bei dem Engpass um die GPU handelt, ignoriert der Indexer die CPU-optimierenden Scaler und steuert direkt die auf die GPU ausgerichteten Scaler (zum Beispiel die Auflösung) an.

2. Niedrigstes Level (Lowest Level): Eigenschaften, deren Level noch nicht erhöht wurde (die ihre Originalqualität behalten haben), erhalten Priorität.

3. Visuelle Auswirkung (Visual Impact): Dies ist die Wahrscheinlichkeit, dass der Spieler es bemerkt, wenn die Qualität einer Eigenschaft verringert wird. Sie wird als Niedrig (Low), Mittel (Medium) oder Hoch (High) klassifiziert. 19 Das System beginnt stets damit, Eigenschaften mit geringer visueller Auswirkung zu reduzieren.

Das System bietet eine äußerst breite Palette an Scalern sowohl für die Standard-Render-Pipeline als auch für die Universal Render Pipeline (URP). Die folgende Tabelle detailliert die Hardware-Ziele dieser Scaler und ihre theoretischen Auswirkungen innerhalb der Anwendung.

Scaler-Klasse Engpass-Ziel Visuelle Auswirkung Theoretische und praktische Auswirkung in der Render Pipeline AdaptiveFramerate CPU / GPU / Fillrate Hoch Modifiziert die Variable Application.targetFrameRate des Spiels innerhalb festgelegter Grenzen. Besonders effektiv bei deaktiviertem VSync. Ein Abfall von 60 FPS auf 30 FPS erhöht die Leerlaufzeit aller Komponenten auf dem Chip und erzeugt eine radikale Abkühlungsphase. 19 AdaptiveResolution GPU / Fillrate Hoch Senkt die Skalierung der Bildschirm-Render-Auflösung (Resolution Scale) dynamisch ab. 19

In URP-Projekten arbeitet dies über die Render Scale. Da es die Pixelfüllrate (Fillrate) geometrisch verringert, ist es die stärkste Waffe zum Brechen der thermischen GPU-Last, beeinträchtigt jedoch direkt die Bildschärfe. 15 AdaptiveLOD CPU / GPU Mittel Manipuliert die Übergangsdistanzen des Detailgrads (Level of Detail - LOD) von dreidimensionalen Modellen in der Szene (LOD-Bias). 18 Stellt sicher, dass selbst bei Annäherung der Kamera an die Modelle polygonärmere Versionen auf dem Bildschirm verbleiben, wodurch CPU-Draw-Calls und GPU-Vertex-Berechnungen reduziert werden. 18 AdaptiveShadowmapResolution GPU Mittel/Niedrig Senkt die Pixelauflösung der Schattenkarte in URP. Da eine Verpixelung der Schattenränder bei starker Bewegung auf dem Bildschirm kognitiv nur schwer wahrnehmbar ist, entlastet dies die GPU-Speicherbandbreite ohne Kompromisse bei der Qualität. 19 AdaptiveShadowCascade CPU / GPU Mittel Reduziert die Anzahl der Cascades bei gerichteten URP-Lichten. Jede Schatten-Cascade erfordert, dass schattenwerfende Objekte in der Szene ein weiteres Mal gerendert werden (Draw Call). Eine Verringerung der Cascade-Anzahl entlastet den CPU-Engpass direkt. 19 AdaptiveViewDistance CPU / GPU Hoch Verengt die Entfernungsebene für die Fernsicht (Far Clip Plane) der Hauptkamera, sodass weiter entfernte Objekte keinesfalls in den Render-Ablauf einbezogen werden (Frustum Culling). 19 Dies ist einer der kritischsten Optimierungsschritte, insbesondere in Open-World-Spielen. 15 AdaptiveLayerCulling CPU / GPU Mittel Anstatt die allgemeine Sichtweite zu verkürzen, passt dies die Sichtbarkeitsdistanz bestimmter Unity-Ebenen (Layers) an. 2

Durch die Einschränkung der Render-Distanz beispielsweise von Umgebungsdetails (Gras, kleine Dekorationen) werden winzige Details gelöscht, während große Strukturen um den Spieler herum erhalten bleiben, wodurch die Leistung gesteigert wird. 16 AdaptivePhysics CPU Yüksek Modifiziert die Aktualisierungsschritte (fixedDeltaTime) oder die Anzahl der Iterationen der Physik-Engine von Unity (PhysX oder Box2D) und entlastet so die CPU-Last. 2 Physikberechnungen gehören zu den größten Verursachern von CPU-basierten Engpässen. 21 AdaptiveBatching CPU Niedrig Steuert die Prozesse des dynamischen Sammelns (Dynamic Batching). Entlastet die CPU in Situationen, die keine übermäßigen Vertex-Berechnungen erfordern. 19 AdaptiveDecals CPU / GPU Niedrig Reduziert im URP-System die Render-Distanz oder die Anzahl von Abziehbildern (Decals) wie Einschusslöchern und Blutflecken an Wänden, um die Overdraw-Last während des Material-Zeichenschritts zu senken. 2

Entwickler sind nicht gezwungen, sich ausschließlich auf die Standard-Scalers zu verlassen. Es wird dringend empfohlen, „Custom Scalers“ (Benutzerdefinierte Skalierer) zu entwickeln, die zu den spezifischen Mechaniken des Spiels passen. 2 Um einen benutzerdefinierten Scaler zu schreiben, reicht es aus, von der Klasse AdaptivePerformanceScaler zu erben und grundlegende Eigenschaften wie VisualImpact, Target und MaxLevel zu implementieren sowie die Methode OnLevel() zu überschreiben (override). 19 In einem Spiel, das beispielsweise in einer nebligen Umgebung spielt, kann ein benutzerdefinierter Scaler geschrieben werden, der die Dichte des Nebels bei steigender Temperatur erhöht (Adaptive Fog). Auf diese Weise verringert sich das Sichtfeld des Spielers auf natürliche Weise, während im Hintergrund die Zeichenentfernung der Kamera verkürzt wird, wodurch eine erhebliche Optimierungsillusion erzeugt wird. 15

Leistungssteuerungs-Modi und Taktfrequenz-Management (Clock Frequency)

Adaptive Performance beschränkt sich nicht nur darauf, die grafischen Eigenschaften innerhalb der Game-Engine zu reduzieren, sondern besitzt auch die Fähigkeit, direkt oder indirekt in die elektrische Leistung und die Taktfrequenzen einzugreifen, die das Betriebssystem der CPU und der GPU bereitstellt. Das Betreiben von Prozessoren mit maximalen Taktgeschwindigkeiten erzeugt eine asymptotische Ineffizienz; das bedeutet, dass für eine geringe Menge an zusätzlicher Rechenleistung eine enorme Menge an Energie verbraucht und Wärme erzeugt wird. 17

Zur Verwaltung dieses Energiehaushalts bietet die Adaptive-Performance-Schnittstelle drei verschiedene Steuerungsmodi (PerformanceControlMode): System, Manuell und Automatisch. 20

1. System-Modus (System Performance Control): Dies ist der Standardmodus, der auf Systemen außerhalb von Android-Anbietern (zum Beispiel Desktop-Simulationen) gilt. Das Betriebssystem bestimmt die CPU/GPU-Frequenzen eigenständig über herkömmliche Methoden; Adaptive Performance greift nicht in die Hardware ein, sondern reduziert lediglich die In-Game-Grafik. 20

2. Manueller Modus (Manual Performance Control): Der Modus, in dem der Entwickler die Variablen Instance.DevicePerformanceControl.CpuLevel und GpuLevel direkt zwischen Null und dem Höchstwert zuweisen kann. 23 Die Verwendung dieses Steuerungsmodus wird außer für sehr spezifische Benchmark-Tests keinesfalls empfohlen. 17 Wenn ein Entwickler, der nicht über tiefgehendes Wissen bezüglich der thermischen Einschränkungen und des Batterieentladeverhaltens von mobiler Hardware verfügt, das CPU-Level kontinuierlich hoch hält, überhitzt das Gerät schnell, das Betriebssystem schaltet Schutzmechanismen ein und sperrt das Spiel in die „Throttling“-Phase, wodurch der Akku sinnlos entladen wird. 20

3. Automatischer Modus (Automatic Performance Control): Dies ist der sicherste, effizienteste und dringendstens zu empfehlende Steuerungsmodus. 17 Alles, was der Entwickler tun muss, ist, mit Application.targetFrameRate die Zielbildrate des Spiels festzulegen (zum Beispiel 30 oder 60). 23 Der Automatikmodus analysiert im Hintergrund die Gerätetemperatur, die Render-Zeit und die Betriebsumgebung (ob man sich im Menü oder im Spiel befindet). 20 Wenn das Spiel das 60-FPS-Ziel sehr bequem erreicht, senkt es die Taktfrequenzen von CPU und GPU im Hintergrund leise ab, anstatt den Prozessor unnötigerweise voll auszulasten. Die Bildrate bleibt weiterhin bei 60, aber die Hardware verbraucht deutlich weniger Strom, wodurch das Spiel kühl bleibt und der Akku stundenlang hält (Battery Life Preservation). 20

Temporäre Leistungsladung: Der Boost-Modus (Verstärkungsmodus)

In manchen Momenten von Handyspielen wird anstelle einer nachhaltigen Leistung kurzzeitig eine extrem große Rechenkapazität benötigt. Für solche spezifischen Szenarien enthält Adaptive Performance die „Boost“-API (Verstärkung). 23 Wenn der Boost-Modus aufgerufen wird, wird die minimale Betriebsfrequenz (Minimum) der CPU oder GPU für eine temporäre Dauer der maximalen Betriebsfrequenz (Maximum) angepasst, wodurch die Hardware gezwungen wird, mit ihrem vollen Potenzial zu arbeiten. 23

Bereiche, in denen der Boost-Modus strategisch eingesetzt werden sollte, sind folgende 23 :

● Auf Ladebildschirmen (Loading Screens) beim Öffnen des Spiels oder von Levels, um die Ladezeiten (load time) schwerer in den Speicher zu ladender Modelle zu minimieren.

● Das Beseitigen von Wartezeiten, die beim Entpacken großer Pakete, die über das Netzwerk (Network) heruntergeladen wurden, oder während asynchroner Datenverarbeitungsvorgänge entstehen.

● Das Verhindern einsekündiger Mikro-Ruckler (hitches), die der Spieler während der Shader-Kompilierung (Shader Compilation) oder bei der prozeduralen Inhaltserzeugung erleben kann.

Die Aktivierung des Boost-Modus zieht jedoch einen enormen Stromfluss aus der Batterie des Geräts und lässt die SoC-Temperatur augenblicklich ansteigen. 23 Befindet sich das Betriebssystem bereits in der Throttling-Phase (ist das Gerät zu heiß), werden die Boost-Anforderung oder die Befehle zur manuellen Anpassung des CPU/GPU-Levels von Unity direkt abgelehnt, um Hardwareschäden zu verhindern, und die Steuerung wird gewaltsam auf den „System-Modus“ zurückgesetzt. 23 Es ist von vitaler Bedeutung, dass Entwickler diese Schnittstelle ausschließlich auf Ladebildschirmen, auf denen der Spieler passiv wartet, und für die Dauer von wenigen Sekunden einsetzen.

Entwickler-Interface: C#-API-Nutzung und Visual Scripting

Die Flexibilität des Adaptive Performance-Pakets besteht darin, dass sie es Entwicklern ermöglicht, das autonome System wogegen sie wollen ohne eine einzige Zeile Code zu nutzen, oder aber eine spezielle Logik aufzubauen, die tief in das Herz des Spiels eingreift.

Ereignisgesteuerte (Event-Driven) Programmierung über die C#-API

Entwickler, die programmatisch auf die Thermaldaten des Systems zugreifen möchten, erhalten die Daten über das mit dem Paket erstellte Singleton-Objekt UnityEngine.AdaptivePerformance.Holder.Instance (oder in neueren Versionen Mobile.AdaptivePerformance.Holder). 18 Insbesondere wird das Ereignis (delegate) IThermalStatus.ThermalStatus.ThermalEvent überwacht, um zu erfassen, dass das Gerät im Begriff ist, in einen Engpass (ThrottlingImminent) zu geraten. 2

Wenn ein Ereignis ausgelöst wird (zum Beispiel, wenn ein Hitzealarm eingeht), wird der Status mit einer switch-case-Struktur analysiert und in die Spielmechanik eingegriffen. 2 Wenn die Warnstufe Throttling lautet, wird die Bildrate von 60 auf 15 oder 30 reduziert; wenn es keine Warnung gibt, wird wieder das Ziel von 60 angestrebt. 2 Befindet sich der Engpass gleichermaßen auf der CPU-Seite, kann ein spezielles Skript (script) einige der aktiven KI-Agenten auf der Karte deaktivieren, um den Prozessor sofort zu entlasten. 2

Visual-Scripting-Integration

Für programmierferne Technical Artists (technical artists) und Spieldesigner wird in Unity 5.0 und neueren Versionen durch Visual-Scripting-Pakete vollständige Unterstützung für die C#-API bereitgestellt. 29

Nachdem das Visual-Scripting-Paket zum Projekt hinzugefügt wurde, sollte der Pfad Edit > Project Settings > Visual Scripting > Node Library > Regenerate Units befolgt werden, um sicherzustellen, dass die Adaptive Performance-Knoten (nodes) zur Fuzzy-Finder-Oberfläche hinzugefügt werden. 27

Dank dieser Integration wird der Zugriff auf eine Reihe spezieller Knoten ermöglicht 30 :

● Thermal-Knoten: Der Knoten On Thermal Metric wird sofort ausgelöst, wenn sich die thermische Warnstufe, der Temperaturprozentsatz (Temperature Level) und der Temperaturtrend (Trend) des Geräts ändern. Das Ausgangskabel dieses Knotens kann direkt an eine Logik angeschlossen werden, die eine schwere Lichtquelle oder ein Partikelsystem in der Szene ausschaltet.

● Performance-Knoten: Der Knoten On Bottleneck signalisiert, ob der Engpass CPU, GPU oder Fillrate ist; die Knoten Frame Timing und FPS sind ideal, um Echtzeit-Leistungsdaten auf dem Spielbildschirm auszugeben. Dank des Knotens Cluster Info können die Kernlasten in der big.LITTLE-Architektur ausgelesen werden.

● Boost- und Levels-Knoten: Durch das Hinzufügen des Knotens Set Boost an den Anfang von Ladeschienenblöcken im visuellen Skriptdiagramm können die Ladegeschwindigkeiten ohne Codierung maximiert werden; mit Get Performance Level kann der aktuelle Prozessorgeschwindigkeitsstatus gelesen werden.

Test-, Profiling- und Optimierungsmethodik

Das Hinzufügen des Adaptive-Performance-System zum Projekt löst nicht alle Probleme von allein; ein nicht richtig konfiguriertes System kann die Grafikqualität des Spiels viel zu früh ruinieren oder völlig wirkungslos sein. Der Entwicklungsprozess sollte auf einer wissenschaftlichen Mess- und Vergleichsmethodik (profiling and benchmarking) basieren.

Erstellung eines Basiswerts (Baseline) und A/B-Tests

Gemäß den gemeinsamen Optimierungspraktiken von Google- und Unity-Ingenieuren besteht der erste Schritt darin, die Leistung des Spiels zu messen (Baseline), bevor ADPF oder Adaptive Performance aktiviert wird. 6 Das Spiel sollte auf ein physisches Mobilgerät geladen werden, das über die niedrigsten angestrebten Systemanforderungen (min-spec) verfügt, und etwa zwanzig Minuten lang gespielt werden, bis das Gerät warm wird. 21 Während dieses Tests sollte das Unity-Profiler-Tool über ein drahtloses Netzwerk (Wi-Fi) mit dem Gerät verbunden (Autoconnect Profiler) und die Minuten, in denen die FPS zu sinken beginnen, sowie die Frame Time-Werte aufgezeichnet werden. 1

Anschließend wird das Adaptive-Performance-System mit den Standard-Skalierern im Projekt aktiviert und dasselbe Testszenario von vorne ausgeführt. 6 Über die neue Registerkarte „Adaptive Performance“ im Profiler-Modul sollte untersucht werden, in welcher Minute das Gerät die Warnung ThrottlingImminent ausgegeben hat, welchen Skalierer (zum Beispiel AdaptiveResolution) das System ausgeführt hat und wie sich dies auf die CPU/GPU-Zeiten ausgewirkt hat, indem dies Seite an Seite mit dem ersten Test verglichen wird. 2 Wenn der Entwickler auf Ergebnisse stößt wie „Das Spiel liefert in der 10. Minute immer noch 60 FPS, aber die Auflösung sinkt zu stark“, sollte er an den Skalierergewichten im Indexer drehen und spielspezifisches Feintuning (fine-tuning) betreiben. 6

Simulation in Desktop-Umgebung: Device Simulator

Obwohl Gerätetests unerlässlich sind, verringert das Warten auf das Aufwärmen und Abkühlen eines physischen Telefons die Iterationsgeschwindigkeit in der Codierungsphase. Um dieses Problem zu überwinden, wurde der Simulator (Desktop) Provider entwickelt. 2 Im Desktop-Entwicklungscomputer kann das Fenster Window > General > Device Simulator geöffnet werden, um den Akkustand, den thermischen Trend und Engpässe des virtuellen Geräts künstlich (artificial bottlenecks) auszulösen. 2 Mit einem einzigen Klick kann der Entwickler den Zustand des virtuellen Geräts in die Phase Throttling versetzen und innerhalb von Sekunden sofort testen, wie von ihm geschriebene spezielle Skalierer (Custom Scalers) die Nebeldichte oder Modelldetails (LOD) im Spiel verändern. 2

Synergie mit traditionellen Optimierungsansätzen

Adaptive Performance ist kein Wunderalgorithmus; ein Spiel mit fehlerhaftem Fundament kann es nicht allein retten. Das System erzeugt in Kombination mit klassischen mobilen Optimierungspraktiken einen massiven Multiplikatoreffekt. 1

● Die Texturen (textures) des Spiels sollten in Dimensionen gestaltet werden, die einer Zweierpotenz (POT - Power of Two) entsprechen, und es sollten mobile Hardware-Komprimierungsformate wie ASTC und ETC2 verwendet werden. 8

● Die Optionen Read/Write Enabled von Modellen und Texturen, die zur Laufzeit nicht verändert werden, sollten deaktiviert werden, um das Halten unnötiger Kopien im CPU- und GPU-Speicher zu verhindern. 31 Der Speicherverbrauch (memory bandwidth) ist eine der größten Wärmequellen. 1

● Wenn der Beschleunigungsmesser-Sensor (accelerometer) auf der mobilen Hardware vom Spiel nicht aktiv genutzt wird (wenn es sich beispielsweise nicht um ein Rennspiel handelt), entlastet das Reduzieren der Scanfrequenz des Beschleunigungsmessers oder das Deaktivieren über die Player Settings das Betriebssystem enorm und erweitert den thermischen Spielraum (thermal envelope). 31

● Die Culling-Matrizen (Occlusion Culling) von Gerätekameras sollten sorgfältig gebacken (baked) werden, und Zehntausende von Polygonmodellen, die sich nicht im Sichtfeld der Kamera befinden, aber hinter Wänden liegen, sollten auf der CPU eliminiert werden, bevor sie an den Grafikprozessor gesendet werden (draw call). 3

Wenn ein Spiel, dessen Aufwärmzeit durch all diese traditionellen Maßnahmen auf 15 Minuten verlängert wurde, durch die Skalierer AdaptiveResolution oder AdaptiveFramerate von Adaptive Performance als letzter Verteidigungslinie unterstützt wird, verwandelt es sich in ein perfektes und nachhaltiges mobiles Meisterwerk, bei dem stundenlanger Betrieb und der Abfall von 60 FPS auf 45 FPS vom Spieler niemals bemerkt werden.

Das Fehlen von Kühlgehäuselüftern bei mobiler Hardware zwingt Spieleentwickler dazu, mit den thermischen Grenzen von Silizium Schach zu spielen. Diese technische Reise, die mit einer einfachen Installation eines Anbieters wie den „Adaptive Performance Settings“ beginnt, gipfelt in der Meisterschaft des Zugriffs auf die Energieverwaltungswentile des Betriebssystems, des Lesens von Thermalanalysederivaten und der Echtzeit-Manipulation von Qualitätsalgorithmen in der Render-Pipeline. Der Optimierungsprozess maximiert sowohl die Zufriedenheit der Spieler als auch den langfristigen Erfolg auf mobilen Plattformen, wenn er sich auf die Nachhaltigkeit einer flüssigen Bildrate (sustained performance) statt auf das Erreichen einer hohen Spitzenleistung (peak performance) konzentriert.

*Hinweis: Die Bilder wurden von Google Gemini generiert.