Diese Seite wurde von der Cloud Translation API übersetzt.

Arbeitsspeichernutzung der App mit dem Speicher-Profiler prüfen

Der Memory Profiler ist eine Komponente im Android Profiler, der können Sie Speicherlecks und -abwanderung finden, die ruckeln, bleibt hängen und stürzt sogar ab. Hier sehen Sie eine Grafik des Arbeitsspeichers Ihrer App in Echtzeit. verwenden und können Sie einen Heap-Dump erfassen, automatische Speicherbereinigungen erzwingen und Arbeitsspeicherzuweisungen.

So öffnen Sie den Memory Profiler:

Klicken Sie auf Ansicht > Tool-Fenster > Profiler: Sie können auch auf Profil klicken. .
Wählen Sie das Gerät und den App-Prozess aus, für den Sie auf dem Android-Gerät ein Profil erstellen möchten. Profiler-Symbolleiste. Wenn Sie ein Gerät über USB verbunden haben, es aber nicht angezeigt wird müssen Sie sicherstellen, USB-Debugging aktiviert ist.
Klicken Sie auf eine beliebige Stelle in der MEMORY-Zeitachse, um den Memory Profiler zu öffnen.

Alternativ können Sie den App-Arbeitsspeicher über die Befehlszeile mit dumpsys und auch Siehe GC-Ereignisse in Logcat.

Warum Sie ein Profil für den App-Arbeitsspeicher erstellen sollten

Android bietet eine verwaltete Arbeitsspeicherumgebung, wenn sie ermittelt, dass Ihre App einige Objekte nicht mehr verwendet, die automatische Speicherbereinigung gibt den ungenutzten Arbeitsspeicher wieder in den Heap frei. So findet Android wird nicht verwendeter Speicher ständig verbessert. Version verwenden, muss das System Ihren Code kurz anhalten. Meistens werden Pausen nicht wahrnehmbar sind. Wenn Ihre App Speicher jedoch schneller zuweist als das System kann, könnte sich Ihre App verzögern, während der Collector genügend Speicherplatz freigibt. um Ihren Zuweisungen zu entsprechen. Die Verzögerung könnte dazu führen, dass deine App die Anzeige überspringt und verlangsamen sich sichtbar.

Selbst wenn Ihre App nicht langsam ist, kann bei Speicherlecks während sie im Hintergrund läuft. Dieses Verhalten kann den Rest verlangsamen der Systemspeicherleistung durch Erzwingen einer unnötigen Speicherbereinigung Ereignisse. Schließlich ist das System gezwungen, Ihren App-Prozess zu beenden, um den zu speichern. Wenn der Nutzer dann zu Ihrer App zurückkehrt, muss sie vollständig neu gestartet werden.

Um diese Probleme zu vermeiden, sollten Sie den Memory Profiler verwenden. Folgendes:

Suchen Sie in der Zeitachse nach unerwünschten Speicherzuweisungsmustern, zu Leistungsproblemen führen.
Dump des Java-Heaps, um zu sehen, welche Objekte zu einem bestimmten Zeitpunkt Arbeitsspeicher verbrauchen . Mehrere Heap-Dumps über einen längeren Zeitraum können dabei helfen, Speicherlecks verursacht.
Speicherzuweisungen während normaler und extremer Nutzerinteraktion ermitteln, wo Ihr Code entweder zu viele Objekte in einem oder das Zuweisen von auslaufenden Objekten.

Informationen zu Programmierpraktiken, die den Arbeitsspeicher deiner App verringern können finden Sie unter App-Speicher verwalten.

Memory Profiler – Übersicht

Wenn Sie den Memory Profiler zum ersten Mal öffnen, sehen Sie eine detaillierte Zeitachse Ihrer Speichernutzung der App und Zugriff auf Tools, um die automatische Speicherbereinigung zu erzwingen, einen Heap zu erfassen Dump-Dateien und zeichnen Arbeitsspeicherzuweisungen auf.

Abbildung 1: Der Arbeitsspeicher-Profiler

Wie in Abbildung 1 dargestellt, enthält die Standardansicht für den Memory Profiler Folgendes:

Eine Schaltfläche zum Erzwingen eines Speicherbereinigungsereignisses.
Eine Schaltfläche zum Erfassen eines Heap-Dumps

Hinweis:Eine Schaltfläche zum Aufnehmen von Erinnerungen. Zuweisungen rechts neben der Heap-Dump-Schaltfläche nur dann angezeigt, die mit einem Gerät mit Android 7.1 (API-Level 25) oder niedriger verbunden sind.
Ein Drop-down-Menü zur Angabe, wie oft der Profiler Arbeitsspeicher erfasst Zuweisungen. Die Auswahl der passenden Option kann Ihnen helfen, App-Leistung während der Profilerstellung verbessern
Schaltflächen zum Vergrößern/Verkleinern der Zeitachse.
Eine Schaltfläche zum Vorspringen zu den Live-Speicherdaten.
Die Ereigniszeitachse, die den Aktivitätsstatus, Nutzereingabeereignisse und Bildschirmdrehungsereignisse.
Die Zeitachse für die Arbeitsspeichernutzung umfasst Folgendes: <ph type="x-smartling-placeholder">
- Ein gestapeltes Diagramm, das anzeigt, wie viel Speicher von jeder Speicherkategorie verwendet wird, wie durch die Y-Achse auf der linken Seite und die Farbtaste ganz oben.
- Eine gestrichelte Linie gibt die Anzahl der zugewiesenen Objekte an. der Y-Achse auf der rechten Seite.
- Ein Symbol für jedes automatische Speicherbereinigungsereignis.

Wenn Sie jedoch ein Gerät mit Android 7.1 oder niedriger verwenden, Profildaten sind standardmäßig sichtbar. Wenn Sie die Meldung "Erweitert" sehen, Profilerstellung für den ausgewählten Prozess nicht verfügbar", du musst Erweiterte Profilerstellung aktivieren um Folgendes zu sehen:

Zeitachse des Ereignisses
Anzahl der zugewiesenen Objekte
Ereignisse für die automatische Speicherbereinigung

Unter Android 8.0 und höher ist die erweiterte Profilerstellung immer für debug-fähige Funktionen aktiviert. Apps.

So wird der Arbeitsspeicher gezählt

Die Zahlen, die Sie oben im Memory Profiler (Abbildung 2) sehen, basieren auf alle Seiten im privaten Speicher, für die Ihre Anwendung einen Commit durchgeführt hat, Android-System. Diese Anzahl enthält keine Seiten, die für das System oder anderen Apps.

Abbildung 2: Die Legende zur Arbeitsspeicheranzahl oben des Memory Profiler

Die Kategorien für die Arbeitsspeicheranzahl sind:

Java: Arbeitsspeicher von Objekten, die aus Java- oder Kotlin-Code zugewiesen wurden.
Nativ: Arbeitsspeicher aus Objekten, die aus C- oder C++-Code zugewiesen sind.

Auch wenn Sie in Ihrer App kein C++ verwenden, sehen Sie möglicherweise nativen Arbeitsspeicher da das Android-Framework nativen Arbeitsspeicher nutzt, verschiedene Aufgaben in Ihrem Auftrag ausführen, z. B. die Verwaltung von Bild-Assets und anderen Grafiken, obwohl der von Ihnen geschriebene Code in Java oder Kotlin geschrieben wurde.
Grafik: Arbeitsspeicher für Grafikpufferwarteschlangen, um Pixel anzuzeigen einschließlich GL-Oberflächen, GL-Texturen usw. (Hinweis: ist der mit der CPU gemeinsam genutzte Arbeitsspeicher, kein dedizierter GPU-Arbeitsspeicher.)
Stack: Der von nativen und Java-Stacks in der Anwendung verwendete Arbeitsspeicher. Dieses bezieht sich normalerweise darauf, wie viele Threads Ihre App ausführt.
Code: Arbeitsspeicher, den Ihre App für Code und Ressourcen verwendet, z. B. DEX bytecode, optimierter oder kompilierter Dex-Code, .so-Bibliotheken und Schriftarten.
Sonstiges: Von Ihrer App verwendeter Arbeitsspeicher, der dem System nicht zugeordnet werden kann zu kategorisieren.
Zugewiesen: Die Anzahl der von Ihrer App zugewiesenen Java-/Kotlin-Objekte. Es werden keine in C oder C++ zugewiesenen Objekte gezählt.

Bei der Verbindung mit einem Gerät mit Android 7.1 und niedriger Die Zählung beginnt erst zu dem Zeitpunkt, zu dem der Memory Profiler mit Ihrem ausgeführte App. Objekte, die vor der Profilerstellung zugewiesen wurden, berücksichtigt. Unter Android 8.0 und höher ist jedoch eine Profilerstellungstool, das alle Zuweisungen verfolgt, sodass diese Zahl immer steht für die Gesamtzahl der ausstehenden Java-Objekte in Ihrer App auf Android 8.0 und höher.

Im Vergleich zu den Arbeitsspeicherzahlen des bisherigen Android Monitor-Tools Der Memory Profiler zeichnet Ihr Gedächtnis auf, sodass es die Speichernutzung ist jetzt höher. Der Memory Profiler überwacht einige zusätzliche Kategorien die die Gesamtzahl erhöhen. Wenn Ihnen aber nur der Java-Heap-Arbeitsspeicher wichtig ist, das „Java“ number sollte dem Wert aus dem vorherigen Tool ähneln. Obwohl die Java-Nummer wahrscheinlich nicht genau mit dem übereinstimmt, was Sie in Android gesehen haben Monitor: Die neue Zahl bezieht sich auf alle Seiten mit physischen Arbeitsspeichern, die dem Java-Heap Ihrer Anwendung zugewiesen, seit er von Zygote abgespalten wurde. Das heißt: eine genaue Darstellung des physischen Arbeitsspeichers Ihrer App tatsächlich nutzen.

Arbeitsspeicherzuweisungen ansehen

Die Arbeitsspeicherzuweisung zeigt Ihnen, wie jedes Java-Objekt und jede JNI-Referenz in Ihrem Arbeitsspeicher zugewiesen wurde. Der Memory Profiler zeigt Ihnen, zu Objektzuweisungen:

Welche Objekttypen zugewiesen wurden und wie viel Speicherplatz sie belegen.
Der Stacktrace jeder Zuweisung, einschließlich des Threads.
Wann die Zuweisung der Objekte aufgehoben wurde (nur bei Verwendung eines Geräts mit Android 8.0) oder höher).

Um Java- und Kotlin-Zuweisungen aufzuzeichnen, wählen Sie Java-/Kotlin-Zuweisungen aufzeichnen Wählen Sie dann Record (Aufnehmen) aus. Wenn auf dem Gerät Android 8 oder höher installiert ist, Die Memory Profiler-Benutzeroberfläche wechselt zu einem separaten Bildschirm mit der aktuellen Aufzeichnung. Du kannst mit der Minizeitachse über der Aufnahme interagieren (z. B. um den Auswahlbereich zu ändern). So schließen Sie die Aufzeichnung ab: Wählen Sie Beenden aus.

Unter Android 7.1 und niedriger verwendet der Arbeitsspeicher-Profiler die alte Zuweisung „Aufzeichnung“. Die Aufzeichnung wird dann auf der Zeitachse angezeigt, bis Sie auf Beenden:

Nach der Auswahl eines Bereichs auf der Zeitachse oder nach dem Beenden einer Aufnahme mit einem Gerät mit Android 7.1 oder niedriger), die Liste der zugewiesenen angezeigt, gruppiert nach Klassennamen und sortiert nach Heap-Anzahl hinzu.

So prüfen Sie den Zuweisungseintrag:

Durchsuchen Sie die Liste nach Objekten mit ungewöhnlich hohen Heap-Anzahlen und die möglicherweise durchgesickert sind. Wenn Sie bekannte Kurse leichter finden möchten, klicken Sie auf den Kursnamen. Spaltenüberschrift, um sie alphabetisch zu sortieren. Klicken Sie dann auf einen Kursnamen. Die Der Bereich Instanzansicht wird rechts angezeigt, in dem alle Instanzen wie in Abbildung 3 dargestellt.
- Alternativ können Sie Objekte schnell finden, indem Sie auf Filter klicken. , oder indem Sie Strg+F (Befehlstaste+F auf einem Mac) drücken und eine Klasse oder ein Paket eingeben, in das Suchfeld ein. Sie können auch nach Methodenname suchen, wenn Sie Anordnen nach Aufrufstack aus dem Drop-down-Menü. Wenn Sie die reguläre Klicken Sie auf das Kästchen neben Regex. Aktivieren Sie das Kontrollkästchen neben Groß-/Kleinschreibung beachten, wenn bei deiner Suchanfrage zwischen Groß- und Kleinschreibung unterschieden wird.
Klicken Sie im Bereich Instanzansicht auf eine Instanz. Tab Aufrufstack unten, wobei angezeigt wird, wo diese Instanz zugewiesen wurde und in welchem Thread.
Klicken Sie auf dem Tab Call Stack mit der rechten Maustaste auf eine Zeile und wählen Sie Zur Quelle springen, um den Code im Editor zu öffnen

Abbildung 3: Details zu jedem zugewiesenen Objekt werden in der Instanzansicht rechts

Über die beiden Menüs über der Liste der zugewiesenen Objekte können Sie auswählen, zu prüfen und zu organisieren.

Wählen Sie im Menü auf der linken Seite den Heap aus, der geprüft werden soll:

Standard-Heap: wenn vom System kein Heap angegeben wird
Image-Heap: Das System-Boot-Image mit Klassen, die beim Booten vorab geladen. Die Zuweisungen hier werden garantiert niemals verschoben oder weg.
zygote heap: Der Copy-on-Write-Heap, aus dem ein Anwendungsprozess verzweigt wird im Android-System.
App-Heap: Der primäre Heap, dem Ihre App Arbeitsspeicher zuweist.
JNI-Heap: Der Heap, der zeigt, wo Java Native Interface (JNI) ist Referenzen zugewiesen und freigegeben werden.

Wählen Sie im Menü rechts aus, wie die Zuweisungen angeordnet werden sollen:

Nach Kurs anordnen: Die Zuweisungen werden nach Kursnamen gruppiert. Dies ist die Standardeinstellung.
Nach Paket anordnen: Gruppiert alle Zuweisungen nach Paketname.
Nach Aufrufstack anordnen: Gruppiert alle Zuweisungen in die entsprechende aufrufen.

Anwendungsleistung während der Profilerstellung verbessern

Der Memory Profiler verwendet Stichproben, um die Anwendungsleistung während der Profilerstellung zu verbessern. die Arbeitsspeicherzuweisungen in regelmäßigen Abständen. Beim Testen auf Geräten, auf denen die API ausgeführt wird ab Level 26 können Sie dieses Verhalten ändern, indem Sie über das Drop-down-Menü Allocation Tracking (Zuordnungs-Tracking) aus. Folgende Optionen sind verfügbar: folgt:

Full: Erfasst alle Objektzuweisungen im Arbeitsspeicher. Dies ist die Standardeinstellung. in Android Studio 3.2 und früheren Versionen. Wenn Sie eine App haben, viele Objekte zuweist, kann es zu sichtbaren Verlangsamungen bei der App während der Profilerstellung.
Stichproben: Die Objektzuweisungen im Arbeitsspeicher werden in regelmäßigen Intervallen abgefragt. Dieses ist die Standardoption und wirkt sich weniger auf die App-Leistung aus, Profilerstellung. Apps, die viele Objekte innerhalb kurzer Zeit zuweisen, trotzdem sichtbare Verlangsamungen aufweisen.
Aus: Die Arbeitsspeicherzuweisung Ihrer App wird nicht mehr erfasst.

Globale JNI-Referenzen ansehen

Java Native Interface (JNI) ist ein Framework, das Java-Code und native um sich gegenseitig anzurufen.

JNI-Referenzen werden manuell durch den nativen Code verwaltet. Daher ist es möglich, Java-Objekte, die von nativem Code verwendet werden, um zu lange am Leben zu halten. Einige Objekte aktiviert Der Java-Heap kann nicht mehr erreichbar sein, wenn eine JNI-Referenz ohne explizit gelöscht wurde. Außerdem ist es möglich, die globale JNI Referenzlimit.

Zur Behebung solcher Probleme verwenden Sie die Ansicht JNI-Heap im Memory Profiler. Alle globalen JNI-Referenzen durchsuchen und nach Java-Typen und nativen Aufrufen filtern Stacks. Mit diesen Informationen können Sie herausfinden, wann und wo globale JNI-Referenzen erstellt und gelöscht werden.

Wählen Sie, während Ihre App ausgeführt wird, den Teil der Zeitachse aus, den Sie Suchen Sie im Drop-down-Menü über der Kursliste den Eintrag JNI-Heap und wählen Sie ihn aus. Sie können dann die Objekte im Heap wie gewohnt untersuchen und doppelklicken Objekte auf dem Tab Allocation Call Stack, um zu sehen, wo sich die JNI-Referenzen befinden die in Ihrem Code zugewiesen und freigegeben werden (siehe Abbildung 4).

Abbildung 4: Globale JNI-Referenzen ansehen

Um die Arbeitsspeicherzuweisungen für den JNI-Code Ihrer App zu prüfen, müssen Sie Ihre App bereitstellen auf einem Gerät mit Android 8.0 oder höher.

Weitere Informationen zu JNI finden Sie unter JNI-Tipps.

Nativer Arbeitsspeicher-Profiler

Der Memory Profiler von Android Studio enthält einen nativen Memory Profiler für Apps die auf physischen und virtuellen Geräten mit Android 10 und höher bereitgestellt werden.

Der Native Memory Profiler verfolgt Zuweisungen/Deals von Objekten in nativen für einen bestimmten Zeitraum und gibt folgende Informationen an:

Allocations:Anzahl der Objekte, die über malloc() oder new zugewiesen wurden für den ausgewählten Zeitraum.
Deallocations:Anzahl der Objekte, die über free() oder den delete im ausgewählten Zeitraum.
Allocations Size (Zuordnungsgröße): Die aggregierte Größe aller Zuweisungen in Byte während ausgewählten Zeitraum.
Deallocations-Größe:Die aggregierte Größe des gesamten freigegebenen Arbeitsspeichers in Byte für den ausgewählten Zeitraum.
Gesamtzahl:Der Wert in der Spalte Allocations abzüglich des Werts in Spalte Deallocations
Verbleibende Größe:Der Wert in der Spalte Allocations Größe abzüglich der in der Spalte Größe der Deallocations.

Um native Zuweisungen auf Geräten mit Android 10 und höher zu erfassen, Wählen Sie Native Zuweisungen aufzeichnen und dann Aufzeichnen aus. Die Aufzeichnung wird fortgesetzt, bis Sie auf Beenden klicken. , Danach wechselt die Memory Profiler-Benutzeroberfläche zu einem separaten Bildschirm. sodass die native Aufzeichnung angezeigt wird.

Unter Android 9 und niedriger ist die Option Native Zuweisungen aufzeichnen nicht verfügbar.

Standardmäßig verwendet der Native Memory Profiler eine Stichprobengröße von 32 Byte: Jede Sobald 32 Byte Arbeitsspeicher zugewiesen sind, wird ein Snapshot des Speichers erstellt. A führt eine kleinere Stichprobengröße zu häufigeren Snapshots, Daten über die Arbeitsspeichernutzung. Eine größere Stichprobe führt zu weniger genauen Ergebnissen. Dadurch werden jedoch weniger Systemressourcen verbraucht und die Leistung während der Aufnahme.

So ändern Sie die Stichprobengröße des Native Memory Profiler:

Wählen Sie Ausführen > Konfigurationen bearbeiten.
Wählen Sie im linken Bereich Ihr App-Modul aus.
Klicken Sie auf den Tab Profiling (Profilerstellung) und geben Sie die Stichprobengröße in das Feld ein. Intervall für die Stichprobenerhebung des nativen Arbeitsspeichers (Byte):
Erstellen Sie die Anwendung und führen Sie sie noch einmal aus.

Heap-Dump erfassen

Ein Heap-Dump zeigt, welche Objekte in Ihrer App zu dem Zeitpunkt, an dem Sie Heap-Dump zu erfassen. Besonders nach einer längeren Nutzersitzung kann ein Heap-Dump können Sie Speicherlecks identifizieren, indem Sie Objekte anzeigen, die sich noch im Arbeitsspeicher befinden, sollte eigentlich nicht mehr vorhanden sein.

Nachdem Sie einen Heap-Dump erfasst haben, können Sie Folgendes ansehen:

Welche Objekttypen Ihre App wie viele zugewiesen hat
Wie viel Speicher jedes Objekt verwendet.
Wo im Code Verweise auf die einzelnen Objekte enthalten sind.
Der Aufrufstack, an dem ein Objekt zugeordnet wurde. Aufrufstacks werden derzeit nur mit Android 7.1 und niedriger mit einem Heap-Dump verfügbar, wenn Sie den Heap-Dump während der Aufzeichnung von Zuweisungen.)

Klicken Sie auf Heap-Dump erfassen und wählen Sie Aufzeichnen aus, um einen Heap-Dump zu erfassen. Während des Dumps des Heaps kann der Java-Arbeitsspeicher vorübergehend erhöht werden. Das ist normal, da der Heap-Dump im selben Prozess wie Ihre Anwendung stattfindet und benötigt etwas Arbeitsspeicher, um die Daten zu sammeln.

Nachdem der Profiler den Heap-Dump erfasst hat, zeigt die Memory Profiler-Benutzeroberfläche zu einem separaten Bildschirm mit dem Heap-Dump über.

Abbildung 5: Heap-Dump wird angezeigt.

Wenn Sie genauer wissen möchten, wann der Dump erstellt wird, können Sie einen Heap-Dump am kritischen Punkt Ihres App-Codes erstellen, indem Sie dumpHprofData()

In der Liste der Kurse sehen Sie die folgenden Informationen:

Allocations: Anzahl der Zuweisungen im Heap.
Native Größe: Gesamtmenge des von diesem Objekttyp verwendeten nativen Arbeitsspeichers in Byte. Diese Spalte ist nur ab Android 7.0 sichtbar.

Hier sehen Sie Arbeitsspeicher für einige in Java zugewiesene Objekte, da Android verwendet für einige Framework-Klassen den nativen Arbeitsspeicher, z. B. Bitmap
Flache Größe: Gesamtmenge des von diesem Objekt verwendeten Java-Arbeitsspeichers Typ (in Byte).
Beibehaltene Größe: Gesamtgröße des Arbeitsspeichers, der aufgrund aller Instanzen beibehalten wird. dieser Klasse (in Byte).

Über die beiden Menüs über der Liste der zugewiesenen Objekte können Sie auswählen, Heap-Dumps zur Überprüfung und zum Organisieren der Daten.

Wählen Sie im Menü auf der linken Seite den Heap aus, der geprüft werden soll:

Standard-Heap: wenn vom System kein Heap angegeben wird
App-Heap: Der primäre Heap, dem Ihre App Arbeitsspeicher zuweist.
Image-Heap: Das System-Boot-Image mit Klassen, die beim Booten vorab geladen. Die Zuweisungen hier werden garantiert niemals verschoben oder weg.
zygote heap: Der Copy-on-Write-Heap, aus dem ein Anwendungsprozess verzweigt wird im Android-System.

Wählen Sie im Menü rechts aus, wie die Zuweisungen angeordnet werden sollen:

Nach Kurs anordnen: Die Zuweisungen werden nach Kursnamen gruppiert. Dies ist die Standardeinstellung.
Nach Paket anordnen: Gruppiert alle Zuweisungen nach Paketname.
Nach Aufrufstack anordnen: Gruppiert alle Zuweisungen in die entsprechende aufrufen. Diese Option funktioniert nur, wenn Sie den Heap-Dump während der Aufzeichnung erfassen Zuweisungen. Dennoch gibt es wahrscheinlich Objekte im Heap, die die vor der Aufzeichnung zugewiesen wurden, damit diese Zuweisungen zuerst angezeigt werden. einfach nach Klassennamen aufgeführt.

Die Liste wird standardmäßig nach der Spalte Behaltene Größe sortiert. So sortieren Sie Werte in einer anderen Spalte auf die Überschrift der Spalte.

Klicken Sie auf einen Klassennamen, um das Fenster Instanzansicht rechts zu öffnen. (siehe Abbildung 6). Jede aufgeführte Instanz enthält Folgendes:

Depth: Die kürzeste Anzahl an Sprüngen von einem beliebigen GC-Stamm zum ausgewählten Instanz.
Native Größe: Größe dieser Instanz im nativen Arbeitsspeicher. Diese Spalte ist nur ab Android 7.0 sichtbar.
Flache Größe: Größe dieser Instanz in Java-Arbeitsspeicher.
Beibehaltene Größe: Die Größe des Arbeitsspeichers, den diese Instanz dominiert (gemäß Dominatorbaum).

Hinweis: Standardmäßig zeigt der Heap-Dump nicht den Stacktrace für jede zugewiesene -Objekt enthält. Um den Stacktrace abzurufen, müssen Sie Speicherzuweisungen aufzeichnen, bevor Sie Heap-Dump erfassen Anschließend können Sie in der Instanzansicht eine Instanz auswählen. Außerdem sehen Sie den Tab Call Stack neben dem Tab Referenzen, wie in Abbildung 6. Es ist jedoch wahrscheinlich, dass einige Objekte zugewiesen wurden, bevor Sie mit der Aufzeichnung von Zuweisungen, sodass der Aufrufstack für diese Objekte nicht verfügbar ist. Instanzen, die einen Aufrufstack enthalten, werden mit einem „Stack“ gekennzeichnet auf der Symbol

(Leider müssen Sie für den Stacktrace eine Zuordnung vornehmen, Aufnahme wird der Stacktrace für Heap-Dumps auf Android derzeit nicht angezeigt 8.0)

Abbildung 6: Die zum Erfassen eines Heaps erforderliche Dauer Dump wird in der Zeitachse angegeben.

So prüfen Sie den Heap:

Durchsuchen Sie die Liste nach Objekten mit ungewöhnlich hohen Heap-Anzahlen und die möglicherweise durchgesickert sind. Wenn Sie bekannte Kurse leichter finden möchten, klicken Sie auf den Kursnamen. Spaltenüberschrift, um sie alphabetisch zu sortieren. Klicken Sie dann auf einen Kursnamen. Die Der Bereich Instanzansicht wird rechts angezeigt, in dem alle Instanzen wie in Abbildung 6 dargestellt.
- Alternativ können Sie Objekte schnell finden, indem Sie auf Filter klicken. , oder indem Sie Strg+F (Befehlstaste+F auf einem Mac) drücken und eine Klasse oder ein Paket eingeben, in das Suchfeld ein. Sie können auch nach Methodenname suchen, wenn Sie Anordnen nach Aufrufstack aus dem Drop-down-Menü. Wenn Sie die reguläre Klicken Sie auf das Kästchen neben Regex. Aktivieren Sie das Kontrollkästchen neben Groß-/Kleinschreibung beachten, wenn bei deiner Suchanfrage zwischen Groß- und Kleinschreibung unterschieden wird.
Klicken Sie im Bereich Instanzansicht auf eine Instanz. Die Referenzen erscheint unten mit allen Verweisen auf dieses Objekt.
Oder klicken Sie auf den Pfeil neben dem Instanznamen, um alle zugehörigen Felder anzusehen, und klicken Sie dann auf einen Feldnamen um alle zugehörigen Verweise anzuzeigen. Wenn Sie die Instanzdetails für ein Feld, klicken Sie mit der rechten Maustaste darauf und wählen Sie Zur Instanz aus.
Wenn du auf dem Tab Referenzen eine Referenz entdeckst, die möglicherweise Klicken Sie mit der rechten Maustaste darauf und wählen Sie Zur Instanz wechseln aus. Dadurch wird die aus dem Heap-Dump zu importieren, wodurch ihre eigenen Instanzdaten angezeigt werden.

Suchen Sie im Heap-Dump nach Speicherlecks, die durch eines der folgenden Ursachen verursacht werden:

Langlebige Verweise auf Activity, Context, View, Drawable und andere Objekte, die einen Verweis auf den Activity- oder Context-Container.
Nicht statische innere Klassen wie ein Runnable, die Eine Activity-Instanz.
Caches, die Objekte länger als nötig enthalten.

Heap-Dump als HPROF-Datei speichern

Nachdem Sie einen Heap-Dump erfasst haben, können die Daten nur im Memory Profiler aufgerufen werden während der Profiler ausgeführt wird. Wenn Sie die Profilerstellungssitzung beenden, geht der Wert für Heap-Dump. Wenn Sie ihn zur späteren Überprüfung speichern möchten, exportieren Sie den Heap-Dump in eine HPROF-Datei. In Android Studio 3.1 und niedriger wird die Funktion Aufnahme in Datei exportieren Die Schaltfläche befindet sich auf der linken Seite der Symbolleiste unterhalb der Zeitachse. in Unter Android Studio 3.2 und höher finden Sie die Schaltfläche Heap-Dump exportieren im Bereich Sitzungen rechts neben jedem Heap-Dump-Eintrag. Wählen Sie im Feld Exportieren als das Dialogfeld erscheint, speichern Sie die Datei mit der Dateiendung .hprof.

Um ein anderes HPROF-Analysetool wie Jhat müssen Sie die HPROF-Datei vom Android-Format in das Java SE HPROF-Format konvertieren. Dies können Sie mit dem hprof-conv-Tool tun, das in der android_sdk/platform-tools/-Verzeichnis. hprof-conv ausführen Befehl mit zwei Argumenten: der ursprünglichen HPROF-Datei und dem Speicherort für die konvertierte HPROF-Datei -Datei. Beispiel:

hprof-conv heap-original.hprof heap-converted.hprof

Heap-Dumpdatei importieren

Klicken Sie zum Importieren einer HPROF-Datei (.hprof) auf Neue Profilerstellungssitzung starten. in der Sitzungen, wählen Sie Aus Datei laden und dann die Datei aus der Datei aus. Browser.

Sie können auch eine HPROF-Datei importieren, indem Sie sie aus dem Dateibrowser in ein im Editorfenster öffnen.

Datenlecks in Memory Profiler

Beim Analysieren eines Heap-Dumps im Memory Profiler können Sie die Profilerstellung filtern Daten, die nach Ansicht von Android Studio auf Speicherlecks für Activity und Fragment Instanzen in Ihrer Anwendung.

Der Filter zeigt folgende Datentypen an:

Activity Instanzen, die gelöscht wurden, auf die aber noch verwiesen wird
Fragment Instanz ohne gültige FragmentManager, aber noch immer als Referenz zu verwenden.

In bestimmten Situationen, wie z. B. folgenden, kann der Filter "false" zurückgeben. Positive Werte:

Fragment wurde erstellt, aber noch nicht verwendet.
Ein Fragment wird im Cache gespeichert, aber nicht als Teil einer FragmentTransaction.

Damit Sie diese Funktion nutzen können, müssen Sie zuerst einen Heap-Dump erstellen. oder Heap-Dumpdatei importieren in Android Studio ein. Um die Fragmente und Aktivitäten anzuzeigen, die möglicherweise Speicherlecks verursacht haben, aktivieren Sie im Heap das Kästchen Aktivitäts-/Fragmentlecks Dump-Bereich des Memory Profiler. Dies ist in Abbildung 7 zu sehen.

Abbildung 7: Einen Heap-Dump nach Speicherlecks filtern

Techniken zum Erstellen eines Erinnerungsprofils

Bei der Verwendung des Memory Profiler sollten Sie Ihren App-Code belasten und versuchen, Speicherlecks verursacht. Eine Möglichkeit, Speicherlecks in Ihrer App zu verursachen, besteht darin, die App bevor Sie den Heap untersuchen. Lecks können bis zum oberen Rand des im Heap. Je kleiner das Leck ist, desto länger müssen die App ausführen, um sie zu sehen.

Sie können ein Speicherleck auch auf eine der folgenden Arten auslösen:

Drehen Sie das Gerät mehrmals vom Hoch- in das Querformat und wieder zurück, während Sie sich in unterschiedlichen Aktivitätsstatus. Das Drehen des Geräts kann häufig dazu führen, Activity, Context oder View-Objekt enthält, weil das System die Activity neu erstellt und wenn Ihr einen Verweis auf eines dieser Objekte an anderer Stelle enthält, kann das System das Objekt nicht automatisch entsorgen.
Sie können in verschiedenen Aktivitätszuständen zwischen Ihrer App und einer anderen App wechseln. Gehen Sie dazu Startbildschirm und kehre dann zur App zurück.

Tipp:Sie können die oben genannten Schritte auch mit dem monkeyrunner-Test Framework.