विभिन्न LogCatविधियाँ हैं:
Log.v(); // Verbose
Log.d(); // Debug
Log.i(); // Info
Log.w(); // Warning
Log.e(); // Errorप्रत्येक प्रकार के लॉगिंग का उपयोग करने के लिए उपयुक्त परिस्थितियां क्या हैं? मुझे पता है कि शायद यह सिर्फ शब्दार्थ का एक छोटा सा हिस्सा है और शायद यह वास्तव में मायने नहीं रखता है, लेकिन LogCatएंड्रॉइड स्टूडियो और एक्लिप्स में फ़िल्टर करने के लिए , यह जानना अच्छा होगा कि मैं उचित समय पर उचित तरीकों का उपयोग कर रहा हूं।
जवाबों:
आइए रिवर्स ऑर्डर में जाएं:
Log.e : यह तब होता है जब खराब सामान होता है। इस टैग का उपयोग कैच स्टेटमेंट के अंदर जैसी जगहों पर करें। आप जानते हैं कि एक त्रुटि हुई है और इसलिए आप एक त्रुटि लॉग कर रहे हैं।
Log.w : इसका उपयोग तब करें जब आपको संदेह हो कि कुछ छायादार चल रहा है। आप पूरी तरह से त्रुटि मोड पर पूरी तरह से नहीं हो सकते हैं, लेकिन शायद आप कुछ अप्रत्याशित व्यवहार से उबर गए हैं। मूल रूप से, इस सामान को लॉग इन करने के लिए उपयोग करें जिसकी आपको उम्मीद नहीं थी लेकिन जरूरी नहीं कि यह एक त्रुटि हो। एक तरह से "हे, यह हुआ, और यह अजीब है , हमें इस पर गौर करना चाहिए।"
Log.i :लॉग मेंउपयोगी जानकारी पोस्ट करने के लिए इसका उपयोग करें। उदाहरण के लिए: कि आप सफलतापूर्वक एक सर्वर से जुड़े हैं। मूल रूप से इसका उपयोग सफलताओं की रिपोर्ट करने के लिए करते हैं।
Log.d : डीबगिंग उद्देश्यों केलिए इसका उपयोग करें। यदि आप संदेशों का एक गुच्छा प्रिंट करना चाहते हैं तो आप अपने प्रोग्राम के सटीक प्रवाह को लॉग इन कर सकते हैं, इसका उपयोग करें। यदि आप चर मानों का लॉग रखना चाहते हैं, तो इसका उपयोग करें।
Log.v : जब आप अपने लॉगिंग के साथ बिल्कुल पागल जाना चाहते हैं तो इसका उपयोग करें। यदि किसी कारण से आपने अपने ऐप के किसी विशेष भाग में हर छोटी चीज़ को लॉग करने का निर्णय लिया है, तो लॉग.व टैग का उपयोग करें।
और एक बोनस के रूप में ...
Log.wtfमैंने भी कई बार जाँच की और वास्तव में ज़ोर से हँसा .. मेरी राय में, सभी एपीआई को कुछ इस तरह से होना चाहिए
विभिन्न विधियाँ प्राथमिकता के संकेत हैं। जैसा कि आपने उन्हें सूचीबद्ध किया है, वे कम से कम सबसे महत्वपूर्ण हैं। मुझे लगता है कि आप अपने कोड में डिबग लॉग के लिए विशेष रूप से उन्हें कैसे मैप करते हैं यह उस घटक या ऐप पर निर्भर करता है जिस पर आप काम कर रहे हैं, साथ ही साथ एंड्रॉइड उन्हें विभिन्न बिल्ड फ़्लेवर (eng, userdebug, और उपयोगकर्ता) पर कैसे व्यवहार करता है। मैंने एंड्रॉइड में देशी डेमॉन में उचित मात्रा में काम किया है, और यह है कि मैं इसे कैसे करता हूं। यह सीधे आपके ऐप पर लागू नहीं हो सकता है, लेकिन कुछ सामान्य आधार हो सकते हैं। अगर मेरी व्याख्या अस्पष्ट लगती है, तो ऐसा इसलिए है क्योंकि इसमें से कुछ एक विज्ञान की तुलना में अधिक कला है। मेरा मूल नियम जितना संभव हो उतना कुशल होना है, सुनिश्चित करें कि आप सिस्टम के प्रदर्शन को मारे बिना अपने घटक को यथोचित डिबग कर सकते हैं, और हमेशा त्रुटियों की जांच कर सकते हैं और उन्हें लॉग इन कर सकते हैं।
V - राज्य के प्रिंटआउट विभिन्न अंतरालों पर, या मेरे घटक प्रक्रियाओं में होने वाली किसी भी घटना पर। संभवतः संदेश / घटनाओं के पेलोड के बहुत विस्तृत प्रिंटआउट जो मेरे घटक को प्राप्त होते हैं या भेजते हैं।
डी - मेरे घटक के साथ घटित होने वाली छोटी घटनाओं का विवरण, साथ ही संदेश / घटनाओं का पेलोड जो मेरा घटक प्राप्त करता है या भेजता है।
मैं - किसी भी संदेश / घटनाओं का शीर्षक जो मेरे घटक को प्राप्त या भेजता है, साथ ही पेलोड के किसी भी महत्वपूर्ण टुकड़े जो मेरे घटक के संचालन के लिए महत्वपूर्ण हैं।
डब्ल्यू - कुछ भी जो असामान्य या संदिग्ध है, लेकिन जरूरी नहीं कि वह त्रुटि हो।
ई - त्रुटियां, मतलब चीजें जो तब होनी चाहिए जब चीजें काम नहीं कर रही हैं जैसा कि उन्हें करना चाहिए।
सबसे बड़ी गलती जो मैं लोगों को देखता हूं, वह यह है कि वे V, D, और I जैसी चीजों का अत्यधिक उपयोग करते हैं, लेकिन कभी भी W या E. का उपयोग नहीं करते हैं। यदि कोई त्रुटि है, तो परिभाषा के अनुसार, ऐसा नहीं होना चाहिए, या केवल बहुत कम ही होना चाहिए, फिर यह अत्यंत है सस्ता जब आप एक संदेश लॉग इन होता है। दूसरी ओर, यदि हर बार कोई व्यक्ति किसी कुंजी को दबाता है तो आप Log.i () करते हैं, तो आप साझा लॉगिंग संसाधन का दुरुपयोग कर रहे हैं। बेशक, सामान्य ज्ञान का उपयोग करें और अपने नियंत्रण (जैसे नेटवर्क त्रुटियों) के बाहर की चीजों के लिए त्रुटि लॉग से सावधान रहें, या तंग छोरों में निहित हैं।
शायद बुरा
Log.i("I am here");अच्छा
Log.e("I shouldn't be here");यह सब ध्यान में रखते हुए, आपका कोड "उत्पादन के लिए तैयार" हो जाता है, जितना अधिक आप अपने कोड के लिए आधार लॉगिंग स्तर को प्रतिबंधित कर सकते हैं (आपको अल्फा में वी की आवश्यकता है, बीटा में डी की जरूरत है, मैं उत्पादन में, या संभवतः उत्पादन में भी डब्ल्यू। )। आपको कुछ सरल उपयोग मामलों के माध्यम से चलना चाहिए और लॉग को देखने के लिए सुनिश्चित करें कि आप अभी भी ज्यादातर समझ सकते हैं कि क्या हो रहा है क्योंकि आप अधिक प्रतिबंधक फ़िल्टरिंग लागू करते हैं। यदि आप नीचे दिए गए फ़िल्टर के साथ चलते हैं, तो आपको अभी भी यह बताने में सक्षम होना चाहिए कि आपका ऐप क्या कर रहा है, लेकिन शायद सभी विवरण नहीं मिले।
logcat -v threadtime MyApp:I *:Sस्रोत कोड कुछ बुनियादी मार्गदर्शन प्रदान करता है:
वर्बोसिटी के संदर्भ में, कम से कम से सबसे अधिक है ERROR, WARN, INFO, DEBUG, VERBOSE। वर्बोज़ को विकास के दौरान कभी भी एक आवेदन में संकलित नहीं किया जाना चाहिए। डिबग लॉग संकलित हैं, लेकिन रनटाइम पर छीन लिए गए हैं। त्रुटि, चेतावनी और सूचना लॉग हमेशा रखे जाते हैं।
अधिक विस्तार के लिए, कुर्तियों का उत्तर मृत है। मैं सिर्फ जोड़ना होगा: पर किसी भी व्यक्तिगत रूप से पहचान या निजी जानकारी लॉग न करें INFOया ऊपर ( WARN/ ERROR)। अन्यथा, बग रिपोर्ट या अन्य कुछ भी जिसमें लॉगिंग शामिल है, प्रदूषित हो सकती है।
आप लॉग का उपयोग कर सकते हैं जैसे:
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)उदाहरण कोड:
private static final String TAG = "MyActivity";
...
Log.i(TAG, "MyClass.getView() — get item number " + position);मुझे लगता है कि उन विभिन्न प्रकार के लॉगिंग का बिंदु यह है कि क्या आप चाहते हैं कि आपका ऐप मूल रूप से अपने लॉग को स्वयं फ़िल्टर करे। तो Verbose आपके ऐप में महत्व की सभी चीज़ों को पूरी तरह से लॉग इन कर सकता है, फिर डीबग स्तर वर्बोज़ लॉग का सबसेट लॉग करेगा, और उसके बाद Info लेवल डीबग लॉग का एक सबसेट लॉग करेगा। जब आप त्रुटि लॉग के लिए नीचे आते हैं, तो आप बस किसी भी तरह की त्रुटियों को लॉग इन करना चाहते हैं जो हो सकता है। वहाँ भी एक डीबग स्तर है जिसे घातक कहा जाता है जब कुछ वास्तव में आपके ऐप में प्रशंसक हिट करता है।
सामान्य तौर पर, आप सही कह रहे हैं, यह मूल रूप से मनमाना है, और आपको यह परिभाषित करना है कि डिबग लॉग बनाम सूचनात्मक, बनाम और त्रुटि, आदि क्या माना जाता है।
भले ही यह प्रश्न पहले से ही उत्तर दिया गया था लेकिन मुझे लगता है कि उत्तर में ऐसे उदाहरण गायब हैं जिनका उत्तर दिया गया था।
इसलिए मैं यहाँ एक ब्लॉग पोस्ट "एंड्रॉइड लॉग लेवल्स" में लिखी गई सामग्री लाऊंगा
वाचाल
लॉगिंग का निम्नतम स्तर है। यदि आप लॉगिंग के साथ पागल जाना चाहते हैं तो आप इस स्तर पर जाएं। मुझे कभी समझ नहीं आया कि कब वर्बोस का उपयोग करना है और कब डिबग का उपयोग करना है। अंतर मुझे बहुत मनमाना लग रहा था। एक बार जब मुझे Android Ver के स्रोत कोड की ओर इशारा किया गया तो मैंने इसे समझा "वर्बोज़ को कभी भी विकास के अलावा किसी अनुप्रयोग में संकलित नहीं किया जाना चाहिए।" अब यह मेरे लिए स्पष्ट है, जब भी आप विकास कर रहे हैं और डिलीट करने योग्य लॉग जोड़ना चाहते हैं जो विकास के दौरान आपकी मदद करते हैं तो क्रिया स्तर होना उपयोगी है इससे आपको उत्पादन में जाने से पहले इन सभी लॉग को हटाने में मदद मिलेगी।
डिबग
डिबगिंग उद्देश्यों के लिए है। यह सबसे निचला स्तर है जो उत्पादन में होना चाहिए। विकास के दौरान मदद करने के लिए यहां मौजूद जानकारी है। अधिकांश बार आप इस लॉग को उत्पादन में अक्षम कर देंगे ताकि कम जानकारी भेजी जाए और समस्या होने पर केवल इस लॉग को सक्षम करें। मुझे उन सभी सूचनाओं को डीबग करना पसंद है जो ऐप सर्वर से भेजता / प्राप्त करता है (ध्यान रखें कि पासवर्ड लॉग न करें))। यह समझने में बहुत मददगार है कि बग सर्वर या ऐप में है या नहीं। मैं महत्वपूर्ण कार्यों में प्रवेश करने और बाहर निकलने के भी लॉग बनाता हूं।
जानकारी
सूचना के संदेशों के लिए जो अनुप्रयोग की प्रगति को उजागर करते हैं। उदाहरण के लिए, जब ऐप को शुरू करना समाप्त हो जाता है। जानकारी जोड़ें जब उपयोगकर्ता गतिविधियों और टुकड़े के बीच चलता है। प्रत्येक एपीआई कॉल को लॉग इन करें लेकिन यूआरएल, स्थिति और प्रतिक्रिया समय जैसी थोड़ी जानकारी।
चेतावनी
जब संभावित रूप से हानिकारक स्थिति होती है।
यह लॉग मेरे अनुभव में एक मुश्किल स्तर है। आपके पास संभावित हानिकारक स्थिति कब है? सामान्य तौर पर या कि यह ठीक है या यह एक त्रुटि है। मैं व्यक्तिगत रूप से इस स्तर का अधिक उपयोग नहीं करता हूं। जब मैं इसका उपयोग करता हूं तो इसके उदाहरण आमतौर पर तब होते हैं जब सामान कई बार होता है। उदाहरण के लिए, उपयोगकर्ता के पास 3 बार से अधिक गलत पासवर्ड है। ऐसा इसलिए हो सकता है क्योंकि उसने 3 बार गलत तरीके से पासवर्ड डाला है, यह इसलिए भी हो सकता है क्योंकि एक ऐसे चरित्र की समस्या है जो हमारे सिस्टम में स्वीकार नहीं किया जा रहा है। वही नेटवर्क कनेक्शन समस्याओं के साथ जाता है।
त्रुटि
त्रुटि घटनाओं। त्रुटि के बाद भी एप्लिकेशन चल सकता है। यह उदाहरण के लिए हो सकता है जब मुझे एक शून्य सूचक मिलता है जहां मुझे एक प्राप्त नहीं होना चाहिए। सर्वर की प्रतिक्रिया पार्स करने में त्रुटि हुई। सर्वर से एक त्रुटि मिली।
डब्ल्यूटीएफ (एक भयानक विफलता क्या है)
घातक गंभीर घटनाओं के लिए है जो एप्लिकेशन को बाहर निकलने के लिए प्रेरित करेगा। एंड्रॉइड में घातक वास्तव में त्रुटि स्तर है, अंतर यह है कि यह फुलस्टैक भी जोड़ता है।
एंड्रॉयड स्टूडियो वेबसाइट हाल ही में किया गया है (मुझे लगता है कि) कुछ सलाह क्या संदेशों के तरह अलग लॉग स्तरों कि कुर्तियों 'जवाब के साथ उपयोगी हो सकता है से उम्मीद करने के लिए प्रदान की है:
Verboseलॉगिंग के लिए है। जब आप हर संभव लॉजिकल ऑपरेशन को आउटपुट करना चाहते हैं तो इसका उपयोग करें।