Schreiben und Anzeigen von Protokollen mit Logcat

Das Logcat-Fenster in Android Studio zeigt Systemmeldungen an, z. B. wenn eine Müllsammlung auftritt, und Meldungen, die Sie Ihrer App mit der Klasse Log hinzugefügt haben. Es zeigt Nachrichten in Echtzeit an und führt einen Verlauf, damit Sie ältere Nachrichten anzeigen können.

Um nur die Informationen anzuzeigen, die von Interesse sind, können Sie Filter erstellen, die Menge der in den Nachrichten angezeigten Informationen ändern, Prioritätsstufen festlegen, nur von App-Code erzeugte Nachrichten anzeigen und das Protokoll durchsuchen. Standardmäßig zeigt logcat nur die Protokollausgabe an, die sich auf die zuletzt ausgeführte Anwendung bezieht.

Wenn eine App eine Ausnahme auslöst, zeigt logcat eine Meldung an, gefolgt vom zugehörigen Stack-Trace, der Links zu der Codezeile enthält.

Ab Android Studio 2.2 zeigt das Fenster Ausführen auch Protokollmeldungen für die aktuell ausgeführte App an. Beachten Sie, dass Sie die Anzeige der logcat-Ausgabe konfigurieren können, nicht aber das Run-Fenster.

Anzeigen der App-Protokolle

So zeigen Sie die Protokollmeldungen für eine App an:

1. Erstellen Sie Ihre App und führen Sie sie auf einem Gerät aus.
2. Klicke auf Ansicht > Werkzeugfenster > Logcat (oder klicke auf Logcat in der Werkzeugfensterleiste).

Das Logcat-Fenster zeigt die Protokollmeldungen für die ausgewählte Anwendung an, wie sie in den Dropdown-Listen oben im Fenster ausgewählt wurden (siehe Abbildung 1).

Abbildung 1. Logcat-Fenster

Standardmäßig zeigt logcat nur die Protokollmeldungen für Ihre auf dem Gerät ausgeführte Anwendung an. Um diese Voreinstellung zu ändern, lesen Sie bitte, wie Sie Logcat-Meldungen filtern können.

Die Logcat-Symbolleiste enthält folgende Schaltflächen:

1. Logcat löschen : Klicken Sie darauf, um das sichtbare Protokoll zu löschen.
2. Blättern Sie zum Ende : Klicken Sie darauf, um an das Ende des Protokolls zu springen und die letzten Protokollmeldungen zu sehen. Wenn Sie dann auf eine Zeile im Protokoll klicken, wird der Bildlauf an dieser Stelle angehalten.
3. Stacktrace nach oben und Stacktrace nach unten : Klicken Sie auf diese Schaltfläche, um in den Stacktraces im Protokoll nach oben und unten zu navigieren und die nachfolgenden Dateinamen auszuwählen (und die entsprechenden Zeilennummern im Editor anzuzeigen), die in den gedruckten Ausnahmen erscheinen. Dies ist das gleiche Verhalten, wie wenn Sie auf einen Dateinamen im Protokoll klicken.
4. Weiche Umbrüche verwenden : Klicken Sie auf diese Option, um den Zeilenumbruch zu aktivieren und das horizontale Scrollen zu verhindern (obwohl alle nicht umbrechbaren Zeichenfolgen weiterhin ein horizontales Scrollen erfordern).
5. Drucken : Klicken Sie darauf, um die Logcat-Meldungen zu drucken. Nachdem Sie Ihre Druckeinstellungen im angezeigten Dialogfeld ausgewählt haben, können Sie auch eine PDF-Datei speichern.
6. Neustart : Klicken Sie darauf, um das Protokoll zu löschen und logcat neu zu starten. Im Gegensatz zur Schaltfläche „Logcat löschen“ werden damit frühere Logmeldungen wiederhergestellt und angezeigt. Dies ist besonders nützlich, wenn Logcat nicht mehr reagiert und Sie Ihre Logmeldungen nicht verlieren möchten.
7. Logcat-Header : Klicken Sie hier, um das Dialogfeld Configure Logcat Header (Logcat-Kopfzeile konfigurieren) zu öffnen, in dem Sie das Aussehen jeder Logcat-Meldung anpassen können, z. B. ob Datum und Uhrzeit angezeigt werden sollen.
8. Screen capture : Klicken Sie auf diese Schaltfläche, um ein Bildschirmfoto zu erstellen.
9. Bildschirmaufzeichnung : Klicken Sie hier, um ein Video des Geräts aufzunehmen (maximal 3 Minuten).

Protokollmeldungen schreiben

Mit der Klasse Log können Sie Protokollmeldungen erstellen, die in logcat erscheinen. Im Allgemeinen sollten Sie die folgenden Log-Methoden verwenden, die in der Reihenfolge von der höchsten bis zur niedrigsten Priorität (oder von der geringsten bis zur ausführlichsten) aufgeführt sind:

• Log.e(String, String) (Fehler)
• Log.w(String, String) (Warnung)
• Log.i(String, String) (Information)
• Log.d(String, String) (Debug)
• Log.v(String, String) (Ausführlich)

Eine vollständige Liste der Optionen finden Sie in der Klassenbeschreibung Log.

Sie sollten niemals ausführliche Protokolle in Ihre Anwendung kompilieren, außer während der Entwicklung. Debug-Protokolle werden einkompiliert, aber zur Laufzeit entfernt, während Fehler-, Warn- und Info-Protokolle immer beibehalten werden.

Für jede Protokollmethode sollte der erste Parameter ein eindeutiges Tag sein und der zweite Parameter ist die Nachricht. Das Tag einer Systemprotokollmeldung ist eine kurze Zeichenkette, die die Systemkomponente angibt, von der die Meldung stammt (zum Beispiel ActivityManager). Ihr Tag kann eine beliebige Zeichenkette sein, die Sie für hilfreich halten, z. B. der Name der aktuellen Klasse.

Eine gute Konvention ist es, eine TAG-Konstante in Ihrer Klasse zu deklarieren, die im ersten Parameter verwendet wird. Sie könnten zum Beispiel eine Informationslogmeldung wie folgt erstellen:

private const val TAG = "MyActivity"...Log.i(TAG, "MyClass.getView() — get item number $position")

private static final String TAG = "MyActivity";...Log.i(TAG, "MyClass.getView() — get item number " + position);

Hinweis: Tag-Namen mit mehr als 23 Zeichen werden in der Logcat-Ausgabe abgeschnitten.

Logcat-Meldungsformat

Jede Android-Logmeldung hat ein Tag und eine Priorität, die mit ihr verbunden sind. Das Tag einer Systemprotokollmeldung ist eine kurze Zeichenkette, die die Systemkomponente angibt, von der die Meldung stammt (zum Beispiel ActivityManager). Ein benutzerdefiniertes Tag kann eine beliebige Zeichenkette sein, die Sie für hilfreich halten, wie z. B. der Name der aktuellen Klasse (empfohlenes Tag). Sie definieren es in einem Log Methodenaufruf, zum Beispiel:

Log.d(tag, message)

Log.d(tag, message);

Die Priorität ist einer der folgenden Werte:

• V: Verbose (niedrigste Priorität)
• D: Debug
• I: Info
• W: Warning (Warnung)
• E: Error (Fehler)
• A: Assert (Bestätigung)

Das Format der Protokollnachricht ist:

date time PID-TID/package priority/tag: message

Die folgende Protokollnachricht hat beispielsweise eine Priorität von V und ein Tag von AuthZen:

12-10 13:02:50.071 1901-4229/com.google.android.gms V/AuthZen: Handling delegate intent.

PID steht für process identifier (Prozesskennung) und TID für thread identifier (Threadkennung); sie können gleich sein, wenn es nur einen Thread gibt.

Protokollebene einstellen

Sie können steuern, wie viele Meldungen in logcat erscheinen, indem Sie die Protokollebene einstellen. Sie können alle Meldungen anzeigen lassen oder nur die Meldungen, die auf die schwerwiegendsten Zustände hinweisen.

Denken Sie daran, dass logcat unabhängig von der Einstellung des Loglevels weiterhin alle Meldungen sammelt. Die Einstellung bestimmt nur, was logcat anzeigt.

Wählen Sie im Menü Loglevel einen der folgenden Werte aus:

• Ausführlich: Alle Protokollmeldungen anzeigen (Standardeinstellung).
• Debug: Zeigt Debug-Protokollmeldungen an, die nur während der Entwicklung nützlich sind, sowie die in dieser Liste niedrigeren Meldungsebenen.
• Info: Zeigt die erwarteten Protokollmeldungen für den normalen Gebrauch sowie die Meldungsebenen unterhalb dieser Liste an.
• Warnung: Zeigt mögliche Probleme an, die noch keine Fehler sind, sowie die Meldungsebenen unterhalb dieser Liste.
• Fehler: Zeigt Probleme an, die zu Fehlern geführt haben, sowie die Meldungsebene unterhalb dieser Liste.
• Assert: Zeigt Probleme an, von denen der Entwickler erwartet, dass sie nie auftreten.

Suchen von Logcat-Meldungen

Um die aktuell in Logcat angezeigten Meldungen zu durchsuchen:

1. Optional wählen Sie Regex, wenn Sie ein Suchmuster mit regulärem Ausdruck verwenden möchten.
2. Geben Sie eine Zeichenfolge in das Suchfeld ein.

   Die Anzeige der Logcat-Ausgabe ändert sich entsprechend.

3. Drücken Sie die Eingabetaste, um die Suchzeichenfolge während dieser Sitzung im Menü zu speichern.
4. Um eine Suche zu wiederholen, wählen Sie sie aus dem Suchmenü aus. Aktivieren oder deaktivieren Sie Regex nach Bedarf (die Einstellung wird nicht gespeichert).

Logcat-Meldungen filtern

Eine Möglichkeit, die Protokollausgabe auf ein überschaubares Maß zu reduzieren, besteht darin, sie mit einem Filter einzuschränken.

Hinweis: Der Filter gilt für die gesamte Logcat-Historie, nicht nur für die derzeit in logcat angezeigten Meldungen. Vergewissern Sie sich, dass Ihre anderen Anzeigeoptionen entsprechend eingestellt sind, damit Sie die Filterausgabe sehen können, die Sie untersuchen möchten.

So definieren Sie einen Filter und wenden ihn an:

1. Wählen Sie im Filtermenü eine Filteroption:
   • Nur ausgewählte Anwendung anzeigen: Zeigt nur die Meldungen an, die vom Anwendungscode erzeugt werden (Standardeinstellung). Logcat filtert die Protokollmeldungen anhand der PID der aktiven Anwendung.
   • Keine Filter: Keine Filter anwenden. Logcat zeigt alle Protokollmeldungen des Geräts an, unabhängig davon, welchen Prozess Sie ausgewählt haben.
   • Filterkonfiguration bearbeiten: Erstellen oder ändern Sie einen benutzerdefinierten Filter. Sie könnten zum Beispiel einen Filter erstellen, um Protokollmeldungen von zwei Anwendungen gleichzeitig anzuzeigen.

   Nachdem Sie Filter definiert haben, können Sie diese auch im Menü auswählen. Um sie aus dem Menü zu entfernen, löschen Sie sie.

2. Wenn Sie Filterkonfiguration bearbeiten gewählt haben, können Sie einen Filter erstellen oder ändern:
   1. Spezifizieren Sie die Filterparameter im Dialogfeld „Neuen Logcat-Filter erstellen“:
      • Filtername: Geben Sie den Namen eines Filters ein, den Sie definieren möchten, oder wählen Sie ihn im linken Fensterbereich aus, um einen vorhandenen Filter zu ändern. Der Name darf nur Kleinbuchstaben, Unterstriche und Ziffern enthalten.
      • Protokoll-Tag: Geben Sie optional ein Tag an. Weitere Informationen finden Sie unter logcat-Meldungsformat.
      • Protokollmeldung: Geben Sie optional den Text der Protokollmeldung an. Weitere Informationen finden Sie unter logcat Meldungsformat.
      • Paketname: Optional kann ein Paketname angegeben werden. Weitere Informationen finden Sie unter logcat Meldungsformat.
      • PID: Optional kann eine Prozess-ID angegeben werden. Weitere Informationen finden Sie unter logcat Meldungsformat.
      • Log Level: Wählen Sie optional eine Protokollstufe aus. Weitere Informationen finden Sie unter Festlegen der Protokollierungsstufe.
      • Regex: Wählen Sie diese Option, um die Syntax eines regulären Ausdrucks für diesen Parameter zu verwenden.
   2. Klicken Sie auf +, um die Filterdefinition zum linken Fensterbereich hinzuzufügen.

      Um einen Filter zu entfernen, wählen Sie ihn im linken Bereich aus und klicken Sie auf -.

   3. Wenn Sie fertig sind, klicken Sie auf OK.

Wenn Sie glauben, dass Sie die gewünschten Protokollmeldungen nicht sehen, versuchen Sie, die OptionKeine Filter auszuwählen und nach bestimmten Protokollmeldungen zu suchen.

Lesen von Garbage-Collection-Meldungen

Gelegentlich werden sie in logcat gedruckt, wenn ein Garbage-Collection-Ereignis auftritt.

Für mehr Details über den Speicher Ihrer Anwendung, verwenden Sie denMemory Profiler.

Dalvik log messages

In Dalvik (aber nicht ART) gibt jede GC die folgenden Informationen in logcat aus:

D/dalvikvm(PID): GC_Reason Amount_freed, Heap_stats, External_memory_stats, Pause_time

Beispiel:

D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms

GC Reason Was hat die GC ausgelöst und um welche Art von Sammlung handelt es sich. Gründe, die erscheinen können, sind unter anderem:GC_CONCURRENTEine gleichzeitige GC, die Speicher freigibt, während sich der Heap zu füllen beginnt.GC_FOR_MALLOCEine GC wurde verursacht, weil Ihre Anwendung versucht hat, Speicher zuzuweisen, als der Heap bereits voll war, so dass das System Ihre Anwendung anhalten und Speicher zurückfordern musste.GC_HPROF_DUMP_HEAPEine GC, die auftritt, wenn Sie die Erstellung einer HPROF-Datei anfordern, um Ihren Heap zu analysieren.GC_EXPLICITEine explizite GC, z. B. wenn Siegc()aufrufen (was Sie vermeiden sollten und stattdessen darauf vertrauen, dass die GC bei Bedarf ausgeführt wird).GC_EXTERNAL_ALLOCDies geschieht nur auf API-Level 10 und niedriger (neuere Versionen allokieren alles im Dalvikheap). Eine GC für extern zugewiesenen Speicher (wie z.B. die Pixeldaten im Arbeitsspeicher oder NIO-Bytepuffer). Amount freed Die Menge an Speicher, die von dieser GC zurückgewonnen wurde. Heap-Statistik Prozentualer Anteil des freien Heaps und (Anzahl der aktiven Objekte)/(Gesamtgröße des Heaps). Externe Speicherstatistik Extern zugewiesener Speicher auf API-Ebene 10 und niedriger (Menge des zugewiesenen Speichers) / (Grenze, bei der die Erfassung erfolgt). Pausenzeit Größere Heaps haben größere Pausenzeiten. Gleichzeitige Pausenzeiten zeigen zwei Pausen an: eine zu Beginn der Sammlung und eine gegen Ende.

Während sich diese Protokollmeldungen ansammeln, achten Sie auf einen Anstieg der Heap-Statistiken (der3571K/9991K Wert im obigen Beispiel). Wenn dieser Wert weiter ansteigt, haben Sie möglicherweise ein Speicherleck.

ART log messages

Im Gegensatz zu Dalvik, protokolliert ART keine Meldungen für GCs, die nicht explizit angefordert wurden. GCs werden nur ausgedruckt, wenn sie als langsam eingestuft werden. Genauer gesagt, wenn die GC-Pause mehr als 5ms oder die GC-Dauer mehr als 100ms beträgt. Wenn sich die Anwendung nicht in einem Zustand befindet, in dem eine Pause wahrnehmbar ist (z. B. wenn sich die Anwendung im Hintergrund befindet, wo der Benutzer eine GC-Pause nicht wahrnehmen kann), dann wird keine ihrer GCs als langsam angesehen. Explizite GCs werden immer protokolliert.

ART enthält die folgenden Informationen in seinen Garbage Collection Log-Meldungen:

I/art: GC_Reason GC_Name Objects_freed(Size_freed) AllocSpace Objects, Large_objects_freed(Large_object_size_freed) Heap_stats LOS objects, Pause_time(s)

Beispiel:

I/art : Explicit concurrent mark sweep GC freed 104710(7MB) AllocSpace objects, 21(416KB) LOS objects, 33% free, 25MB/38MB, paused 1.230ms total 67.216ms

GC Reason Was hat die GC ausgelöst und um welche Art von Collection handelt es sich. Gründe, die erscheinen können, sind unter anderem:ConcurrentEine gleichzeitige GC, die die Anwendungsthreads nicht unterbricht. Diese GC läuft in einem Hintergrund-Thread und verhindert keine Zuweisungen.AllocDie GC wurde ausgelöst, weil Ihre Anwendung versucht hat, Speicher zuzuweisen, als der Heap bereits voll war. In diesem Fall erfolgte die Garbage Collection im allokierenden Thread.ExplicitDie Garbage Collection wurde explizit von einer Anwendung angefordert, zum Beispiel durch den Aufruf vongc()odergc(). Wie bei Dalvik ist es auch bei ART die beste Praxis, der GC zu vertrauen und explizite GCs nach Möglichkeit zu vermeiden.Von expliziten GCs wird abgeraten, da sie den allokierenden Thread blockieren und unnötig CPU-Zyklen verschwenden. Explizite GCs können auch Jank (Stottern, Ruckeln oder Anhalten in der Anwendung) verursachen, wenn sie dazu führen, dass andere Threads vorzeitig beendet werden.NativeAllocDie Sammlung wurde durch nativen Speicherdruck von nativen Zuweisungen wie Bitmaps oder RenderScript-Zuweisungsobjekten verursacht.CollectorTransitionDie Auflistung wurde durch einen Heap-Übergang verursacht; dies wird durch eine Änderung der GC-Strategie zur Laufzeit verursacht (z. B. wenn die App zwischen pausierbaren Zuständen wechselt). Collector-Übergänge bestehen aus dem Kopieren aller Objekte von einem Free-List-Backed-Space zu einem Bump-Pointer-Space (oder umgekehrt).

Dies tritt nur auf Geräten mit geringem RAM vor Android 8.0, wenn eine App den Prozesszustand von einem pauseperceptible state (z.B. wenn die App im Vordergrund ist, wo der Benutzer eine GC-Pause wahrnehmen kann) zu einem non pause perceptible state (oder umgekehrt) ändert.

HomogeneousSpaceCompactHomogeneous space compaction ist free-list space to free-list space compaction, die normalerweise auftritt, wenn eine App in einen pause imperceptible process state verschoben wird. Die Hauptgründe dafür sind die Reduzierung der RAM-Nutzung und die Defragmentierung des Heaps.DisableMovingGcDies ist kein echter GC-Grund, sondern ein Hinweis darauf, dass die Sammlung aufgrund der Verwendung vonGetPrimitiveArrayCritical. blockiert wurde, während gleichzeitig eine Heap-Kompaktierung stattfindet. Im Allgemeinen wird von der Verwendung vonGetPrimitiveArrayCritical aufgrund der Einschränkungen beim Verschieben von Collectors dringend abgeraten.HeapTrimDies ist kein GC-Grund, sondern ein Hinweis darauf, dass die Sammlung blockiert wurde, bis ein Heap-Trim abgeschlossen ist. GC Name ART hat verschiedene GCs, die ausgeführt werden können.Concurrent mark sweep (CMS)Ein ganzer Heap-Collector, der alle Bereiche außer dem Bildbereich freigibt.Concurrent partial mark sweepEin meist ganzer Heap-Collector, der alle Spaces außer den Image- und Zygoten-Spaces sammelt.Concurrent sticky mark sweepEin Generationskollektor, der nur Objekte freigeben kann, die seit der letzten GC zugewiesen wurden. Diese Müllsammlung wird häufiger als ein vollständiger oder teilweiser Mark-Sweep ausgeführt, da sie schneller ist und weniger Pausen hat.Marksweep + semispaceEine nicht-parallele, kopierende GC, die für Heap-Übergänge sowie für homogene Spacecompaction (zum Defragement des Heaps) verwendet wird. Objects freed Die Anzahl der Objekte, die von dieser GC aus dem Nicht-Großobjektbereich zurückgewonnen wurden. Size freed Die Anzahl der Bytes, die von dieser GC aus dem nicht-großen Objektraum zurückgewonnen wurden. Large objects freed Die Anzahl der Objekte im Large Object Space, die aus dieser Garbagecollection zurückgewonnen wurden. Large object size freed Die Anzahl der Bytes im Large Object Space, die aus dieser Garbagecollection zurückgewonnen wurden. Heap-Statistiken Prozentualer Anteil der freien und (Anzahl der aktiven Objekte)/(gesamte Heap-Größe). Pausenzeiten Die Pausenzeiten sind in der Regel proportional zur Anzahl der Objektreferenzen, die während der Ausführung der GC geändert wurden. Derzeit gibt es bei den ART CMS GCs nur eine Pause gegen Ende der GC, bei den Moving GCs gibt es eine lange Pause, die den Großteil der GC-Dauer ausmacht.

Wenn Sie eine große Anzahl von GCs in logcat sehen, achten Sie auf einen Anstieg der Heap-Statistiken (der25MB/38MB Wert im obigen Beispiel). Wenn dieser Wert weiter ansteigt und nicht kleiner zu werden scheint, könnte es sich um ein Speicherleck handeln. Oder wenn Sie GC sehen, die aus dem Grund „Alloc“ sind, dann arbeiten Sie bereits nahe an Ihrer Heap-Kapazität und können in naher Zukunft mitOOM -Ausnahmen rechnen.