Anwendungsleistung messen – Übersicht

In diesem Dokument erfährst du, wie du wichtige Leistungsprobleme deiner App erkennen und beheben kannst.

Wichtige Leistungsprobleme

Es gibt viele Probleme, die zu einer schlechten Leistung einer App führen können. Im Folgenden sind jedoch einige häufige Probleme aufgeführt, nach denen Sie in Ihrer App suchen sollten:

Latenz beim Starten

Die Startlatenz ist die Zeit, die zwischen dem Tippen auf das Anwendungssymbol, die Benachrichtigung oder einen anderen Einstiegspunkt vergeht, bis die Daten des Nutzers auf dem Bildschirm angezeigt werden.

Folgende Ziele für Start-ups sollten in Ihren Apps angestrebt werden:

• Kaltstart in weniger als 500 ms. Ein Kaltstart tritt auf, wenn sich die zu startende App nicht im Systemspeicher befindet. Dies ist der erste Start der App seit dem Neustart oder weil der Anwendungsprozess vom Nutzer oder vom System beendet wurde.

  Ein Warmstart findet hingegen statt, wenn die Anwendung bereits im Hintergrund ausgeführt wird. Ein Kaltstart erfordert die meiste Arbeit im System, da alles aus dem Speicher geladen und die App initialisiert werden muss. Versuchen Sie, Kaltstarts mit einer Dauer von maximal 500 ms durchzuführen.

• Die P95- und P99-Latenzen liegen sehr nahe an der Medianlatenz. Wenn der Start einer App lange dauert, ist die Nutzererfahrung schlecht. Interprocess Communication (IPCs) und unnötige E/A-Vorgänge während des kritischen Pfads des Anwendungsstarts können zu Sperrkonflikten und zu Inkonsistenzen führen.

Scrollverzögerung

Mit dem Begriff Jank wird die visuelle Störung beschrieben, die auftritt, wenn das System Frames nicht rechtzeitig erstellen und bereitstellen kann, um sie mit der angeforderten Frequenz von 60 Hz oder höher auf den Bildschirm zu ziehen. Das Manöver ist beim Scrollen am deutlichsten, da es statt des gleitenden Animationsflusses zu Problemen kommt. Ein Stoß wird angezeigt, wenn die Bewegung für einen oder mehrere Frames im Weg anhält, da die App zum Rendern von Inhalten länger dauert als die Dauer eines Frames im System.

Apps müssen auf eine Aktualisierungsrate von 90 Hz ausgerichtet sein. Die herkömmlichen Renderingraten betragen 60 Hz. Viele neuere Geräte arbeiten jedoch bei Nutzerinteraktionen wie Scrollen im 90-Hz-Modus. Einige Geräte unterstützen sogar noch höhere Frequenzen von bis zu 120 Hz.

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

Nicht reibungslose Übergänge

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

Ineffizienzen bei der Stromversorgung

Durch Arbeit wird der Akku geschont, während unnötige Arbeiten die Akkulaufzeit verringern.

Speicherzuweisungen, die durch das Erstellen neuer Objekte im Code entstehen, können zu erheblichen Arbeitsaufwand im System führen. Das liegt daran, dass nicht nur die Zuweisungen selbst den Aufwand der Android Runtime (ART), sondern auch Zeit und Aufwand erfordern, um diese Objekte später freizugeben (automatische Speicherbereinigung). Sowohl die Zuweisung als auch die Erfassung sind viel schneller und effizienter, insbesondere bei temporären Objekten. Früher war es die Best Practice, möglichst keine Objekte zuzuweisen. Wir empfehlen jedoch, stattdessen das zu verwenden, was für Ihre Anwendung und Architektur am sinnvollsten ist. Das Einsparen von Zuweisungen, bei denen das Risiko von nicht verwaltbarem Code besteht, ist in Anbetracht dessen, was ART kann, nicht die Best Practice.

Dies ist jedoch mit Aufwand verbunden. Beachten Sie daher, dass es zu Leistungsproblemen führen kann, wenn Sie viele Objekte in Ihrer inneren Schleife zuweisen.

Probleme erkennen

Wir empfehlen den folgenden Workflow, um Leistungsprobleme zu identifizieren und zu beheben:

1. Identifizieren und prüfen Sie die folgenden kritischen Nutzerpfade:
   • Gängige Startabläufe, auch über den Launcher und Benachrichtigungen.
   • Bildschirme, auf denen der Nutzer durch Daten scrollt.
   • Übergänge zwischen Bildschirmen.
   • Lang andauernde Abläufe wie Navigation oder Musikwiedergabe
2. Prüfen Sie mit den folgenden Debugging-Tools, was in den vorherigen Abläufen passiert:
   • Perfetto: Hiermit können Sie anhand von genauen Zeitdaten sehen, was auf dem gesamten Gerät passiert.
   • Memory Profiler: Zeigt an, welche Arbeitsspeicherzuweisungen auf dem Heap erfolgen.
   • Simpleperf: Zeigt ein Flamegraph an, der zeigt, welche Funktionsaufrufe während eines bestimmten Zeitraums die meiste CPU-Leistung verbrauchen. Wenn Sie etwas feststellen, das in Systrace lange dauert, aber nicht den Grund dafür kennen, kann Simpleperf zusätzliche Informationen liefern.

Damit Sie diese Leistungsprobleme verstehen und beheben können, ist es wichtig, Fehler in einzelnen Testläufen manuell zu beheben. Sie können die vorherigen Schritte nicht durch die Analyse aggregierter Daten ersetzen. Um jedoch zu verstehen, was Nutzer tatsächlich sehen, und um zu erkennen, wann Regressionen auftreten können, ist es wichtig, die Messwerterfassung für automatisierte Tests und in der Praxis einzurichten:

• Startvorgänge
  • Feldmesswerte: Play Console-Startzeit
  • Labortests: Teststart mit MacroBenchmark
• Ruck
  • Feldmesswerte
    • Play Console-Frames: In der Play Console können Messwerte nicht auf einen bestimmten Nutzerpfad eingegrenzt werden. Sie meldet lediglich eine Verzögerung in der gesamten App.
    • Benutzerdefinierte Messung mit FrameMetricsAggregator: Mit FrameMetricsAggregator können Sie Verzögerungsmesswerte während eines bestimmten Workflows aufzeichnen.
  • Labortests
    • Scrollen mit MacroBenchmark:
    • MacroBenchmark erfasst das Frame-Timing mit dumpsys gfxinfo-Befehlen, die eine einzelne Nutzerreise einklammern. So können Sie Schwankungen der Verzögerung in einer bestimmten User Journey verstehen. Die RenderTime-Messwerte, die angeben, wie lange das Zeichnen von Frames dauert, sind für die Identifizierung von Regressionen oder Verbesserungen wichtiger als die Anzahl der instabilen Frames.

Probleme bei der Bestätigung von App-Links

App-Links sind Deeplinks, die auf Ihrer Website-URL basieren und nachweislich zu Ihrer Website gehören. Die folgenden Gründe können dazu führen, dass App Link-Überprüfungen fehlschlagen.

• Intent-Filterbereiche: Füge autoVerify nur für URLs, auf die deine App reagieren kann, zu Intent-Filtern hinzu.
• Nicht verifizierte Protokollwechsel: Nicht bestätigte serverseitige und Subdomain-Weiterleitungen gelten als Sicherheitsrisiken und bestehen bei der Überprüfung nicht. Sie führen dazu, dass alle autoVerify-Verknüpfungen fehlschlagen. Wenn Sie beispielsweise Links von HTTP zu HTTPS, z. B. von example.com zu www.example.com, weiterleiten, ohne die HTTPS-Links zu bestätigen, kann dies zu einem Fehler bei der Überprüfung führen. Überprüfe App-Links durch Hinzufügen von Intent-Filtern.
• Nicht überprüfbare Links: Wenn du nicht überprüfbare Links zu Testzwecken hinzufügst, kann es sein, dass das System App-Links für deine App nicht überprüft.
• Unzuverlässige Server: Stellen Sie sicher, dass Ihre Server eine Verbindung zu Ihren Client-Apps herstellen können.

App für Leistungsanalysen einrichten

Eine ordnungsgemäße Einrichtung ist wichtig, um genaue, wiederholbare und umsetzbare Benchmarks aus einer App zu erhalten. Testen Sie auf einem System, das sich so nah wie möglich an der Produktion befindet, und unterdrücken Sie Rauschquellen. In den folgenden Abschnitten findest du eine Reihe von APK- und systemspezifischen Schritten, die du zum Vorbereiten einer Testeinrichtung unternehmen kannst. Einige davon sind anwendungsfallspezifisch.

Trace-Punkte

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

Während Traces erfasst werden, verursacht das Tracing einen geringen Mehraufwand von etwa 5 μs pro Abschnitt. Legen Sie ihn also nicht für jede Methode um. Wenn Sie größere Arbeitsblöcke von mehr als 0,1 ms verfolgen, können Sie wichtige Erkenntnisse zu Engpässen gewinnen.

Überlegungen zum APK

Achtung :Messen Sie die Leistung bei einem Debug-Build nicht.

Debug-Varianten können bei der Fehlerbehebung und Symbolisierung von Stackbeispielen hilfreich sein, haben aber erhebliche Auswirkungen auf die Leistung. Geräte mit Android 10 (API-Level 29) und höher können profileable android:shell="true" in ihrem Manifest verwenden, um die Profilerstellung in Release-Builds zu ermöglichen.

Verwenden Sie Ihre produktionstaugliche Konfiguration zur Codereduzierung. Je nachdem, welche Ressourcen Ihre Anwendung verwendet, kann dies erhebliche Auswirkungen auf die Leistung haben. Bei einigen ProGuard-Konfigurationen werden Tracepunkte entfernt. Daher sollten Sie diese Regeln für die Konfiguration entfernen, mit der Sie Tests ausführen.

Compilation

Kompiliere deine App auf dem Gerät zu einem bekannten Zustand, in der Regel speed oder speed-profile. JIT-Aktivitäten (Just-in-Time) im Hintergrund können einen erheblichen Leistungsaufwand verursachen. Diesen Wert erreichen Sie häufig, wenn Sie das APK zwischen den Testläufen neu installieren. Dazu verwenden Sie den folgenden Befehl:

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

Die Anwendung wird im speed-Kompilierungsmodus vollständig kompiliert. Der Modus speed-profile kompiliert die Anwendung anhand eines Profils der verwendeten Codepfade, das während der Anwendungsnutzung erfasst wird. Es kann schwierig sein, Profile einheitlich und korrekt zu erfassen. Wenn Sie sich also für deren Verwendung entscheiden, sollten Sie prüfen, ob damit das erfasst wird, was Sie erwarten. Die Profile befinden sich an folgendem Ort:

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

Mit MacroBenchmark können Sie den Kompilierungsmodus direkt angeben.

Systemüberlegungen

Kalibrieren Sie Ihre Geräte für Low-Level- und High-Fidelity-Messungen. Führen Sie A/B-Vergleiche für dasselbe Gerät und dieselbe Betriebssystemversion durch. Es kann erhebliche Leistungsschwankungen geben, sogar beim selben Gerätetyp.

Auf gerooteten Geräten bietet es sich an, ein lockClocks-Script für MicroBenchmarks zu verwenden. Diese Scripts erledigen unter anderem Folgendes:

• Platzieren Sie CPUs mit einer festen Frequenz.
• Deaktivieren Sie kleine Kerne und konfigurieren Sie die GPU.
• Energiedrosselung deaktivieren.

Wir raten davon ab, ein lockClocks-Skript für Tests zur Nutzerfreundlichkeit wie App-Start-, DoU- und Verzögerungstests zu verwenden. Es kann jedoch für die Reduzierung von Rauschen in MicroBenchmark-Tests wichtig sein.

Verwenden Sie nach Möglichkeit ein Test-Framework wie MacroBenchmark, mit dem Sie Rauschen bei Ihren Messungen reduzieren und Messungenauigkeiten vermeiden können.

Langsamer App-Start: unnötige Trampolinaktivität

Eine Trampolinaktivität kann die Startzeit der App unnötig verlängern. Es ist wichtig, sich darüber im Klaren zu sein, ob Ihre App dies tut. Wie im folgenden Beispiel-Trace gezeigt, folgt auf ein activityStart direkt ein weiterer activityStart, ohne dass von der ersten Aktivität Frames gezeichnet werden.

Abbildung 1: Eine Spur, die eine Trampolinaktivität zeigt.

Dies kann sowohl in einem Einstiegspunkt für Benachrichtigungen als auch an einem normalen Anwendungsstartpunkt vorkommen. Häufig lässt sich das durch eine Refaktorierung beheben. Wenn Sie diese Aktivität beispielsweise für die Einrichtung verwenden, bevor eine andere Aktivität ausgeführt wird, nehmen Sie diesen Code in eine wiederverwendbare Komponente oder Bibliothek auf.

Hinweis :Zur Verbesserung der App-Leistung und Nutzerfreundlichkeit dürfen Apps, die auf Android 12 oder höher ausgerichtet sind, keine Aktivitäten von Diensten oder Übertragungsempfängern starten, die als Trampolin in eine Aktivität verwendet werden.

Unnötige Zuweisungen, die häufige GCs auslösen

Sie werden möglicherweise feststellen, dass die automatische Speicherbereinigung häufiger als erwartet in einem Systrace erfolgt.

Im folgenden Beispiel ist alle 10 Sekunden während eines lang andauernden Vorgangs ein Hinweis darauf, dass die Anwendung im Laufe der Zeit unnötige, aber konstante Zuweisungen vornehmen könnte:

Abbildung 2: Ein Trace, das Leerzeichen zwischen GC-Ereignissen zeigt.

Wenn Sie den Arbeitsspeicher-Profiler verwenden, stellen Sie möglicherweise fest, dass ein bestimmter Aufrufstack die überwiegende Mehrheit der Zuweisungen vornimmt. Sie müssen nicht alle Zuweisungen aggressiv eliminieren, da dies die Verwaltung des Codes erschweren kann. Beginnen Sie stattdessen mit Hotspots der Zuweisung.

Ruckelnde Rahmen

Die Grafikpipeline ist relativ kompliziert und es kann Nuancen bei der Entscheidung sein, ob ein Nutzer letztendlich einen ausgelassenen Frame sieht. In einigen Fällen kann die Plattform einen Frame mithilfe der Zwischenspeicherung „retten“. Sie können den Großteil dieser Nuance jedoch ignorieren, um problematische Frames aus der Perspektive Ihrer App zu identifizieren.

Wenn Frames mit wenig Arbeitsaufwand von der App gezeichnet werden, treten die Tracepoints Choreographer.doFrame() mit einer Frequenz von 16,7 ms auf einem Gerät mit 60 fps auf:

Abbildung 3: Ein Trace, das häufige schnelle Frames zeigt.

Wenn Sie herauszoomen und durch den Trace navigieren, sehen Sie manchmal, dass Frames etwas länger dauern.Das ist aber in Ordnung, da sie nicht mehr als die zugeteilte Zeit von 16,7 ms benötigen:

Abbildung 4: Ein Trace, der häufige schnelle Frames mit periodischen Arbeitslastspitzen zeigt.

Wenn du eine Unterbrechung dieser regelmäßigen Kadenz feststellst, handelt es sich um einen ruckeligen Frame, wie in Abbildung 5 gezeigt:

Abbildung 5: Eine Spur, die einen ruckeligen Frame zeigt.

Sie können üben, sie zu identifizieren.

Abbildung 6: Ein Trace, das mehr instabile Frames zeigt.

In einigen Fällen müssen Sie einen Tracepoint heranzoomen, um weitere Informationen darüber zu erhalten, welche Ansichten aufgebläht werden oder was RecyclerView tut. In anderen Fällen müssen Sie möglicherweise weitere Nachforschungen anstellen.

Weitere Informationen zum Erkennen von fehlerhaften Frames und zum Beheben ihrer Ursachen finden Sie unter Langsames Rendering.

Häufige RecyclerView-Fehler

Das Entwerten der gesamten Sicherungsdaten von RecyclerView kann unnötig lange Frame-Renderingzeiten und Verzögerungen verursachen. Um die Anzahl der zu aktualisierenden Ansichten zu minimieren, entwerten Sie stattdessen nur die Daten, die sich ändern.

Unter Dynamische Daten präsentieren erfahren Sie, wie Sie kostspielige notifyDatasetChanged()-Aufrufe vermeiden, die dazu führen, dass Inhalte aktualisiert werden, anstatt sie vollständig zu ersetzen.

Wenn nicht jedes verschachtelte RecyclerView-Element ordnungsgemäß unterstützt wird, kann dies dazu führen, dass das interne RecyclerView-Element jedes Mal vollständig neu erstellt wird. Für jede verschachtelte, innere RecyclerView muss RecycledViewPool festgelegt sein, damit Ansichten zwischen jedem inneren RecyclerView wiederverwendet werden können.

Wenn nicht genügend Daten vorab abgerufen werden oder die Daten nicht rechtzeitig vorab abgerufen werden, kann es verwirrend sein, das Ende einer Scrollliste zu erreichen, wenn ein Nutzer auf weitere Daten vom Server warten muss. Dies ist zwar technisch gesehen keine Verzögerung, da keine Frame-Fristen überschritten werden, können Sie die UX erheblich verbessern, indem Sie den Zeitpunkt und die Anzahl des Vorabrufs ändern, sodass der Nutzer nicht auf Daten warten muss.

App-Fehler beheben

Im Folgenden finden Sie verschiedene Methoden, um Fehler in der Leistung Ihrer App zu beheben. Das folgende Video bietet einen Überblick über die Systemverfolgung und die Verwendung des Profilers in Android Studio.

Fehler beim Starten der Anwendung mit Systrace beheben

Eine Übersicht über den Anwendungsstartprozess finden Sie unter App-Startzeit. Das folgende Video bietet eine Übersicht über das System-Tracing.

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

• Kaltstart: Hiermit wird ein neuer Prozess ohne gespeicherten Status erstellt.
• Warmer Start: Er erstellt entweder die Aktivität neu, während der Prozess wiederverwendet wird, oder erstellt den Prozess mit dem gespeicherten Status neu.
• Heißstart: Die Aktivität wird neu gestartet und beginnt bei Inflation.

Wir empfehlen, Systraces mit der System Tracing App auf dem Gerät zu erfassen. Verwenden Sie für Android 10 und höher Perfetto. Verwenden Sie für Android 9 und niedriger Systrace. Sie sollten sich Trace-Dateien auch mit dem webbasierten Perfetto Trace Viewer ansehen. Weitere Informationen finden Sie unter Übersicht über die Systemverfolgung.

Achten Sie unter anderem auf Folgendes:

• Konflikt im Blick behalten: Der Wettbewerb um Monitor-geschützte Ressourcen kann zu erheblichen Verzögerungen beim Starten von Anwendungen führen.

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

  Tipp: Mit am trace-ipc start können Sie weitere Informationen zu diesen Aufrufen abrufen. Deaktivieren Sie sie, bevor Sie das Benchmarking fortsetzen, da sie erheblichen Mehraufwand verursachen und ansonsten bis zum Neustart des Geräts bestehen bleiben.

• Gleichzeitige Speicherbereinigung: Dies ist eine häufige und relativ geringe Auswirkung. Wenn Sie dies jedoch häufig feststellen, sollten Sie dies mit dem Arbeitsspeicherprofiler von Android Studio in Betracht ziehen.

• E/A: Suchen nach E/A, die während des Starts durchgeführt wurden, und nach langen Wartezeiten.

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

Wir empfehlen, reportFullyDrawn aufzurufen, wenn der Start aus Sicht der App abgeschlossen ist. So lassen sich bessere Berichte zu App-Startmesswerten erstellen. Weitere Informationen zur Verwendung von reportFullyDrawn finden Sie im Abschnitt Zeit bis zur vollständigen Anzeige. Sie können von RFD definierte Startzeiten über den Perfetto-Trace-Prozessor extrahieren und ein für den Nutzer sichtbares Trace-Ereignis ausgegeben.

System-Tracing auf dem Gerät verwenden

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

Memory Profiler von Android Studio verwenden

Mit dem Memory Profiler von Android Studio können Sie die Speicherauslastung prüfen, die durch Speicherlecks oder ungültige Nutzungsmuster verursacht werden kann. Sie bietet eine Live-Ansicht der Objektzuweisungen.

Sie können Arbeitsspeicherprobleme in Ihrer Anwendung beheben, indem Sie den Informationen aus dem Memory Profiler folgen, um zu verfolgen, warum und wie oft GCs auftreten.

Führen Sie die folgenden Schritte aus, um ein Profil für den App-Arbeitsspeicher zu erstellen:

1. Speicherprobleme erkennen.

   Zeichnen Sie eine Sitzung mit einem Arbeitsspeicherprofil der User Journey auf, auf die Sie sich konzentrieren möchten. Achten Sie auf eine steigende Objektanzahl (siehe Abbildung 7), die schließlich zu GCs führt (siehe Abbildung 8).

   Abbildung 7: Objektanzahl wird erhöht.

   Abbildung 8: Automatische Speicherbereinigung.

   Nachdem Sie die User Journey identifiziert haben, die zu einer erhöhten Speicherauslastung führt, analysieren Sie die Ursachen der Speicherauslastung.

2. Diagnose von Hotspots bei Speicherauslastung.

   Wählen Sie einen Bereich auf der Zeitachse aus, um sowohl Allocations als auch Flache Größe zu visualisieren, wie in Abbildung 9 dargestellt.

   Abbildung 9: Werte für Allocations und Flache Größe.

   Es gibt mehrere Möglichkeiten, diese Daten zu sortieren. Die folgenden Beispiele zeigen, wie jede Ansicht bei der Analyse von Problemen helfen kann.

   • Anordnen nach Klasse: Nützlich, wenn Sie Klassen suchen möchten, die Objekte generieren, die ansonsten im Cache gespeichert oder aus einem Arbeitsspeicherpool wiederverwendet werden.

     Wenn Sie beispielsweise sehen, dass eine Anwendung pro Sekunde 2.000 Objekte der Klasse „Vertex“ erstellt, wird die Anzahl der Allocations pro Sekunde um 2.000 erhöht. Dies ist auch beim Sortieren nach Klasse zu sehen. Wenn Sie diese Objekte wiederverwenden möchten, um automatischen Speicher zu vermeiden, implementieren Sie einen Speicherpool.

   • Nach Aufrufstack anordnen: Dies ist hilfreich, wenn Sie herausfinden möchten, wo es einen Hot Path gibt, in dem Speicher zugewiesen wird, beispielsweise in einer Schleife oder in einer bestimmten Funktion, die viel Zuweisungsarbeit übernimmt.

   • Flache Größe: Erfasst nur den Arbeitsspeicher des Objekts selbst. Es ist nützlich, um einfache Klassen zu verfolgen, die ausschließlich aus primitiven Werten bestehen.

   • Beibehaltene Größe: Zeigt den Gesamtarbeitsspeicher aufgrund des Objekts und der Referenzen an, auf die ausschließlich das Objekt verweist. Es ist nützlich, um die Speicherauslastung aufgrund komplexer Objekte zu verfolgen. Um diesen Wert zu erhalten, nehmen Sie einen vollständigen Speicherdump, wie in Abbildung 10 gezeigt, und fügen Sie Beibehaltene Größe als Spalte hinzu, wie in Abbildung 11 gezeigt.

     Abbildung 10: Vollständiger Arbeitsspeicher-Dump.

     

     Abbildung 11. Spalte "Größe beibehalten".

3. Messen Sie die Auswirkungen einer Optimierung.

   GCs sind deutlicher erkennbar und die Auswirkungen von Speicheroptimierungen lassen sich leichter messen. Wenn durch eine Optimierung die Speicherauslastung reduziert wird, treten weniger GCs auf.

   Messen Sie auf der Profiler-Zeitachse die Zeit zwischen den Speicherbereinigungsvorgängen, um die Auswirkungen der Optimierung zu messen. Sie können sehen, dass es zwischen den GCs länger dauert.

   Die ultimativen Auswirkungen einer Verbesserung des Arbeitsspeichers sind folgende:

   • Das Herunterfahren von unzureichendem Arbeitsspeicher wird wahrscheinlich reduziert, wenn die Anwendung nicht ständig die Arbeitsspeicherauslastung beeinträchtigt.
   • Weniger GCs verbessern die Verzögerungsmesswerte, insbesondere beim P99. Dies liegt daran, dass GCs CPU-Konflikte verursachen, die dazu führen können, dass Renderingaufgaben während der Speicherbereinigung zurückgestellt werden.