iOS
Android
Flutter
Unity
หน้านี้จะให้ความช่วยเหลือในการแก้ปัญหาและคำตอบสำหรับคำถามที่พบบ่อย
คำถามเกี่ยวกับการใช้ Crashlytics หากคุณ
ไม่พบสิ่งที่คุณต้องการหรือต้องการความช่วยเหลือเพิ่มเติม โปรดติดต่อ
การสนับสนุน Firebase
การแก้ปัญหาทั่วไป/คำถามที่พบบ่อย
ไม่เห็น
เมตริกที่ปลอดอุบัติเหตุและ/หรือการแจ้งเตือนอัตราความเร็ว
หากคุณไม่เห็นเมตริกที่ไม่มีข้อขัดข้อง (เช่น ผู้ใช้และเซสชันที่ไม่พบข้อขัดข้อง)
และ/หรือการแจ้งเตือนอัตราความเร็ว โปรดตรวจสอบว่าคุณกำลังใช้
Crashlytics SDK 11.7.0 ขึ้นไป
ไม่เห็นบันทึกเบรดครัมบ์
หากคุณไม่เห็นตำแหน่ง
บันทึกเบรดครัมบ์
เราขอแนะนำให้คุณตรวจสอบการกำหนดค่าแอปสำหรับ Google Analytics
ตรวจสอบว่าคุณมีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้
เห็นสิ่งไม่มีสัญลักษณ์
สแต็กเทรซสำหรับแอป Android ในหน้าแดชบอร์ด Crashlytics
หากคุณใช้ Unity IL2CPP
และเห็นสแต็กเทรซที่ไม่มีสัญลักษณ์ ให้ลองทำดังนี้
ตรวจสอบว่าคุณใช้ Crashlytics Unity เวอร์ชัน 8.6.1 ขึ้นไป
SDK
ตรวจสอบว่ามีการตั้งค่าและเรียกใช้ 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
และผู้ใช้ ค. ตารางต่อไปนี้แสดงให้เห็นว่าผู้ใช้รายใดมีส่วนร่วมกับแอปของคุณในแต่ละวัน
และผู้ใช้รายใดที่ขัดข้องในวันนั้น
จันทร์
อังคาร
พุธ
ผู้ใช้ที่มีส่วนร่วมกับแอปของคุณ
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 วันที่ผ่านมา แต่
รวมถึงไม่พบข้อขัดข้อง
ไม่ควรเปรียบเทียบค่าของผู้ใช้ที่ไม่พบข้อขัดข้องในระยะเวลาที่ต่างกัน
ความน่าจะเป็นของผู้ใช้รายเดียวที่จะประสบการขัดข้องก็เพิ่มขึ้นตามไปด้วย
ดังนั้นมูลค่าผู้ใช้ที่ไม่พบข้อขัดข้องจึงมีแนวโน้มที่จะลดลงเป็นเวลานานขึ้น
ระยะเวลา
หมายเหตุ: คุณจะเห็นการ์ดสถิติที่ไม่มีข้อขัดข้อง ที่ว่างเปล่า หากกรองเหตุการณ์
ประเภท ไปยังปัญหาที่ไม่ร้ายแรงเท่านั้น เปอร์เซ็นต์ผู้ใช้ที่ไม่พบข้อขัดข้องคือ
ที่คำนวณเพื่อหาเหตุการณ์ร้ายแรง
ใครสามารถดู เขียน และลบบันทึกเกี่ยวกับปัญหา
หมายเหตุช่วยให้สมาชิกโปรเจ็กต์สามารถแสดงความคิดเห็นเกี่ยวกับปัญหาหรือคำถามและสถานะที่เฉพาะเจาะจง
อัปเดต ฯลฯ
เมื่อสมาชิกโครงการโพสต์หมายเหตุจะมีป้ายกำกับเป็นอีเมล
ของคุณได้ อีเมลนี้จะปรากฏพร้อมกับโน้ตของทุกโปรเจ็กต์
สมาชิกที่มีสิทธิ์ดูโน้ต
ข้อมูลต่อไปนี้จะอธิบายถึงการเข้าถึงที่จำเป็นในการดู เขียน และลบ
หมายเหตุ
ใครสามารถดู เขียน และลบบันทึกเกี่ยวกับปัญหา
หมายเหตุช่วยให้สมาชิกโปรเจ็กต์สามารถแสดงความคิดเห็นเกี่ยวกับปัญหาหรือคำถามและสถานะที่เฉพาะเจาะจง
อัปเดต ฯลฯ
เมื่อสมาชิกโครงการโพสต์หมายเหตุจะมีป้ายกำกับเป็นอีเมล
ของคุณได้ อีเมลนี้จะปรากฏพร้อมกับโน้ตของทุกโปรเจ็กต์
สมาชิกที่มีสิทธิ์ดูโน้ต
ข้อมูลต่อไปนี้จะอธิบายถึงการเข้าถึงที่จำเป็นในการดู เขียน และลบ
หมายเหตุ
การผสานรวม
แอปยังใช้
SDK โฆษณาในอุปกรณ์เคลื่อนที่ของ Google แต่ไม่เกิดข้อขัดข้อง
หากโปรเจ็กต์ของคุณใช้ Crashlytics ควบคู่ไปกับ SDK โฆษณาในอุปกรณ์เคลื่อนที่ของ Google
มีความเป็นไปได้ว่า ผู้รายงานปัญหาจะเข้ามาแทรกแซง
การลงทะเบียนเครื่องจัดการข้อยกเว้น ในการแก้ไขปัญหานี้ ให้ปิดการรายงานข้อขัดข้องใน
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 ข้อดังต่อไปนี้
หลังจากเปิดใช้การรายงานข้อยกเว้นที่ตรวจไม่พบว่าร้ายแรง ตอนนี้ฉันมีข้อขัดข้องใหม่จำนวนมาก ฉันจะจัดการข้อยกเว้นเหล่านี้อย่างเหมาะสมได้อย่างไร
เมื่อคุณเริ่มได้รับรายงานเกี่ยวกับข้อยกเว้นที่ตรวจไม่พบว่าร้ายแรง ต่อไปนี้คือ
ตัวเลือกบางอย่างในการจัดการกับข้อยกเว้นที่ตรวจไม่พบเหล่านี้
จับและจัดการข้อยกเว้น จะมีการสร้างข้อยกเว้นขึ้นเพื่อให้สอดคล้องกับโดยไม่คาดคิดหรือพิเศษ
รัฐ
การแก้ไขปัญหาที่แสดงจากข้อยกเว้นที่แสดงข้อผิดพลาดนั้นรวมถึงการส่งคืน
ให้อยู่ในสถานะที่รู้จัก (กระบวนการที่เรียกว่า ข้อยกเว้น
Handling
เราขอแนะนำให้จับและจัดการข้อยกเว้นทั้งหมด ล่วงหน้า เว้นแต่
ไม่สามารถเปลี่ยนกลับไปเป็นสถานะที่รู้จักได้
หากต้องการควบคุมประเภทข้อยกเว้นที่ระบบจะตรวจจับและจัดการโดยโค้ด
Wrapper โค้ดที่อาจสร้างข้อยกเว้นในบล็อก try-catch
ตรวจสอบว่าเงื่อนไขในคำสั่ง catch แคบเท่ากับ
เพื่อจัดการข้อยกเว้นเฉพาะได้อย่างเหมาะสม
บันทึกข้อยกเว้นใน Unity หรือ Crashlytics คุณบันทึกข้อยกเว้นใน Unity หรือ Crashlytics ได้หลายวิธี
ดีบักปัญหา
สาเหตุที่พบบ่อยที่สุดและแนะนำมีดังนี้เมื่อใช้ Crashlytics
ตัวเลือก:
ตัวเลือกที่ 1: พิมพ์ในคอนโซล Unity แต่ไม่รายงานไปยัง Crashlytics
ระหว่างการพัฒนาหรือการแก้ปัญหา
พิมพ์ไปยังคอนโซล Unity โดยใช้ Debug.Log(exception)
Debug.LogWarning(exception) และ Debug.LogError(exception) ซึ่ง
พิมพ์เนื้อหาของข้อยกเว้นไปยังคอนโซล Unity และไม่ต้อง
ส่งข้อยกเว้นอีกครั้ง
ตัวเลือกที่ 2: อัปโหลดไปยัง Crashlytics เพื่อสร้างการรายงานรวมใน
แดชบอร์ด Crashlytics สำหรับสถานการณ์ต่อไปนี้
หากข้อยกเว้นควรค่ากับการบันทึกเพื่อแก้ไขข้อบกพร่องในครั้งต่อๆ ไป
เหตุการณ์ Crashlytics แล้วใช้ Crashlytics.Log(exception.ToString())
ควรรายงานข้อยกเว้นไปยัง Crashlytics หรือไม่
มีการดักจับและจัดการ ให้ใช้ Crashlytics.LogException(exception)
เพื่อบันทึกเป็นเหตุการณ์ที่ไม่ร้ายแรง
อย่างไรก็ตาม หากคุณต้องการรายงานเหตุการณ์ร้ายแรงไปยัง Unity Cloud ด้วยตนเอง
การวินิจฉัย คุณสามารถใช้ Debug.LogException ได้ ตัวเลือกนี้จะพิมพ์ข้อยกเว้น
ไปยังคอนโซล Unity เช่น ตัวเลือกที่ 1 แต่ก็มีข้อยกเว้นด้วย
(ว่ามีการขว้างหรือจับกุมได้หรือไม่) ระบบทำให้เกิดข้อผิดพลาด
ไม่ใช่ในท้องถิ่น ซึ่งหมายความว่าแม้กระทั่งรอบๆ Debug.LogException(exception)
ที่มี try-catch การบล็อกยังคงทำให้เกิดข้อยกเว้นที่ตรวจไม่พบ
ดังนั้น โปรดโทรหา Debug.LogException เฉพาะเมื่อต้องการทำทั้งหมด
วิธีพิมพ์ข้อยกเว้นไปยังคอนโซล Unity
เพื่ออัปโหลดข้อยกเว้นไปยัง Crashlytics เป็นเหตุการณ์ร้ายแรง
หากต้องการส่งข้อยกเว้น ให้ถือเป็นข้อยกเว้นที่ตรวจไม่พบ และ
ให้รายงานไปยังการวินิจฉัยของ Unity Cloud
โปรดทราบว่าหากคุณต้องการพิมพ์ข้อยกเว้นที่พบในคอนโซล Unity และ
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
//
}
