Anwendungsleistung messen – Übersicht

In diesem Dokument erfahren Sie, wie Sie wichtige Leistungsprobleme in Ihrer App erkennen und beheben können.

Wichtige Leistungsprobleme

Es gibt viele Probleme, die zu einer schlechten Leistung einer App beitragen können. Im Folgenden finden Sie einige häufige Probleme, nach denen Sie suchen sollten:

Latenz beim Starten

Die Startlatenz ist die Zeit, die zwischen dem Tippen auf das App-Symbol, die Benachrichtigung oder einen anderen Einstiegspunkt und der Anzeige der Daten des Nutzers auf dem Bildschirm vergeht.

Ihre Apps sollten die folgenden Startziele erreichen:

• Kaltstart in weniger als 500 ms. Ein Kaltstart erfolgt, wenn die gestartete App nicht im Arbeitsspeicher des Systems vorhanden ist. Dies geschieht, wenn die App zum ersten Mal seit dem Neustart oder seit dem Beenden des App-Prozesses durch den Nutzer oder das System gestartet wird. Ein Kaltstart erfordert die meiste Arbeit vom System, da es alles aus dem Speicher laden und die App initialisieren muss. Kaltstarts sollten nicht länger als 500 ms dauern.
• Warmstart in weniger als 200 ms und Heißstart in weniger als 150 ms. Ein Warmstart erfolgt, wenn der Prozess der Anwendung bereits im Hintergrund ausgeführt wird, das System aber die Benutzeroberfläche neu initialisieren oder die Aktivität in den Vordergrund holen muss, z. B. wenn ein Nutzer die App schließt und kurz darauf wieder öffnet. Ein Kaltstart ist noch schneller, da die Aktivität der App bereits im Arbeitsspeicher zwischengespeichert ist und nur in den Vordergrund gebracht werden muss, ohne dass die Ansichtshierarchie neu erstellt werden muss. Achten Sie darauf, dass Warmstarts weniger als 200 ms und Hotstarts weniger als 150 ms dauern.
• P95- und P99-Latenzen liegen sehr nahe an der Medianlatenz. P95 und P99 stehen für das 95. und 99. Perzentil der Startzeiten, während der Median das 50. Perzentil ist. Wenn das Starten der App lange dauert, ist das schlecht für die Nutzererfahrung. Bei der prozessübergreifenden Kommunikation (Interprocess Communication, IPC) und unnötigen E/A-Vorgängen während des kritischen Pfads des App-Starts kann es zu Konflikten bei der Sperrung kommen und Inkonsistenzen können auftreten.

Ruckeln beim Scrollen

Jank ist der Begriff, der den visuellen Schluckauf beschreibt, der auftritt, wenn das System nicht in der Lage ist, Frames rechtzeitig zu erstellen und bereitzustellen, um sie mit der angeforderten Frequenz von 60 Hz oder höher auf dem Bildschirm darzustellen. Ruckeln ist am deutlichsten beim Scrollen zu sehen, wenn es anstelle eines flüssigen Übergangs zu Unterbrechungen kommt. Verzögerung tritt auf, wenn die Bewegung für ein oder mehrere Frames pausiert wird, da die App länger zum Rendern von Inhalten benötigt als die Dauer eines Frames auf dem System.

Richte deine Apps auf eine Aktualisierungsrate von 90 Hz aus. Die herkömmlichen Rendering-Raten betragen 60 Hz. Viele neuere Geräte arbeiten jedoch bei Nutzerinteraktionen wie dem Scrollen im 90‑Hz-Modus. Einige Geräte unterstützen sogar noch höhere Raten von bis zu 120 Hz.

Wenn Sie sehen möchten, welche Aktualisierungsrate ein Gerät zu einem bestimmten Zeitpunkt verwendet, aktivieren Sie im Abschnitt Debugging unter Entwickleroptionen > Aktualisierungsrate anzeigen ein Overlay.

Übergänge sind nicht flüssig

Das ist bei Interaktionen wie dem Wechsel zwischen Tabs oder dem Laden einer neuen Aktivität deutlich zu sehen. Diese Übergänge müssen flüssige Animationen sein und dürfen keine Verzögerungen oder visuelles Flimmern enthalten.

Ineffiziente Stromversorgung

Durch die Arbeit wird der Akku entladen und die Akkulaufzeit verkürzt.

Speicherzuweisungen, die durch das Erstellen neuer Objekte im Code entstehen, verursachen Arbeit im System. Nicht nur die Zuweisungen selbst erfordern Aufwand von der Android-Laufzeit (ART), sondern auch das spätere Freigeben dieser Objekte (Garbage Collection) erfordert Zeit und Aufwand.

Sowohl die Arbeitsspeicherzuweisung als auch die automatische Speicherbereinigung sind viel schneller und effizienter geworden, insbesondere für temporäre Objekte. Früher war es Best Practice, die Zuweisung von Objekten nach Möglichkeit zu vermeiden. Wir empfehlen Ihnen jedoch, das zu tun, was für Ihre App und Architektur am sinnvollsten ist. Einsparungen bei Zuweisungen auf Kosten von nicht wartungsfähigem Code sind angesichts der Möglichkeiten von ART nicht die beste Vorgehensweise.

Zuweisungen erfordern jedoch Aufwand. Wenn Sie also viele Objekte in Ihrer inneren Schleife zuweisen, kann dies zu Leistungsproblemen führen.

Probleme ermitteln

Um Leistungsprobleme zu beheben, müssen Sie die folgenden kritischen Nutzeraktionen identifizieren und untersuchen:

• Gängige Startvorgänge, z. B. über den Launcher und über Benachrichtigungen.
• Bildschirme, auf denen der Nutzer durch Daten scrollt.
• Übergänge zwischen Bildschirmen.
• Lang andauernde Abläufe wie die Navigation oder die Musikwiedergabe.

Sehen Sie sich für jeden dieser Abläufe an, was passiert, indem Sie die folgenden Debugging-Tools verwenden:

• Perfetto: Damit können Sie mit präzisen Zeitmessungsdaten sehen, was auf dem gesamten Gerät passiert.
• Speicher-Profiler: Damit können Sie sehen, welche Arbeitsspeicherzuweisungen im Heap erfolgen.
• Simpleperf: Zeigt ein Flame-Diagramm der Funktionsaufrufe, die in einem bestimmten Zeitraum die meiste CPU-Zeit beanspruchen. Wenn Sie in Systrace etwas identifizieren, das lange dauert, aber nicht wissen, warum, kann Simpleperf zusätzliche Informationen liefern.

Um diese Leistungsprobleme zu verstehen und zu beheben, ist es wichtig, einzelne Testläufe manuell zu debuggen. Sie können die vorherigen Schritte nicht durch die Analyse aggregierter Daten ersetzen. Um jedoch zu verstehen, was Nutzer tatsächlich sehen, und um Regressionen zu erkennen, ist es wichtig, die Erfassung von Messwerten in automatisierten Tests und im Feld einzurichten:

• Start-up-Abläufe
  • Messwerte für das Feld: Startzeit der Play Console
  • Labortests: Start mit Macrobenchmark testen
• Jank
  • Feldmesswerte
    • Play Console-Frame-Vitals: In der Play Console können Sie Messwerte nicht auf einen bestimmten Nutzerpfad eingrenzen. Es wird nur die gesamte Ruckeligkeit in der App erfasst.
    • Benutzerdefinierte Messung mit FrameMetricsAggregator: Mit FrameMetricsAggregator können Sie Verzögerungsmesswerte während eines bestimmten Workflows aufzeichnen.
  • Labortests
    • Scrollen mit Makrobenchmark:
    • Beim Makrobenchmark werden Frame-Timings mit dumpsys gfxinfo-Befehlen erfasst, die einen einzelnen User Journey umfassen. So können Sie die Schwankungen bei Rucklern während eines bestimmten Nutzerablaufs nachvollziehen. Die RenderTime-Messwerte, die angeben, wie lange das Rendern von Frames dauert, sind wichtiger als die Anzahl der fehlerhaften Frames, um Regressionen oder Verbesserungen zu erkennen.

Probleme mit der Bestätigung von App-Links

App-Links sind Deeplinks, die auf Ihrer Website-URL basieren und nachweislich zu Ihrer Website gehören. Die Überprüfung von App-Links kann aus folgenden Gründen fehlschlagen:

• Falsche Intent-Filterbereiche:Fügen Sie autoVerify nur Intent-Filtern für URLs hinzu, auf die Ihre App reagieren kann.
• Nicht bestätigte Protokollwechsel:Nicht bestätigte serverseitige und Subdomain-Weiterleitungen gelten als Sicherheitsrisiko und führen zu einem Fehler bei der Bestätigung. Sie führen dazu, dass alle autoVerify-Links fehlschlagen. Wenn Sie beispielsweise Links von HTTP zu HTTPS weiterleiten, z. B. von beispiel.de zu www.beispiel.de, ohne die HTTPS-Links zu bestätigen, kann die Bestätigung fehlschlagen. Achten Sie darauf, App-Links zu überprüfen, indem Sie Intent-Filter hinzufügen.
• Nicht überprüfbare Links:Wenn Sie nicht überprüfbare Links zu Testzwecken hinzufügen, kann es sein, dass das System App-Links für Ihre App nicht überprüft.
• Unzuverlässige Server:Achten Sie darauf, dass Ihre Server eine Verbindung zu Ihren Client-Apps herstellen können.

App für die Leistungsanalyse einrichten

Es ist wichtig, die Einrichtung richtig vorzunehmen, um genaue, wiederholbare und umsetzbare Benchmarks für eine App zu erhalten. Testen Sie auf einem System, das so nah wie möglich an der Produktion ist, und unterdrücken Sie Störquellen. In den folgenden Abschnitten werden einige APK- und systemspezifische Schritte beschrieben, die Sie zur Vorbereitung einer Testkonfiguration ausführen können. Einige davon sind anwendungsfallspezifisch.

Tracepoints

Apps können ihren Code mit benutzerdefinierten Trace-Ereignissen instrumentieren.

Während die Traces erfasst werden, entsteht ein geringer Overhead von etwa 5 μs pro Abschnitt. Verwenden Sie die Funktion daher nicht für jede Methode. Das Aufzeichnen größerer Arbeitsabschnitte (> 0,1 ms) kann wichtige Informationen zu Engpässen liefern.

Hinweise zu APKs

Debug-Varianten können bei der Fehlerbehebung und Symbolisierung von Stapelproben hilfreich sein, haben aber erhebliche Auswirkungen auf die Leistung. Auf Geräten mit Android 10 (API-Level 29) und höher kann profileable android:shell="true" im Manifest verwendet werden, um das Profiling in Release-Builds zu aktivieren.

Verwenden Sie Ihre Codekomprimierung-Konfiguration für die Produktion. Je nach den Ressourcen, die Ihre App verwendet, kann sich dies erheblich auf die Leistung auswirken. Bei einigen ProGuard-Konfigurationen werden Tracepoints entfernt. Entfernen Sie daher diese Regeln für die Konfiguration, mit der Sie Tests ausführen.

Compilation

Kompilieren Sie Ihre App auf dem Gerät in einen bekannten Zustand – in der Regel speed aus Gründen der Einfachheit oder speed-profile, um die Produktionsleistung genauer zu erreichen. Dazu muss die Anwendung jedoch aufgewärmt und Profile müssen gesichert oder die Baseline-Profile der App kompiliert werden.

Sowohl speed als auch speed-profile reduzieren die Menge an Code, der aus DEX interpretiert wird, und damit die Menge an JIT-Kompilierung (Just-in-Time) im Hintergrund, die zu erheblichen Störungen führen kann. Nur speed-profile reduziert die Auswirkungen des Laufzeit-Klassenladens aus DEX.

Mit dem folgenden Befehl wird die Anwendung im speed-Modus kompiliert:

adb shell cmd package compile -m speed -f com.example.packagename

Im Kompilierungsmodus speed werden die Methoden der App vollständig kompiliert. Im Modus speed-profile werden die Methoden und Klassen der App gemäß einem Profil der verwendeten Codepfade kompiliert, das während der App-Nutzung erfasst wird. Es kann schwierig sein, Profile konsistent und korrekt zu erfassen. Wenn Sie sich also für die Verwendung von Profilen entscheiden, sollten Sie prüfen, ob die erwarteten Daten erfasst werden. Die Profile befinden sich an folgendem Speicherort:

/data/misc/profiles/ref/[package-name]/primary.prof

Systemanforderungen

Für Messungen auf niedriger Ebene und mit hoher Genauigkeit müssen Sie Ihre Geräte kalibrieren. A/B-Vergleiche auf demselben Gerät und mit derselben Betriebssystemversion durchführen. Die Leistung kann selbst bei Geräten desselben Typs erheblich variieren.

Auf gerooteten Geräten sollten Sie für Microbenchmarks ein lockClocks-Script verwenden. Diese Skripts führen unter anderem folgende Aufgaben aus:

• CPUs mit einer festen Frequenz platzieren
• Deaktivieren Sie kleine Kerne und konfigurieren Sie die GPU.
• Deaktiviere die thermische Drosselung.

Wir empfehlen nicht, ein lockClocks-Skript für Tests zu verwenden, die sich auf die Nutzerfreundlichkeit konzentrieren, z. B. App-Start, DoU-Tests und Verzögerungstests. Es kann jedoch wichtig sein, das Rauschen bei Microbenchmark-Tests zu reduzieren.

Verwenden Sie nach Möglichkeit ein Testframework wie Macrobenchmark, um Rauschen bei Ihren Messungen zu reduzieren und Messungenauigkeiten zu vermeiden.

Langsamer App-Start: unnötige Trampolinaktivität

Eine Trampolin-Aktivität kann die Startzeit der App unnötig verlängern. Es ist daher wichtig, dass Sie wissen, ob Ihre App dies tut. Wie im folgenden Beispiel-Trace zu sehen ist, folgt auf ein activityStart unmittelbar ein weiteres activityStart, ohne dass durch die erste Aktivität Frames gezeichnet werden.

Abbildung 1: Ein Trace, der Trampolinaktivitäten zeigt.

Das kann sowohl bei einem Benachrichtigungs- als auch bei einem regulären App-Startpunkt passieren. Oft lässt sich das Problem durch Refactoring beheben. Wenn Sie diese Aktivität beispielsweise verwenden, um vor dem Ausführen einer anderen Aktivität eine Einrichtung vorzunehmen, sollten Sie diesen Code in eine wiederverwendbare Komponente oder Bibliothek auslagern.

Unnötige Zuweisungen, die häufige Garbage Collections auslösen

In einem Systrace sehen Sie möglicherweise häufiger als erwartet automatische Speicherbereinigungen (Garbage Collections, GCs).

Im folgenden Beispiel ist die automatische Speicherbereinigung alle 10 Sekunden während eines Vorgangs mit langer Ausführungszeit ein Hinweis darauf, dass die App möglicherweise unnötig, aber konsistent über die Zeit hinweg Speicher zuweist:

Abbildung 2. Ein Trace, der den Zeitraum zwischen GC-Ereignissen zeigt.

Möglicherweise stellen Sie im Speicher-Profiler auch fest, dass ein bestimmter Aufrufstack den Großteil der Zuweisungen verursacht. Sie müssen nicht alle Zuweisungen aggressiv eliminieren, da dies die Wartung des Codes erschweren kann. Beginnen Sie stattdessen mit der Bearbeitung von Hotspots bei Zuweisungen.

Falsch gerenderte Frames

Die Grafikpipeline ist relativ kompliziert und es kann schwierig sein, festzustellen, ob ein Nutzer letztendlich ein ausgelassenes Frame sieht. In einigen Fällen kann die Plattform einen Frame durch Pufferung „retten“. Sie können jedoch die meisten dieser Nuancen ignorieren, um problematische Frames aus der Sicht Ihrer App zu identifizieren.

Wenn Frames mit wenig Aufwand für die App gerendert werden, treten die Choreographer.doFrame()-Tracepoints auf einem Gerät mit 60 FPS alle 16,7 ms auf:

Abbildung 3: Ein Trace mit häufigen schnellen Frames.

Wenn Sie herauszoomen und durch den Trace navigieren, sehen Sie manchmal, dass Frames etwas länger als die zugewiesenen 16,7 ms benötigen. Diese Frames sind in Ordnung:

Abbildung 4: Ein Trace mit häufigen schnellen Frames und regelmäßigen Arbeitsspitzen.

Wenn diese regelmäßige Abfolge unterbrochen wird, handelt es sich um einen ruckelnden Frame, wie in Abbildung 5 und 6 dargestellt:

Abbildung 5: Ein Trace mit einem ruckelnden Frame.

Abbildung 6: Ein Trace mit mehr Frames, die ruckeln.

In einigen Fällen müssen Sie in einen Tracepoint hineinzoomen, um weitere Informationen dazu zu erhalten, welche UI-Komponenten von Compose aktualisiert werden oder, wie in Abbildung 6, was eine LazyColumn macht. Bei der Diagnose dieser UI-Engpässe wird durch standardmäßiges System-Tracing möglicherweise nicht angezeigt, welche Composables die Ursache sind. Verwenden Sie in diesen Fällen Jetpack Compose-Kompositions-Tracing. Damit werden genaue zusammensetzbare Funktionen direkt im Trace angezeigt, sodass Sie unerwartete Neukompositionen leichter erkennen können. Abbildung 5 und Abbildung 6 zeigen die Ergebnisse der Kompositionsanalyse.

Weitere Informationen zum Optimieren der Compose-Leistung finden Sie unter Jetpack Compose-Leistung. Weitere Informationen zum Identifizieren von Frames mit Rucklern und zum Beheben der Ursachen finden Sie unter Langsames Rendern.

Häufige Fehler bei Lazy Layouts

Wenn der gesamte zugrunde liegende Zustand eines Lazy Layout unnötig ungültig gemacht wird, kann dies zu übermäßigen Neukompositionen, langen Frame-Rendering-Zeiten und Verzögerungen führen. Um die Anzahl der zu aktualisierenden Listenelemente zu minimieren, verwenden Sie Elementschlüssel für Ihre Elemente und ändern Sie nur die spezifischen Zustandselemente, die sich ändern.

Unter Lazy-Layout-Schlüssel verwenden finden Sie Informationen dazu, wie Sie kostspielige Neuzuweisungen der gesamten Liste vermeiden können, die dazu führen, dass Inhalte aktualisiert und nicht vollständig ersetzt werden.

Eine falsche Implementierung von verschachtelten Scrolllisten kann zu Leistungseinbußen führen. Vermeiden Sie es, ein Lazy-Layout mit Scrollfunktion in einen anderen Container mit Scrollfunktion zu verschachteln, ohne explizite Einschränkungen festzulegen. Weitere Informationen finden Sie unter Verschachtelung von Komponenten vermeiden, die in dieselbe Richtung gescrollt werden können.

Wenn nicht genügend Daten oder nicht rechtzeitig vorab abgerufen werden, kann es zu einem Ruckeln kommen, wenn ein Nutzer das Ende einer scrollenden Liste erreicht und auf weitere Daten vom Server warten muss. Obwohl dies technisch gesehen kein Ruckeln ist, da keine Frame-Deadlines verpasst werden, können Sie die Nutzerfreundlichkeit erheblich verbessern, indem Sie das Timing und die Menge des Prefetching so anpassen, dass der Nutzer nicht auf Daten warten muss.

Anwendung debuggen

Im Folgenden finden Sie Methoden zum Debuggen der Leistung Ihrer App.

App-Start mit Systrace debuggen

Unter App-Startzeit finden Sie eine Übersicht über den App-Startprozess. Im folgenden Video erhalten Sie einen Überblick über das System-Tracing und die Verwendung des Android Studio-Profilers.

Sie können Startup-Typen in den folgenden Phasen unterscheiden:

• Kaltstart: Hier wird ein neuer Prozess ohne gespeicherten Status erstellt.
• Kaltstart: Die Aktivität wird entweder neu erstellt, während der Prozess wiederverwendet wird, oder der Prozess wird mit dem gespeicherten Status neu erstellt.
• Kaltstart: Die Aktivität wird neu gestartet und beginnt mit der Aufblähung.

Wir empfehlen, Systraces mit der System Tracing App auf dem Gerät aufzuzeichnen. Verwenden Sie für Android 10 und höher Perfetto. Verwenden Sie für Android 9 und niedriger Systrace. Wir empfehlen außerdem, Trace-Dateien mit dem webbasierten Perfetto Trace Viewer anzusehen. Weitere Informationen finden Sie unter System-Tracing – Übersicht.

Achten Sie unter anderem auf Folgendes:

• Monitor-Konflikte: Die Konkurrenz um monitorgeschützte Ressourcen kann zu erheblichen Verzögerungen beim Starten der App führen.

• Synchrone Binder-Transaktionen: Suchen Sie im kritischen Pfad Ihrer App nach unnötigen Transaktionen. Wenn eine erforderliche Transaktion teuer ist, sollten Sie mit dem zugehörigen Plattformteam zusammenarbeiten, um Verbesserungen vorzunehmen.

• Gleichzeitige Garbage Collection: Dies ist häufig und hat relativ geringe Auswirkungen. Wenn sie jedoch oft auftritt, sollten Sie sie mit dem Android Studio-Speicherprofiler untersuchen.

• E/A: Prüfen Sie, ob während des Starts E/A-Vorgänge ausgeführt werden, und suchen Sie nach langen Verzögerungen.

• Erhebliche Aktivität in anderen Threads: Diese können den UI-Thread beeinträchtigen. Achten Sie daher auf Hintergrundaufgaben beim Start.

Wir empfehlen, reportFullyDrawn aufzurufen, wenn der Start aus Sicht der App abgeschlossen ist, um die Berichterstellung für App-Startmesswerte zu verbessern. Weitere Informationen zur Verwendung von reportFullyDrawn finden Sie im Abschnitt Zeit bis zur vollständigen Anzeige. Sie können RFD-definierte Startzeiten über den Perfetto-Trace-Prozessor extrahieren. Außerdem wird ein für Nutzer sichtbares Trace-Ereignis ausgegeben.

System-Tracing auf dem Gerät verwenden

Mit der App „System Tracing“ auf Systemebene können Sie einen System-Trace auf einem Gerät aufzeichnen. Mit dieser App können Sie Traces vom Gerät aufzeichnen, ohne es anschließen oder mit adb verbinden zu müssen.

Speicher-Profiler von Android Studio verwenden

Mit dem Speicher-Profiler von Android Studio können Sie den Speicherdruck untersuchen, der durch Speicherlecks oder schlechte Nutzungsmuster verursacht wird. Sie bietet eine Live-Ansicht der Objektzuweisungen.

Mit dem Speicher-Profiler können Sie Speicherprobleme in Ihrer App beheben, indem Sie nachvollziehen, warum und wie oft automatische Speicherbereinigungen stattfinden.

So erstellen Sie ein Profil für den App-Arbeitsspeicher:

1. Arbeitsspeicherprobleme erkennen

   Nehmen Sie eine Speicherprofilerstellungssitzung des Nutzerprozesses auf, auf den Sie sich konzentrieren möchten. Achten Sie auf eine steigende Anzahl von Objekten, wie in Abbildung 7 dargestellt, die schließlich zu Garbage Collections führt, wie in Abbildung 8 dargestellt.

   Abbildung 7. Anzahl der Objekte wird erhöht.

   Abbildung 8. Automatische Speicherbereinigung.

   Nachdem Sie die User Journey ermittelt haben, die den Speicherdruck erhöht, analysieren Sie die Ursachen dafür.

2. Hotspots für Arbeitsspeicherdruck diagnostizieren

   Wählen Sie einen Bereich in der Zeitachse aus, um sowohl Zuweisungen als auch Shallow Size zu visualisieren (siehe Abbildung 9).

   Abbildung 9. Werte für Zuweisungen und Shallow Size.

   Es gibt mehrere Möglichkeiten, diese Daten zu sortieren. Im Folgenden finden Sie einige Beispiele dafür, wie Sie Probleme mit den einzelnen Ansichten analysieren können.

   • Nach Klasse sortieren: Nützlich, wenn Sie Klassen finden möchten, die Objekte generieren, die ansonsten aus einem Speicherpool zwischengespeichert oder wiederverwendet werden.

     Wenn eine App beispielsweise jede Sekunde 2.000 Objekte einer bestimmten Klasse erstellt, erhöht sich die Anzahl der Zuweisungen jede Sekunde um 2.000. Das sehen Sie, wenn Sie nach Klasse sortieren. Wenn Sie diese Objekte wiederverwenden möchten, um die Erstellung von Garbage zu vermeiden, implementieren Sie einen Memory Pool.

   • Nach Callstack sortieren: Nützlich, wenn Sie herausfinden möchten, wo sich ein Hotpath befindet, in dem Speicher zugewiesen wird, z. B. in einer Schleife oder in einer bestimmten Funktion, die viele Zuweisungen vornimmt.

   • Shallow Size (Flache Größe): Hier wird nur der Arbeitsspeicher des Objekts selbst erfasst. Sie ist nützlich, um einfache Klassen zu verfolgen, die hauptsächlich aus primitiven Werten bestehen.

   • Beibehaltene Größe: Zeigt den gesamten Speicherplatz an, der durch das Objekt selbst und alle Referenzen belegt wird, auf die nur durch das Objekt verwiesen wird. Sie ist nützlich, um den Arbeitsspeicherdruck aufgrund komplexer Objekte zu verfolgen. Um diesen Wert zu erhalten, erstellen Sie einen vollständigen Speicherauszug, wie in Abbildung 10 dargestellt. Retained Size (Behaltene Größe) wird als Spalte hinzugefügt (siehe Abbildung 11).

     Abbildung 10. Vollständiger Speicherauszug.

     

3. Auswirkungen einer Optimierung messen

   GCs sind deutlicher und die Auswirkungen von In-Memory-Optimierungen lassen sich leichter messen. Wenn durch eine Optimierung die Arbeitsspeicherlast verringert wird, werden weniger Garbage Collections ausgeführt.

   Um die Auswirkungen der Optimierung zu messen, können Sie in der Profiler-Zeitachse die Zeit zwischen den automatischen Speicherbereinigungen messen. Eine positive Auswirkung führt zu längeren Zeitabständen zwischen den Garbage Collections.

   Die Auswirkungen von Arbeitsspeicheroptimierungen sind:

   • Wenn die App nicht ständig unter Arbeitsspeicherdruck steht, werden wahrscheinlich weniger Beendigungen aufgrund von Arbeitsspeichermangel auftreten.
   • Weniger automatische Speicherbereinigungen verbessern die Verzögerungs-Messwerte, insbesondere im P99. Das liegt daran, dass die Garbage Collection zu CPU-Konflikten führt, die dazu führen können, dass Rendering-Aufgaben während der Garbage Collection aufgeschoben werden.