Android Log.v (), Log.d (), Log.i (), Log.w (), Log.e () - Her biri ne zaman kullanılır?


330

Farklı LogCatyöntemler:

Log.v(); // Verbose
Log.d(); // Debug
Log.i(); // Info
Log.w(); // Warning
Log.e(); // Error

Her Günlük Kaydı türünü kullanmak için uygun durumlar nelerdir? Belki biraz semantik olduğunu ve belki de gerçekten önemli olmadığını biliyorum, ancak LogCatAndroid Studio ve Eclipse'de filtrelemek için uygun zamanlarda uygun yöntemleri kullandığımı bilmek güzel olurdu.

Yanıtlar:


726

Ters sırayla gidelim:

  • Log.e : Bu, kötü şeyler olduğunda ortaya çıkar. Bu etiketi, catch ifadesinin içindeki gibi yerlerde kullanın. Sen biliyor bir o hata oluştu ve bu nedenle bir hata günlüğü ediyoruz.

  • Log.w : Gölgeli bir şeyin olduğundan şüpheleniyorsanız bunu kullanın. Hata modunda tamamen dolu olmayabilirsiniz, ancak bazı beklenmedik davranışlardan kurtuldunuz. Temel olarak, olmasını beklemediğiniz, ancak mutlaka bir hata olmayan şeyleri günlüğe kaydetmek için bunu kullanın. Bir çeşit "hey, bu oldu ve garip , içine bakmalıyız."

  • Log.i : Günlüğe yararlı bilgiler göndermek içinbunu kullanın. Örneğin: bir sunucuya başarıyla bağlandığınız. Temel olarak başarıları raporlamak için kullanın.

  • Log.d : Hata ayıklama amacıylakullanın. Programınızın tam akışını kaydedebilmek için bir grup mesaj yazdırmak istiyorsanız, bunu kullanın. Değişken değerlerin bir günlüğünü tutmak istiyorsanız, bunu kullanın.

  • Log.v : Günlük kaydı ile kesinlikle çıldırmak istediğinizde bunu kullanın. Herhangi bir nedenle uygulamanızın belirli bir kısmındaki her küçük şeyi günlüğe kaydetmeye karar verdiyseniz, Log.v etiketini kullanın.

Ve bonus olarak ...

  • Log.wtf : İşler kesinlikle, korkunç, kutsal saçmalık yanlış gittiğinde kullanın. Asla almamanız gerekenhataları yakaladığınız blokları biliyorsunuz... evet, eğer giriş yapmak istiyorsanız Log.wtf kullanın

Log.v, Verbosegünlük kaydı içindir. Olası her mantıksal işlemi çıkarmak istediğinizde kullandığınız şeydir.
slayton

2
Hey dostum! Sonunda kendimi Google'da bazı Android çalışmaları yaparken buldum. Bir şeylerin nasıl günlüğe kaydedileceğini anlamaya çalışırken bununla karşılaştım. :)
Gizemli

11
Log.wtfHatta birkaç kez kontrol ve gerçekten yüksek sesle güldü inanmıyordu .. Bence, tüm API'ları içinde böyle bir şey olmalıdır
MBH

57
wtf "Ne Korkunç Bir Başarısızlık" anlamına gelir
Abhishek

8
Bu yöntemi kim adlandırdı? Bu korkunç bir fikir. Eşyalarımı yalnızca 1 harf adıyla adlandırırsam ekibimin nasıl takdir edeceğini merak ediyorum. Eminim beni cehenneme gönderecekler mi?
SandRock

19

Farklı yöntemler öncelik göstergeleridir. Onları listeledikçe, en önemlisinden en önemlisine gidiyorlar. Kodunuzdaki günlükleri hata ayıklamak için onları nasıl eşlediğinizi, çalıştığınız bileşene veya uygulamaya ve Android'in farklı yapı lezzetlerine (eng, userdebug ve kullanıcı) nasıl davrandığına bağlı olduğunu düşünüyorum. Android'deki yerel armağanlarda oldukça fazla iş yaptım ve işte böyle yapıyorum. Doğrudan uygulamanız için geçerli olmayabilir, ancak bazı ortak zeminler olabilir. Açıklamam belirsiz görünüyorsa, bunun nedeni bir bilimden ziyade bir sanattır. Temel kuralım, olabildiğince verimli olmak, sistemin performansını öldürmeden bileşeninizde makul bir şekilde hata ayıklayabilmenizi sağlamak ve her zaman hataları kontrol etmek ve günlüğe kaydetmek.

V - Farklı aralıklarla veya bileşenimin işlediği olayların çıktıları. Ayrıca, bileşenimin aldığı veya gönderdiği mesajların / olayların yüklerinin çok ayrıntılı çıktıları.

D - Bileşenimde gerçekleşen küçük etkinliklerin yanı sıra bileşenimin aldığı veya gönderdiği iletilerin / etkinliklerin yükleri.

I - Bileşenimin aldığı veya gönderdiği tüm mesajların / etkinliklerin ve ayrıca yükümün bileşenimin çalışması için kritik olan önemli parçalarının başlığı.

W - Olağandışı veya şüpheli olan, ancak mutlaka bir hata olmayan her şey.

E - Hatalar, yani işler olması gerektiği gibi çalışırken gerçekleşmesi gerekmeyen şeyler.

İnsanların yaptığı en büyük hata, V, D ve I gibi şeyleri gereğinden fazla kullanmaları, ancak asla W veya E kullanmamalarıdır. bir mesajı oluştuğunda günlüğe kaydetmeniz ucuzdur. Öte yandan, birisi bir tuşa her bastığında bir Log.i () işlemi yaparsanız, paylaşılan günlük kaynağını kötüye kullanırsınız. Elbette sağduyunuzu kullanın ve kontrolünüz dışındaki (ağ hataları gibi) veya sıkı döngülerde bulunanlar için hata günlüklerine dikkat edin.

Belki Kötü

Log.i("I am here");

İyi

Log.e("I shouldn't be here");

Tüm bunları göz önünde bulundurarak, kodunuz "üretime hazır" durumuna ne kadar yaklaşırsa, kodunuz için temel günlük kaydı düzeyini o kadar kısıtlayabilirsiniz (alfada V, beta'da D, üretimde ve hatta üretimde W olması gerekir) ). Bazı basit kullanım durumlarını gözden geçirmeli ve daha kısıtlayıcı filtreleme uygularken neler olduğunu çoğunlukla anlayabilmeniz için günlükleri görüntülemelisiniz. Aşağıdaki filtreyle çalışırsanız, uygulamanızın ne yaptığını söyleyebilmeniz gerekir, ancak tüm ayrıntıları alamayabilirsiniz.

logcat -v threadtime MyApp:I *:S

6

Kaynak kodu bazı temel rehberlik sağlar:

Ayrıntı açısından, en azından en çoğuna kadar olan sıralama HATA, UYARI, BİLGİ, HATA AYIKLAMA, VERBOSE şeklindedir. Verbose, geliştirme haricinde asla bir uygulamada derlenmemelidir. Hata ayıklama günlükleri derlenir, ancak çalışma zamanında çıkarılır. Hata, uyarı ve bilgi günlükleri her zaman saklanır.

Daha fazla ayrıntı için Kurtis'in cevabı öldü. Sadece şunu ekleyeceğim: Kişisel olarak tanımlanabilir veya özel bilgileri INFO( WARN/ ERROR) üzerine veya üzerine kaydetmeyin . Aksi takdirde, hata raporları veya günlük kaydı içeren herhangi bir şey kirlenebilir.


5

LOG'u aşağıdaki gibi kullanabilirsiniz:

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)

örnek kod:

private static final String TAG = "MyActivity";
...
Log.i(TAG, "MyClass.getView() — get item number " + position);

3

Uygulamanızın temel olarak kendi günlüklerini filtrelemesini istiyorsanız, bu farklı günlük kaydı türlerinin amacı olduğunu düşünüyorum. Bu nedenle Ayrıntılı, uygulamanızda kesinlikle önemli olan her şeyi günlüğe kaydetmek olabilir, ardından hata ayıklama düzeyi ayrıntılı günlüklerin bir alt kümesini günlüğe kaydeder ve ardından Bilgi düzeyi hata ayıklama günlüklerinin bir alt kümesini günlüğe kaydeder. Hata günlüklerine indiğinizde, oluşabilecek her türlü hatayı günlüğe kaydetmek istersiniz. Bir şey uygulamanızdaki fana gerçekten çarptığında Fatal adlı bir hata ayıklama seviyesi de vardır.

Genel olarak haklısınız, temelde keyfi ve bilgi, karşı ve hata vb.


3

Bu soru zaten cevaplanmış olmasına rağmen, cevapta eksik örnekler olduğunu hissediyorum.

Bu nedenle buraya "Android Log Levels" adlı bir blog yazısında yazdıklarımı getireceğim

gereksiz sözlerle dolu

Günlük kaydı en düşük düzeydedir. Eğer giriş ile fındık gitmek istiyorsanız o zaman bu seviye ile gitmek. Verbose'u ne zaman ve Debug'ı ne zaman kullanacağımı hiç anlamadım. Aradaki fark bana çok keyfi geldi. Sonunda Android'in kaynak koduna işaret ettiğimde anladım¹ “Verbose, geliştirme dışında hiçbir zaman bir uygulamaya derlenmemelidir.” Şimdi benim için açık, ne zaman gelişiyor ve geliştirme sırasında size yardımcı olacak silinebilir günlükleri eklemek istediğinizde, üretime geçmeden önce tüm bu günlükleri silmenize yardımcı olacak ayrıntılı seviyeye sahip olmak yararlıdır.

Hata ayıklama

Hata ayıklama amaçlıdır. Bu, üretimde olması gereken en düşük seviyedir. Burada bulunan bilgiler gelişim sırasında yardımcı olmaktır. Çoğu zaman bu oturum açma üretimini devre dışı bırakırsınız, böylece daha az bilgi gönderilir ve bu sorun yalnızca sorun yaşıyorsanız etkinleştirilir. Uygulamanın sunucudan gönderdiği / aldığı tüm bilgileri hata ayıklamak için giriş yapmayı seviyorum (şifreleri günlüğe kaydetmemeye dikkat edin !!!). Bu, hatanın sunucuda veya uygulamada olup olmadığını anlamak için çok yararlıdır. Ayrıca önemli fonksiyonlara giriş ve çıkış kayıtları da yapıyorum.

Bilgi

Uygulamanın ilerlemesini vurgulayan bilgi mesajları için. Örneğin, uygulamanın başlatılması tamamlandığında. Kullanıcı etkinlikler ve parçalar arasında hareket ettiğinde bilgi ekleyin. Her bir API çağrısını günlüğe kaydedin, ancak URL, durum ve yanıt süresi gibi çok az bilgi kaydedin.

Uyarı

Potansiyel olarak zararlı bir durum olduğunda.

Bu günlük tecrübelerime göre zor bir seviyedir. Ne zaman potansiyel bir zararlı durumunuz var? Genel olarak veya sorun olmadığını veya bir hata olduğunu. Ben şahsen bu seviyeyi fazla kullanmıyorum. Ne zaman kullandığımın örnekleri genellikle birkaç kez bir şey olduğunda ortaya çıkar. Örneğin, bir kullanıcının şifresi 3 defadan fazla yanlış. Bunun nedeni, şifreyi 3 kez yanlış girmiş olması, sistemimizde kabul edilmeyen bir karakterle ilgili bir sorun olması olabilir. Ağ bağlantısı sorunları için de aynı şey geçerlidir.

Hata

Hata olayları. Uygulama, hatadan sonra da çalışmaya devam edebilir. Bu, örneğin bir tane almamam gereken bir boş gösterici aldığımda olabilir. Sunucunun yanıtı ayrıştırılırken bir hata oluştu. Sunucudan bir hata var.

WTF (Ne Korkunç Bir Hata)

Ölümcül, uygulamanın çıkmasına neden olacak ciddi hata olayları içindir. Android'de ölümcül gerçekte Hata seviyesidir, fark aynı zamanda fullstack'i eklemesidir.


2

Android Studio web sitesi (Bence) tür mesajların Kurtis' cevabı ile birlikte yararlı olabilir, farklı günlük düzeylerinden ne olacağını bazı tavsiyeler sağlanan geçenlerde vardır:

  • Ayrıntılı - Tüm günlük mesajlarını göster (varsayılan).
  • Hata Ayıkla - Yalnızca geliştirme sırasında yararlı olan hata ayıklama günlüğü iletilerinin yanı sıra bu listede daha düşük olan ileti düzeylerini gösterir.
  • Bilgi - Normal kullanım için beklenen günlük mesajlarını ve bu listede daha düşük mesaj düzeylerini gösterir.
  • uyarmak - Henüz hata olmayan olası sorunları ve bu listede daha düşük mesaj düzeylerini göster.
  • Error - Hatalara neden olan sorunları ve bu listede daha düşük mesaj düzeyini gösterir.
  • Assert - Geliştiricinin asla gerçekleşmemesi beklenen sorunları gösterin.
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.