Android Log.v (), Log.d (), Log.i (), Log.w (), Log.e () - เมื่อใดที่จะใช้แต่ละอัน?

LogCatวิธีการที่แตกต่างกันคือ:

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

สถานการณ์ที่เหมาะสมในการใช้การบันทึกแต่ละประเภทมีอะไรบ้าง ฉันรู้ว่าบางทีมันอาจเป็นแค่ความหมายเล็กน้อยและบางทีมันก็ไม่สำคัญ แต่สำหรับการLogCatกรองใน Android Studio และ Eclipse จะเป็นการดีที่รู้ว่าฉันใช้วิธีการที่เหมาะสมในเวลาที่เหมาะสม

ไปในลำดับที่กลับกัน:

• Log.e : สิ่งนี้มีไว้สำหรับสิ่งที่ไม่ดีเกิดขึ้น ใช้แท็กนี้ในสถานที่เช่นในคำสั่ง catch คุณรู้ว่ามีข้อผิดพลาดเกิดขึ้นและคุณกำลังบันทึกข้อผิดพลาด

• Log.w : ใช้สิ่งนี้เมื่อคุณสงสัยว่ามีบางสิ่งไม่เหมาะสมเกิดขึ้น คุณอาจยังไม่เต็มในโหมดข้อผิดพลาด แต่บางทีคุณอาจกู้คืนจากพฤติกรรมที่ไม่คาดคิดบางอย่าง โดยทั่วไปให้ใช้สิ่งนี้เพื่อบันทึกสิ่งที่คุณไม่คาดว่าจะเกิดขึ้น แต่ไม่จำเป็นต้องเป็นข้อผิดพลาด เป็นเหมือน "เฮ้นี่มันเกิดขึ้นแล้วและมันแปลกเราควรมองเข้าไปในนั้น"

• Log.i : ใช้สิ่งนี้เพื่อโพสต์ข้อมูลที่เป็นประโยชน์ลงในบันทึก ตัวอย่างเช่น: คุณเชื่อมต่อกับเซิร์ฟเวอร์สำเร็จแล้ว โดยทั่วไปใช้เพื่อรายงานความสำเร็จ

• Log.d : ใช้สำหรับการแก้จุดบกพร่องวัตถุประสงค์ หากคุณต้องการพิมพ์ข้อความจำนวนมากเพื่อให้คุณสามารถบันทึกขั้นตอนการทำงานของโปรแกรมได้ หากคุณต้องการเก็บบันทึกค่าตัวแปรให้ใช้สิ่งนี้

• Log.v : ใช้สิ่งนี้เมื่อคุณต้องการที่จะถั่วอย่างแน่นอนด้วยการเข้าสู่ระบบของคุณ หากด้วยเหตุผลบางอย่างที่คุณตัดสินใจที่จะบันทึกทุกสิ่งในส่วนหนึ่งของแอปของคุณให้ใช้แท็ก Log.v

และเป็นโบนัส ...

• Log.wtf : ใช้สิ่งนี้เมื่อสิ่งต่าง ๆ เกิดขึ้นอย่างน่ากลัวผิดศีลธรรม คุณรู้ว่าบล็อก catch เหล่านั้นที่คุณจับข้อผิดพลาดซึ่งคุณไม่ควรได้รับ ... ใช่ถ้าคุณต้องการบันทึกให้ใช้ log.wtf

วิธีการที่แตกต่างกันบ่งบอกถึงลำดับความสำคัญ ในขณะที่คุณระบุพวกเขาพวกเขาจะจากน้อยไปสำคัญที่สุด ฉันคิดว่าวิธีการที่คุณแมปพวกเขาโดยเฉพาะเพื่อตรวจแก้จุดบกพร่องบันทึกในรหัสของคุณขึ้นอยู่กับส่วนประกอบหรือแอพที่คุณกำลังทำงานเช่นเดียวกับวิธีที่ Android ปฏิบัติต่อพวกเขาในการสร้างรสชาติที่แตกต่าง (อังกฤษ userdebug ฉันใช้งาน daemons ดั้งเดิมใน Android แล้วและนี่เป็นวิธีที่ฉันทำ อาจใช้ไม่ได้กับแอปของคุณโดยตรง แต่อาจมีสาเหตุบางประการ หากคำอธิบายของฉันฟังดูคลุมเครือนั่นเป็นเพราะบางสิ่งนี้เป็นศิลปะมากกว่าวิทยาศาสตร์ กฎพื้นฐานของฉันคือให้มีประสิทธิภาพมากที่สุดตรวจสอบให้แน่ใจว่าคุณสามารถดีบักส่วนประกอบของคุณอย่างสมเหตุสมผลโดยไม่ทำลายประสิทธิภาพของระบบและตรวจสอบข้อผิดพลาดและบันทึกพวกเขาอยู่เสมอ

V - พิมพ์ของรัฐในช่วงเวลาที่แตกต่างกันหรือตามเหตุการณ์ใด ๆ ที่เกิดขึ้นซึ่งองค์ประกอบของฉันกระบวนการ อาจเป็นงานพิมพ์ที่มีรายละเอียดมากของเพย์โหลดของข้อความ / เหตุการณ์ที่องค์ประกอบของฉันได้รับหรือส่ง

D - รายละเอียดของเหตุการณ์เล็ก ๆ น้อย ๆ ที่เกิดขึ้นภายในองค์ประกอบของฉันเช่นเดียวกับน้ำหนักบรรทุกของข้อความ / เหตุการณ์ที่องค์ประกอบของฉันได้รับหรือส่ง

I - ส่วนหัวของข้อความ / เหตุการณ์ใด ๆ ที่องค์ประกอบของฉันได้รับหรือส่งรวมถึงส่วนสำคัญใด ๆ ของส่วนของข้อมูลซึ่งมีความสำคัญต่อการทำงานของส่วนประกอบของฉัน

W - อะไรก็ตามที่เกิดขึ้นที่ผิดปกติหรือน่าสงสัย แต่ไม่จำเป็นต้องเป็นข้อผิดพลาด

E - ข้อผิดพลาดหมายถึงสิ่งที่ไม่ควรเกิดขึ้นเมื่อสิ่งต่าง ๆ ทำงานได้อย่างที่ควรจะเป็น

ความผิดพลาดที่ใหญ่ที่สุดที่ฉันเห็นคนทำคือพวกเขาใช้มากเกินไปเช่น V, D และฉัน แต่ไม่เคยใช้ W หรือ E หากมีข้อผิดพลาดตามคำจำกัดความไม่ควรเกิดขึ้นหรือควรเกิดขึ้นน้อยมาก ประหยัดสำหรับคุณที่จะบันทึกข้อความเมื่อมันเกิดขึ้น ในทางกลับกันถ้าทุกครั้งที่มีคนกดปุ่มที่คุณใช้ Log.i () คุณจะใช้ทรัพยากรการบันทึกที่ใช้ร่วมกันในทางที่ผิด แน่นอนใช้สามัญสำนึกและระมัดระวังบันทึกข้อผิดพลาดสำหรับสิ่งที่อยู่นอกเหนือการควบคุมของคุณ (เช่นข้อผิดพลาดเครือข่าย) หรือที่มีอยู่ในลูปแน่น

อาจจะไม่ดี

Log.i("I am here");

ดี

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

เมื่อคำนึงถึงสิ่งนี้ยิ่งรหัสของคุณใกล้ถึง "พร้อมใช้การผลิต" ยิ่งคุณสามารถ จำกัด ระดับการบันทึกฐานสำหรับรหัสของคุณได้มากขึ้นเท่านั้น (คุณต้องการ V ในอัลฟ่า, D ในเบต้า, ฉันกำลังผลิตหรืออาจเป็น W ) คุณควรใช้กรณีการใช้งานง่าย ๆ และดูบันทึกเพื่อให้แน่ใจว่าคุณยังสามารถเข้าใจสิ่งที่เกิดขึ้นในขณะที่คุณใช้การกรองที่เข้มงวดมากขึ้น หากคุณใช้ตัวกรองด้านล่างคุณควรจะสามารถบอกได้ว่าแอปของคุณกำลังทำอะไรอยู่ แต่อาจไม่ได้รับรายละเอียดทั้งหมด

logcat -v threadtime MyApp:I *:S

ซอร์สโค้ดมีคำแนะนำพื้นฐาน:

ลำดับในแง่ของการใช้คำฟุ่มเฟื่อยจากน้อยไปหามากที่สุดคือข้อผิดพลาดคำเตือนข้อมูลข้อบกพร่องคำต่อคำ ไม่ควรรวบรวมข้อมูล verbose ลงในแอปพลิเคชันยกเว้นในระหว่างการพัฒนา บันทึกการดีบักจะถูกคอมไพล์ แต่ถูกตัดออกตอนรันไทม์ บันทึกข้อผิดพลาดคำเตือนและข้อมูลจะถูกเก็บไว้เสมอ

สำหรับรายละเอียดเพิ่มเติมคำตอบของ Kurtis นั้นตายแล้ว ฉันจะเพิ่ม: อย่าบันทึกข้อมูลส่วนตัวหรือข้อมูลส่วนตัวที่สามารถระบุได้ที่INFOหรือสูงกว่า ( WARN/ ERROR) มิฉะนั้นรายงานข้อผิดพลาดหรือสิ่งอื่นใดที่มีการบันทึกอาจมีการปนเปื้อน

คุณสามารถใช้ LOG เช่น:

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 อาจบันทึกทุกอย่างที่มีความสำคัญในแอปของคุณจากนั้นระดับการดีบักจะบันทึกชุดย่อยของบันทึก verbose จากนั้นระดับข้อมูลจะบันทึกชุดย่อยของบันทึกการแก้ไขข้อบกพร่อง เมื่อคุณลงบันทึกข้อผิดพลาดคุณเพียงแค่ต้องการบันทึกข้อผิดพลาดประเภทใด ๆ ที่อาจเกิดขึ้น นอกจากนี้ยังมีระดับการดีบักที่เรียกว่า Fatal เมื่อมีบางสิ่งที่ฮิตแฟน ๆ ในแอปของคุณ

โดยทั่วไปแล้วคุณถูกต้องมันเป็นกฎเกณฑ์โดยทั่วไปและขึ้นอยู่กับคุณที่จะกำหนดว่าอะไรคือบันทึกการดีบักเมื่อเทียบกับการให้ข้อมูลข้อผิดพลาดและอื่น ๆ เป็นต้น

แม้ว่าคำถามนี้จะตอบแล้วฉันรู้สึกว่ามีตัวอย่างที่ขาดหายไปในคำตอบที่ตอบแล้ว

ดังนั้นฉันจะนำสิ่งที่ฉันเขียนในโพสต์บล็อก"ระดับการบันทึก Android"

ละเอียด

เป็นระดับการบันทึกต่ำสุด ถ้าคุณต้องการบันทึกการบันทึกด้วยถั่วคุณก็จะได้ระดับนี้ ฉันไม่เคยเข้าใจว่าจะใช้ Verbose เมื่อใดและเมื่อใดควรใช้ Debug ความแตกต่างฟังฉันโดยพลการมาก ในที่สุดฉันก็เข้าใจแล้วเมื่อฉันชี้ไปที่ซอร์สโค้ดของAndroid¹“ Verbose ไม่ควรรวบรวมลงในแอปพลิเคชันยกเว้นในระหว่างการพัฒนา” ตอนนี้มันชัดเจนสำหรับฉันเมื่อใดก็ตามที่คุณกำลังพัฒนาและต้องการเพิ่มบันทึกที่ลบได้ที่ช่วยคุณในระหว่างการพัฒนามันมีประโยชน์ที่จะมีระดับ verbose สิ่งนี้จะช่วยให้คุณลบบันทึกเหล่านี้ทั้งหมดก่อนที่จะเริ่มการผลิต

ตรวจแก้จุดบกพร่อง

ใช้สำหรับการดีบัก นี่คือระดับต่ำสุดที่ควรจะเป็นในการผลิต ข้อมูลที่นี่คือการช่วยเหลือในระหว่างการพัฒนา เวลาส่วนใหญ่คุณจะปิดการใช้งานการเข้าสู่ระบบนี้เพื่อให้มีการส่งข้อมูลน้อยลงและเปิดใช้งานบันทึกนี้เฉพาะเมื่อคุณมีปัญหา ฉันชอบที่จะเข้าสู่ระบบการแก้ปัญหาข้อมูลทั้งหมดที่แอปส่ง / รับจากเซิร์ฟเวอร์ (ระวังไม่ให้เข้าสู่ระบบรหัสผ่าน !!!) สิ่งนี้มีประโยชน์มากที่จะเข้าใจว่าข้อผิดพลาดอยู่ในเซิร์ฟเวอร์หรือแอป ฉันยังทำบันทึกการเข้าและออกจากฟังก์ชั่นที่สำคัญ

ข้อมูล

สำหรับข้อความที่ให้ข้อมูลที่เน้นความคืบหน้าของแอปพลิเคชัน ตัวอย่างเช่นเมื่อการเริ่มต้นแอปเสร็จสิ้น เพิ่มข้อมูลเมื่อผู้ใช้ย้ายระหว่างกิจกรรมและชิ้นส่วน บันทึกการโทรแต่ละครั้ง แต่มีข้อมูลเพียงเล็กน้อยเช่น URL สถานะและเวลาตอบสนอง

คำเตือน

เมื่อมีสถานการณ์ที่อาจเป็นอันตราย

บันทึกนี้อยู่ในประสบการณ์ของฉันในระดับที่ยุ่งยาก คุณมีสถานการณ์ที่เป็นอันตรายเมื่อใด โดยทั่วไปหรือว่ามันก็โอเคหรือว่ามันเป็นข้อผิดพลาด โดยส่วนตัวฉันไม่ได้ใช้ระดับนี้มากนัก ตัวอย่างเมื่อฉันใช้มันมักจะเกิดขึ้นเมื่อมีสิ่งต่าง ๆ เกิดขึ้นหลายครั้ง ตัวอย่างเช่นผู้ใช้มีรหัสผ่านผิดมากกว่า 3 ครั้ง อาจเป็นเพราะเขาป้อนรหัสผ่านผิด 3 ครั้งอาจเป็นเพราะมีปัญหากับตัวละครที่ไม่ได้รับการยอมรับในระบบของเรา กันไปกับปัญหาการเชื่อมต่อเครือข่าย

ความผิดพลาด

เหตุการณ์ผิดพลาด แอปพลิเคชันยังคงสามารถทำงานต่อได้หลังจากข้อผิดพลาด นี่อาจเป็นตัวอย่างเมื่อฉันได้รับตัวชี้โมฆะที่ฉันไม่ควรได้รับ มีข้อผิดพลาดในการแยกวิเคราะห์การตอบสนองของเซิร์ฟเวอร์ มีข้อผิดพลาดจากเซิร์ฟเวอร์

WTF (ช่างเป็นความล้มเหลวที่ยิ่งใหญ่)

ร้ายแรงสำหรับเหตุการณ์ข้อผิดพลาดร้ายแรงที่จะนำแอปพลิเคชันออกไป ใน Android ความตายในความเป็นจริงแล้วระดับข้อผิดพลาดความแตกต่างก็คือมันเพิ่ม fullstack

เว็บไซต์ Android สตูดิโอเมื่อเร็ว ๆ นี้ (ฉันคิด) ให้คำแนะนำบางสิ่งที่ชนิดของข้อความที่คาดหวังจากระดับเข้าสู่ระบบที่แตกต่างกันที่อาจเป็นประโยชน์พร้อมกับคำตอบของเคอร์ติ

• Verbose - แสดงข้อความบันทึกทั้งหมด (ค่าเริ่มต้น)
• ดีบัก - แสดงข้อความบันทึกการดีบักที่มีประโยชน์ระหว่างการพัฒนาเท่านั้นรวมถึงระดับข้อความที่ต่ำกว่าในรายการนี้
• ข้อมูล - แสดงข้อความบันทึกที่คาดไว้สำหรับการใช้งานปกติรวมถึงระดับข้อความที่ต่ำกว่าในรายการนี้
• คำเตือน - แสดงปัญหาที่เป็นไปได้ที่ยังไม่มีข้อผิดพลาดรวมถึงระดับข้อความที่ต่ำกว่าในรายการนี้
• ข้อผิดพลาด - แสดงปัญหาที่ทำให้เกิดข้อผิดพลาดรวมถึงระดับข้อความที่ต่ำกว่าในรายการนี้
• ยืนยัน - แสดงปัญหาที่นักพัฒนาคาดว่าจะไม่เกิดขึ้น