Fönstret Logcat i Android Studio visar systemmeddelanden, t.ex. när en garbagecollection inträffar, och meddelanden som du har lagt till i din app med klassen Log. Det visar meddelanden i realtid och har en historik så att du kan visa äldre meddelanden.
För att visa just den information som är av intresse kan du skapa filter, ändra hur mycket information som visas i meddelanden, ställa in prioritetsnivåer, visa meddelanden som endast produceras av app-kod och söka i loggboken. Som standard visar logcats endast loggutdata som är relaterade till den senast körda appen.
När en app gör ett undantag visar logcat ett meddelande följt av den tillhörande stapelspårningen som innehåller länkar till kodraden.
Från och med Android Studio 2.2 visar fönstret Kör även loggmeddelanden för den app som körs för tillfället. Observera att du kan konfigurera logcat-utgångsdisplayen, men inte Run-fönstret.
Visa appens loggar
Så här visar du loggmeddelanden för en app:
- Bygg och kör din app på en enhet.
- Klicka på Visa > Verktygsfönster > Logcat (eller klicka på Logcat
i verktygsfönsterfältet).
Fönstret Logcat visar loggmeddelanden för den valda appen, som valts från rullgardinslistorna högst upp i fönstret, enligt figur 1.
Figur 1. Logcat-fönstret
Som standard visar logcat bara loggmeddelanden för din app som körs på enheten. Om du vill ändra detta standardvärde kan du se hur du filtrerar logcatmeddelanden.
Logcat-verktygsfältet har följande knappar:
- Rensa logcat
: Klicka för att rensa den synliga loggen. - Rulla till slutet
: Klicka för att rensa den synliga loggen: Klicka för att hoppa till slutet av loggen och se de senaste loggmeddelandena. Om du sedan klickar på en rad i loggen pausar visningen rullningen vid den punkten. - Uppåt i stapelspåret
och nedåt i stapelspåret 
: Klicka för att navigera uppåt och nedåt i stapelspåren i loggen, genom att välja efterföljande filnamn (och visa motsvarande radnummer i redigeraren) som visas i de utskrivna undantagen. Detta är samma beteende som när du klickar på ett filnamn i loggen. - Använd mjuka omslag
: Klicka för att aktivera radbrytning och förhindra horisontell rullning (även om alla obrytbara strängar fortfarande kräver horisontell rullning). - Skriv ut
: Klicka för att skriva ut logcat-meddelanden. När du har valt dina utskriftsinställningar i dialogrutan som visas kan du också välja att spara till en PDF. - Starta om
: Klicka för att rensa loggen och starta om logcat. Till skillnad från knappen Rensa logcat återställer detta och visar tidigare loggmeddelanden, så det är mest användbart om Logcat inte svarar och du inte vill förlora dina loggmeddelanden. - Logcat header
: Klicka för att öppna dialogrutan Konfigurera logcat-huvud, där du kan anpassa utseendet på varje logcat-meddelande, t.ex. om datum och tid ska visas. - Skärmklipp
: Klicka för att öppna dialogrutan Konfigurera logcat-huvud, där du kan anpassa utseendet på varje logcat-meddelande, t.ex. om datum och tid ska visas: Klicka för att ta en skärmdump. - Skärminspelning
: Klicka för att spela in en video av enheten (i högst 3 minuter).
Skriv loggmeddelanden
Med klassen Log kan du skapa loggmeddelanden som visas i logcat. Generellt sett bör du använda följande loggmetoder, listade i ordning från högsta till lägsta prioritet (eller, minst till mest utförliga):
-
Log.e(String, String)(error) -
Log.w(String, String)(warning) -
Log.i(String, String)(information) -
Log.d(String, String)(debug) -
Log.v(String, String)(verbose)
Se beskrivningen av klassen Log för en mer fullständig lista över alternativ.
Du bör aldrig kompilera verbose-loggar i din app, utom under utveckling. Loggar för felsökning kompileras in men tas bort vid körning, medan fel-, varnings- och informationsloggar alltid behålls.
För varje loggmetod bör den första parametern vara en unik tagg och den andra parametern är meddelandet. Taggen för ett systemloggmeddelande är en kort sträng som anger den systemkomponent från vilken meddelandet kommer (t.ex. ActivityManager). Din tagg kan vara vilken sträng som helst som du tycker är användbar, till exempel namnet på den aktuella klassen.
En bra konvention är att deklarera en TAG-konstant i din klass för att använda den i den första parametern. Du kan till exempel skapa ett informationslogmeddelande på följande sätt:
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);
Observera: Taggnamn som är större än 23 tecken trunkeras i logcat-utgången.
Logcat-meddelandeformat
Varje Android-loggmeddelande har en tagg och en prioritet som är associerade med det. Taggen för ett systemloggmeddelande är en kort sträng som anger den systemkomponent som meddelandet kommer från (till exempel ActivityManager). En användardefinierad tagg kan vara vilken sträng som helst som du tycker är användbar, till exempel namnet på den aktuella klassen (den rekommenderade taggen). Du definierar den i ett Log metodanrop, till exempel:
Kotlin
Log.d(tag, message)
Java
Log.d(tag, message);
Prioriteten är ett av följande värden:
- V: Verbose (lägsta prioritet)
- D: Debug
- I: Info
- W: Warning
- E: Error
- A: Assert
Loggmeddelandeformatet är:
date time PID-TID/package priority/tag: message
Följande loggmeddelande har till exempel prioriteten V och taggen AuthZen:
12-10 13:02:50.071 1901-4229/com.google.android.gms V/AuthZen: Handling delegate intent.
PID står för processidentifiering och TID för trådidentifiering; de kan vara desamma om det bara finns en tråd.
Inställ loggnivå
Du kan styra hur många meddelanden som visas i logcat genom att ställa in loggnivån. Du kan visa alla meddelanden eller bara de meddelanden som indikerar de allvarligaste förhållandena.
Kom ihåg att logcat fortsätter att samla in alla meddelanden oavsett inställningen av loggnivån. Inställningen bestämmer bara vad logcat visar.
I menyn Loggnivå väljer du ett av följande värden:
- Verbose: Visa alla loggmeddelanden (standardvärdet).
- Debug: Visa felsökningsloggmeddelanden som endast är användbara under utveckling, samt de meddelandenivåer som ligger lägre i den här listan.
- Info: Visa förväntade loggmeddelanden för regelbunden användning, samt de meddelandenivåer som ligger lägre i den här listan.
- Varning: Visa möjliga problem som ännu inte är fel, samt meddelandenivåerna lägre i den här listan.
- Fel: Visa problem som har orsakat fel, samt meddelandenivån lägre i den här listan.
- Assert: Visa problem som utvecklaren förväntar sig att aldrig ska inträffa.
Söka logcat-meddelanden
För att söka i de meddelanden som för närvarande visas i logcat:
- Välj eventuellt Regex om du vill använda ett sökmönster med reguljära uttryck.
- Ta in en teckensekvens i sökfältet
.
Logcat-utgångsdisplayen ändras i enlighet med detta.
- Tryck på Enter för att lagra söksträngen i menyn under den här sessionen.
- För att upprepa en sökning väljer du den från sökmenyn. Markera eller avmarkera Regex vid behov (inställningen sparas inte).
Filtrera logcat-meddelanden
Ett sätt att minska loggutmatningen till en hanterbar nivå är att begränsa den med hjälp av ett filter.
Observera: Filtret gäller hela din logcat-historik, inte bara de meddelanden som för närvarande visas i logcat. Se till att dina andra visningsalternativ är inställda på rätt sätt så att du kan se den filterutgång du vill undersöka.
Så här definierar och tillämpar du ett filter:
- I filtermenyn väljer du ett filteralternativ:
- Visa endast det valda programmet: Visa endast de meddelanden som produceras av programkoden (standard). Logcat filtrerar loggmeddelandena med hjälp av PID för den aktiva appen.
- Inga filter: Tillämpa inga filter. Logcat visar alla loggmeddelanden från enheten, oavsett vilken process du valt.
- Redigera filterkonfiguration: Skapa eller ändra ett anpassat filter. Du kan till exempel skapa ett filter för att visa loggmeddelanden från två appar samtidigt.
När du har definierat filter kan du också välja dem i menyn. Om du vill ta bort dem från menyn tar du bort dem.
- Om du har valt Redigera filterkonfiguration skapar eller ändrar du ett filter:
- Ange filterparametrarna i dialogrutan Skapa nytt logcatfilter:
- Filternamn: Du kan också välja det i den vänstra rutan om du vill ändra ett befintligt filter. Namnet kan endast innehålla små bokstäver, understrykningar och siffror.
- Loggmärke: Ange valfritt en tagg. Mer information finns i logcat Meddelandeformat.
- Loggmeddelande: Ange eventuellt loggmeddelandetext. Mer information finns i logcat Message Format.
- Paketnamn: Ange eventuellt ett paketnamn. För mer information, se logcat Message Format.
- PID: Ange eventuellt ett process-ID. För mer information, se logcat Message Format.
- Loggnivå: Välj eventuellt en loggningsnivå. Mer information finns i Ange loggnivå.
- Regex: Välj det här alternativet för att använda syntax för reguljära uttryck för den parametern.
- Klicka på + för att lägga till filterdefinitionen i den vänstra rutan.
Om du vill ta bort ett filter markerar du det i den vänstra rutan och klickar på -.
- Klicka på OK när du är klar.
- Ange filterparametrarna i dialogrutan Skapa nytt logcatfilter:
Om du inte tror att du ser de loggmeddelanden du vill se, kan du försöka välja Inga filter och söka efter särskildaloggmeddelanden.
Läs meddelanden om skräpplockning
Ibland när en skräpplockningshändelse inträffar skrivs de ut till logcat.
Om du vill ha mer information om minnet i din app kan du användaMemory Profiler.
Dalvik loggmeddelanden
I Dalvik (men inte ART) skriver varje GC ut följande information till logcat:
D/dalvikvm(PID): GC_Reason Amount_freed, Heap_stats, External_memory_stats, Pause_time
Exempel:
D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms
GC Reason Vad som utlöste GC:n och vilken typ av insamling det är. Orsaker som kan förekomma är bland annat:GC_CONCURRENTEn samtidig GC som frigör minne när din heap börjar fyllas.GC_FOR_MALLOCEn GC orsakades av att din app försökte allokera minne när din heap redan var full, så systemet var tvunget att stoppa din app och återkräva minne.GC_HPROF_DUMP_HEAPEn GC som uppstår när du begär att skapa en HPROF-fil för att analysera din heap.GC_EXPLICITEn explicit GC, till exempel när du anropargc()(vilket du bör undvika att anropa och istället lita på att GC körs när det behövs).GC_EXTERNAL_ALLOCDetta sker endast på API-nivå 10 och lägre (nyare versioner allokerar allt i Dalvikheap). En GC för externt allokerat minne (t.ex. pixeldata som lagras i innativt minne eller NIO-bytebuffertar). Amount freed Mängden minne som återkrävts från den här GC:n. Heap stats Procentuell andel fri av heap och (antal levande objekt)/(total heapstorlek). Extern minnesstatistik Externt allokerat minne på API-nivå 10 och lägre (mängden allokerat minne)/(gräns vid vilken insamling kommer att ske). Paustid Större heaps har större paustider. Samtida paustider visar två pauser: en i början av insamlingen och en i slutet av insamlingen.
Medans dessa loggmeddelanden ackumuleras, håll utkik efter ökningar i heap-statistiken (3571K/9991K-värdet i exemplet ovan). Om detta värde fortsätter att öka kan du ha en minnesläcka.
ART loggmeddelanden
Till skillnad från Dalvik loggar ART inte meddelanden för GCs som inte uttryckligen begärts. GC:er skrivs bara ut när de anses vara långsamma. Närmare bestämt om GC-pausen överstiger 5 ms eller om GC-varaktigheten överstiger 100 ms. Om appen inte befinner sig i ett tillstånd där paus kan uppfattas (t.ex. när appen befinner sig i bakgrunden, där användaren inte kan uppfatta en GC-paus) anses ingen av dess GC:er vara långsam. Explicita GC:er loggas alltid.
ART inkluderar följande information i sina loggmeddelanden för garbage collection:
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)
Exempel:
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 Vad som utlöste GC:en och vilken typ av insamling det är. Orsaker som kan förekomma är bland annat:ConcurrentEn samtidig GC som inte avbryter apptrådar. Denna GC körs i en bakgrundstråd och förhindrar inte allokeringar.AllocGC initierades eftersom din app försökte allokera minne när heapet redan var fullt. I det här fallet skedde sophämtningen i den allokerande tråden.ExplicitEn app begärde uttryckligen att få skräpplockning, till exempel genom att anropagc()ellergc(). Precis som i Dalvik är den bästa metoden i ART att du litar på GC och om möjligt undviker att begära uttryckliga GC:s. Uttryckliga GC:s avråds eftersom de blockerar den allokerande tråden och slösar onödigt mycket CPU-cykler. Explicit GCs kan också orsaka jank (stuttering, juddering eller stopp i appen) om de leder till att andra trådar blir preempted.NativeAllocSamlingen orsakades av inhemskt minnestryck från inhemska allokeringar som Bitmaps eller RenderScript-allokeringsobjekt.CollectorTransitionSamlingen orsakades av en heap-övergång; detta orsakas av att GC-strategin ändras vid körning (t.ex. när appen växlar mellan pausbara tillstånd). Samlingsövergångar består av att alla objekt kopieras från ett utrymme med stöd för en fri lista till ett utrymme med bumppekare (eller vice versa).
Detta inträffar endast på enheter med lågt RAM-minne före Android 8.0när en app ändrar processtillstånd från ett pausuppfattbart tillstånd (t.ex. när appen är i förgrunden, där användaren kan uppfatta en GC-paus) till ett icke pausuppfattbart tillstånd (eller tvärtom).
HomogeneousSpaceCompactHomogen space compaction är komprimering från free-list space till free-list space som vanligtvis inträffar när en app flyttas till ett pausuppfattbart processtillstånd. De viktigaste skälen till att göra detta är att minska användningen av RAM-minne och defragmentera heap.DisableMovingGcDetta är inte en riktig GC-skäl, utan en notering om att insamlingen blockerades på grund av användning avGetPrimitiveArrayCritical. medan samtidig komprimering av heap sker. I allmänhet avråds starkt från användningen avGetPrimitiveArrayCritical på grund av dess begränsningar för att flytta insamlare.HeapTrimDetta är inte en GC-orsak, utan en notering om att insamlingen blockerades tills en heapkomprimering avslutades. GC Name ART har flera olika GC:er som kan köras.Concurrent mark sweep (CMS)En hel heap-uppsamlare som frigör samlar in alla andra utrymmen än bildutrymmet.Concurrent partial mark sweepEn mestadels whole heap collector som samlar in alla andra utrymmen än image- och zygote-utrymmena.Concurrent sticky mark sweepEn generationsinsamlare som endast kan frigöra objekt som allokerats sedan senaste GC. Denna garbagecollection körs oftare än en hel eller partiell mark sweep eftersom den är snabbare och har färre pauser.Marksweep + semispaceEn icke-konkurrent, kopierande GC som används för heapövergångar samt homogen spacecompaction (för att defragmentera heapen). Objects freed Antalet objekt som återkrävdes från denna GC från det icke-stora objektutrymmet. Size freed Antalet bytes som återkrävdes från denna GC från det icke stora objektutrymmet. Stora objekt frigjorda Antalet objekt i det stora objektutrymmet som frigjorts från den här skräpinsamlingen. Stor objektstorlek frigjord Antalet bytes i det stora objektutrymmet som återkrävdes från denna skräpkollektion. Heap-statistik Procent fri och (antal levande objekt)/(total heapstorlek). Paustider I allmänhet är paustiderna proportionella mot antalet objektreferenser som ändrades under tiden som GC kördes. För närvarande har ART CMS GCs endast en paus, nära slutet av GC:n. De rörliga GC:erna har en lång paus som varar under större delen av GC:ns varaktighet.
Om du ser en stor mängd GCs i logcat, leta efter ökningar i heap-statistiken (värdet25MB/38MB i exemplet ovan). Om det här värdet fortsätter att öka och aldrig verkar bli mindre kan du ha en minnesläcka. Alternativt, om du ser GC som har orsaken ”Alloc”, så arbetar du redan nära din heapkapacitet och kan förvänta digOOM -undantag inom en snar framtid.