Android fejlesztőként mindenki tudja, hogy a naplóelemzés a fejlesztés egyik fázisa, és időről időre találkozunk vele.
De a naplóelemzés a fő kihívást jelentő dolog a kódfenntartó vagy a támogatási mérnök számára.
Mihelyt bármilyen Android termék elindul a piacon, és az ügyfelek elkezdik használni. Akkor a valós forgatókönyv hibák / problémák kezdenek jönni, és ez a fő feladat a Support Engineer / projekt karbantartó mérnök elemzése a hiba / probléma a megadott naplókkal.
Először is kezdjük az Android Eco-rendszerben rendelkezésre álló naplótípusokkal: –
- Application Log
- System Log
- Event Log
- Radio Log
Android naplózási rendszer a következőkből áll:
- egy kernel meghajtó és kernel pufferek a naplóüzenetek tárolására
- C, C++ és Java osztályok a naplóbejegyzések készítésére és a naplóüzenetek elérésére.
- Logcat (önálló program a naplóüzenetek megtekintésére )
- DDMS (a naplóüzenetek megtekintésének és szűrésének lehetősége a gazdagépről)
Android Log Buffer/container
- main – a fő alkalmazás naplója
- events – a rendszer eseményinformációkhoz
- radio – a rádió és telefon-kapcsolódó információkhoz
- system – az alacsony szintű rendszerüzenetek és hibakeresés naplója
Mit tartalmaz a naplóüzenet:-
A napló minden egyes üzenete
- Egy címkéből áll, amely a rendszer vagy az alkalmazás azon részét jelzi, ahonnan az üzenet érkezett
- Egy időbélyegzőből (mikor érkezett ez az üzenet)
- Az üzenet naplózási szintje (vagy az üzenet által képviselt esemény prioritása) és
- Maga a naplóüzenet (a hiba, kivétel vagy információ részletes leírása stb.)
Mit tartalmaznak az egyes naplótípusok:-
1. Application log
- use android.util.Log osztály metódusait a különböző prioritású üzenetek naplóba írásához
- A Java osztályok statikusan deklarálják a tagjüket egy stringként, amit átadnak a log metódusnak
- A használt log metódus jelzi az üzenet “súlyosságát” (vagy naplózási szintjét)
- Az üzeneteket tag vagy prioritás szerint lehet szűrni, amikor a naplókat visszakeresési eszközökkel (logcat)
2. Rendszer napló
- Az android.util.Slog osztályt, hogy különböző prioritású üzenetet írjon a hozzá tartozó üzenetekkel
- Sok Android keretrendszer osztály használja a rendszernaplót, hogy üzeneteiket elkülönítse az (esetleg zajos) alkalmazásnapló üzeneteitől
- A formázott üzenet a C/C++ könyvtáron keresztül jut le a kernel meghajtóhoz, amely az üzenetet a megfelelő pufferben (system buffer)
3. Eseménynapló
- Az eseménynaplók üzenetei az android.util.EventLog osztály segítségével jönnek létre, amely bináris formátumú naplóüzeneteket hoz létre.
- A naplóbejegyzések bináris címkódokból állnak, amelyeket bináris paraméterek követnek.
- Az üzenet címkódjai a rendszerben tárolódnak a: /system/etc/event-log-tags.
- Minden üzenet tartalmazza a naplóüzenet karakterláncát, valamint az adott bejegyzéshez kapcsolódó (tárolt) értékeket jelző kódokat.
4. Rádió napló
- Rádióval és telefonnal (modemmel) kapcsolatos információkhoz
- A naplóbejegyzések bináris címkék kódjából és üzenetből állnak a hálózati információkhoz
- A naplórendszer automatikusan a rádió pufferébe irányítja az adott címkékkel ellátott üzeneteket
Napló formátum Androidon
az alábbiakban az androidban szokásos napló formátum
tv_sec tv_nsec priority pid tid tag messageLen Message
tag: tv_nsec & tv_nsec: a naplóüzenetek időbélyege
pid: a folyamat azonosítója, ahonnan a naplóüzenetek származnak
tid: a szál azonosítója
A prioritás értéke a következő karakteres értékek egyike, a legalacsonyabbtól a legmagasabb prioritásig sorrendben:
V – Verbose (legalacsonyabb prioritás)*
D – Debug*
I – Info*
W – Warning*
E – Error*
F – Fatal*
S – Silent (legmagasabb prioritás, amire soha semmi nem kerül kiírásra)
Log-fájlok helye
Már több könyvtár van, ahol a naplók (köztük az összeomlásokból származó) tárolódnak, és ezek nem szabványosak(i.azaz egyesek ROM-specifikusak lehetnek). Ide teszek néhány közöset.
- /data/anr : A Dalvik ide írja a stack traces-t az ANR-en, ill. “Application Not Responding” aka “Force-Close”
- /data/dontpanic : tartalmaz néhány összeomlási naplót, beleértve a nyomokat is
- /data/kernelpanics :- Tárolja a “kernel panic” kapcsolatos naplókat
- /data/tombstones :- több tombstone_nn fájlt is tartalmazhat (nn egy szám 0-tól 10-ig és 10 után ismétlés)
‘Log’ parancssori eszköz
Az androidos eszközök/emulátor naplóinak rögzítéséhez Az alábbiakban néhány parancssori eszköz. A valós életbeli projektekben vannak naplórögzítő alkalmazások / eszközök, amelyeket a felhasználói eszközön lévő naplók rögzítésére és a fejlesztőnek / karbantartónak elemzés céljából történő megosztására használnak.
- adb logcat (megmutatja az összes típusú naplót az aktuális android rendszerhez
- adb logcat -v threadtime (tartalmazza a dátumot és az időt)
- adb logcat -v threadtime > logfile.txt (A naplók tárolása a logfile.txt-ben)
Hasznos szűrő minták
A naplók szűrésére az alábbi szűrőt használhatja az adb parancsban. Ezt a szűrőt használhatja a naplófájlok keresésére is(a felhasználói eszköz által biztosított naplók).
- adb logcat -f <output_file> Az összes naplófájl mentése egy fájlba
- adb logcat “*:E” Az összes hiba és fatal
- adb logcat | grep -i “foo.example.” #kapja az összes naplót a “foo.example.*”-hoz kapcsolódóan tagname
- adb logcat “application_or_tag_name:*” “*:S” Get all logs by application name
- adb logcat -b events “gsm_service_state_change” “*:S” Get all GSM state changes
- adb logcat -b radio Get all Radio events
Log Analysis
Till now we get all the fundamental exposure of the Android Logging System. Most itt az ideje, hogy elemezzük az alkalmazásból vagy a végfelhasználótól érkező naplókat. Itt két részre oszthatjuk a naplóelemzést
- Debug Log:- a fejlesztési és tesztelési fázisban érkező naplófájlok
- Production Log:- a közvetlenül a végfelhasználótól érkező naplófájlok.
Szóval találd ki, melyik a nehéz Production one Igaz? Tehát mi a legjobb megközelítés a hibakereséshez és a kívánt információk megszerzéséhez a rögzített naplókból? Ahogy fentebb tárgyaltam, Megtehetjük a
- “Hasznos szűrőminták” és
- Néhány eszköz használatával (például LogRabit, GoogleLogTool és SonyLogTool)
Tehát az utolsó Android naplóelemzés folyamatos tanulás és a tapasztalati folyamat felhasználása. Személy szerint én elemzett naplók keresztül releváns szűrő és eszköz a múltbeli tapasztalataim.
De egy dolog jó Minden android elemzés (végfelhasználói probléma / hiba napló) ad új tanulást és tapasztalatot. Szóval folytasd ezt és élvezd az életed, mint az android rendszer kódolója és karbantartója😎😎😎😎