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

เห็นรูปแบบที่แตกต่างกัน (และบางครั้งก็เห็น "ตัวแปร") สำหรับปัญหาบางอย่างในตารางปัญหา

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

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

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

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

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

การปรับปรุงเหล่านี้จะช่วยให้คุณได้รับประสบการณ์การใช้งานดังนี้

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

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

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

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

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

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

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

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

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

ไม่เห็นบันทึกเบรดครัมบ์

หากไม่เห็นบันทึกเส้นทาง (iOS+ | Android | Flutter | Unity) เราขอแนะนำให้ตรวจสอบการกำหนดค่าของแอปสำหรับ Google Analytics โปรดตรวจสอบว่าคุณมีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้

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

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

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

• คุณใช้ Firebase SDK เวอร์ชันล่าสุดสําหรับผลิตภัณฑ์ทั้งหมดที่คุณใช้ในแอป (iOS+ | Android | Flutter | Unity)

  สําหรับแพลตฟอร์ม Apple และแอป Android โปรดตรวจสอบว่าคุณใช้ Firebase SDK สําหรับ Google Analytics เวอร์ชันต่อไปนี้อย่างน้อย iOS+ — v6.3.1+ (v8.9.0+ สําหรับ macOS และ tvOS) | Android — v17.2.3+ (BoM v24.7.1+)

ไม่เห็นการแจ้งเตือนอัตราความเร็ว

หากไม่เห็นการแจ้งเตือนความเร็ว โปรดตรวจสอบว่าคุณใช้

ไม่เห็นเมตริกแบบไม่มีข้อขัดข้อง (หรือเห็นเมตริกที่ไม่น่าเชื่อถือ)

หากไม่เห็นเมตริกที่ไม่มีข้อขัดข้อง (เช่น ผู้ใช้และเซสชันที่ไม่มีข้อขัดข้อง) หรือเห็นเมตริกที่ไม่น่าเชื่อถือ ให้ตรวจสอบสิ่งต่อไปนี้

• ตรวจสอบว่าคุณใช้

• ตรวจสอบว่าการตั้งค่าการเก็บรวบรวมข้อมูลไม่ส่งผลต่อคุณภาพของ เมตริกแบบไม่มีข้อขัดข้อง

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

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

วิธีคำนวณจำนวนผู้ใช้ที่ไม่พบข้อขัดข้อง

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

ใครดู เขียน และลบหมายเหตุในปัญหาได้บ้าง

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

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

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

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

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

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

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

ปัญหาที่ถดถอยคืออะไร

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

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

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

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

เหตุใดฉันจึงเห็นปัญหาที่ถดถอย สำหรับแอปเวอร์ชันเก่า

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

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

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

แอปยังใช้ SDK Google Mobile Ads ด้วย แต่ไม่พบข้อขัดข้อง

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

ชุดข้อมูล BigQuery ของฉันอยู่ที่ไหน

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

ไม่มี dSYM/ไม่ได้อัปโหลด

หากต้องการอัปโหลด dSYM ของโปรเจ็กต์และรับเอาต์พุตแบบละเอียด ให้ตรวจสอบสิ่งต่อไปนี้

1. ตรวจสอบว่าเฟสการสร้างของโปรเจ็กต์มีCrashlyticsสคริปต์ที่เรียกใช้ ซึ่งช่วยให้ Xcode อัปโหลด dSYM ของโปรเจ็กต์ได้ในเวลาสร้าง (อ่าน การเริ่มต้น Crashlytics เพื่อดูวิธีการเพิ่มสคริปต์) หลังจากอัปเดตโปรเจ็กต์แล้ว ให้บังคับให้เกิดข้อขัดข้องและยืนยันว่า ข้อขัดข้องปรากฏในแดชบอร์ด Crashlytics

2. หากเห็นการแจ้งเตือน "ไม่มี dSYM" ในFirebase คอนโซล ให้ตรวจสอบ Xcode เพื่อให้แน่ใจว่า สร้าง dSYM อย่างถูกต้อง สำหรับบิลด์

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

   • ตรวจสอบว่าคุณใช้ Crashlytics เวอร์ชันล่าสุดอยู่

   • อัปโหลดไฟล์ dSYM ที่ขาดหายไปด้วยตนเอง

     • ตัวเลือกที่ 1: ใช้ตัวเลือก "ลากและวาง" ที่อิงตามคอนโซลในแท็บ dSYM เพื่ออัปโหลดไฟล์เก็บถาวรแบบ ZIP ที่มีไฟล์ dSYM ที่ขาดหายไป
     • ตัวเลือกที่ 2: ใช้สคริปต์ upload-symbols เพื่ออัปโหลดไฟล์ dSYM ที่ขาดหายไปสำหรับ UUID ที่ระบุในแท็บ dSYM

4. หากยังคงเห็น dSYM ที่ขาดหายไปหรือยังอัปโหลดไม่สำเร็จ โปรดติดต่อทีมสนับสนุน Firebase และอย่าลืมแนบไฟล์บันทึก

ข้อขัดข้องมีการ แทนที่สแต็กเทรซข้อขัดข้องด้วยสัญลักษณ์ไม่ดี

หาก Stack Trace ดูเหมือนจะมีการสร้างสัญลักษณ์ไม่ดี ให้ตรวจสอบสิ่งต่อไปนี้

• หากเฟรมจากคลังของแอปไม่มีการอ้างอิงถึงโค้ดของแอป ให้ตรวจสอบว่าไม่ได้ตั้งค่า -fomit-frame-pointer เป็นแฟล็กการคอมไพล์

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

ฉันใช้ Crashlytics สำหรับ macOS หรือ tvOS ได้ไหม

ได้ คุณสามารถใช้ Crashlytics ในโปรเจ็กต์ macOS และ tvOS โปรดตรวจสอบว่าได้รวม Firebase SDK เวอร์ชัน 8.9.0 ขึ้นไปสำหรับ Google Analytics เพื่อให้ข้อขัดข้องมีสิทธิ์เข้าถึงเมตริกที่ Google Analytics รวบรวม (ผู้ใช้ที่ไม่มีข้อขัดข้อง, เวอร์ชันล่าสุด, การแจ้งเตือนความเร็ว และบันทึกเส้นทางการเข้าชม)

ฉันใช้ Crashlytics ในโปรเจ็กต์ Firebase ที่มีแอปหลายแอปในแพลตฟอร์ม Apple ต่างๆ ได้ไหม

ตอนนี้คุณสามารถรายงานข้อขัดข้องของแอปหลายแอปในโปรเจ็กต์ Firebase เดียวได้แล้ว แม้ว่าแอปจะสร้างขึ้นสำหรับแพลตฟอร์ม Apple ที่แตกต่างกัน (เช่น iOS, tvOS และ Mac Catalyst) ก่อนหน้านี้ คุณต้องแยกแอปออกเป็นโปรเจ็กต์ Firebase แต่ละโปรเจ็กต์หากแอปมี Bundle ID เดียวกัน

เหตุใดจึงมีการรายงาน ANR สำหรับ Android 11 ขึ้นไปเท่านั้น

Crashlytics รองรับการรายงาน ANR สำหรับแอป Android จากอุปกรณ์ที่ใช้ Android 11 ขึ้นไป API พื้นฐานที่เราใช้เพื่อรวบรวม ANR (getHistoricalProcessExitReasons) มีความน่าเชื่อถือมากกว่าวิธีการที่ใช้ SIGQUIT หรือ Watchdog API นี้ใช้ได้เฉพาะในอุปกรณ์ Android 11 ขึ้นไป

ทำไม ANR บางรายการจึงไม่มี BuildId

หาก ANR บางรายการไม่มี BuildId ให้แก้ปัญหาดังนี้

• ตรวจสอบว่าคุณใช้ CrashlyticsAndroid SDK และ Crashlyticsปลั๊กอิน Gradle เวอร์ชันล่าสุด

  หากคุณไม่มี BuildId สำหรับ Android 11 และ ANR บางรายการของ Android 12 แสดงว่าคุณอาจใช้ SDK, ปลั๊กอิน Gradle หรือทั้ง 2 อย่างที่ล้าสมัย หากต้องการรวบรวม BuildId สำหรับ ANR เหล่านี้อย่างถูกต้อง คุณต้องใช้เวอร์ชันต่อไปนี้

  • Crashlytics Android SDK v18.3.5 ขึ้นไป (Firebase BoM v31.2.2 ขึ้นไป)
  • Crashlytics ปลั๊กอิน Gradle v2.9.4 ขึ้นไป

• ตรวจสอบว่าคุณใช้ตำแหน่งที่ไม่เป็นไปตามมาตรฐานสำหรับไลบรารีที่ใช้ร่วมกันหรือไม่

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

• ตรวจสอบว่าคุณไม่ได้ลบ BuildId ในระหว่างกระบวนการสร้าง

  โปรดทราบว่าเคล็ดลับในการแก้ปัญหาต่อไปนี้ใช้ได้กับทั้ง ANR และข้อขัดข้องที่เกิดในโค้ดเนทีฟ

  • ตรวจสอบว่ามี BuildId หรือไม่โดยเรียกใช้ readelf -n ในไบนารี หากไม่มี BuildId ให้เพิ่ม -Wl,--build-id ลงในแฟล็กสำหรับ ระบบบิลด์

  • ตรวจสอบว่าคุณไม่ได้นำ BuildId ออกโดยไม่ตั้งใจเพื่อ ลดขนาด APK

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

ความแตกต่าง ระหว่างรายงาน ANR ในCrashlyticsแดชบอร์ดและ Google Play Console

จำนวน ANR ระหว่าง Google Play กับ Crashlytics อาจไม่ตรงกัน ความแตกต่างนี้อาจเกิดขึ้นได้เนื่องจากกลไกการรวบรวมและรายงานข้อมูล ANR แตกต่างกัน Crashlytics จะรายงาน ANR เมื่อแอป เริ่มทํางานครั้งถัดไป ในขณะที่ Android Vitals จะส่งข้อมูล ANR หลังจากเกิด ANR

นอกจากนี้ Crashlytics จะแสดงเฉพาะ ANR ที่เกิดขึ้นในอุปกรณ์ที่ใช้ Android 11 ขึ้นไปเท่านั้น ซึ่งแตกต่างจาก Google Play ที่แสดง ANR จากอุปกรณ์ที่ยอมรับข้อกำหนดในการให้บริการของ Google Play และยินยอมให้เก็บรวบรวมข้อมูล

เหตุใดฉันจึงเห็นข้อขัดข้อง จากไฟล์ .kt ที่ติดป้ายกำกับเป็นปัญหา .java

เมื่อแอปใช้ Obfuscator ที่ไม่แสดงนามสกุลไฟล์ Crashlytics จะสร้างปัญหาแต่ละรายการด้วยนามสกุลไฟล์ .java โดยค่าเริ่มต้น

เพื่อให้ Crashlytics สร้างปัญหาที่มีนามสกุลไฟล์ที่ถูกต้องได้ โปรดตรวจสอบว่าแอปของคุณใช้การตั้งค่าต่อไปนี้

• ใช้ Android Gradle 4.2.0 ขึ้นไป
• ใช้ R8 โดยเปิดการปิดบังไว้ หากต้องการอัปเดตแอปเป็น R8 ให้ทำตามเอกสารประกอบนี้

โปรดทราบว่าหลังจากอัปเดตเป็นการตั้งค่าที่อธิบายไว้ข้างต้นแล้ว คุณอาจเริ่มเห็น.ktปัญหาใหม่ที่ซ้ำกับปัญหา .java ที่มีอยู่ ดูข้อมูลเพิ่มเติมเกี่ยวกับกรณีดังกล่าวได้ที่คำถามที่พบบ่อย

เหตุใดฉันจึงเห็นปัญหา .kt ที่ซ้ำกับปัญหา .java ที่มีอยู่

ตั้งแต่ช่วงกลางเดือนธันวาคม 2021 เป็นต้นไป เราจะCrashlyticsปรับปรุงการรองรับแอปพลิเคชัน ที่ใช้ Kotlin

ก่อนหน้านี้ Obfuscator ที่มีอยู่ไม่ได้แสดงนามสกุลไฟล์ ดังนั้น Crashlyticsจึงสร้างปัญหาแต่ละรายการด้วยนามสกุลไฟล์ .java โดยค่าเริ่มต้น อย่างไรก็ตาม ตั้งแต่ Android Gradle 4.2.0 เป็นต้นมา R8 รองรับนามสกุลไฟล์แล้ว

การอัปเดตนี้ช่วยให้ Crashlytics สามารถระบุได้ว่าคลาสแต่ละคลาสที่ใช้ภายในแอปเขียนด้วย Kotlin หรือไม่ และรวมชื่อไฟล์ที่ถูกต้องไว้ในลายเซ็นของปัญหา ตอนนี้ระบบจะระบุแหล่งที่มาของข้อขัดข้องไปยังไฟล์ .kt อย่างถูกต้อง (ตามความเหมาะสม) หากแอปมีการตั้งค่าต่อไปนี้

• แอปของคุณใช้ Android Gradle 4.2.0 ขึ้นไป
• แอปของคุณใช้ R8 โดยเปิดการปิดบัง

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

ไม่พบข้อขัดข้องเมื่อใช้ Dexguard

หากคุณเห็นข้อยกเว้นต่อไปนี้ แสดงว่าคุณอาจใช้ DexGuard เวอร์ชันที่ไม่เข้ากันกับ Firebase Crashlytics SDK

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

ข้อยกเว้นนี้จะไม่ทำให้แอปขัดข้อง แต่จะป้องกันไม่ให้แอปส่งรายงานข้อขัดข้อง วิธีแก้ปัญหามีดังนี้

1. ตรวจสอบว่าคุณใช้ DexGuard 8.x เวอร์ชันล่าสุด เวอร์ชันล่าสุด มีกฎที่ SDK ของ Firebase Crashlytics กำหนด

2. หากไม่ต้องการเปลี่ยนเวอร์ชัน DexGuard ให้ลองเพิ่มบรรทัดต่อไปนี้ ลงในกฎการปกปิดโค้ด (ในไฟล์กำหนดค่า DexGuard)

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

ความแตกต่าง ระหว่าง Stack Trace ของ NDK ในแดชบอร์ด Crashlytics กับ Logcat

LLVM และ GNU Toolchain มีค่าเริ่มต้นและการจัดการที่แตกต่างกันสำหรับส่วนแบบอ่านอย่างเดียวของไบนารีของแอป ซึ่งอาจสร้าง Stack Trace ที่ไม่สอดคล้องกันในFirebase คอนโซล หากต้องการลดปัญหานี้ ให้เพิ่มแฟล็ก Linker ต่อไปนี้ ลงในกระบวนการบิลด์

• หากคุณใช้ lld Linker จากชุดเครื่องมือ LLVM ให้เพิ่มสิ่งต่อไปนี้

  -Wl,--no-rosegment

• หากคุณใช้โปรแกรมลิงก์ ld.gold จาก GNU Toolchain ให้เพิ่มสิ่งต่อไปนี้

  -Wl,--rosegment

หากยังคงเห็นความไม่สอดคล้องกันของ Stack Trace (หรือหากไม่มีแฟล็กใดที่เกี่ยวข้องกับ Toolchain) ให้ลองเพิ่มสิ่งต่อไปนี้ลงในกระบวนการบิลด์แทน

-fno-omit-frame-pointer

ฉันจะใช้ไบนารีตัวสร้างไฟล์สัญลักษณ์ Breakpad ของตัวเองสำหรับ NDK ได้อย่างไร

ปลั๊กอิน Crashlytics จะรวมเครื่องมือสร้างไฟล์สัญลักษณ์ Breakpad ที่กำหนดเอง หากต้องการใช้ไบนารีของคุณเองเพื่อสร้างไฟล์สัญลักษณ์ Breakpad (เช่น หากต้องการสร้างไฟล์ปฏิบัติการแบบเนทีฟทั้งหมดในห่วงโซ่การสร้างจากแหล่งที่มา) ให้ใช้พร็อพเพอร์ตี้ส่วนขยาย symbolGeneratorBinary ที่ไม่บังคับเพื่อระบุเส้นทางไปยังไฟล์ปฏิบัติการ

คุณระบุเส้นทางไปยังไบนารีของเครื่องมือสร้างไฟล์สัญลักษณ์ Breakpad ได้ 1 ใน 2 วิธีต่อไปนี้

• ตัวเลือกที่ 1: ระบุเส้นทางผ่านส่วนขยาย firebaseCrashlytics ในไฟล์ build.gradle

  เพิ่มโค้ดต่อไปนี้ลงในไฟล์ build.gradle.kts ระดับแอป

  ปลั๊กอิน Gradle เวอร์ชัน 3.0.0 ขึ้นไป

  android {
    buildTypes {
      release {
        configure<CrashlyticsExtension> {
          nativeSymbolUploadEnabled = true
          // Add these optional fields to specify the path to the executable
          symbolGeneratorType = "breakpad"
          breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
        }
      }
    }
  }

  ปลั๊กอินเวอร์ชันที่ต่ำกว่า

  android {
    // ...
    buildTypes {
      // ...
      release {
        // ...
        firebaseCrashlytics {
          // existing; required for either symbol file generator
          nativeSymbolUploadEnabled true
          // Add this optional new block to specify the path to the executable
          symbolGenerator {
            breakpad {
              binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
     }
  }

• ตัวเลือกที่ 2: ระบุเส้นทางผ่านบรรทัดพร็อพเพอร์ตี้ในไฟล์ Gradle properties

  คุณใช้พร็อพเพอร์ตี้ com.google.firebase.crashlytics.breakpadBinary เพื่อระบุเส้นทางไปยังไฟล์ที่เรียกใช้งานได้

  คุณอัปเดตไฟล์ Gradle Properties ด้วยตนเองหรืออัปเดตไฟล์ ผ่านบรรทัดคำสั่งได้ เช่น หากต้องการระบุเส้นทางผ่านบรรทัดคำสั่ง ให้ใช้คำสั่งต่อไปนี้

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

Crashlytics รองรับ armeabi ไหม

Firebase Crashlytics NDK ไม่รองรับ ARMv5 (armeabi) เราได้นำการรองรับ ABI นี้ออกแล้วตั้งแต่ NDK r17

การเห็นสแต็กเทรซที่ไม่ได้ทำสัญลักษณ์ สำหรับแอป Android ในแดชบอร์ด Crashlytics

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

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

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

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

Crashlytics ใช้กับแอปที่ใช้ IL2CPP ได้ไหม

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

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

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

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

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

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

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

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

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

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

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

โปรดทราบว่าหากต้องการพิมพ์ข้อยกเว้นที่ตรวจพบไปยังคอนโซล 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
    //
}