การแก้ปัญหาและคำถามที่พบบ่อยเกี่ยวกับ Crashlytics

คุณอาจสังเกตเห็นปัญหาที่แสดงในตารางปัญหาในคอนโซล Firebase อยู่ 2 รูปแบบ และคุณอาจเห็นฟีเจอร์ที่เรียกว่า "ตัวแปร" ในปัญหาบางรายการด้วย เหตุผลมีดังนี้

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

Crashlytics จะวิเคราะห์เหตุการณ์ทั้งหมดจากแอป (เช่น ข้อขัดข้อง ข้อขัดข้องที่ไม่ร้ายแรง และ ANR) และสร้างกลุ่มเหตุการณ์ที่เรียกว่าปัญหา ซึ่งเหตุการณ์ทั้งหมดในปัญหาจะมีจุดที่ผิดพลาดเหมือนกัน

ตอนนี้เครื่องมือวิเคราะห์ที่ปรับปรุงแล้วจะพิจารณาเหตุการณ์หลายแง่มุมเพื่อจัดกลุ่มเหตุการณ์เป็นปัญหาเหล่านี้ ซึ่งรวมถึงเฟรมในสแต็กเทรซ ข้อความข้อยกเว้น รหัสข้อผิดพลาด และลักษณะอื่นๆ ของแพลตฟอร์มหรือประเภทข้อผิดพลาด

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

ต่อไปนี้คือสิ่งที่คุณจะพบจากการปรับปรุงเหล่านี้

• ข้อมูลเมตาที่ปรับปรุงใหม่ซึ่งแสดงในแถวปัญหา
  ตอนนี้คุณเข้าใจและจัดลำดับความสำคัญของปัญหาในแอปได้ง่ายขึ้น

• ปัญหาที่ซ้ำกันน้อยลง
  การเปลี่ยนแปลงหมายเลขบรรทัดจะไม่ทำให้เกิดปัญหาใหม่

• แก้ไขข้อบกพร่องของปัญหาที่ซับซ้อนซึ่งมีสาเหตุที่หลากหลายได้ง่ายขึ้น
  ใช้ตัวแปรเพื่อแก้ไขข้อบกพร่องของสแต็กเทรซที่พบบ่อยที่สุดภายในปัญหา

• การแจ้งเตือนและสัญญาณที่สื่อความหมายมากขึ้น
  ปัญหาใหม่หมายถึงข้อบกพร่องใหม่

• การค้นหาที่มีประสิทธิภาพมากขึ้น
  ปัญหาแต่ละรายการจะมีข้อมูลเมตาที่ค้นหาได้มากขึ้น เช่น ประเภทข้อยกเว้นและชื่อแพ็กเกจ

การเปิดตัวการปรับปรุงเหล่านี้มีดังนี้

• เมื่อได้รับเหตุการณ์ใหม่จากแอปของคุณ เราจะตรวจสอบว่าเหตุการณ์ดังกล่าวตรงกับปัญหาที่มีอยู่หรือไม่

• หากไม่ตรงกัน เราจะใช้อัลกอริทึมการจัดกลุ่มเหตุการณ์ที่ชาญฉลาดยิ่งขึ้นกับเหตุการณ์นั้นโดยอัตโนมัติ และสร้างปัญหาใหม่ด้วยการออกแบบข้อมูลเมตาที่ปรับปรุงใหม่

นี่เป็นอัปเดตครั้งใหญ่ครั้งแรกที่เราทำกับการจัดกลุ่มเหตุการณ์ หากมีความคิดเห็นหรือพบปัญหาใดๆ โปรดแจ้งให้เราทราบโดย ยื่นรายงาน

หากไม่เห็นเมตริกที่ไม่มีการขัดข้อง (เช่น ผู้ใช้และเซสชันที่ไม่มีการขัดข้อง) และ/หรือการแจ้งเตือนเกี่ยวกับความเร็ว ให้ตรวจสอบว่าคุณใช้ Crashlytics SDK 11.7.0 ขึ้นไป

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

• คุณได้เปิดใช้ Google Analytics ในโปรเจ็กต์ Firebase แล้ว

• คุณได้เปิดใช้การแชร์ข้อมูลสําหรับ Google Analytics แล้ว ดูข้อมูลเพิ่มเติมเกี่ยวกับการตั้งค่านี้ในจัดการการตั้งค่าการแชร์ข้อมูล Analytics

• คุณได้ เพิ่ม Firebase SDK สําหรับ Google Analytics ลงในแอปแล้ว SDK นี้ต้องเพิ่มนอกเหนือจาก Crashlytics SDK

• คุณใช้ Firebase SDK เวอร์ชันล่าสุด สำหรับผลิตภัณฑ์ทั้งหมดที่คุณใช้ในแอป

หากคุณใช้ Unity IL2CPP และเห็นสแต็กเทรซที่ไม่มีสัญลักษณ์ ให้ลองทำดังนี้

1. ตรวจสอบว่าคุณใช้ Crashlytics Unity SDK เวอร์ชัน 8.6.1 ขึ้นไป

2. ตรวจสอบว่าคุณได้ตั้งค่าและเรียกใช้คำสั่ง Firebase CLI crashlytics:symbols:upload เพื่อสร้างและอัปโหลดไฟล์สัญลักษณ์แล้ว

   คุณต้องเรียกใช้คําสั่ง CLI นี้ทุกครั้งที่สร้างบิวด์รุ่นหรือบิวด์ที่ต้องการดูสแต็กเทรซที่แปลงสัญลักษณ์ในคอนโซล Firebase ดูข้อมูลเพิ่มเติมได้ในหน้าดูรายงานข้อขัดข้องที่อ่านได้

ได้ Crashlytics สามารถแสดงสแต็กเทรซที่มีสัญลักษณ์สําหรับแอปที่ใช้ IL2CPP ความสามารถนี้มีให้บริการสำหรับแอปที่เผยแพร่ในแพลตฟอร์ม Android หรือ Apple สิ่งที่คุณต้องทํามีดังนี้

1. ตรวจสอบว่าคุณใช้ CrashlyticsUnity SDK เวอร์ชัน 8.6.0 ขึ้นไป

2. ทํางานที่จําเป็นสําหรับแพลตฟอร์มให้เสร็จสมบูรณ์

   • สำหรับแอปบนแพลตฟอร์ม Apple: คุณไม่ต้องดำเนินการใดๆ เป็นพิเศษ สําหรับแอปแพลตฟอร์ม Apple ปลั๊กอิน Firebase Unity Editor จะกําหนดค่าโปรเจ็กต์ Xcode ให้อัปโหลดสัญลักษณ์โดยอัตโนมัติ

   • สำหรับแอป Android: ตรวจสอบว่าคุณได้ตั้งค่าและเรียกใช้คำสั่ง Firebase CLI crashlytics:symbols:upload เพื่อสร้างและอัปโหลดไฟล์สัญลักษณ์แล้ว

     คุณต้องเรียกใช้คําสั่ง CLI นี้ทุกครั้งที่สร้างบิวด์รุ่นหรือบิวด์ที่ต้องการดูสแต็กเทรซที่แปลงสัญลักษณ์ในคอนโซล Firebase ดูข้อมูลเพิ่มเติมได้ในหน้าดูรายงานข้อขัดข้องที่อ่านได้

ค่า "ไม่พบข้อขัดข้อง" แสดงเปอร์เซ็นต์ของผู้ใช้ที่มีส่วนร่วมกับแอปแต่ไม่พบข้อขัดข้องในช่วงระยะเวลาหนึ่งๆ

สูตรการคำนวณเปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้องมีดังนี้ Google Analytics จะเป็นผู้ระบุค่าอินพุต

CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100

• เมื่อเกิดข้อขัดข้อง Google Analytics จะส่งเหตุการณ์ประเภท app_exception และ CRASHED_USERS จะแสดงจํานวนผู้ใช้ที่เชื่อมโยงกับเหตุการณ์ประเภทนั้น

• ALL_USERS แสดงจํานวนผู้ใช้ทั้งหมดที่มีส่วนร่วมกับแอปของคุณในระยะเวลาที่เลือกจากเมนูแบบเลื่อนลงที่ด้านขวาบนของหน้าแดชบอร์ด Crashlytics

เปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้องคือการรวบรวมข้อมูลตามช่วงเวลา ไม่ใช่ค่าเฉลี่ย

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

• ในวันพุธ เปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้องคือ 50% (ผู้ใช้ 1 ใน 2 คนไม่พบข้อขัดข้อง)
  ผู้ใช้ 2 รายมีส่วนร่วมกับแอปของคุณในวันพุธ แต่มีเพียงผู้ใช้รายเดียว (ผู้ใช้ ข.) ที่ไม่พบข้อขัดข้อง

• ในช่วง 2 วันที่ผ่านมา เปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้องคือ 33.3% (ผู้ใช้ 1 ใน 3 ไม่พบข้อขัดข้อง)
  ผู้ใช้ 3 รายมีส่วนร่วมกับแอปในช่วง 2 วันที่ผ่านมา แต่มีเพียงผู้ใช้รายเดียว (ผู้ใช้ ค) ที่ไม่พบข้อขัดข้อง

• ในช่วง 3 วันที่ผ่านมา เปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้องคือ 0% (ผู้ใช้ 0 รายจาก 3 รายที่ไม่พบข้อขัดข้อง)
  ผู้ใช้ 3 รายมีส่วนร่วมกับแอปในช่วง 3 วันที่ผ่านมา แต่ไม่มีผู้ใช้รายใดที่พบข้อขัดข้อง

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

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

เมื่อสมาชิกในโปรเจ็กต์โพสต์โน้ต ระบบจะติดป้ายกำกับโน้ตด้วยอีเมลของบัญชี Google อีเมลนี้และโน้ตจะแสดงให้สมาชิกโปรเจ็กต์ทุกคนที่มีสิทธิ์ดูโน้ตเห็น

สิทธิ์เข้าถึงที่จําเป็นในการดู เขียน และลบโน้ตมีดังนี้

• สมาชิกโปรเจ็กต์ที่มีบทบาทต่อไปนี้จะดูและลบโน้ตที่มีอยู่ รวมถึงเขียนโน้ตใหม่เกี่ยวกับปัญหาได้

  • เจ้าของหรือผู้แก้ไขโปรเจ็กต์ ผู้ดูแลระบบ Firebase ผู้ดูแลระบบคุณภาพ หรือ ผู้ดูแลระบบ Crashlytics

• สมาชิกโปรเจ็กต์ที่มีบทบาทต่อไปนี้จะดูหมายเหตุที่โพสต์ในปัญหาได้ แต่จะลบหรือเขียนหมายเหตุไม่ได้

  • ผู้ดูโปรเจ็กต์, ผู้ดู Firebase, ผู้ดูคุณภาพ หรือ ผู้ดู Crashlytics

ดูทําความเข้าใจเมตริกที่ไม่มีการขัดข้อง

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

เมื่อสมาชิกในโปรเจ็กต์โพสต์โน้ต ระบบจะติดป้ายกำกับโน้ตด้วยอีเมลของบัญชี Google อีเมลนี้และโน้ตจะแสดงให้สมาชิกโปรเจ็กต์ทุกคนที่มีสิทธิ์ดูโน้ตเห็น

สิทธิ์เข้าถึงที่จําเป็นในการดู เขียน และลบโน้ตมีดังนี้

• สมาชิกโปรเจ็กต์ที่มีบทบาทต่อไปนี้จะดูและลบโน้ตที่มีอยู่ รวมถึงเขียนโน้ตใหม่เกี่ยวกับปัญหาได้

  • เจ้าของหรือผู้แก้ไขโปรเจ็กต์ ผู้ดูแลระบบ Firebase ผู้ดูแลระบบคุณภาพ หรือ ผู้ดูแลระบบ Crashlytics

• สมาชิกโปรเจ็กต์ที่มีบทบาทต่อไปนี้จะดูหมายเหตุที่โพสต์ในปัญหาได้ แต่จะลบหรือเขียนหมายเหตุไม่ได้

  • ผู้ดูโปรเจ็กต์, ผู้ดู Firebase, ผู้ดูคุณภาพ หรือ ผู้ดู Crashlytics

หากโปรเจ็กต์ใช้ Crashlytics ร่วมกับ SDK ของ Google Mobile Ads ก็มีความเป็นไปได้ว่าเครื่องมือรายงานข้อขัดข้องจะรบกวนเมื่อลงทะเบียนตัวแฮนเดิลข้อยกเว้น หากต้องการแก้ไขปัญหา ให้ปิดการรายงานข้อขัดข้องใน Mobile Ads SDK โดยเรียกใช้ disableSDKCrashReporting

หลังจากลิงก์ Crashlytics กับ BigQuery แล้ว ชุดข้อมูลใหม่ที่สร้างขึ้นจะอยู่ในสหรัฐอเมริกาโดยอัตโนมัติ ไม่ว่าโปรเจ็กต์ Firebase จะอยู่ที่ไหนก็ตาม

ปัญหากลับมาเกิดขึ้นอีกเมื่อคุณปิดปัญหาไปแล้วก่อนหน้านี้ แต่Crashlyticsได้รับรายงานใหม่ว่าปัญหาเกิดขึ้นอีกครั้ง Crashlytics จะเปิดปัญหาที่กลับมาอีกครั้งเหล่านี้ขึ้นใหม่โดยอัตโนมัติเพื่อให้คุณแก้ไขตามความเหมาะสมสำหรับแอปของคุณ

ต่อไปนี้เป็นตัวอย่างสถานการณ์ที่อธิบายวิธีที่ Crashlytics จัดหมวดหมู่ปัญหาเป็นการถดถอย

1. Crashlytics ได้รับรายงานข้อขัดข้องเกี่ยวกับข้อขัดข้อง "A" เป็นครั้งแรก Crashlytics เปิดปัญหาที่เกี่ยวข้องสำหรับการขัดข้องนั้น (ปัญหา "ก")
2. คุณแก้ไขข้อบกพร่องนี้อย่างรวดเร็ว ปิดปัญหา "ก" แล้วเผยแพร่แอปเวอร์ชันใหม่
3. Crashlytics ได้รับรายงานอีกฉบับเกี่ยวกับปัญหา "ก" หลังจากที่คุณปิดปัญหาแล้ว
   • หากรายงานมาจากเวอร์ชันแอปที่ Crashlytics ทราบเมื่อคุณปิดปัญหา (หมายความว่าเวอร์ชันดังกล่าวได้ส่งรายงานข้อขัดข้องสำหรับข้อขัดข้องใดๆ ก็ตาม) Crashlytics จะไม่ถือว่าปัญหาดังกล่าวแย่ลง ปัญหาจะยังคงปิดอยู่
   • หากรายงานมาจากเวอร์ชันแอปที่ Crashlyticsไม่ทราบเลยว่ามีเมื่อคุณปิดปัญหา (หมายความว่าเวอร์ชันดังกล่าวไม่เคยส่งรายงานข้อขัดข้องใดๆเลย) Crashlyticsจะถือว่าปัญหากลับมาอีกครั้งและจะเปิดปัญหาดังกล่าวขึ้นมาใหม่

เมื่อปัญหากลับมาเกิดขึ้นอีก เราจะส่งการแจ้งเตือนการตรวจหาการเกิดซ้ำและเพิ่มสัญญาณการเกิดซ้ำลงในปัญหาเพื่อแจ้งให้ทราบว่า Crashlytics ได้เปิดปัญหาขึ้นมาอีกครั้ง หากไม่ต้องการให้ระบบเปิดปัญหาขึ้นมาอีกครั้งเนื่องจากอัลกอริทึมการถดถอย ให้ "ปิดเสียง" ปัญหาแทนการปิด

หากรายงานมาจากแอปเวอร์ชันเก่าที่ไม่เคยส่งรายงานข้อขัดข้องเลยเมื่อคุณปิดปัญหา Crashlytics จะถือว่าปัญหากลับมาอีกครั้งและจะเปิดปัญหานั้นขึ้นมาใหม่

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

หากไม่ต้องการให้ระบบเปิดปัญหาขึ้นมาอีกครั้งเนื่องจากอัลกอริทึมการถดถอยของเรา ให้ "ปิดเสียง" ปัญหาแทนการปิด

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

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

Crashlytics จะรายงานข้อยกเว้นที่ตรวจไม่พบว่าเป็นข้อยกเว้นร้ายแรงได้ก็ต่อเมื่อเป็นไปตามเงื่อนไขทั้ง 2 ข้อต่อไปนี้

• ในระหว่างการเริ่มต้นใช้งานในแอป คุณต้องตั้งค่าพร็อพเพอร์ตี้ ReportUncaughtExceptionsAsFatal เป็น true

• แอปของคุณ (หรือไลบรารีที่รวมไว้) แสดงข้อยกเว้นที่ไม่ได้จับ ระบบจะไม่ถือว่าข้อยกเว้นที่สร้างขึ้นแต่ไม่ได้แสดงเป็นข้อยกเว้นที่ไม่มีการจับ

เมื่อเริ่มได้รับรายงานข้อยกเว้นที่ตรวจไม่พบเป็นข้อยกเว้นร้ายแรง ตัวเลือกการจัดการข้อยกเว้นที่ตรวจไม่พบเหล่านี้มีดังนี้

• พิจารณาวิธีเริ่มจับและจัดการข้อยกเว้นที่ไม่มีการจับเหล่านี้
• ลองใช้ตัวเลือกต่างๆ ในการบันทึกข้อยกเว้นไปยังคอนโซลแก้ไขข้อบกพร่องของ Unity และ Crashlytics

จับและจัดการข้อยกเว้นที่โยน

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

แนวทางปฏิบัติแนะนำคือให้จับและจัดการข้อยกเว้นที่คาดการณ์ไว้ทั้งหมด เว้นแต่โปรแกรมจะไม่สามารถกลับไปยังสถานะที่รู้จักได้

หากต้องการควบคุมประเภทข้อยกเว้นที่โค้ดจะจับและจัดการ ให้รวมโค้ดที่อาจสร้างข้อยกเว้นไว้ในบล็อก try-catch ตรวจสอบว่าเงื่อนไขในคำสั่ง catch นั้นแคบที่สุดเท่าที่จะเป็นไปได้เพื่อจัดการกับข้อยกเว้นที่เฉพาะเจาะจงอย่างเหมาะสม

บันทึกข้อยกเว้นใน Unity หรือ Crashlytics

การบันทึกข้อยกเว้นใน Unity หรือ Crashlytics เพื่อช่วยแก้ไขข้อผิดพลาดทำได้หลายวิธี

เมื่อใช้ Crashlytics ตัวเลือกที่พบบ่อยที่สุดและแนะนํามี 2 ตัวเลือกดังนี้

• ตัวเลือกที่ 1: พิมพ์ในคอนโซล Unity แต่ไม่ต้องรายงานไปยัง Crashlytics ระหว่างการพัฒนาหรือการแก้ปัญหา

  • พิมพ์ไปยังคอนโซล Unity โดยใช้ Debug.Log(exception), Debug.LogWarning(exception) และ Debug.LogError(exception) ซึ่งจะพิมพ์เนื้อหาของข้อยกเว้นไปยังคอนโซล Unity และไม่แสดงข้อยกเว้นอีกครั้ง

• ตัวเลือกที่ 2: อัปโหลดไปยัง Crashlytics สำหรับการรายงานแบบรวมในแดชบอร์ด Crashlytics สำหรับสถานการณ์ต่อไปนี้

  • หากข้อยกเว้นควรบันทึกเพื่อแก้ไขข้อบกพร่องของเหตุการณ์ Crashlytics ที่อาจเกิดขึ้นในภายหลัง ให้ใช้ Crashlytics.Log(exception.ToString())
  • หากยังคงต้องรายงานข้อยกเว้นไปยัง Crashlytics แม้ว่าจะมีการจับและจัดการแล้ว ให้ใช้ Crashlytics.LogException(exception) เพื่อบันทึกเป็นเหตุการณ์ที่ไม่ร้ายแรง

อย่างไรก็ตาม หากต้องการรายงานเหตุการณ์ร้ายแรงไปยัง Unity Cloud Diagnostic ด้วยตนเอง ให้ใช้ Debug.LogException ตัวเลือกนี้จะแสดงข้อยกเว้นในคอนโซล Unity เช่นเดียวกับตัวเลือกที่ 1 แต่จะแสดงข้อยกเว้นด้วย (ไม่ว่าจะมีการแสดงหรือจับข้อยกเว้นไว้แล้วหรือไม่ก็ตาม) แต่จะแสดงข้อผิดพลาดแบบไม่แสดงในหน้า ซึ่งหมายความว่าแม้ Debug.LogException(exception) ที่มีบล็อก try-catch อยู่รอบๆ ก็จะยังคงทำให้เกิดข้อยกเว้นที่ตรวจไม่พบ

ดังนั้น ให้เรียกใช้ Debug.LogException เฉพาะในกรณีที่คุณต้องการทำทั้งหมดต่อไปนี้เท่านั้น

• วิธีพิมพ์ข้อยกเว้นไปยังคอนโซล Unity
• วิธีอัปโหลดข้อยกเว้นไปยัง Crashlytics เป็นเหตุการณ์ร้ายแรง
• หากต้องการแสดงข้อยกเว้น ให้ถือว่าข้อยกเว้นนั้นเป็นข้อยกเว้นที่ตรวจไม่พบ และรายงานไปยัง Unity Cloud Diagnostics

โปรดทราบว่าหากต้องการพิมพ์ข้อยกเว้นที่พบในคอนโซล Unity และอัปโหลดไปยัง Crashlytics เป็นเหตุการณ์ที่ไม่ร้ายแรง ให้ทําดังนี้แทน

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}