Skriv og vis logfiler med Logcat

Logcat-vinduet i Android Studio viser systemmeddelelser, f.eks. når der opstår en garbagecollection, og meddelelser, som du har tilføjet til din app med Log-klassen. Det viser meddelelser i realtid og gemmer en historik, så du kan se ældre meddelelser.

For at få vist kun de oplysninger, der er af interesse, kan du oprette filtre, ændre hvor mange oplysninger, der vises i meddelelser, indstille prioritetsniveauer, kun vise meddelelser, der er produceret af app-kode, og søge i loggen. Som standard viser logcats kun loggen, der er relateret til den senest kørte app.

Når en app kaster en undtagelse, viser logcat en meddelelse efterfulgt af den tilknyttede staksporing, der indeholder links til kodelinjen.

Som i Android Studio 2.2 viser vinduet Kør også logmeddelelser for den aktuelt kørende app. Bemærk, at du kan konfigurere logcat-udgangsvisningen, men ikke Kør-vinduet.

Se dine app-logfiler

Sådan viser du logmeddelelserne for en app:

1. Opbyg og kør din app på en enhed.
2. Klik på Vis > Værktøjsvinduer > Logcat (eller klik på Logcat i værktøjsvinduets bjælke).

Vinduet Logcat viser logmeddelelserne for den valgte app, som valgt fra dropdownlisterne øverst i vinduet, som vist i figur 1.

Figur 1. Logcat-vinduet

Som standard viser logcat kun logmeddelelser for din app, der kører på enheden. Du kan ændre denne standardindstilling ved at se, hvordan du filtrerer logcat-meddelelser.

Logcat-værktøjslinjen indeholder følgende knapper:

1. Ryd logcat : Klik på for at rydde den synlige log.
2. Rul til slutningen : Klik for at springe til bunden af loggen og se de seneste logmeddelelser. Hvis du derefter klikker på en linje i loggen, holder visningen pause med at rulle på det pågældende punkt.
3. Opad stacktrace og nedad stacktrace : Klik for at navigere opad og nedad i staksporene i loggen og vælge de efterfølgende filnavne (og få vist de tilsvarende linjenumre i editoren), der vises i de udskrevne undtagelser. Dette er den samme opførsel, som når du klikker på et filnavn i loggen.
4. Brug soft wraps : Klik for at aktivere linjeombrydning og forhindre vandret rulning (selvom alle ubrydelige strenge stadig vil kræve vandret rulning).
5. Udskriv : Klik for at udskrive logcat-meddelelserne. Når du har valgt dine udskriftspræferencer i den dialogboks, der vises, kan du også vælge at gemme til en PDF.
6. Genstart : Klik for at rydde loggen og genstarte logcat. I modsætning til knappen Ryd logcat genopretter og viser tidligere logmeddelelser, så dette er mest nyttigt, hvis Logcat ikke reagerer, og du ikke ønsker at miste dine logmeddelelser.
7. Logcat header : Klik for at åbne dialogboksen Konfigurer logcat-overskrift, hvor du kan tilpasse udseendet af hver logcat-meddelelse, f.eks. om dato og klokkeslæt skal vises.
8. Skærmbillede : Klik for at åbne dialogboksen Konfigurer logcat-overskrift : Klik for at tage et skærmbillede.
9. Skærmoptagelse : Klik for at optage en video af enheden (i højst 3 minutter).

Skriv logmeddelelser

Med Log-klassen kan du oprette logmeddelelser, der vises i logcat. Generelt bør du bruge følgende logmetoder,der er anført i rækkefølge fra højeste til laveste prioritet (eller fra mindst til mest mundret):

• Log.e(String, String) (fejl)
• Log.w(String, String) (advarsel)
• Log.i(String, String) (information)
• Log.d(String, String) (fejlfinding)
• Log.v(String, String) (udførlig)

Se beskrivelsen af Log-klassen for at få en mere komplet liste over muligheder.

Du bør aldrig kompilere verbose-logfiler i din app, undtagen under udvikling. Debug-logs kompileres, men fjernes ved kørselstid, mens fejl-, advarsels- og info-logs altid bevares.

For hver logmetode skal den første parameter være et unikt tag, og den anden parameter er meddelelsen. En systemlogmeddelelses tag er en kort streng, der angiver den systemkomponent, hvorfra meddelelsen stammer (f.eks. ActivityManager). Dit tag kan være en hvilken som helst streng, som du finder nyttig, f.eks. navnet på den aktuelle klasse.

En god konvention er at deklarere en TAG konstant i din klasse til brug i den første parameter. Du kan f.eks. oprette en informationslogmeddelelse som følger:

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);

Bemærk: Tag-navne, der er større end 23 tegn, bliver afkortet i logcat-udgangen.

Logcat-meddelelsesformat

Hver Android-logmeddelelse har et tag og en prioritet, der er tilknyttet den. Tagget for en systemlogmeddelelse er en kort streng, der angiver den systemkomponent, som meddelelsen stammer fra (f.eks. ActivityManager). Et brugerdefineret tag kan være en hvilken som helst streng, som du finder nyttig, f.eks. navnet på den aktuelle klasse (det anbefalede tag). Du definerer det i et Log metodekald, f.eks.:

Log.d(tag, message)

Log.d(tag, message);

Prioriteten er en af følgende værdier:

• V: Verbose (laveste prioritet)
• D: Debug
• I: Info
• W: Advarsel
• E: Fejl
• A: Bekræftelse

Logmeddelelsesformatet er:

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

Følgende logmeddelelse har f.eks. en prioritet på V og et tag på AuthZen:

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

PID står for procesidentifikator og TID er trådidentifikator; de kan være de samme, hvis der kun er én tråd.

Sæt logniveauet

Du kan styre, hvor mange meddelelser der vises i logcat, ved at indstille logniveauet. Du kan vise alle meddelelser eller kun de meddelelser, der angiver de mest alvorlige forhold.

Husk, at logcat fortsætter med at indsamle alle meddelelser uanset indstillingen af logniveauet. Indstillingen bestemmer blot, hvad logcat viser.

I menuen Logniveau skal du vælge en af følgende værdier:

• Verbose: Vis alle logmeddelelser (standardværdien).
• Debug: Vis debug-logmeddelelser, som kun er nyttige under udvikling, samt de meddelelsesniveauer, der ligger lavere på denne liste.
• Info: Vis forventede logmeddelelser til almindelig brug samt de meddelelsesniveauer, der ligger lavere på denne liste.
• Advarsel: Viser mulige problemer, der endnu ikke er fejl, samt meddelelsesniveauerne lavere på denne liste.
• Fejl: Vis problemer, der har forårsaget fejl, samt meddelelsesniveauet lavere i denne liste.
• Assert: Viser problemer, som udvikleren forventer, at der aldrig må ske.

Søg logcat-meddelelser

Sådan søger du i de meddelelser, der i øjeblikket vises i logcat:

1. Vælg eventuelt Regex, hvis du vil bruge et søgemønster med regulære udtryk.
2. Typ en tegnsekvens i søgefeltet .

   Logcat-udgangsvisningen ændres i overensstemmelse hermed.

3. Tryk på Enter for at gemme søgestrengen i menuen under denne session.
4. For at gentage en søgning skal du vælge den fra søgemenuen. Vælg eller fravælg Regex efter behov (indstillingen gemmes ikke).

Filtrer logcat-meddelelser

En måde at reducere logoutput til et håndterbart niveau er at begrænse det ved hjælp af et filter.

Bemærk: Filteret gælder for hele din logcat-historik, ikke kun de meddelelser, der i øjeblikket vises i logcat. Sørg for, at dine andre visningsindstillinger er indstillet korrekt, så du kan se det filteroutput, du ønsker at undersøge.

Sådan definerer og anvender du et filter:

1. Vælg en filterindstilling i filtermenuen:
   • Vis kun det valgte program: Vis kun de meddelelser, der er produceret af programkoden (standardindstillingen). Logcat filtrerer logmeddelelserne ved hjælp af PID’et for den aktive app.
   • Ingen filtre: Anvend ingen filtre. Logcat viser alle logmeddelelser fra enheden, uanset hvilken proces du har valgt.
   • Rediger filterkonfiguration: Opret eller ændr et brugerdefineret filter. Du kan f.eks. oprette et filter for at få vist logmeddelelser fra to apps på samme tid.

   Når du har defineret filtre, kan du også vælge dem i menuen. Hvis du vil fjerne dem fra menuen, skal du slette dem.

2. Hvis du har valgt Rediger filterkonfiguration, kan du oprette eller ændre et filter:
   1. Angiv filterparametrene i dialogboksen Opret nyt Logcat-filter:
      • Filternavn:
        • Filternavn: Du kan også vælge det i venstre rude for at ændre et eksisterende filter. Navnet kan kun indeholde små bogstaver, understregninger og cifre.
        • Logmærke: Angiv eventuelt et tag. Du kan finde flere oplysninger under logcat-meddelelsesformat.
        • Logmeddelelse: Angiv eventuelt logmeddelelsesteksten. Du kan finde flere oplysninger under logcat Message Format.
        • Package Name (Pakkenavn): Angiv eventuelt et pakkenavn. Du kan finde flere oplysninger under logcat Message Format.
        • PID: Angiv eventuelt et proces-ID. Du kan finde flere oplysninger under logcat Message Format.
        • Logniveau: Vælg eventuelt et logniveau. Du kan finde flere oplysninger under Indstil logniveauet.
        • Regex: Vælg denne indstilling for at bruge syntaks for regulære udtryk for den pågældende parameter.
      • Klik på + for at tilføje filterdefinitionen til venstre rude.

        Hvis du vil fjerne et filter, skal du vælge det i venstre rude og klikke på – for at fjerne det.

      • Når du er færdig, skal du klikke på OK.

Hvis du ikke mener, at du ser de ønskede logmeddelelser, kan du prøve at vælge Ingen filtre og søge efter bestemtelogmeddelelser.

Læs meddelelser om garbage collection

I nogle tilfælde, når der opstår en garbage collection-hændelse, udskrives de til logcat.

For at få flere detaljer om din apps hukommelse skal du brugeMemory Profiler.

Dalvik-logmeddelelser

I Dalvik (men ikke ART) udskriver hver GC følgende oplysninger til logcat:

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

Eksempel:

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

GC-årsag Hvad udløste GC’en, og hvilken type indsamling det er. Årsager, der kan vises, omfatter bl.a:GC_CONCURRENTEn samtidig GC, der frigør hukommelse, når din heap begynder at blive fyldt op.GC_FOR_MALLOCEn GC blev udløst, fordi din app forsøgte at allokere hukommelse, da din heap allerede var fuld, så systemet var nødt til at stoppe din app og genvinde hukommelse.GC_HPROF_DUMP_HEAPEn GC, der opstår, når du anmoder om at oprette en HPROF-fil for at analysere din heap.GC_EXPLICITEn eksplicit GC, f.eks. når du kaldergc()(som du bør undgå at kalde og i stedet stole på, at GC’en kører, når det er nødvendigt).GC_EXTERNAL_ALLOCDette sker kun på API-niveau 10 og lavere (nyere versioner allokerer alt i Dalvikheap). En GC for eksternt allokeret hukommelse (f.eks. pixeldata, der er lagret inativ hukommelse eller NIO-bytebuffere). Mængde frigjort Mængden af hukommelse, der er genindvundet fra denne GC. Heap-statistik Procentdel fri af heap’en og (antal levende objekter)/(samlet heap-størrelse). Ekstern hukommelsesstatistik Eksternt allokeret hukommelse på API-niveau 10 og lavere (mængden af allokeret hukommelse)/(grænse, ved hvilken indsamling vil finde sted). Pausetid Større heaps vil have større pausetider. Samtidige pausetider viser to pauser: en i begyndelsen af opsamlingen og en anden i slutningen af opsamlingen.

Mens disse logmeddelelser akkumuleres, skal du holde øje med stigninger i heap-statistikken (værdien3571K/9991K i ovenstående eksempel). Hvis denne værdi fortsætter med at stige, har du måske en hukommelseslækage.

ART-logmeddelelser

I modsætning til Dalvik logger ART ikke meddelelser for GC’er, der ikke udtrykkeligt er blevet anmodet om. GC’er bliver kun udskrevet, når de anses for langsomme. Mere præcist, hvis GC-pausen overstiger 5 ms eller GC-varigheden overstiger 100 ms. Hvis appen ikke er i en tilstand, der kan opfattes som en pause (f.eks. når appen er i baggrunden, hvor brugeren ikke kan opfatte en GC-pause), anses ingen af dens GC’er for at være langsomme. Eksplicitte GC’er logges altid.

ART indeholder følgende oplysninger i sine garbage collection-logmeddelelser:

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)

Eksempel:

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 Årsag Hvad der udløste GC’en, og hvilken type indsamling det er. Årsager, der kan vises, omfatter bl.a:ConcurrentEn samtidig GC, der ikke suspenderer app-tråde. Denne GC kører i en baggrundstråd og forhindrer ikke allokeringer.AllocGC’en blev igangsat, fordi din app forsøgte at allokere hukommelse, da din heap allerede var fuld. I dette tilfælde fandt garbage collection sted i den allokerende tråd.ExplicitEn app anmodede udtrykkeligt om garbage collection, f.eks. ved at kaldegc()ellergc(). Ligesom i Dalvik er det i ART den bedste praksis, at man stoler på GC’en og om muligt undgår at anmode om eksplicit GC’s. Eksplicit GC’er frarådes, fordi de blokerer den allokerende tråd og unødigt spilder CPU-cykler. Eksplicitte GC’er kan også forårsage jank (stuttering, juddering eller stop i programmet), hvis de får andre tråde til at blive præemptet.NativeAllocOpsamlingen blev forårsaget af native hukommelsespres fra native allokeringer såsom Bitmaps eller RenderScript-allokeringsobjekter.CollectorTransitionOpsamlingen blev forårsaget af en heap-overgang; dette skyldes ændring af GC-strategien på kørselstidspunktet (f.eks. når appen skifter mellem pausemærkbare tilstande). Opsamlingsovergange består i at kopiere alle objekter fra et rum med en fri liste med backing til et rum med bump pointer (eller omvendt).

Dette sker kun på enheder med lavt RAM-lager før Android 8.0når en app skifter procestilstand fra en pauseopfattelig tilstand (f.eks. når appen er i forgrunden, hvor brugeren kan opfatte en GC-pause) til en ikke-pauseopfattelig tilstand (eller omvendt).

HomogeneousSpaceCompactHomogen rumkomprimering er komprimering fra frilisteplads til frilisteplads, som normalt forekommer, når en app flyttes til en pauseopfattelig procestilstand. De vigtigste grunde til at gøre dette er at reducere RAM-forbruget og defragmentere heap’en.DisableMovingGcDette er ikke en egentlig GC-årsag, men en bemærkning om, at indsamling blev blokeret på grund af brug afGetPrimitiveArrayCritical. mens samtidig heap-komprimering finder sted. Generelt frarådes brugen afGetPrimitiveArrayCritical kraftigt på grund af dets begrænsninger for flytning af opsamlere.HeapTrimDette er ikke en GC-årsag, men en bemærkning om, at indsamling blev blokeret, indtil en heap-trimning blev afsluttet. GC Navn ART har forskellige forskellige GC’er, som kan blive kørt.Concurrent mark sweep (CMS)En whole heap collector, som frigør indsamler alle andre rum end billedrummet.Concurrent partial mark sweepEn hovedsagelig hel heap-opsamler, der indsamler alle andre rum end image- og zygote-rummene.Concurrent sticky mark sweepEn generationsopsamler, som kun kan frigøre objekter, der er allokeret siden den sidste GC. Denne garbagecollection køres oftere end en hel eller delvis mark sweep, da den er hurtigere og har færre pauser.Marksweep + semispaceEn ikke-konkurrerende, kopierende GC, der anvendes til heapovergange samt homogen spacecompaction (for at defragmentere heap’en). Objects freed Antallet af objekter, der blev genindvundet fra denne GC fra den ikke-storeobject space. Size freed Antallet af bytes, der blev genindvundet fra denne GC fra det ikke store objektområde. Store objekter frigjort Antallet af objekter i det store objektområde, som er blevet frigjort fra denne affaldssamling. Større objektstørrelse frigjort Antallet af bytes i det store objektområde, som er blevet genbrugt fra denne garbagecollection. Heap-statistik Procentdel fri og (antal levende objekter)/(samlet heap-størrelse). Pausetider Generelt er pausetider proportionale med antallet af objektreferencer, der blev ændret, mens GC’en kørte. I øjeblikket har ART CMS GC’erne kun én pause, nær slutningen af GC’en, mens de bevægelige GC’er har en lang pause, som varer i størstedelen af GC’ens varighed.

Hvis du ser en stor mængde GC’er i logcat, skal du kigge efter stigninger i heap-statistikkerne (værdien25MB/38MB i ovenstående eksempel). Hvis denne værdi fortsætter med at stige og aldrig synes at blive mindre, kan du have en hukommelseslækage. Alternativt, hvis du ser GC, som er af årsagen “Alloc”, så opererer du allerede tæt på din heap-kapacitet og kan forventeOOM- undtagelser i den nærmeste fremtid.