Som Android-utvecklare vet alla att logganalyser är en del av utvecklingen och att vi stöter på det från tid till annan.
Men logganalys är den största utmaningen för kodhållare eller supporttekniker.
När någon Android-produkt lanseras på marknaden och kunderna börjar använda den. Då börjar det komma buggar/problem i verkliga scenarier och det är supportteknikerns/projektunderhållsteknikerns huvuduppgift att analysera buggen/problemet med hjälp av de loggfiler som tillhandahålls.
Först börjar vi med vilken typ av logg som finns i Androids ekosystem:-
- Applikationslogg
- Systemlogg
- Händelselogg
- Radielogg
Androids loggsystem består av:
- En kärndrivrutin och kärnbuffertar för lagring av loggmeddelanden
- C-, C++- och Javaklasser för att göra loggposter och få tillgång till loggmeddelanden.
- Logcat (ett fristående program för att visa loggmeddelanden )
- DDMS (möjlighet att visa och filtrera loggmeddelanden från värddatorn)
Android Log Buffer/container
- main – huvudprogrammets logg
- events – för information om systemhändelser
- radio – för radio och telefon-relaterad information
- system – en logg för systemmeddelanden på låg nivå och felsökning
Vad loggmeddelandet innehåller:-
Varje meddelande i loggen består av
- En tagg som anger den del av systemet eller programmet som meddelandet kom från
- En tidsstämpel (vid vilken tidpunkt meddelandet kom)
- Den loggnivå för meddelandet (eller prioritet för den händelse som meddelandet representerar) och
- själva loggmeddelandet (detaljerad beskrivning av fel eller undantag eller information etc)
Vad varje loggtyp innehåller:-
1. Applikationslogg
- använd android.util.Log-klassmetoder för att skriva meddelanden av olika prioritet i loggen
- Java-klasser deklarerar sin tagg statiskt som en sträng, som de överlämnar till loggmetoden
- Den loggmetod som används anger meddelandets ”allvarlighetsgrad” (eller loggnivå)
- Meddelanden kan filtreras efter tagg eller prioritet när loggarna bearbetas av hämtningsverktyg (logcat)
2. Systemlogg
- Använd android.util.Slog-klassen för att skriva ett meddelande med olika prioritet med tillhörande meddelanden
- Många Android-ramklasser använder systemloggen för att hålla sina meddelanden åtskilda från (eventuellt bullriga) programloggmeddelanden
- Ett formaterat meddelande levereras via C/C++-biblioteket ner till kärndrivrutinen, som lagrar meddelandet i lämplig buffert(systembuffert)
3. Händelselogg
- Händelseloggmeddelanden skapas med hjälp av klassen android.util.EventLog, som skapar binärt formaterade loggmeddelanden.
- Loggposter består av binära taggkoder, följt av binära parametrar.
- Meddelandets taggkoder lagras i systemet vid: /system/etc/event-log-tags.
- Varje meddelande har strängen för loggmeddelandet samt koder som anger de värden som är associerade med (lagrade med) den posten.
4. Radiologg
- Används för radio- och telefon(modem)-relaterad information
- Loggposter består av binära taggar kod och meddelande för nätverksinformation
- Loggningssystemet dirigerar automatiskt meddelanden med specifika taggar in i radiobuffert
Loggformat på Android
Nedan följer vanligt loggformat i android
tv_sec tv_nsec priority pid tid tag messageLen Message
tag: log tag
tv_sec & tv_nsec: tidsstämpel för loggmeddelanden
pid: process-id för var loggmeddelanden kommer ifrån
tid: tråd-ID
Prioritetsvärdet är ett av följande teckenvärden, ordnat från lägsta till högsta prioritet:
V – Verbose (lägsta prioritet)*
D – Debug*
I – Info*
W – Warning*
E – Error*
F – Fatal*
S – Silent (högsta prioritet, där inget skrivs ut)
Log-File locations
Det finns flera kataloger där loggfiler (inklusive loggfiler från krascher) lagras och de är inte standardiserade(i.dvs. vissa kan vara ROM-specifika). Jag lägger några vanliga här.
- /data/anr : Dalvik skriver stacktraces här på ANR, dvs. ”Application Not Responding” aka ”Force-Close”
- /data/dontpanic : innehåller en del kraschloggar inklusive spår
- /data/kernelpanics :- Lagrar ”kernel panic” relaterade loggar
- /data/tombstones :- kan innehålla flera tombstone_nn-filer (nn är ett nummer från 0 till 10 och efter 10 upprepas det igen)
’Log’ kommandoradsverktyg
För att fånga upp loggar från android-enheter/emulatorn Nedan finns ett kommandoradsverktyg. I verkliga projekt finns det program/verktyg för loggupptagning som används för att fånga loggarna på användarenheten och dela dem tillbaka till utvecklaren/underhållaren för analys.
- adb logcat (visar alla typloggar för det aktuella androidsystemet
- adb logcat -v threadtime (det kommer att inkludera datum och tid)
- adb logcat -v threadtime > logfile.txt (lagra loggar i logfile.txt)
Användbara filtermönster
Du kan använda nedanstående filter i ditt adb-kommando för att filtrera loggar. Du kan också använda det här filtret för att söka i din loggfil (loggar som tillhandahålls av användarenheten).
- adb logcat -f <output_file> Spara alla loggar i en fil
- adb logcat ”*:E” Hämta alla fel och fatals
- adb logcat | grep -i ”foo.example.” #hämta alla loggar som rör ”foo.example.*” tagname
- adb logcat ”application_or_tag_name:*” ”*:S” Hämta alla loggar efter programnamn
- adb logcat -b events ”gsm_service_state_change” ”*:S” Hämta alla GSM-statusförändringar
- adb logcat -b radio Hämta alla radiohändelser
Logganalys
Till nu har vi fått all grundläggande exponering av Androids loggningssystem. Nu är det dags att analysera de loggar som kommer från din applikation eller slutanvändare. Här kan vi dela upp logganalysen i två delar
- Debug Log:- loggfil som kommer under utvecklings- och testfasen
- Produktionslogg:- Loggfil som kommer direkt från slutanvändaren.
Du kan väl gissa vilken som är den svåra produktionsloggen? Så vad är det bästa tillvägagångssättet för att felsöka och få den önskade informationen från de fångade loggarna? Som jag diskuterade ovan kan vi göra det genom att använda
- ”Användbara filtermönster” och
- Med hjälp av något verktyg (t.ex. LogRabit, GoogleLogTool och SonyLogTool)
Så i sista Android-logganalysen är kontinuerlig inlärning och användning av din erfarenhetsprocess. Personligen analyserade jag loggar via relevanta filter och verktyg med min tidigare erfarenhet.
Men en sak är bra Varje androidanalys (slutanvändarproblem/bugglogg) ger dig ny inlärning och erfarenhet. Så fortsätt med det och njut av ditt liv som kodare och underhållare av androidsystem😎😎😎😎
.