Zápis a zobrazení protokolů pomocí Logcat

V okně Logcat v aplikaci Android Studio se zobrazují systémové zprávy, například když dojde ke sběru odpadků, a zprávy, které jste do aplikace přidali pomocí třídy Log. Zobrazuje zprávy v reálném čase a uchovává historii, takže si můžete prohlédnout starší zprávy.

Chcete-li zobrazit jen ty informace, které vás zajímají, můžete vytvářet filtry, upravovat, kolik informací se ve zprávách zobrazí, nastavovat úrovně priority, zobrazovat pouze zprávy vytvořené kódem aplikace a prohledávat protokol. Ve výchozím nastavení logcatszobrazuje pouze výstupy protokolu týkající se naposledy spuštěné aplikace.

Pokud aplikace vyhodí výjimku, logcat zobrazí zprávu, za kterou následuje související stopa zásobníku obsahující odkazy na řádek kódu.

Okno Spustit od verze Android Studio 2.2 zobrazuje také zprávy protokolu pro aktuálně spuštěnou aplikaci. Všimněte si, že můžete konfigurovat zobrazení výstupu logcat, ale ne okno Spustit.

Zobrazení protokolů aplikace

Zobrazení zpráv protokolu pro aplikaci:

1. Sestavte a spusťte aplikaci na zařízení.
2. Klikněte na Zobrazit > Okna nástrojů > Logcat (nebo klikněte na Logcat na panelu oken nástrojů).

V okně Logcat se zobrazí zprávy protokolu pro vybranou aplikaci, vybrané z rozevíracích seznamů v horní části okna, jak je znázorněno na obrázku 1.

Obrázek 1: Zprávy protokolu pro vybranou aplikaci. Okno Logcat

Ve výchozím nastavení zobrazuje logcat pouze zprávy protokolu pro vaši aplikaci spuštěnou v zařízení. Chcete-li toto výchozí nastavení změnit, podívejte se, jak filtrovat zprávy logcat.

Na panelu nástrojů Logcat jsou k dispozici následující tlačítka:

1. Vymazat logcat :
2. Posunout na konec : Klepnutím vymažete viditelný protokol: Kliknutím přejdete na konec protokolu a zobrazíte poslední zprávy protokolu. Pokud pak kliknete na řádek v protokolu, zobrazení se v tomto bodě zastaví při posouvání.
3. Nahoru stopa zásobníku a Dolů stopa zásobníku : Kliknutím se můžete pohybovat nahoru a dolů po stopách zásobníku v protokolu a vybírat následné názvy souborů (a zobrazovat odpovídající čísla řádků v editoru), které se objevují ve vytištěných výjimkách. Jedná se o stejné chování, jako když kliknete na název souboru v protokolu.
4. Použít měkké obálky : Klepnutím povolíte obtékání řádků a zabráníte horizontálnímu rolování (ačkoli všechny nezlomitelné řetězce budou stále vyžadovat horizontální rolování).
5. Tisk : Kliknutím vytisknete zprávy logcat. Po výběru preferencí tisku v zobrazeném dialogovém okně můžete také zvolit uložení do PDF.
6. Restartovat : Kliknutím vymažete protokol a znovu spustíte logcat. Na rozdíl od tlačítka Vymazat logcat obnoví a zobrazí předchozí zprávy protokolu, takže je nejužitečnější, pokud Logcat přestane reagovat a vy nechcete přijít o zprávy protokolu.
7. Hlavička logcatu :
8. Snímání obrazovky : Klepnutím otevřete dialogové okno Konfigurace záhlaví Logcat, kde můžete upravit vzhled každé zprávy Logcat, například zda se má zobrazovat datum a čas:
9. Záznam obrazovky : Klepnutím nahrajete video zařízení (maximálně po dobu 3 minut).

Zapisování zpráv protokolu

Třída Logumožňuje vytvářet zprávy protokolu, které se objevív logcat. Obecně byste měli používat následující metody záznamu,uvedené v pořadí od nejvyšší po nejnižší prioritu(nebo od nejmenší po nejhrubší):

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

Úplnější seznam možností najdete v popisu třídy Log.

Nikdy byste neměli do své aplikace zakompilovat verbose logy, s výjimkou vývoje. Ladicí protokoly jsou zakompilovány, ale za běhu jsou odstraněny, zatímco chybové,varovné a informační protokoly jsou vždy zachovány.

Pro každou metodu protokolu by prvním parametrem měla být jedinečná značka a druhým parametrem je zpráva. Tag zprávy systémového protokolu je krátký řetězec označující systémovou komponentu, ze které zpráva pochází (například ActivityManager). Váš tag může být jakýkoli řetězec, který považujete za užitečný, například název aktuální třídy.

Dobrou konvencí je deklarovat ve třídě konstantu TAG, kterou použijete v prvním parametru. Informační zprávu protokolu můžete například vytvořit takto:

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

Poznámka: Názvy značek větší než 23 znaků jsou ve výstupu logcatu zkráceny.

Formát zprávy logcatu

Každá zpráva protokolu systému Android má přiřazenou značku a prioritu. Značka systémové zprávy protokolu je krátký řetězec označující systémovou komponentu, ze které zpráva pochází (například ActivityManager). Uživatelem definovaný tag může být jakýkoli řetězec, který považujete za užitečný, například název aktuální třídy (doporučený tag). Definujete jej ve volání metody Log, například:

Log.d(tag, message)

Log.d(tag, message);

Priorita je jedna z následujících hodnot:

• V: Verbose (nejnižší priorita)
• D: Debug
• I: W: Warning
• E: Error
• A: Assert

Formát zprávy protokolu je:

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

Například následující zpráva protokolu má prioritu V a značku AuthZen:

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

PID znamená identifikátor procesu a TID je identifikátor vlákna; mohou být stejné, pokud existuje pouze jedno vlákno.

Nastavení úrovně protokolu

Nastavením úrovně protokolu můžete ovlivnit, kolik zpráv se zobrazí v logcatu. Můžete zobrazit všechny zprávy nebo jen zprávy označující nejzávažnější stavy.

Nezapomeňte, že logcat nadále shromažďuje všechny zprávy bez ohledu na nastavení úrovně protokolu. Nastavení pouze určuje, co logcat zobrazí.

V nabídce Úroveň protokolu vyberte jednu z následujících hodnot:

• Verbose: Zobrazí se všechny zprávy protokolu (výchozí hodnota).
• Debug (Ladění): Zobrazit zprávy protokolu ladění, které jsou užitečné pouze při vývoji, stejně jako zprávy na nižších úrovních v tomto seznamu.
• Info: Zobrazí očekávané zprávy protokolu pro běžné použití, stejně jako nižší úrovně zpráv v tomto seznamu.
• Upozornit: Zobrazí možné problémy, které ještě nejsou chybami, a také úrovně zpráv nižší v tomto seznamu.
• Chyba: Zobrazit problémy, které způsobily chyby, a také úrovně zpráv nižší v tomto seznamu.
• Assert: Zobrazí problémy, u kterých vývojář očekává, že by k nim nikdy nemělo dojít.

Vyhledávání zpráv logcatu

Prohledávání zpráv aktuálně zobrazených v logcatu:

1. Případně vyberte Regex, pokud chcete použít vyhledávací vzor regulárního výrazu.
2. Zadejte posloupnost znaků do vyhledávacího pole .

   Výstupní zobrazení logcatu se odpovídajícím způsobem změní.

3. Stisknutím klávesy Enter uložíte vyhledávací řetězec do nabídky během této relace.
4. Chcete-li vyhledávání zopakovat, vyberte jej z nabídky vyhledávání. Podle potřeby vyberte nebo zrušte výběr možnosti Regex (nastavení se nepamatuje).

Filtr zpráv logcatu

Jedním ze způsobů, jak omezit výstup protokolu na zvládnutelnou úroveň, je jeho omezení pomocí filtru.

Poznámka: Filtr se vztahuje na celou historii logcatu, nejen na zprávy aktuálně zobrazené v logcatu. Ujistěte se, že ostatní možnosti zobrazení jsou vhodně nastaveny, abyste mohli zobrazit výstup filtru, který chcete zkoumat.

Definování a použití filtru:

1. V nabídce filtru vyberte možnost filtru:
   • Zobrazit pouze vybranou aplikaci: Zobrazit pouze zprávy vytvořené kódem aplikace (výchozí nastavení). Logcat filtruje zprávy protokolu pomocí PID aktivní aplikace.
   • Žádné filtry: Nepoužije žádné filtry. Logcat zobrazí všechny zprávy protokolu ze zařízení bez ohledu na to, který proces jste vybrali.
   • Upravit konfiguraci filtrů: Vytvoření nebo úprava vlastního filtru. Můžete například vytvořit filtr pro zobrazení zpráv protokolu ze dvou aplikací současně.

   Po definování filtrů je můžete také vybrat v nabídce. Chcete-li je z nabídky odstranit, odstraňte je.

2. Pokud jste vybrali možnost Upravit konfiguraci filtru, vytvořte nebo upravte filtr:
   1. Zadejte parametry filtru v dialogovém okně Vytvořit nový filtr Logcat:
      • Název filtru: Zadejte název filtru, který chcete definovat, nebo jej vyberte v levém podokně, chcete-li upravit existující filtr. Název může obsahovat pouze malá písmena, podtržítka a číslice.
      • Značka protokolu: Zadejte název filtru: Volitelně zadejte značku. Další informace naleznete v části Formát zprávy logcat.
      • Zprávu protokolu: Volitelně zadejte text zprávy protokolu. Další informace naleznete v části Formát zprávy logcat.
      • Název balíčku: Volitelně zadejte název balíčku. Další informace naleznete v části Formát zprávy logcat.
      • PID: Volitelně zadejte ID procesu. Další informace naleznete v části Formát zprávy logcat.
      • Úroveň protokolu: Volitelně vyberte úroveň protokolu. Další informace naleznete v části Nastavení úrovně protokolu.
      • Regex: Tuto možnost vyberte, chcete-li pro daný parametr použít syntaxi regulárního výrazu.
   2. Kliknutím na tlačítko + přidáte definici filtru do levého podokna.

      Chcete-li filtr odebrat, vyberte jej v levém podokně a klikněte na tlačítko -.

   3. Po dokončení klikněte na tlačítko OK.

Pokud si myslíte, že nevidíte požadované zprávy protokolu, zkuste vybrat možnostŽádné filtry a vyhledat konkrétnízprávy protokolu.

Číst zprávy o vybírání odpadu

Někdy se při události vybírání odpadu vypíší do protokolu logcat.

Podrobnější informace o paměti aplikace získáte pomocí nástrojeMemory Profiler.

Zprávy logu Dalvik

V Dalviku (ale ne v ART) se při každém GC do logcatu vypíší následující informace:

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

Příklad:

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

GC Reason Co vyvolalo GC a o jaký druh sběru se jedná. Důvody, které se mohou objevit, zahrnují:GC_CONCURRENTSouběžné GC, které uvolňuje paměť, když se začíná zaplňovat halda.GC_FOR_MALLOCGC bylo způsobeno tím, že se vaše aplikace pokusila alokovat paměť, když už byla halda plná, takže systém musel zastavit vaši aplikaci a získat paměť zpět.GC_HPROF_DUMP_HEAPGC, ke kterému došlo, když jste požádali o vytvoření souboru HPROF pro analýzu vaší haldy.GC_EXPLICITExplicitní GC, například když zavolátegc()(jehož volání byste se měli vyhnout a místo toho důvěřovat GC, že se spustí v případě potřeby).GC_EXTERNAL_ALLOCK tomu dochází pouze na úrovni API 10 a nižší (novější verze alokují vše v haldě Dalvikheap). GC pro externě alokovanou paměť (jako jsou data pixelů uložená vnativní paměti nebo bajtové buffery NIO). Amount freed Množství paměti získané zpět z tohoto GC. Statistika haldy Procento volné haldy a (počet živých objektů)/(celková velikost haldy). Statistika externí paměti Externě alokovaná paměť na úrovni API 10 a nižší (množství alokované paměti) / (limit, při kterém dojde ke sběru). Doba pauzy Větší haldy budou mít větší dobu pauzy. Současné doby pauzy ukazují dvě pauzy: jednu nazačátku kolekce a druhou ke konci.

Při hromadění těchto zpráv protokolu si dávejte pozor na nárůst statistik haldy (hodnota3571K/9991K ve výše uvedeném příkladu). Pokud se tato hodnota stále zvyšuje, může se jednat o únik paměti.

Zprávy logu ART

Na rozdíl od Dalviku ART neloguje zprávy pro GC, které nebyly explicitně vyžádány. GC se tisknou pouze tehdy, když jsou považovány za pomalé. Přesněji řečeno, pokud pauza GC přesáhne 5 ms nebotrvání GC přesáhne 100 ms. Pokud aplikace není ve stavu vnímání pauzy (například když je aplikace na pozadí, kde uživatel nemůže vnímat pauzu GC), pak není žádný z jejích GC považován za pomalý. Explicitní GC jsou logovány vždy.

ART do svých zpráv logu garbage collection zahrnuje následující informace:

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)

Příklad:

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 Co vyvolalo GC a o jaký druh kolekce se jedná. Důvody, které se mohou objevit, zahrnují:ConcurrentSouběžné GC, které nepozastavuje vlákna aplikace. Tento GC běží ve vlákně na pozadía nebrání alokacím.AllocGC bylo zahájeno, protože se vaše aplikace pokusila alokovat paměť, když už byla halda plná. V tomto případě došlo k garbage collection ve vlákně alokace.ExplicitO garbage collection výslovně požádala aplikace, například volánímgc()nebogc(). Stejně jako v Dalviku, i v ART je nejlepším postupem důvěřovat GC a pokud možno se vyhnout explicitnímu vyžádání GC. explicitní GC se nedoporučuje, protože blokuje alokující vlákno a zbytečně plýtvá cykly CPU. Explicitní GC by také mohly způsobit jank (zadrhávání, trhání nebo zastavení aplikace), pokud by způsobily preempci jiných vláken.NativeAllocShromažďování bylo způsobeno nativním tlakem na paměť z nativních alokací, jako jsou Bitmapy nebo alokační objektyRenderScriptu.CollectorTransitionKolekce byla způsobena přechodem na haldu; ten je způsoben změnou strategie GC za běhu (například když aplikace přechází mezi stavy vnímatelnými pauzou). Přechody sběru spočívají v kopírování všech objektůz prostoru se zálohovaným volným seznamem do prostoru s ukazatelem bump (nebo naopak).

Tento jev se vyskytuje pouze na zařízení s malou pamětí RAM před systémem Android 8.0když aplikace změní stavy procesu ze stavu vnímatelného pauzou (například když je aplikace v popředí, kde uživatel může vnímat pauzu GC) do stavu nevnímatelného pauzou (nebo naopak).

HomogeneousSpaceCompactHomogenní kompakce prostoru je kompakce z prostoru volného seznamu do prostoru volného seznamu, ke které obvykle dochází při přechodu aplikace do stavu procesu nevnímatelného pauzou. Hlavními důvody, proč se tak děje, jsou snížení využití paměti RAM a defragmentace haldy.DisableMovingGcToto není skutečný důvod GC, ale poznámka, že kolekce byla zablokována kvůli použitíGetPrimitiveArrayCritical. zatímco probíhá souběžná kompakce haldy. Obecně se použitíGetPrimitiveArrayCritical důrazně nedoporučuje kvůli jeho omezením při přesouvání kolektorů.HeapTrimNejedná se o důvod GC, ale o poznámku, že kolekce byla zablokována, dokud nedojde k dokončení trimování haldy. Název GC ART má různé různé GC, které se mohou spustit.Concurrent mark sweep (CMS)Kolektor celé haldy, který uvolňuje kolekce všech prostorů kromě prostoru obrazu.Concurrent partial mark sweepVětšinou celý heap collector, který sbírá všechny prostory kromě prostorů image a zygote.Concurrent sticky mark sweepGenerační kolektor, který může uvolnit pouze objekty alokované od posledního GC. Tento garbagecollection se spouští častěji než full nebo partial mark sweep, protože je rychlejší a má menší pauzy.Marksweep + semispaceNesouběžný kopírovací GC používaný pro přechody na haldu a také pro homogenní zhušťování prostoru (k defragmentaci haldy). Objects freed Počet objektů, které byly při tomto GC získány zpět z prostoru pro nevelké objekty. Uvolněná velikost Počet bajtů, které byly z tohoto GC získány zpět z nevelkého prostoru objektů. Uvolněné velké objekty Počet objektů v prostoru velkých objektů, které byly získány zpět z této sbírky odpadků. Large object size freed Počet bajtů v prostoru velkých objektů, které byly z této garbagecollection získány zpět. Statistika haldy Procento volných a (počet živých objektů)/(celková velikost haldy). Doba pauzy Obecně je doba pauzy úměrná počtu referencí na objekty, které byly změněny během běhu GC. V současné době mají GC ART CMS pouze jednu pauzu, a to ke konci GC. pohyblivé GC mají dlouhou pauzu, která trvá po většinu doby trvání GC.

Pokud v logcatu vidíte velké množství GC, hledejte nárůst ve statistikách haldy (hodnota25MB/38MB ve výše uvedeném příkladu). Pokud se tato hodnota stále zvyšuje a nikdy se nezdá, že by se zmenšovala, mohlo by se jednat o únik paměti. Případně pokud vidíte GC, které jsou z důvodu „Alloc“, pak již pracujete blízko kapacity haldy a v blízké budoucnosti můžete očekávat výjimkyOOM.