iOS
Android
Flutter
Unity
หน้านี้ให้ความช่วยเหลือในการแก้ปัญหาและคำตอบสำหรับคำถามที่พบบ่อยเกี่ยวกับการใช้ Crashlytics หากไม่พบสิ่งที่ต้องการหรือต้องการความช่วยเหลือเพิ่มเติม โปรดติดต่อทีมสนับสนุน Firebase
การแก้ปัญหาทั่วไป/คําถามที่พบบ่อย
ไม่เห็นเมตริกและ/หรือการแจ้งเตือนความเร็วที่ไม่มีข้อขัดข้อง
หากคุณไม่เห็นเมตริกที่ไม่มีข้อขัดข้อง (เช่น ผู้ใช้และเซสชันที่ไม่พบข้อขัดข้อง)
และ/หรือการแจ้งเตือนอัตราความเร็ว โปรดตรวจสอบว่าคุณกำลังใช้
Crashlytics SDK 11.7.0 ขึ้นไป
ไม่เห็นบันทึกเบรดครัมบ์
หากคุณไม่เห็นตำแหน่ง
บันทึกเบรดครัมบ์
เราขอแนะนำให้ตรวจสอบการกำหนดค่าของแอปสำหรับ Google Analytics
โปรดตรวจสอบว่าคุณมีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้
เห็นสิ่งไม่มีสัญลักษณ์
สแต็กเทรซสำหรับแอป Android ในแดชบอร์ดของ Crashlytics
หากคุณใช้ Unity IL2CPP
และเห็นสแต็กเทรซที่ไม่มีสัญลักษณ์ ให้ลองทำดังนี้
ตรวจสอบว่าคุณใช้ Crashlytics Unity
SDK เวอร์ชัน 8.6.1 ขึ้นไป
ตรวจสอบว่าคุณได้ตั้งค่าและเรียกใช้คำสั่ง Firebase CLI
crashlytics:symbols:upload เพื่อสร้างและอัปโหลดไฟล์สัญลักษณ์แล้ว
คุณต้องเรียกใช้คําสั่ง CLI นี้ทุกครั้งที่สร้างบิวด์รุ่นหรือบิวด์ที่ต้องการดูสแต็กเทรซที่แปลงสัญลักษณ์ในคอนโซล Firebase ดูข้อมูลเพิ่มเติมใน
รับรายงานข้อขัดข้องที่อ่านได้
Crashlytics ใช้กับแอปที่ใช้ IL2CPP ได้ไหม
ได้ Crashlytics สามารถแสดงสแต็กเทรซที่แทนที่ด้วยสัญลักษณ์สำหรับแอปที่
ใช้ IL2CPP ความสามารถนี้พร้อมใช้งานสำหรับแอปที่เผยแพร่ในแพลตฟอร์ม Android หรือ Apple สิ่งที่ต้องทำมีดังนี้
ตรวจสอบว่าคุณใช้ Crashlytics Unity เวอร์ชัน 8.6.0 ขึ้นไป
SDK
ทำงานที่จำเป็นสำหรับแพลตฟอร์มของคุณให้เสร็จสมบูรณ์
สำหรับแอปบนแพลตฟอร์ม Apple : คุณไม่ต้องดำเนินการใดๆ เป็นพิเศษ สําหรับแอปแพลตฟอร์ม Apple ปลั๊กอิน Firebase Unity Editor จะกําหนดค่าโปรเจ็กต์ Xcode ให้อัปโหลดสัญลักษณ์โดยอัตโนมัติ
สำหรับแอป Android : ตรวจสอบว่าคุณได้ตั้งค่าและเรียกใช้คำสั่ง Firebase CLI crashlytics:symbols:upload เพื่อสร้างและอัปโหลดไฟล์สัญลักษณ์แล้ว
คุณต้องเรียกใช้คําสั่ง CLI นี้ทุกครั้งที่สร้างบิวด์รุ่นหรือบิวด์ที่ต้องการดูสแต็กเทรซที่แปลงสัญลักษณ์ในคอนโซล Firebase ดูข้อมูลเพิ่มเติมได้ในหน้าดูรายงานข้อขัดข้องที่อ่านได้
ระบบคำนวณผู้ใช้ที่ไม่พบข้อขัดข้องอย่างไร
ค่า "ไม่พบข้อขัดข้อง" แสดงเปอร์เซ็นต์ของผู้ใช้ที่มีส่วนร่วมกับแอปแต่ไม่
สูตรการคำนวณเปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้องมีดังนี้ ข้อมูลที่ป้อน
ค่ามาจาก Google Analytics
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS ) x 100
เมื่อเกิดข้อขัดข้อง Google Analytics จะส่งเหตุการณ์ประเภท app_exception และ CRASHED_USERS จะแสดงจํานวนผู้ใช้ที่เชื่อมโยงกับเหตุการณ์ประเภทนั้น
ALL_USERS แสดงจำนวนผู้ใช้ทั้งหมดที่มีส่วนร่วม
ในช่วงเวลาที่คุณเลือกจากเมนูแบบเลื่อนลงใน
ที่ด้านขวาบนของแดชบอร์ด Crashlytics
หมายเหตุ: หากต้องการคำนวณเปอร์เซ็นต์ผู้ใช้ที่ไม่พบข้อขัดข้องในแอปด้วยตัวเอง
คุณจะเห็นจำนวนเหตุการณ์ app_exception เหตุการณ์สำหรับแอปของคุณใน
หน้าแดชบอร์ด Analytics แต่เนื่องจากข้อขัดข้องมีความแตกต่างกันเล็กน้อย
ประมวลผลแล้ว ค่า app_exception ที่แสดงในแดชบอร์ด Analytics
บางครั้งอาจแตกต่างจากค่าที่เราใช้ในการคำนวณการปราศจากการขัดข้อง
เปอร์เซ็นต์ผู้ใช้ เปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้องคือการรวบรวมข้อมูลเมื่อเวลาผ่านไป ไม่ใช่ค่าเฉลี่ย
ตัวอย่างเช่น สมมติว่าแอปของคุณมีผู้ใช้ 3 ราย เราจะเรียกผู้ใช้เหล่านั้นว่าผู้ใช้ ก ผู้ใช้ ข และผู้ใช้ ค ตารางต่อไปนี้แสดงผู้ใช้ที่มีส่วนร่วมกับแอปในแต่ละวัน และผู้ใช้รายใดที่พบข้อขัดข้องในวันนั้น
จันทร์
อังคาร
พุธ
ผู้ใช้ที่มีส่วนร่วมกับแอปของคุณ
A, B, C
A, B, C
A, B
ผู้ใช้ที่พบการขัดข้อง
C
B
A
ในวันพุธ เปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้องคือ 50% (ผู้ใช้ 1 ใน 2 คนไม่พบข้อขัดข้อง)ผู้ใช้ 2 คนมีส่วนร่วมกับแอปของคุณในวันพุธ แต่เป็นผู้ใช้เพียงรายเดียว
(ผู้ใช้ ข) ไม่พบข้อขัดข้อง
เปอร์เซ็นต์ผู้ใช้ที่ไม่พบข้อขัดข้องในช่วง 2 วันที่ผ่านมาคือ 33.3% (1 จาก 3
ที่ผู้ใช้ไม่พบข้อขัดข้อง)ผู้ใช้ 3 คนมีส่วนร่วมกับแอปของคุณในช่วง 2 วันที่ผ่านมา แต่มีเพียง
หนึ่งในนั้น (ผู้ใช้ C) ไม่มีปัญหาใดๆ
เปอร์เซ็นต์ผู้ใช้ที่ไม่พบข้อขัดข้องในช่วง 3 วันที่ผ่านมาคือ 0% (0 จาก 3
ที่ผู้ใช้ไม่พบข้อขัดข้อง)ผู้ใช้ 3 รายมีส่วนร่วมกับแอปในช่วง 3 วันที่ผ่านมา แต่ ไม่มีผู้ใช้รายใดพบข้อขัดข้อง
ไม่ควรเปรียบเทียบค่าผู้ใช้ที่ไม่ได้รับผลจากความขัดข้องในช่วงเวลาต่างๆ
ความน่าจะเป็นของผู้ใช้รายเดียวที่จะประสบการขัดข้องก็เพิ่มขึ้นตามไปด้วย
ดังนั้นมูลค่าผู้ใช้ที่ไม่พบข้อขัดข้องจึงมีแนวโน้มที่จะลดลงเป็นเวลานานขึ้น
ระยะเวลา
หมายเหตุ: คุณจะเห็นการ์ดสถิติที่ไม่มีการขัดข้อง ว่างเปล่าหากกรองประเภทเหตุการณ์ เป็นปัญหาที่ไม่ร้ายแรงเท่านั้น เปอร์เซ็นต์ผู้ใช้ที่ไม่พบข้อขัดข้องคือ
ที่คำนวณเพื่อหาเหตุการณ์ร้ายแรง
ใครดู เขียน และลบหมายเหตุเกี่ยวกับปัญหาได้บ้าง
หมายเหตุช่วยให้สมาชิกโปรเจ็กต์แสดงความคิดเห็นเกี่ยวกับปัญหาที่เฉพาะเจาะจงได้ พร้อมคำถาม สถานะ การอัปเดต ฯลฯ
เมื่อสมาชิกโครงการโพสต์หมายเหตุจะมีป้ายกำกับเป็นอีเมล
ของคุณได้ อีเมลนี้จะปรากฏพร้อมกับโน้ตของทุกโปรเจ็กต์
สมาชิกที่มีสิทธิ์ดูโน้ต
สิทธิ์เข้าถึงที่จําเป็นในการดู เขียน และลบโน้ตมีดังนี้
ใครสามารถดู เขียน และลบบันทึกเกี่ยวกับปัญหา
หมายเหตุช่วยให้สมาชิกโปรเจ็กต์แสดงความคิดเห็นเกี่ยวกับปัญหาที่เฉพาะเจาะจงได้ พร้อมคำถาม สถานะ การอัปเดต ฯลฯ
เมื่อสมาชิกโครงการโพสต์หมายเหตุจะมีป้ายกำกับเป็นอีเมล
ของคุณได้ อีเมลนี้จะปรากฏพร้อมกับโน้ตของทุกโปรเจ็กต์
สมาชิกที่มีสิทธิ์ดูโน้ต
สิทธิ์เข้าถึงที่จําเป็นในการดู เขียน และลบโน้ตมีดังนี้
การผสานรวม
แอปใช้ Google Mobile Ads SDK ด้วย แต่ไม่มีการขัดข้อง
หากโปรเจ็กต์ใช้ Crashlytics ร่วมกับ SDK ของ Google Mobile Ads ก็มีความเป็นไปได้ว่าเครื่องมือรายงานข้อขัดข้องจะรบกวนเมื่อลงทะเบียนตัวแฮนเดิลข้อยกเว้น ในการแก้ไขปัญหานี้ ให้ปิดการรายงานข้อขัดข้องใน
Mobile Ads SDK โดยเรียกใช้ disableSDKCrashReporting
ชุดข้อมูล BigQuery ของฉันอยู่ที่ไหน
หลังจากที่ลิงก์ Crashlytics กับ BigQuery ชุดข้อมูลใหม่ที่คุณสร้างจะเป็น
อัตโนมัติในสหรัฐอเมริกา ไม่ว่าสถานที่ตั้งของ
โปรเจ็กต์ Firebase
ปัญหาเดิม
การถดถอยคืออะไร
ปัญหาเคยมีการถดถอยเมื่อคุณปิดปัญหาไปก่อนหน้านี้แต่
Crashlytics ได้รับรายงานใหม่ว่าเกิดปัญหาขึ้นซ้ำ
Crashlytics จะเปิดปัญหาเดิมอีกครั้งโดยอัตโนมัติเพื่อให้คุณสามารถ
จัดการตามความเหมาะสมสำหรับแอปของคุณ
ต่อไปนี้เป็นตัวอย่างสถานการณ์ที่อธิบายวิธีที่ Crashlytics จัดหมวดหมู่ปัญหาเป็นการถดถอย
Crashlytics ได้รับรายงานข้อขัดข้องเกี่ยวกับข้อขัดข้องเป็นครั้งแรกเป็นครั้งแรก
"A" Crashlytics เปิดปัญหาที่เกี่ยวข้องกับข้อขัดข้องดังกล่าว (ปัญหา "A")คุณแก้ไขข้อบกพร่องนี้อย่างรวดเร็ว ปิดปัญหา "ก" แล้วเผยแพร่เวอร์ชันใหม่
แอปของคุณ
Crashlytics ได้รับรายงานอีกฉบับเกี่ยวกับปัญหา "A" หลังจากปิด
ปัญหา
หากรายงานมาจากเวอร์ชันแอปที่ Crashlytics รู้จัก
เมื่อคุณปิดปัญหาแล้ว (หมายความว่าเวอร์ชันได้ส่งข้อขัดข้อง
สำหรับข้อขัดข้องใดๆ เลย) Crashlytics จะไม่พิจารณา
ว่าเกิดปัญหาซ้ำ ปัญหานี้จะยังคงปิดอยู่
หากรายงานมาจากเวอร์ชันแอปที่ Crashlytics ไม่ ล่วงรู้ไม่เคย ส่งรายงานข้อขัดข้องใดๆ เกี่ยวกับข้อขัดข้องใดๆ เลย) Crashlytics จะถือว่าปัญหากลับมาอีกครั้งและจะเปิดปัญหาดังกล่าวขึ้นมาใหม่
หมายเหตุ: ก่อนเดือนกุมภาพันธ์ 2022 Crashlytics จะจัดหมวดหมู่ปัญหาเป็นการถดถอยเมื่อปัญหานั้นเกิดขึ้นอีกครั้งในเวอร์ชันใดก็ได้ ของแอป แม้กระทั่งเวอร์ชันที่เราทราบเมื่อคุณปิดปัญหาแล้ว ส่งผลให้ Crashlytics ระบุการถดถอยอย่างไม่ถูกต้องในบางครั้ง ตอนนี้เราใช้
ดังที่อธิบายไว้ข้างต้น เมื่อปัญหากลับมาเกิดขึ้นอีก เราจะส่งการแจ้งเตือนการตรวจหาการเกิดซ้ำและเพิ่มสัญญาณการเกิดซ้ำลงในปัญหาเพื่อแจ้งให้ทราบว่า Crashlytics ได้เปิดปัญหาขึ้นมาอีกครั้ง หากคุณไม่ต้องการให้ปัญหาเปิดขึ้นใหม่เนื่องจาก
อัลกอริทึมการถดถอย "ปิดเสียง" ปัญหาแทนที่จะปิดไปเฉยๆ
ทำไมฉันจึงเห็นการถดถอย
สำหรับแอปเวอร์ชันเก่า
หากรายงานมาจากแอปเวอร์ชันเก่าที่ไม่เคยส่งรายงานข้อขัดข้อง
ทั้งหมดเมื่อคุณปิดปัญหาแล้ว Crashlytics จะพิจารณาปัญหา
เกิดปัญหาซ้ำและจะเปิดปัญหาอีกครั้ง
สถานการณ์นี้อาจเกิดขึ้นได้ในสถานการณ์ต่อไปนี้: คุณได้แก้ไขข้อบกพร่องและ
เปิดตัวแอปเวอร์ชันใหม่แล้ว แต่คุณยังมีผู้ใช้เวอร์ชันเก่าอยู่
โดยไม่ต้องแก้ไขข้อบกพร่อง หากเวอร์ชันเก่าเวอร์ชันใดเวอร์ชันหนึ่งไม่เคย ส่งรายงานข้อขัดข้องเมื่อคุณปิดปัญหา และผู้ใช้เหล่านั้นเริ่มพบข้อบกพร่อง รายงานข้อขัดข้องเหล่านั้นจะทริกเกอร์ปัญหาที่กลับมาอีกครั้ง
หากคุณไม่ต้องการให้ปัญหาเปิดขึ้นอีกครั้งเนื่องจากอัลกอริทึมการถดถอยของเรา คุณสามารถ "ปิดเสียง" ได้
ปัญหาแทนที่จะปิดไปเฉยๆ
หมายเหตุ: ก่อนเดือนกุมภาพันธ์ 2022 Crashlytics ได้จัดหมวดหมู่ปัญหาเป็น
การถดถอยเมื่อเกิดปัญหานั้นซ้ำในแอปเวอร์ชันใดก็ตาม แม้แต่ในเวอร์ชันแอป
ที่เราทราบเมื่อคุณปิดปัญหานี้แล้ว ส่งผลให้ Crashlytics
ระบุการถดถอยอย่างไม่ถูกต้องในบางครั้ง ตอนนี้เราใช้ข้อตกลง
ที่อธิบายไว้ข้างต้น
การรายงานข้อยกเว้นที่ตรวจไม่พบเป็นข้อยกเว้นร้ายแรง Crashlytics สามารถรายงานข้อยกเว้นที่ตรวจไม่พบเป็นข้อยกเว้นร้ายแรงได้ (ตั้งแต่ v10.4.0 ของ Unity SDK) คําถามที่พบบ่อยต่อไปนี้จะช่วยอธิบายเหตุผลและแนวทางปฏิบัติแนะนําในการใช้ฟีเจอร์นี้
เหตุใดแอปจึงควรรายงานข้อยกเว้นที่ตรวจไม่พบว่าเป็นข้อผิดพลาดร้ายแรง
การรายงานข้อยกเว้นที่ตรวจไม่พบว่าร้ายแรงช่วยให้คุณได้รับตัวบ่งชี้ที่สมจริงมากขึ้น
มีข้อยกเว้นบางประการที่อาจส่งผลให้เกมเล่นไม่ได้ แม้ว่าแอปจะ
จะยังคงทำงานต่อไป
โปรดทราบว่าหากคุณเริ่มรายงานข้อขัดข้องร้ายแรง เปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้อง (CFU) มีแนวโน้มที่จะลดลง แต่เมตริก CFU จะแสดงถึงประสบการณ์ของผู้ใช้ปลายทางกับแอปของคุณได้มากกว่า
สำคัญ: การรายงานข้อยกเว้นที่ตรวจไม่พบเนื่องจากร้ายแรงจะไม่ Android Vitals
รายการที่ร้ายแรงที่รายงานใน Crashlytics จะแสดงให้คุณเห็นเท่านั้น เพื่อให้คุณสามารถ
ค้นพบและแก้ไขปัญหาในแอปและเกมของคุณ
ข้อยกเว้นใดบ้างที่ระบบจะรายงานเป็นข้อยกเว้นร้ายแรง
Crashlytics จะรายงานข้อยกเว้นที่ตรวจไม่พบว่าเป็นข้อยกเว้นร้ายแรงได้ก็ต่อเมื่อเป็นไปตามเงื่อนไขทั้ง 2 ข้อต่อไปนี้
หลังจากเปิดใช้การรายงานข้อยกเว้นที่ตรวจไม่พบเป็นข้อยกเว้นร้ายแรง ตอนนี้ฉันมีข้อยกเว้นร้ายแรงใหม่จำนวนมาก ฉันจะจัดการกับข้อยกเว้นเหล่านี้อย่างเหมาะสมได้อย่างไร
เมื่อเริ่มได้รับรายงานข้อยกเว้นที่ตรวจไม่พบเป็นข้อยกเว้นร้ายแรง ตัวเลือกการจัดการข้อยกเว้นที่ตรวจไม่พบเหล่านี้มีดังนี้
จับและจัดการข้อยกเว้น ระบบจะสร้างและแสดงข้อยกเว้นเพื่อแสดงสถานะที่ผิดปกติหรือที่ไม่คาดคิด
การแก้ปัญหาที่แสดงโดยข้อยกเว้นที่โยนนั้นเกี่ยวข้องกับการทำให้โปรแกรมกลับคืนสู่สถานะที่รู้จัก (กระบวนการที่เรียกว่าการจัดการข้อยกเว้น
แนวทางปฏิบัติแนะนำคือให้จับและจัดการข้อยกเว้นที่คาดการณ์ไว้ทั้งหมด เว้นแต่โปรแกรมจะไม่สามารถกลับไปยังสถานะที่รู้จัก
หากต้องการควบคุมประเภทข้อยกเว้นที่โค้ดจะจับและจัดการ ให้รวมโค้ดที่อาจสร้างข้อยกเว้นไว้ในบล็อก try-catch
ตรวจสอบว่าเงื่อนไขในคำสั่ง catch แคบเท่ากับ
เพื่อจัดการข้อยกเว้นเฉพาะได้อย่างเหมาะสม
บันทึกข้อยกเว้นใน Unity หรือ Crashlytics คุณบันทึกข้อยกเว้นใน Unity หรือ Crashlytics ได้หลายวิธี
ดีบักปัญหา
เมื่อใช้ Crashlytics ตัวเลือกที่พบบ่อยที่สุดและแนะนํามี 2 ตัวเลือกดังนี้
ตัวเลือกที่ 1: พิมพ์ในคอนโซล Unity แต่ไม่รายงานไปยัง Crashlytics
ระหว่างการพัฒนาหรือการแก้ปัญหา
พิมพ์ไปยังคอนโซล Unity โดยใช้ Debug.Log(exception)
Debug.LogWarning(exception) และ Debug.LogError(exception) ซึ่ง
พิมพ์เนื้อหาของข้อยกเว้นไปยังคอนโซล Unity และไม่ต้อง
ส่งข้อยกเว้นอีกครั้ง
ตัวเลือกที่ 2: อัปโหลดไปยัง Crashlytics เพื่อการรายงานรวมใน
หน้าแดชบอร์ด Crashlytics สำหรับสถานการณ์ต่อไปนี้
หากข้อยกเว้นควรค่ากับการบันทึกเพื่อแก้ไขข้อบกพร่องในครั้งต่อๆ ไป
Crashlytics เหตุการณ์ จากนั้นใช้ Crashlytics.Log(exception.ToString())
ควรรายงานข้อยกเว้นไปยัง Crashlytics แม้ว่า
มีการดักจับและจัดการ ให้ใช้ Crashlytics.LogException(exception)
เพื่อบันทึกเป็นเหตุการณ์ที่ไม่ร้ายแรง
อย่างไรก็ตาม หากต้องการรายงานเหตุการณ์ร้ายแรงไปยัง Unity Cloud Diagnostic ด้วยตนเอง ให้ใช้ Debug.LogException ตัวเลือกนี้จะแสดงข้อยกเว้นในคอนโซล Unity เช่นเดียวกับตัวเลือกที่ 1 แต่จะแสดงข้อยกเว้นด้วย (ไม่ว่าจะมีการแสดงหรือจับข้อยกเว้นไว้แล้วหรือไม่ก็ตาม) ระบบทำให้เกิดข้อผิดพลาด
ไม่ใช่ในท้องถิ่น ซึ่งหมายความว่าแม้ Debug.LogException(exception)
ที่มีบล็อก try-catch อยู่รอบๆ ก็จะยังคงทำให้เกิดข้อยกเว้นที่ตรวจไม่พบ
ดังนั้น ให้เรียกใช้ Debug.LogException เฉพาะในกรณีที่คุณต้องการทำทั้งหมด
วิธีพิมพ์ข้อยกเว้นไปยังคอนโซล Unity
วิธีอัปโหลดข้อยกเว้นไปยัง Crashlytics เป็นเหตุการณ์ร้ายแรง
หากต้องการแสดงข้อยกเว้น ให้ถือว่าข้อยกเว้นนั้นเป็นข้อยกเว้นที่ตรวจไม่พบ และรายงานไปยัง Unity Cloud Diagnostics
โปรดทราบว่าหากคุณต้องการพิมพ์ข้อยกเว้นที่พบในคอนโซล Unity และ Crashlytics เนื่องจากเป็นเหตุการณ์ที่ไม่ร้ายแรง ให้ทําตามขั้นตอนต่อไปนี้แทน
try
{
methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
// Print the exception to the Unity console at the error level.
Debug.LogError(exception);
// Upload the exception to Crashlytics as a non-fatal event.
Crashlytics.LogException(exception); // not Debug.LogException
//
// Code that handles the exception
//
}
