iOS+
Android
Flutter
Unity
หน้านี้จะให้ความช่วยเหลือในการแก้ปัญหาและตอบคำถามที่พบบ่อยเกี่ยวกับการใช้ Crashlytics หากไม่พบสิ่งที่ต้องการหรือต้องการความช่วยเหลือเพิ่มเติม โปรดติดต่อทีมสนับสนุน Firebase
การแก้ปัญหา/คำถามที่พบบ่อยทั่วไป
ไม่เห็นบันทึกเบรดครัมบ์
หากไม่เห็นบันทึกเส้นทาง
เราขอแนะนำให้ตรวจสอบการกำหนดค่าของแอปสำหรับ Google Analytics
โปรดตรวจสอบว่าคุณมีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้
ไม่เห็นการแจ้งเตือนอัตราความเร็ว
หากไม่เห็นการแจ้งเตือนความเร็ว โปรดตรวจสอบว่าคุณใช้
Crashlytics SDK เวอร์ชัน 11.7.0 ขึ้นไป
ไม่เห็นเมตริกแบบไม่มีข้อขัดข้อง (หรือเห็นเมตริกที่ไม่น่าเชื่อถือ)
หากไม่เห็นเมตริกที่ไม่มีข้อขัดข้อง (เช่น ผู้ใช้และเซสชันที่ไม่มีข้อขัดข้อง) หรือเห็นเมตริกที่ไม่น่าเชื่อถือ ให้ตรวจสอบสิ่งต่อไปนี้
การเห็นสแต็กเทรซที่ไม่ได้ทำสัญลักษณ์
สำหรับแอป Android ในแดชบอร์ด Crashlytics
หากคุณใช้ Unity IL2CPP
และเห็น Stack Trace ที่ไม่ได้ทำสัญลักษณ์ ให้ลองทำดังนี้
ตรวจสอบว่าคุณใช้ Crashlytics Unity
SDK เวอร์ชัน 8.6.1 ขึ้นไป
ตรวจสอบว่าคุณได้ตั้งค่าและเรียกใช้คำสั่ง Firebase CLI
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 ดูข้อมูลเพิ่มเติมได้ในหน้ารับรายงานข้อขัดข้องที่อ่านได้
ใครดู เขียน และลบหมายเหตุในปัญหาได้บ้าง
หมายเหตุช่วยให้สมาชิกโปรเจ็กต์แสดงความคิดเห็นเกี่ยวกับปัญหาที่เฉพาะเจาะจงได้ด้วยคำถาม การอัปเดตสถานะ
และอื่นๆ
เมื่อสมาชิกในโปรเจ็กต์โพสต์โน้ต ระบบจะติดป้ายกำกับด้วยอีเมลของบัญชี Google
อีเมลนี้จะแสดงพร้อมกับหมายเหตุต่อสมาชิกโปรเจ็กต์ทั้งหมดที่มีสิทธิ์ดูหมายเหตุ
ต่อไปนี้จะอธิบายสิทธิ์เข้าถึงที่จำเป็นในการดู เขียน และลบ
โน้ต
การผสานรวม
แอปยังใช้ SDK Google Mobile Ads แต่ไม่พบข้อขัดข้อง
หากโปรเจ็กต์ใช้ Crashlytics ควบคู่กับ SDK ของ Google Mobile Ads
มีแนวโน้มที่เครื่องมือรายงานข้อขัดข้องจะรบกวนเมื่อ
ลงทะเบียนตัวแฮนเดิลข้อยกเว้น หากต้องการแก้ไขปัญหานี้ ให้ปิดการรายงานข้อขัดข้องใน SDK ของ Mobile Ads โดยเรียกใช้ disableSDKCrashReporting
ชุดข้อมูล BigQuery ของฉันอยู่ที่ไหน
หลังจากลิงก์ Crashlytics กับ BigQuery แล้ว ชุดข้อมูลใหม่ที่คุณสร้างจะอยู่ในสหรัฐอเมริกาโดยอัตโนมัติ ไม่ว่าโปรเจ็กต์ Firebase จะอยู่ที่ใด
ปัญหาเดิม
ปัญหาที่ถดถอยคืออะไร
ปัญหาเกิดการถดถอยเมื่อคุณปิดปัญหาไปก่อนหน้านี้ แต่
Crashlytics ได้รับรายงานใหม่ว่าปัญหาเกิดขึ้นอีกครั้ง
Crashlytics จะเปิดปัญหาที่ถดถอยเหล่านี้อีกครั้งโดยอัตโนมัติเพื่อให้คุณ
แก้ไขปัญหาตามความเหมาะสมกับแอปของคุณ
ต่อไปนี้คือสถานการณ์ตัวอย่างที่อธิบายวิธีที่ Crashlytics จัดหมวดหมู่ปัญหาเป็นรีเกรสชัน
เป็นครั้งแรกที่ Crashlytics ได้รับรายงานข้อขัดข้องเกี่ยวกับข้อขัดข้อง "ก"
Crashlytics จะเปิดปัญหาที่เกี่ยวข้องกับการขัดข้องนั้น (ปัญหา "ก")
คุณแก้ไขข้อบกพร่องนี้อย่างรวดเร็ว ปิดปัญหา "ก" แล้วเผยแพร่แอปเวอร์ชันใหม่
Crashlytics ได้รับรายงานอีกฉบับเกี่ยวกับปัญหา "ก" หลังจากที่คุณปิดปัญหาแล้ว
หากรายงานมาจากแอปเวอร์ชันที่ Crashlytics ทราบ
เมื่อคุณปิดปัญหา (หมายความว่าเวอร์ชันได้ส่งรายงานข้อขัดข้อง
สำหรับข้อขัดข้องใดๆ ) Crashlytics จะไม่ถือว่าปัญหา
ดังกล่าวเป็นปัญหาที่เกิดซ้ำ เราจะปิดปัญหาต่อไป
หากรายงานมาจากแอปเวอร์ชันที่ Crashlytics ไม่ทราบ
เกี่ยวกับ เมื่อคุณปิดปัญหา (หมายความว่าเวอร์ชันไม่เคย ส่งรายงานข้อขัดข้องใดๆ สำหรับข้อขัดข้องใดๆ เลย) Crashlytics จะถือว่าปัญหาเกิดซ้ำและจะเปิดปัญหาอีกครั้ง
หมายเหตุ: ก่อนเดือนกุมภาพันธ์ 2022 Crashlytics จัดประเภทปัญหาเป็นการ
ถดถอยเมื่อปัญหานั้นเกิดขึ้นอีกครั้งในแอปเวอร์ชันใดก็ได้ แม้ว่าจะเป็นแอป
เวอร์ชันที่เราทราบเมื่อคุณปิดปัญหาแล้วก็ตาม ซึ่งส่งผลให้Crashlytics ระบุการถดถอยไม่ถูกต้องในบางครั้ง ตอนนี้เราใช้
รูปแบบที่อธิบายไว้ข้างต้น เมื่อเกิดปัญหาซ้ำ เราจะส่งการแจ้งเตือนการตรวจหาการเกิดซ้ำและเพิ่ม
สัญญาณการเกิดซ้ำลงในปัญหาเพื่อแจ้งให้คุณทราบว่า Crashlytics ได้
เปิดปัญหาอีกครั้ง หากไม่ต้องการให้ระบบเปิดปัญหาอีกครั้งเนื่องจาก
อัลกอริทึมการถดถอยของเรา ให้ "ปิดเสียง" ปัญหาแทนการปิด
เหตุใดฉันจึงเห็นปัญหาที่ถดถอย
สำหรับแอปเวอร์ชันเก่า
หากรายงานมาจากแอปเวอร์ชันเก่าที่ไม่เคยส่งรายงานข้อขัดข้องเลยเมื่อคุณปิดปัญหา Crashlytics จะถือว่าปัญหาดังกล่าวCrashlytics กลับมาเกิดซ้ำและจะเปิดปัญหาอีกครั้ง
สถานการณ์นี้อาจเกิดขึ้นในกรณีต่อไปนี้ คุณแก้ไขข้อบกพร่องและ
เผยแพร่แอปเวอร์ชันใหม่แล้ว แต่ยังมีผู้ใช้ที่ใช้แอปเวอร์ชันเก่า
ที่ไม่มีการแก้ไขข้อบกพร่อง หากเวอร์ชันเก่าเหล่านั้นไม่เคย ส่งรายงานข้อขัดข้องเลยเมื่อคุณปิดปัญหา และผู้ใช้เริ่มพบข้อบกพร่อง รายงานข้อขัดข้องเหล่านั้นจะทําให้เกิดปัญหาที่ถดถอย
หากไม่ต้องการให้ระบบเปิดปัญหาอีกครั้งเนื่องจากอัลกอริทึมการถดถอยของเรา ให้ "ปิดเสียง"
ปัญหาแทนการปิด
หมายเหตุ: ก่อนเดือนกุมภาพันธ์ 2022 Crashlytics จะจัดประเภทปัญหาเป็น
การถดถอยเมื่อปัญหานั้นเกิดขึ้นอีกครั้งในแอปเวอร์ชันใดก็ตาม แม้ว่าจะเป็นแอปเวอร์ชัน
ที่เราทราบเมื่อคุณปิดปัญหาแล้วก็ตาม ซึ่งส่งผลให้Crashlytics
บางครั้งระบุการถดถอยอย่างไม่ถูกต้อง ตอนนี้เราใช้รูปแบบ
ที่อธิบายไว้ข้างต้น
รายงานข้อยกเว้นที่ไม่ได้แคชเป็นข้อผิดพลาดร้ายแรง Crashlytics สามารถรายงานข้อยกเว้นที่ไม่ได้จัดการเป็นข้อผิดพลาดร้ายแรง (เริ่มต้นด้วย Unity SDK v10.4.0 ) คำถามที่พบบ่อยต่อไปนี้จะช่วยอธิบายเหตุผลและแนวทางปฏิบัติแนะนำในการใช้ฟีเจอร์นี้
เหตุใดแอปจึงควรรายงานข้อยกเว้นที่ไม่ได้จัดการเป็นข้อผิดพลาดร้ายแรง
การรายงานข้อยกเว้นที่ไม่ได้แคชเป็นข้อผิดพลาดร้ายแรงจะช่วยให้คุณทราบถึงข้อบ่งชี้ที่สมจริงมากขึ้น
ว่าข้อยกเว้นใดที่อาจส่งผลให้เกมเล่นไม่ได้ แม้ว่าแอปจะยังคงทำงานต่อไปก็ตาม
โปรดทราบว่าหากเริ่มรายงานข้อผิดพลาดร้ายแรง เปอร์เซ็นต์ผู้ใช้ที่ไม่พบข้อขัดข้อง (CFU)
อาจลดลง แต่เมตริก CFU จะแสดงถึงประสบการณ์ของผู้ใช้ปลายทาง
ที่มีต่อแอปของคุณได้ดีขึ้น
สำคัญ: การรายงานข้อยกเว้นที่ไม่ได้แคชเป็นข้อผิดพลาดร้ายแรงไม่มี Android Vitals
ข้อผิดพลาดร้ายแรงที่รายงานใน Crashlytics จะแสดงต่อคุณเท่านั้นเพื่อให้คุณค้นพบและแก้ไขปัญหาในแอปและเกมได้
ระบบจะรายงานข้อยกเว้นใดเป็นข้อยกเว้นที่ร้ายแรง
หากต้องการให้ Crashlytics รายงานข้อยกเว้นที่ไม่ได้แคชเป็นข้อผิดพลาดร้ายแรง จะต้องเป็นไปตามเงื่อนไขทั้ง 2 ข้อต่อไปนี้
ในระหว่างการเริ่มต้นในแอป คุณต้องตั้งค่าพร็อพเพอร์ตี้ ReportUncaughtExceptionsAsFatal
เป็น
true
แอป (หรือไลบรารีที่รวมไว้) แสดงข้อยกเว้นที่ไม่ได้ตรวจพบ ระบบจะไม่ถือว่าข้อยกเว้นที่สร้างขึ้นแต่ไม่ได้ส่ง เป็นข้อยกเว้นที่ไม่ได้จัดการ
หลังจากเปิดใช้การรายงานข้อยกเว้นที่ไม่ได้จัดการเป็นข้อผิดพลาดร้ายแรง ตอนนี้ฉันมีข้อผิดพลาดร้ายแรงใหม่ๆ มากมาย ฉันจะจัดการข้อยกเว้นเหล่านี้อย่างถูกต้องได้อย่างไร
เมื่อเริ่มได้รับรายงานข้อยกเว้นที่ไม่ได้แคชเป็นข้อผิดพลาดร้ายแรง คุณมีตัวเลือกในการจัดการข้อยกเว้นที่ไม่ได้แคชเหล่านี้ดังนี้
ดักจับและจัดการข้อยกเว้นที่เกิดขึ้น ระบบจะสร้างและส่งข้อยกเว้นเพื่อแสดงสถานะที่ไม่คาดคิดหรือผิดปกติ
การแก้ไขปัญหาที่เกิดจากข้อยกเว้นที่ส่งคืนเกี่ยวข้องกับการนำโปรแกรมกลับสู่สถานะที่ทราบ (กระบวนการที่เรียกว่าการจัดการข้อยกเว้น
แนวทางปฏิบัติแนะนำคือการตรวจหาและจัดการข้อยกเว้นที่คาดการณ์ไว้ทั้งหมด เว้นแต่โปรแกรมจะกลับสู่สถานะที่ทราบไม่ได้
หากต้องการควบคุมว่าโค้ดใดจะตรวจหาและจัดการข้อยกเว้นประเภทใด
ให้รวมโค้ดที่อาจสร้างข้อยกเว้นไว้ในบล็อก 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
โปรดทราบว่าหากต้องการพิมพ์ข้อยกเว้นที่ตรวจพบไปยังคอนโซล 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
//
}
