Google ใช้เทคโนโลยี AI เพื่อแปลเนื้อหาเป็นภาษาที่คุณต้องการ การแปลโดย AI อาจมีข้อผิดพลาด

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

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

ในหน้านี้ คุณจะเห็นข้อมูลเกี่ยวกับหัวข้อประเภทต่อไปนี้

การแก้ปัญหาทั่วไป รวมถึงคำถามเกี่ยวกับการ แสดงข้อมูลหรือการทำงานกับข้อมูลในFirebaseคอนโซล และคำถาม เกี่ยวกับปัญหาที่กลับมาเกิดซ้ำ
การสนับสนุนเฉพาะแพลตฟอร์ม รวมถึงคำถามที่เจาะจง สำหรับแพลตฟอร์มของ Apple Android และ Unity
การสนับสนุนเกี่ยวกับการผสานรวม รวมถึงคำถามเกี่ยวกับ BigQuery

การแก้ปัญหา/คำถามที่พบบ่อยทั่วไป

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

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

ในช่วงต้นปี 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 จัดหมวดหมู่ปัญหาเป็นการเกิดปัญหาซ้ำ

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

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

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

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

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

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

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

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

การสนับสนุนเฉพาะแพลตฟอร์ม

ส่วนต่อไปนี้ให้การสนับสนุนการแก้ปัญหาและคำถามที่พบบ่อยสำหรับแพลตฟอร์มที่เฉพาะเจาะจง iOS+ | Android | Unity

การรองรับแพลตฟอร์ม Apple

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

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

ตรวจสอบว่าระยะการสร้างของโปรเจ็กต์มีCrashlyticsสคริปต์ที่เรียกใช้ ซึ่งช่วยให้ Xcode อัปโหลด dSYM ของโปรเจ็กต์ได้ในเวลาที่สร้าง (อ่าน การเริ่มต้น Crashlytics เพื่อดูวิธีการเพิ่มสคริปต์) หลังจากอัปเดตโปรเจ็กต์แล้ว ให้บังคับให้เกิดข้อขัดข้องและยืนยันว่า ข้อขัดข้องปรากฏในแดชบอร์ด Crashlytics
หากเห็นการแจ้งเตือน "ไม่มี dSYM" ในFirebase คอนโซล ให้ตรวจสอบ Xcode เพื่อให้แน่ใจว่า สร้าง dSYM อย่างถูกต้อง สําหรับบิลด์
หาก Xcode สร้าง dSYM อย่างถูกต้อง แต่คุณยังเห็น dSYM ที่ขาดหายไป แสดงว่าเครื่องมือสคริปต์ที่เรียกใช้อาจค้างขณะอัปโหลด dSYM ในกรณีนี้ ให้ลองทำดังนี้
- ตรวจสอบว่าคุณใช้ Crashlytics เวอร์ชันล่าสุดอยู่
- อัปโหลดไฟล์ dSYM ที่ขาดหายไปด้วยตนเอง
  - ตัวเลือกที่ 1: ใช้ตัวเลือก "ลากและวาง" ในคอนโซลในแท็บ dSYM เพื่ออัปโหลดไฟล์เก็บถาวรแบบ Zip ที่มีไฟล์ dSYM ที่ขาดหายไป
  - ตัวเลือกที่ 2: ใช้สคริปต์ upload-symbols เพื่ออัปโหลดไฟล์ dSYM ที่ขาดหายไปสำหรับ UUID ที่ระบุในแท็บ dSYMs
หากยังคงเห็น dSYM ที่ขาดหายไป หรือการอัปโหลดไม่สำเร็จ โปรดติดต่อทีมสนับสนุน Firebase และอย่าลืมแนบไฟล์บันทึก

ข้อขัดข้องมีสัญลักษณ์ไม่ถูกต้อง

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

หากเฟรมจากไลบรารีของแอปไม่มีการอ้างอิงถึงโค้ดของแอป ให้ตรวจสอบว่าไม่ได้ตั้งค่า -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 แต่ละโปรเจ็กต์หากแอปมีรหัสชุดเดียวกัน

การสนับสนุน Android

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

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

เหตุใด ANR บางรายการจึงไม่มี `BuildId`

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

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

หากคุณไม่มี BuildIdสำหรับ ANR ของ Android 11 และ 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
- หากคุณเก็บไลบรารีทั้งเวอร์ชันที่แยกและไม่แยก ให้ตรวจสอบว่าได้ ชี้ไปยังเวอร์ชันที่ถูกต้องในโค้ด

ความแตกต่าง ระหว่างรายงาน 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`

เมื่อแอปใช้เครื่องมือปกปิดโค้ดที่ไม่แสดงนามสกุลไฟล์ 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 เวอร์ชันที่เข้ากันไม่ได้กับ SDK Firebase Crashlytics

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

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

ตรวจสอบว่าคุณใช้ DexGuard เวอร์ชัน 8.x ล่าสุด เวอร์ชันล่าสุด มีกฎที่ SDK ของ Firebase Crashlytics กำหนด
หากไม่ต้องการเปลี่ยนเวอร์ชัน DexGuard ให้ลองเพิ่มบรรทัดต่อไปนี้ ลงในกฎการปกปิดโค้ด (ในไฟล์กำหนดค่า DexGuard)
```
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
```

วิธีอัปเกรดเป็นปลั๊กอิน Crashlytics Gradle v3

Crashlyticsปลั๊กอิน Gradle เวอร์ชันล่าสุดเป็นเวอร์ชันหลัก (v3.0.0) และปรับปรุง SDK ให้ทันสมัยด้วยการเลิกการรองรับ Gradle และปลั๊กอิน Android Gradle เวอร์ชันที่ต่ำกว่า นอกจากนี้ การเปลี่ยนแปลงใน รุ่นนี้ยังช่วยแก้ปัญหาเกี่ยวกับ AGP v8.1 ขึ้นไป และปรับปรุงการรองรับแอปแบบเนทีฟและ บิลด์ที่กำหนดเอง

ข้อกำหนดขั้นต่ำ

ปลั๊กอิน Crashlytics Gradle v3 มีข้อกำหนดขั้นต่ำดังนี้

ปลั๊กอิน Android Gradle 8.1 ขึ้นไป
อัปเกรดปลั๊กอินนี้โดยใช้ ผู้ช่วยอัปเกรดปลั๊กอิน Android Gradle ใน Android Studio เวอร์ชันล่าสุด
google-servicesปลั๊กอิน Gradle 4.4.1 ขึ้นไป
ของ Firebase อัปเกรดปลั๊กอินนี้โดยระบุเวอร์ชันล่าสุดในไฟล์บิลด์ Gradle ของโปรเจ็กต์ ดังนี้

Kotlin

plugins {
  id("com.android.application") version "8.1.4" apply false
  id("com.google.gms.google-services") version "4.5.0" apply false
  ...
}

Groovy

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.5.0' apply false
  ...
}

การเปลี่ยนแปลงส่วนขยาย Crashlytics

ปลั๊กอิน Crashlytics Gradle เวอร์ชัน 3 มีการเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบต่อไปนี้ ในส่วนขยาย Crashlytics

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

เปลี่ยนฟิลด์ unstrippedNativeLibsDir ให้เป็นแบบสะสม

ดูตัวอย่างที่มีหลายไดเรกทอรี

buildTypes {
  release {
    configure<CrashlyticsExtension> {
      nativeSymbolUploadEnabled = true
      unstrippedNativeLibsDir = file("MY/NATIVE/LIBS")
    }
  }
  productFlavors {
    flavorDimensions += "feature"
    create("basic") {
      dimension = "feature"
      // ...
    }
    create("featureX") {
      dimension = "feature"
      configure<CrashlyticsExtension> {
        unstrippedNativeLibsDir = file("MY/FEATURE_X/LIBS")
      }
    }
  }
}

งาน uploadCrashlyticsSymbolFilesBasicRelease จะอัปโหลดเฉพาะสัญลักษณ์ใน MY/NATIVE/LIBS แต่ uploadCrashlyticsSymbolFilesFeatureXRelease จะอัปโหลดสัญลักษณ์ทั้งใน MY/NATIVE/LIBS และ MY/FEATURE_X/LIBS

แทนที่ฟิลด์การปิด symbolGenerator ด้วยฟิลด์ระดับบนสุดใหม่ 2 รายการ ดังนี้
- symbolGeneratorType สตริงของ "breakpad" (ค่าเริ่มต้น) หรือ "csym"
- breakpadBinary ไฟล์ของการแทนที่ไบนารี dump_syms ในเครื่อง

ตัวอย่างวิธีอัปเกรดส่วนขยาย

Kotlin

ก่อน

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGenerator(
                closureOf<SymbolGenerator> {
                  symbolGeneratorType = "breakpad"
                  breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              )
            }
          }
        }

พร้อมใช้งานใน v3 แล้ว

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGeneratorType = "breakpad"
              breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }

Groovy

ก่อน

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGenerator {
                breakpad {
                  binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              }
            }
          }
        }

พร้อมใช้งานใน v3 แล้ว

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGeneratorType "breakpad"
              breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }

การสนับสนุนเฉพาะสำหรับ Android-NDK

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

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

หากคุณใช้ lld ลิงก์เกอร์จากชุดเครื่องมือ LLVM ให้เพิ่มสิ่งต่อไปนี้
```
-Wl,--no-rosegment
```
หากคุณใช้ ld.gold Linker จาก GNU Toolchain ให้เพิ่มสิ่งต่อไปนี้
```
-Wl,--rosegment
```

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

-fno-omit-frame-pointer

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

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

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

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

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

ปลั๊กอิน Gradle v3.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

การสนับสนุน Unity

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

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

ตรวจสอบว่าคุณใช้ Crashlytics Unity SDK เวอร์ชัน 8.6.1 ขึ้นไป
ตรวจสอบว่าคุณได้ตั้งค่าและเรียกใช้คำสั่ง FirebaseCLI crashlytics:symbols:upload เพื่อสร้างและอัปโหลดไฟล์ สัญลักษณ์แล้ว

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

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

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

ตรวจสอบว่าคุณใช้ Crashlytics Unity SDK เวอร์ชัน 8.6.0 ขึ้นไป
ทํางานที่จําเป็นสําหรับแพลตฟอร์มของคุณให้เสร็จสมบูรณ์
- สำหรับแอปแพลตฟอร์ม Apple: ไม่จำเป็นต้องดำเนินการใดๆ เป็นพิเศษ สำหรับแอปแพลตฟอร์ม Apple ปลั๊กอิน Firebase Unity Editor จะกำหนดค่าโปรเจ็กต์ Xcode โดยอัตโนมัติเพื่ออัปโหลดสัญลักษณ์
- สำหรับแอป Android: ตรวจสอบว่าคุณได้ตั้งค่าและเรียกใช้คำสั่ง Firebase CLI crashlytics:symbols:upload เพื่อสร้างและ อัปโหลดไฟล์สัญลักษณ์แล้ว
  
  คุณต้องเรียกใช้คำสั่ง CLI นี้ทุกครั้งที่สร้างบิลด์รุ่น หรือบิลด์ใดก็ตามที่คุณต้องการดู Stack Trace ที่มีสัญลักษณ์ในFirebaseคอนโซล ดูข้อมูลเพิ่มเติมได้ที่ รับรายงานข้อขัดข้องที่อ่านได้

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

Crashlytics สามารถรายงานข้อยกเว้นที่ไม่ได้จัดการเป็นข้อผิดพลาดร้ายแรง (เริ่มต้นด้วย Unity SDK v10.4.0) คำถามที่พบบ่อยต่อไปนี้จะช่วยอธิบายเหตุผลและแนวทางปฏิบัติแนะนำในการใช้ฟีเจอร์นี้

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

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

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

การสนับสนุนการผสานรวม

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

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

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

Firebase จะส่งออกข้อมูลไปยังตำแหน่งชุดข้อมูลที่คุณเลือกเมื่อตั้งค่าการส่งออกข้อมูลไปยัง BigQuery

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

พบปัญหาหลังจากอัปเกรดเป็นโครงสร้างพื้นฐานการส่งออกใหม่สำหรับ BigQuery ใช่ไหม

เมื่อกลางเดือนตุลาคม 2024 Crashlytics ได้เปิดตัวโครงสร้างพื้นฐานใหม่สำหรับการส่งออกแบบเป็นชุดของข้อมูล Crashlytics ไปยัง BigQuery

เราได้อัปเกรดโปรเจ็กต์ Firebase ทั้งหมดเป็นโครงสร้างพื้นฐานการส่งออกเป็นกลุ่มใหม่โดยอัตโนมัติตั้งแต่วันที่ 2 มีนาคม 2026

ความแตกต่างที่สำคัญระหว่างโครงสร้างพื้นฐานการส่งออกแบบเดิมกับโครงสร้างพื้นฐานการส่งออกแบบใหม่

โครงสร้างพื้นฐานใหม่รองรับCrashlyticsตำแหน่งชุดข้อมูลนอก สหรัฐอเมริกา
- เปิดใช้การส่งออกก่อนช่วงกลางเดือนตุลาคม 2024 และอัปเกรดเป็นโครงสร้างพื้นฐานการส่งออกใหม่ — ตอนนี้คุณสามารถเปลี่ยนตำแหน่งสำหรับการส่งออกข้อมูลได้แล้ว (ไม่บังคับ)
- เปิดใช้การส่งออกในช่วงกลางเดือนตุลาคม 2024 หรือหลังจากนั้น - ระบบแจ้งให้คุณเลือกระหว่างการตั้งค่าตำแหน่งที่จะส่งออกข้อมูล
โครงสร้างพื้นฐานใหม่ไม่รองรับการเติมข้อมูลย้อนหลังก่อนที่คุณเปิดใช้การส่งออก
- โครงสร้างพื้นฐานเดิมรองรับการแสดงโฆษณาสำรองย้อนหลังได้สูงสุด 30 วันก่อนวันที่คุณเปิดใช้การส่งออก
- โครงสร้างพื้นฐานใหม่รองรับการป้อนข้อมูลย้อนหลัง ได้สูงสุด 30 วันที่ผ่านมา หรือวันที่ล่าสุดเมื่อคุณเปิดใช้การส่งออก ไปยัง BigQuery (แล้วแต่ว่าวันที่ใดล่าสุด)
โครงสร้างพื้นฐานใหม่จะตั้งชื่อBigQueryตารางกลุ่มโดยใช้ตัวระบุที่ตั้งค่าไว้สำหรับแอป Firebase ในโปรเจ็กต์ Firebase
- โครงสร้างพื้นฐานเดิมจะเขียนข้อมูลลงในตารางกลุ่มที่มีชื่อตามรหัสแพ็กเกจหรือชื่อแพ็กเกจในไบนารีของแอป
- โครงสร้างพื้นฐานใหม่จะเขียนข้อมูลลงในตารางแบบกลุ่มโดยมีชื่อตาม Bundle ID หรือชื่อแพ็กเกจ ที่ตั้งค่าไว้สําหรับแอป Firebase ที่ลงทะเบียนในโปรเจ็กต์ Firebase

หากชื่อตารางกลุ่มข้อมูลเดิมไม่ตรงกับตัวระบุแอป Firebase

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

ทําความเข้าใจวิธีที่โครงสร้างพื้นฐานการส่งออกใช้ตัวระบุเพื่อเขียนข้อมูลลงในตาราง BigQuery

โครงสร้างพื้นฐานการส่งออกทั้ง 2 แบบจะเขียนCrashlyticsข้อมูลไปยังตารางแบบกลุ่ม BigQueryดังนี้

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

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

จะเกิดอะไรขึ้นหากไม่ได้แก้ไขก่อนอัปเกรด

หากตัวระบุใน 2 ตำแหน่งนี้ไม่ตรงกัน แสดงว่าเกิดสิ่งต่อไปนี้ ขึ้น

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

ตัวอย่างสถานการณ์ของตัวระบุที่ไม่ตรงกัน

โปรดทราบว่าระบบจะต่อท้ายชื่อตารางกลุ่มBigQueryโดยอัตโนมัติด้วย _IOSหรือ_ANDROIDเพื่อระบุแพลตฟอร์มของแอป

ตัวระบุในไบนารีของแอป	ตัวระบุที่ตั้งค่าไว้สำหรับแอป Firebase	ลักษณะการทำงานเดิม	ลักษณะการทำงานหลังการอัปเกรด เป็นโครงสร้างพื้นฐานการส่งออกใหม่	โซลูชัน
`foo`	`bar`	เขียนไปยังตารางเดียวที่ตั้งชื่อตามตัวระบุในไบนารีของแอป (`foo`)	สร้างแล้วเขียนลงในตารางเดียวซึ่งตั้งชื่อตาม ตัวระบุที่ตั้งค่าไว้สําหรับแอป Firebase (`bar`)	ใช้ตัวเลือกที่ 1 หรือ 2 ตามที่อธิบายไว้ด้านล่าง
`foo`	`bar`, `qux` ฯลฯ	เขียนไปยังตารางเดียวที่ตั้งชื่อตามตัวระบุในไบนารีของแอป (`foo`)	สร้าง* แล้วเขียนไปยังตารางหลายตารางซึ่งตั้งชื่อตาม ตัวระบุที่ตั้งค่าไว้สําหรับแอป Firebase (`bar`, `qux`, ฯลฯ)	ใช้ตัวเลือกที่ 2 ตามที่อธิบายไว้ด้านล่าง
`foo`, `baz` ฯลฯ	`bar`	เขียนไปยังตารางหลายรายการที่มีชื่อตามตัวระบุหลายรายการ ในไบนารีของแอป (`foo`, `baz` ฯลฯ)	สร้าง** แล้วเขียนข้อมูลของทุกแอปไปยังตารางเดียวชื่อ หลังจากชุดตัวระบุที่ตั้งไว้สําหรับแอป Firebase (`bar`)	ไม่สามารถใช้ตัวเลือกใดได้ คุณยังคงแยกความแตกต่างของข้อมูลจากแต่ละแอปภายในตารางเดียวได้โดยใช้`bundle_identifier`ของแอป ซึ่งจะส่งออกพร้อมกับข้อมูล

^{* หากตัวระบุในไบนารีของแอปตรงกับตัวระบุที่ตั้งค่าไว้สำหรับแอป Firebase อย่างใดอย่างหนึ่ง โครงสร้างพื้นฐานการส่งออกใหม่จะไม่สร้างตารางใหม่สำหรับตัวระบุดังกล่าว แต่จะเขียนข้อมูลสำหรับแอปนั้นๆ ลงในไดเรกทอรีต่อไป ระบบจะเขียนแอปอื่นๆ ทั้งหมดลงในตารางใหม่}

^{** หากตัวระบุตัวใดตัวหนึ่งในไบนารีของแอปตรงกับ
ชุดตัวระบุที่ตั้งค่าไว้สำหรับแอป Firebase โครงสร้างพื้นฐานการส่งออกใหม่จะไม่
สร้างตารางใหม่ แต่จะยังคงตารางนั้นไว้และเริ่มเขียน
ข้อมูลสำหรับแอปทั้งหมดลงในตาราง}

ตัวเลือกในการลดผลกระทบ

ตัวเลือกที่ 1:
ใช้ตารางใหม่ที่สร้างขึ้นโดยโครงสร้างพื้นฐานการส่งออกใหม่ คุณจะคัดลอกข้อมูลจากตารางเดิมไปยังตารางใหม่
1. ในGoogle Cloudคอนโซล คัดลอกข้อมูลทั้งหมด จากตารางเดิมไปยังตารางใหม่ที่สร้างขึ้นระหว่าง การอัปเกรดโครงสร้างพื้นฐาน
2. หากคุณมีทรัพยากร Dependency ที่ดาวน์สตรีมซึ่งขึ้นอยู่กับตารางกลุ่ม ให้เปลี่ยนไปใช้ตารางใหม่
หมายเหตุ: ระบบจะไม่เขียนข้อมูลใหม่ลงในตารางเดิม ระบบจะไม่ลบข้อมูลที่เขียนไว้ก่อนหน้านี้ในตารางเดิม
ตัวเลือกที่ 2:
กำหนดค่าใหม่เพื่อเขียนไปยังตารางเดิมอีกครั้ง คุณจะต้อง ลบล้างค่าเริ่มต้นบางอย่างในการกำหนดค่า BigQuery เพื่อให้ได้ผลลัพธ์นี้
1. ในFirebaseคอนโซล ให้ค้นหาและจดรหัสแอป Firebase (เช่น 1:1234567890:ios:321abc456def7890) ของแอปที่มี ชื่อตารางกลุ่มและตัวระบุไม่ตรงกัน
  ไปที่ การตั้งค่าโปรเจ็กต์ จากนั้นไปที่การ์ดแอปของคุณเพื่อดูแอป Firebase ทั้งหมดและ ข้อมูลของแอป
2. ในGoogle Cloud Console ให้เปลี่ยน "การกำหนดค่าการโอนข้อมูล" ใหม่ที่ สร้างขึ้นจากการอัปเกรดโครงสร้างพื้นฐานเพื่อให้ระบบเขียนข้อมูลลงในตารางเดิม
  1. ไปที่ BigQuery > การโอนข้อมูล เพื่อดู "การกำหนดค่าการโอนข้อมูล"
  2. เลือกการกำหนดค่าที่มีแหล่งที่มา Firebase Crashlytics with Multi-Region Support
  3. คลิกแก้ไขที่มุมขวาบน
  4. ในส่วนรายละเอียดแหล่งข้อมูล ให้ค้นหารายการสำหรับ gmp_app_id และรายการสำหรับ client_namespace
    
    ใน BigQuery รหัสแอป Firebase จะเรียกว่าgmp_app_id โดยค่าเริ่มต้น ค่า client_namespace ใน BigQuery คือรหัสชุด / ชื่อแพ็กเกจที่ไม่ซ้ำกันที่เกี่ยวข้องของแอป แต่คุณจะลบล้างการกำหนดค่าเริ่มต้นนี้
    
    BigQuery ใช้ค่า client_namespace เป็นชื่อของ ตารางกลุ่มที่แอป Firebase ที่ลิงก์แต่ละแอปเขียน
  5. ค้นหา gmp_app_id ของแอป Firebase ที่คุณต้องการ ลบล้างการตั้งค่าเริ่มต้น เปลี่ยนค่า client_namespace เป็น ชื่อของตารางที่คุณต้องการให้แอป Firebase เขียนแทน (โดยปกติจะเป็นชื่อของตารางเดิมที่แอปเขียน ด้วยโครงสร้างพื้นฐานการส่งออกเดิม)
    
    หมายเหตุ: หากก่อนหน้านี้คุณเขียนข้อมูลลงในตารางเดียวและตอนนี้มีหลายตารางหลังจากอัปเกรด คุณสามารถใช้ตารางเดียวกัน client_namespaceสำหรับแต่ละgmp_app_idที่เกี่ยวข้องได้ BigQuery จะผสานตารางทั้งหมดและเขียนข้อมูลทั้งหมดสําหรับ แอป Firebase ทั้งหมดลงในตารางเดียว
  6. บันทึกการเปลี่ยนแปลงการกำหนดค่า
3. กำหนดเวลาการป้อนข้อมูลย้อนหลัง สำหรับวันที่ตารางเดิมไม่มีข้อมูล
4. เมื่อการเติมข้อมูลย้อนหลังเสร็จสมบูรณ์ ให้ ลบตารางใหม่ ที่โครงสร้างพื้นฐานการส่งออกใหม่สร้างขึ้นโดยอัตโนมัติ

การแก้ปัญหา/คำถามที่พบบ่อยทั่วไป

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

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

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

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

ระบบคำนวณผู้ใช้ที่ไม่มีข้อขัดข้องอย่างไร

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

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

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

การสนับสนุนเฉพาะแพลตฟอร์ม

การรองรับแพลตฟอร์ม Apple

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

ข้อขัดข้องมีสัญลักษณ์ไม่ถูกต้อง

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

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

การสนับสนุน Android

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

เหตุใด ANR บางรายการจึงไม่มี BuildId

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

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

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

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

วิธีอัปเกรดเป็นปลั๊กอิน Crashlytics Gradle v3

ข้อกำหนดขั้นต่ำ

Kotlin

Groovy

การเปลี่ยนแปลงส่วนขยาย Crashlytics

ตัวอย่างวิธีอัปเกรดส่วนขยาย

Kotlin

Groovy

การสนับสนุนเฉพาะสำหรับ Android-NDK

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

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

ปลั๊กอิน Gradle v3.0.0 ขึ้นไป

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

Crashlytics รองรับ armeabi ไหม

การสนับสนุน Unity

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

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

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

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

ระบบจะรายงานข้อยกเว้นใดเป็นข้อผิดพลาดร้ายแรง

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

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

การสนับสนุนการผสานรวม

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

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

พบปัญหาหลังจากอัปเกรดเป็นโครงสร้างพื้นฐานการส่งออกใหม่สำหรับ BigQuery ใช่ไหม

ความแตกต่างที่สำคัญระหว่างโครงสร้างพื้นฐานการส่งออกแบบเดิมกับโครงสร้างพื้นฐานการส่งออกแบบใหม่

หากชื่อตารางกลุ่มข้อมูลเดิมไม่ตรงกับตัวระบุแอป Firebase

ทําความเข้าใจวิธีที่โครงสร้างพื้นฐานการส่งออกใช้ตัวระบุเพื่อเขียนข้อมูลลงในตาราง BigQuery

จะเกิดอะไรขึ้นหากไม่ได้แก้ไขก่อนอัปเกรด

ตัวอย่างสถานการณ์ของตัวระบุที่ไม่ตรงกัน

ตัวเลือกในการลดผลกระทบ

เหตุใด ANR บางรายการจึงไม่มี `BuildId`

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

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