Het Logcat-venster in Android Studio toont systeemberichten, zoals wanneer een garbagecollection optreedt, en berichten die u hebt toegevoegd aan uw app met de Log klasse. Het toont berichten in realtime en houdt een geschiedenis bij, zodat u oudere berichten kunt bekijken.
Om alleen de informatie van belang weer te geven, kunt u filters maken, wijzigen hoeveel informatie wordt weergegeven in berichten, prioriteitsniveaus instellen, alleen berichten weergeven die door app code zijn geproduceerd, en het logboek doorzoeken. Standaard toont logcat alleen de log output van de laatst gedraaide app.
Wanneer een app een uitzondering gooit, toont logcat een bericht gevolgd door de bijbehorende stack trace met links naar de regel code.
Vanaf Android Studio 2.2, toont het venster Uitvoeren ook logboekberichten voor de huidige draaiende app. Merk op dat u de logcat-uitvoerweergave kunt configureren, maar niet het Run-venster.
Bekijk uw app-logs
Om de logberichten voor een app weer te geven:
- Bouw en voer uw app uit op een apparaat.
- Klik op Beeld > Gereedschapsvensters > Logcat (of klik op Logcat
in de gereedschapsvensterbalk).
Het Logcat-venster toont de logberichten voor de geselecteerde toepassing, zoals geselecteerd in de vervolgkeuzelijsten boven in het venster, zoals getoond in figuur 1.
Figuur 1. Logcat venster
Standaard geeft logcat alleen de logberichten weer voor uw app die op het apparaat draait. Om deze standaard te wijzigen, zie hoe logcat-berichten te filteren.
De Logcat-werkbalk bevat de volgende knoppen:
- Logcat wissen
: Klik om het zichtbare logboek te wissen. - Scroll naar het einde
: Klik om naar de onderkant van het log te springen en de laatste logberichten te zien. Als u vervolgens op een regel in het logboek klikt, wordt het scrollen op dat punt onderbroken. - De stacktrace omhoog
en de stacktrace omlaag 
: Klik om omhoog en omlaag te navigeren door de stack traces in het log, waarbij de opeenvolgende bestandsnamen worden geselecteerd (en de corresponderende regelnummers in de editor worden weergegeven) die in de afgedrukte uitzonderingen verschijnen. Dit is hetzelfde gedrag als wanneer u klikt op een bestandsnaam in de log. - Gebruik soft wraps
: Klik om regelomloop in te schakelen en horizontaal scrollen te voorkomen (hoewel eventuele onbreekbare strings nog steeds horizontaal scrollen vereisen). - Afdrukken
: Klik om de logcat-berichten af te drukken. Na het selecteren van uw afdrukvoorkeuren in het dialoogvenster dat verschijnt, kunt u ook kiezen om op te slaan in een PDF. - Herstart
: Klik hierop om het logboek te wissen en logcat opnieuw te starten. In tegenstelling tot de knop Logcat wissen, worden hiermee eerdere logboekberichten hersteld en weergegeven, dus dit is het handigst als Logcat niet meer reageert en u uw logboekberichten niet kwijt wilt. - Logcat header
: Klik op om het dialoogvenster Configure Logcat Header te openen, waarin u het uiterlijk van elk logcat-bericht kunt aanpassen, zoals of de datum en tijd moeten worden weergegeven. - Screen capture
: Klik hierop om een schermafbeelding te maken. - Schermopname
: Klik om een video van het apparaat op te nemen (maximaal 3 minuten).
Logberichten schrijven
Met de klasse Log kunt u logberichten maken die in logcat verschijnen. Over het algemeen zou u de volgende log methodes moeten gebruiken, opgesomd in volgorde van hoogste naar laagste prioriteit (of, minst naar meest uitgebreid):
-
Log.e(String, String)(fout) -
Log.w(String, String)(waarschuwing) -
Log.i(String, String)(informatie) -
Log.d(String, String)(debug) -
Log.v(String, String)(verbose)
Zie de Log klassebeschrijving voor een meer volledige lijst van opties.
U zou nooit verbose logs in uw app moeten compileren, behalve tijdens de ontwikkeling. Debug logs worden gecompileerd, maar tijdens runtime verwijderd, terwijl error, warning, en info logs altijd worden behouden.
Voor elke log methode, moet de eerste parameter een unieke tag zijn en de tweede parameter is het bericht. De tag van een systeemlogbericht is een korte string die aangeeft van welk systeemonderdeel het bericht afkomstig is (bijvoorbeeld ActivityManager). Uw tag kan elke tekenreeks zijn die u nuttig vindt, zoals de naam van de huidige klasse.
Een goede conventie is om een TAG constante te declareren in uw klasse om te gebruiken in de eerste parameter. U zou bijvoorbeeld een informatielogbericht als volgt kunnen maken:
Kotlin
private const val TAG = "MyActivity"...Log.i(TAG, "MyClass.getView() — get item number $position")
Java
private static final String TAG = "MyActivity";...Log.i(TAG, "MyClass.getView() — get item number " + position);
Opmerking: Tagnamen van meer dan 23 tekens worden afgekapt in de logcat-uitvoer.
Logcat-berichtindeling
Elk Android-logbericht heeft een tag en een prioriteit die ermee zijn geassocieerd. De tag van een systeemlogbericht is een korte tekenreeks die de systeemcomponent aangeeft waarvan het bericht afkomstig is (bijvoorbeeld ActivityManager). Een door de gebruiker gedefinieerde tag kan elke tekenreeks zijn die u nuttig vindt, zoals de naam van de huidige klasse (de aanbevolen tag). U definieert deze in een Log-methodeaanroep, bijvoorbeeld:
Kotlin
Log.d(tag, message)
Java
Log.d(tag, message);
De prioriteit is een van de volgende waarden:
- V: Verbose (laagste prioriteit)
- D: Debug
- I: Info
- W: Warning
- E: Error
- A: Assert
De indeling van het logbericht is:
date time PID-TID/package priority/tag: message
Bijvoorbeeld, het volgende logbericht heeft een prioriteit van V en een tag van AuthZen:
12-10 13:02:50.071 1901-4229/com.google.android.gms V/AuthZen: Handling delegate intent.
PID staat voor process identifier en TID is thread identifier; ze kunnen hetzelfde zijn als er slechts één thread is.
Het log-niveau instellen
U kunt bepalen hoeveel berichten er in logcat verschijnen door het log-niveau in te stellen. U kunt alle berichten weergeven, of alleen de berichten die de meest ernstige omstandigheden aangeven.
Onthoud dat logcat alle berichten blijft verzamelen, ongeacht de instelling van het logniveau. De instelling bepaalt alleen wat logcat weergeeft.
In het Log level menu, selecteer een van de volgende waarden:
- Verbose: Toon alle logberichten (de standaardinstelling).
- Debug: Toon debug-logberichten die alleen nuttig zijn tijdens ontwikkeling, evenals de berichtniveaus lager in deze lijst.
- Info: Toon verwachte logberichten voor regelmatig gebruik, evenals de berichtniveaus lager in deze lijst.
- Waarschuwen: Toon mogelijke problemen die nog geen fouten zijn, evenals de berichtniveaus lager in deze lijst.
- Fout: Toont problemen die fouten hebben veroorzaakt, evenals het berichtniveau lager in deze lijst.
- Assert: Toon problemen waarvan de ontwikkelaar verwacht dat ze nooit mogen gebeuren.
Zoek naar logcat berichten
Om te zoeken in de berichten die momenteel worden weergegeven in logcat:
- Selecteer optioneel Regex als u een zoekpatroon met reguliere expressie wilt gebruiken.
- Type een tekenreeks in het zoekveld
.
De weergave van de logcat-uitvoer verandert dienovereenkomstig.
- Druk op Enter om de zoekreeks op te slaan in het menu tijdens deze sessie.
- Om een zoekactie te herhalen, kiest u deze uit het zoekmenu. Selecteer of deselecteer Regex als nodig (de instelling wordt niet onthouden).
Filter logcat berichten
Een manier om de log uitvoer te beperken tot een beheersbaar niveau is door het gebruik van een filter.
Opmerking: Het filter is van toepassing op uw volledige logcat geschiedenis, niet alleen de berichten die momenteel worden weergegeven in logcat. Zorg ervoor dat uw andere weergave-opties juist zijn ingesteld, zodat u de filteruitvoer kunt zien die u wilt onderzoeken.
Om een filter te definiëren en toe te passen:
- In het filtermenu, selecteert u een filteroptie:
- Toon alleen geselecteerde toepassing: Geef alleen de berichten weer die door de app-code zijn geproduceerd (de standaardinstelling). Logcat filtert de logberichten aan de hand van de PID van de actieve app.
- Geen filters: Pas geen filters toe. Logcat geeft alle logberichten van het apparaat weer, ongeacht welk proces u hebt geselecteerd.
- Filterconfiguratie bewerken: Een aangepast filter maken of wijzigen. U kunt bijvoorbeeld een filter maken om logberichten van twee apps tegelijk te bekijken.
Nadat u filters hebt gedefinieerd, kunt u ze ook in het menu selecteren. Om ze uit het menu te verwijderen, verwijdert u ze.
- Als u Filterconfiguratie bewerken hebt geselecteerd, kunt u een filter maken of wijzigen:
- Specificeer de filterparameters in het dialoogvenster Nieuw Logcat-filter maken:
- Filter Name: Typ de naam van een filter dat u wilt definiëren, of selecteer deze in het linkerdeelvenster om een bestaand filter te wijzigen. De naam mag alleen kleine letters, underscores en cijfers bevatten.
- Log Tag: Geef optioneel een tag op. Voor meer informatie, zie logcat Message Format.
- Logbericht: Geef optioneel de tekst van het logbericht op. Voor meer informatie, zie logcat Message Format.
- Pakketnaam: Geef optioneel een pakketnaam op. Voor meer informatie, zie logcat Message Format.
- PID: Optioneel specificeren van een proces-ID. Voor meer informatie, zie logcat Message Format.
- Log Level: Selecteer optioneel een logniveau. Voor meer informatie, zie Logboekniveau instellen.
- Regex: Selecteer deze optie om de reguliere expressiesyntaxis voor die parameter te gebruiken.
- Klik op + om de filterdefinitie toe te voegen aan het linkerdeelvenster.
Om een filter te verwijderen, selecteert u het in het linkerdeelvenster en klikt u op -.
- Als u klaar bent, klikt u op OK.
- Specificeer de filterparameters in het dialoogvenster Nieuw Logcat-filter maken:
Als u denkt dat u de logberichten die u wilt zien niet ziet, probeer dan Geen filters te selecteren en te zoeken naar bepaalde logberichten.
Lees vuilnisophaal berichten
Soms wordt een vuilnisophaal voorval afgedrukt naar logcat.
Voor meer details over het geheugen van uw app, gebruikt u deMemory Profiler.
Dalvik-logberichten
In Dalvik (maar niet ART), drukt elke GC de volgende informatie af naar logcat:
D/dalvikvm(PID): GC_Reason Amount_freed, Heap_stats, External_memory_stats, Pause_time
Voorbeeld:
D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms
GC Reden Wat de GC triggerde en wat voor soort collectie het is. Redenen die kunnen voorkomen zijn onder andere:GC_CONCURRENTEen concurrent GC die geheugen vrijmaakt terwijl je heap vol begint te raken.GC_FOR_MALLOCEen GC werd veroorzaakt omdat uw app probeerde geheugen toe te wijzen terwijl uw heap al vol was, dus het systeem moest uw app stoppen en geheugen terugwinnen.GC_HPROF_DUMP_HEAPEen GC die optreedt wanneer u vraagt om een HPROF-bestand te maken om uw heap te analyseren.GC_EXPLICITEen expliciete GC, zoals wanneer ugc()aanroept (wat u zou moeten vermijden en in plaats daarvan erop vertrouwen dat de GC wordt uitgevoerd wanneer dat nodig is).GC_EXTERNAL_ALLOCDit gebeurt alleen op API level 10 en lager (nieuwere versies alloceren alles in de Dalvikheap). Een GC voor extern gealloceerd geheugen (zoals de pixel data opgeslagen in innative geheugen of NIO byte buffers). Amount freed De hoeveelheid geheugen die van deze GC is teruggehaald. Heap stats Percentage vrij van de heap en (aantal live objecten)/(totale heap grootte). External memory stats Extern gealloceerd geheugen op API level 10 en lager (hoeveelheid gealloceerd geheugen) / (limiet waarbij collectie zal plaatsvinden). Pauzetijd Grotere heaps zullen grotere pauzetijden hebben. Samenlopende pauzetijden laten twee pauzes zien: een aan het begin van de verzameling en een aan het eind.
Terwijl deze log berichten zich opstapelen, kijk uit naar stijgingen in de heap stats (de3571K/9991K waarde in het bovenstaande voorbeeld). Als deze waarde blijft stijgen, heb je mogelijk een geheugenlek.
ART log messages
In tegenstelling tot Dalvik, logt ART geen berichten voor GCs die niet expliciet zijn aangevraagd. GC’s worden alleen afgedrukt als ze traag worden geacht. Meer precies, als de GC pauze langer is dan 5ms of de GC duur langer is dan 100ms. Als de app niet in een pauze waarneembare staat is (zoals wanneer de app in de achtergrond is, waar de gebruiker geen GC-pauze kan waarnemen), dan wordt geen van zijn GC’s als traag beschouwd. Expliciete GC’s worden altijd gelogd.
ART neemt de volgende informatie op in zijn garbage collection log-berichten:
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)
Example:
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 Wat triggerde de GC en wat voor soort collectie het is. Redenen die kunnen voorkomen zijn onder andere:ConcurrentEen gelijktijdige GC die app-threads niet onderbreekt. Deze GC draait in een achtergrond thread en voorkomt geen toewijzingen.AllocDe GC werd gestart omdat uw app probeerde geheugen toe te wijzen terwijl uw heap al vol was. In dit geval vond de garbage collection plaats in de toewijzende thread.ExplicitDe garbage collection werd expliciet aangevraagd door een app, bijvoorbeeld doorgc()ofgc()aan te roepen. Net als in Dalvik is het in ART het beste om de GC te vertrouwen en het aanvragen van expliciete GC’s te vermijden, indien mogelijk. Expliciete GC’s worden ontmoedigd omdat ze de toewijzende thread blokkeren en onnodig CPUcycles verspillen. Expliciete GC’s kunnen ook jank (stotteren, juddering, of stoppen in de app) veroorzaken als ze andere threads preempted maken.NativeAllocDe verzameling werd veroorzaakt door geheugendruk van inheemse toewijzingen zoals Bitmaps of RenderScript toewijzingsobjecten.CollectorTransitionDe verzameling werd veroorzaakt door een heap-overgang; dit wordt veroorzaakt door het veranderen van de GC-strategie tijdens runtime (zoals wanneer de app wisselt tussen pause-waarneembare staten). Verzamel transities bestaan uit het kopiëren van alle objecten van een free-list backed space naar een bump pointer space (of vice versa).
Dit komt alleen voor op low RAM device van voor Android 8.0wanneer een app verandert proces staten van een pauze waarneembare staat (zoals wanneer de app op de voorgrond is, waar de gebruiker een GC-pauze kan waarnemen) naar een niet-pauze waarneembare staat (of vice versa).
HomogeneousSpaceCompactHomogene ruimte verdichting is vrije-lijst ruimte naar vrije-lijst ruimte verdichting die meestal optreedt wanneer een app wordt verplaatst naar een pauze onmerkbare proces staat. De belangrijkste redenen om dit te doen zijn het verminderen van RAM-gebruik en het defragmenteren van de heap.DisableMovingGcDit is geen echte GC reden, maar een opmerking dat collectie werd geblokkeerd door gebruik vanGetPrimitiveArrayCritical. terwijl gelijktijdige heap compactie plaatsvindt. In het algemeen wordt het gebruik vanGetPrimitiveArrayCritical sterk afgeraden vanwege de beperkingen op het verplaatsen van collectors.HeapTrimDit is geen GC reden, maar een notitie dat collectie werd geblokkeerd totdat een heap trim klaar was. GC Name ART heeft verschillende GC’s die kunnen worden uitgevoerd.Concurrent mark sweep (CMS)Een hele heap collector die alle andere ruimtes dan de image ruimte vrijmaakt.Concurrent partial mark sweepEen meestal hele heap verzamelaar die alle ruimtes verzamelt behalve de image en zygote ruimtes.Concurrent sticky mark sweepEen generatie-verzamelaar die alleen objecten kan bevrijden die zijn gealloceerd sinds de laatste GC. Deze vuilnisverzamelaar wordt vaker uitgevoerd dan een volledige of gedeeltelijke mark sweep omdat hij sneller is en minder pauzes heeft.Marksweep + semispaceEen niet gelijktijdige, kopiërende GC die wordt gebruikt voor heap-overgangen en homogene ruimteverdichting (om de heap te defraggen). Objects freed Het aantal objecten dat door deze GC is teruggehaald uit de non largeobject space. Size freed Het aantal bytes dat van deze GC is teruggevorderd uit de niet-grote objectruimte. Grote objecten vrijgegeven Het aantal objecten in de grote objectruimte dat uit deze vuilnisverzameling is teruggehaald. Grote objectgrootte vrij Het aantal bytes in de grote objectruimte dat uit deze afvalverzameling is vrijgemaakt. Heap stats Percentage vrij en (aantal live objecten)/(totale heap grootte). Pauzetijden In het algemeen zijn pauzetijden evenredig met het aantal objectreferenties die werden gewijzigd terwijl de GC liep. Momenteel hebben de ART CMS GC’s maar één pauze, aan het einde van de GC. De bewegende GC’s hebben een lange pauze die het grootste deel van de GC-duur duurt.
Als u een groot aantal GC’s in logcat ziet, kijk dan naar stijgingen in de heap stats (de25MB/38MB waarde in het bovenstaande voorbeeld). Als deze waarde blijft toenemen en nooit kleiner lijkt te worden, zou je een geheugenlek kunnen hebben. Als u GC ziet met als reden “Alloc”, dan bent u al dicht bij uw heap capaciteit en kunt uOOM excepties verwachten in de nabije toekomst.