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

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

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

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

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

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

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

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

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

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

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

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

สิ่งที่คุณจะได้รับจากการปรับปรุงเหล่านี้มีดังนี้

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

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

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

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

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

หากไม่เห็นบันทึกเบรดครัมบ์ (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+)

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

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

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

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

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

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

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

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

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

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

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

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

ปัญหาที่เกิดซ้ำคืออะไร

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

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

เป็นครั้งแรกที่ Crashlytics ได้รับรายงานข้อขัดข้องเกี่ยวกับข้อขัดข้อง "A" Crashlytics จะเปิดปัญหาที่เกี่ยวข้องกับการขัดข้องนั้น (ปัญหา "A")
คุณแก้ไขข้อบกพร่องนี้อย่างรวดเร็ว ปิดปัญหา "A" แล้วเผยแพร่แอปเวอร์ชันใหม่
Crashlytics ได้รับรายงานอีกฉบับเกี่ยวกับปัญหา "A" หลังจากที่คุณปิดปัญหาแล้ว
- หากรายงานมาจากแอปเวอร์ชันที่ 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 ที่ระบุในแท็บ dSYM
หากยังคงเห็น 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 และปลั๊กอิน Gradle เวอร์ชัน Crashlytics ล่าสุด

หากคุณไม่เห็น 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

จนกระทั่งเมื่อไม่นานมานี้ เครื่องมือสร้างความสับสนที่มีอยู่ไม่ได้แสดงนามสกุลไฟล์ ดังนั้น 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
```

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

ปลั๊กอิน Gradle ของ Crashlytics รุ่นล่าสุดเป็นเวอร์ชันหลัก (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 มีการเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบดังต่อไปนี้

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

ความแตกต่างระหว่างสแต็กเทรซ NDK ในแดชบอร์ด Crashlytics และ Logcat

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

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

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

-fno-omit-frame-pointer

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

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

คุณระบุเส้นทางไปยังไบนารีของเครื่องมือสร้างไฟล์สัญลักษณ์ Breakpad ได้ 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

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

คุณสามารถอัปเดตไฟล์พร็อพเพอร์ตี้ Gradle ด้วยตนเองหรืออัปเดตไฟล์ผ่านบรรทัดคำสั่งก็ได้ เช่น หากต้องการระบุเส้นทางผ่านบรรทัดคำสั่ง ให้ใช้คำสั่งต่อไปนี้
```
./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 และเห็นสแต็กเทรซที่ไม่มีสัญลักษณ์ ให้ลองทำดังนี้

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

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

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

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

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

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

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

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

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

โปรดทราบว่าหากคุณเริ่มรายงานข้อขัดข้องร้ายแรง เปอร์เซ็นต์ผู้ใช้ที่ไม่พบข้อขัดข้อง (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 แต่จะแสดงข้อยกเว้นด้วย (ไม่ว่าจะแสดงหรือตรวจพบหรือไม่ก็ตาม) โดยจะแสดงข้อผิดพลาด แบบไม่จำกัดเฉพาะที่ ซึ่งหมายความว่าแม้แต่ 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
- โครงสร้างพื้นฐานแบบเก่าจะเขียนข้อมูลลงในตารางกลุ่มที่มีชื่อตามรหัสชุดหรือชื่อแพ็กเกจในไบนารีของแอป
- โครงสร้างพื้นฐานใหม่จะเขียนข้อมูลลงในตารางแบบกลุ่มที่มีชื่อตามรหัสชุดหรือชื่อแพ็กเกจที่ตั้งค่าไว้สำหรับแอป Firebase ที่ลงทะเบียนในโปรเจ็กต์ Firebase

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

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

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

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

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

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

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

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

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

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

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

ตัวระบุในไบนารีของแอป	ตัวระบุที่ตั้งค่าไว้สําหรับแอป 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 ให้เปลี่ยน "การกำหนดค่าการโอนข้อมูล" ใหม่ที่สร้างขึ้นโดยการอัปเกรดโครงสร้างพื้นฐานเพื่อให้ระบบเขียนข้อมูลลงในตารางเดิม ดังนี้
  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

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

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

Kotlin

Groovy

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

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

Kotlin

Groovy

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

ความแตกต่างระหว่างสแต็กเทรซ 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` รายการที่มีอยู่