หน้านี้ให้ความช่วยเหลือในการแก้ปัญหาและคำตอบสำหรับคำถามที่พบบ่อยเกี่ยวกับการใช้ Crashlytics หากคุณไม่พบสิ่งที่ต้องการหรือต้องการความช่วยเหลือเพิ่มเติม โปรดติดต่อ ฝ่ายสนับสนุนของ Firebase
การแก้ไขปัญหาทั่วไป/คำถามที่พบบ่อย
หากคุณไม่เห็นผู้ใช้ที่ไม่มีข้อขัดข้อง บันทึกการแสดงเส้นทาง และ/หรือการแจ้งเตือนความเร็ว เราขอแนะนำให้ตรวจสอบการกำหนดค่าแอปของคุณสำหรับ Google Analytics
ตรวจสอบว่าคุณ เปิดใช้ Google Analytics ในโครงการ Firebase แล้ว
ตรวจสอบว่าเปิดใช้ การแชร์ข้อมูล สำหรับ Google Analytics ในหน้า การผสานรวม > Google Analytics ของคอนโซล Firebase โปรดทราบว่าการตั้งค่า การแชร์ข้อมูล จะแสดงในคอนโซล Firebase แต่จัดการในคอนโซล Google Analytics
นอกจาก Firebase Crashlytics SDK แล้ว ตรวจสอบให้แน่ใจว่าคุณได้เพิ่ม Firebase SDK สำหรับ Google Analytics ลงในแอปของคุณ ( iOS+ | Android )
ตรวจสอบว่าคุณใช้เวอร์ชันล่าสุดสำหรับ Firebase SDK ทั้งหมด ( iOS+ | Android )
ตรวจสอบเป็นพิเศษว่าคุณใช้ Firebase SDK สำหรับ Google Analytics เวอร์ชันต่อไปนี้ เป็นอย่างน้อย : iOS+ — v6.3.1+ (v8.9.0+ สำหรับ macOS และ tvOS) | Android — v17.2.3+(BoM v24.7.1+)
คุณอาจสังเกตเห็นรูปแบบที่แตกต่างกัน 2 รูปแบบสำหรับปัญหาที่แสดงในตาราง ปัญหา ในคอนโซล Firebase และคุณอาจสังเกตเห็นคุณลักษณะที่เรียกว่า "รูปแบบต่างๆ" ในบางปัญหาของคุณ นี่คือเหตุผล!
ในช่วงต้นปี 2023 เราเปิดตัวเครื่องมือวิเคราะห์ที่ปรับปรุงแล้วสำหรับการจัดกลุ่มเหตุการณ์ รวมถึงการออกแบบที่อัปเดตและฟีเจอร์ขั้นสูงบางอย่างสำหรับปัญหาใหม่ๆ (เช่น ตัวแปรต่างๆ!) ตรวจสอบ โพสต์บล็อก ล่าสุดของเราสำหรับรายละเอียดทั้งหมด แต่คุณสามารถอ่านด้านล่างสำหรับไฮไลท์
Crashlytics วิเคราะห์เหตุการณ์ทั้งหมดจากแอปของคุณ (เช่น ข้อขัดข้อง ที่ไม่ร้ายแรง และ ANR) และสร้างกลุ่มของ เหตุการณ์ ที่เรียกว่าปัญหา เหตุการณ์ทั้งหมดในปัญหามีจุดล้มเหลวร่วมกัน
ในการจัดกลุ่มเหตุการณ์ให้เป็นประเด็นเหล่านี้ เอ็นจิ้นการวิเคราะห์ที่ได้รับการปรับปรุงจะดูที่หลายๆ แง่มุมของเหตุการณ์ รวมถึงเฟรมในการติดตามสแต็ก ข้อความแสดงข้อยกเว้น รหัสข้อผิดพลาด และแพลตฟอร์มหรือลักษณะประเภทข้อผิดพลาดอื่นๆ
อย่างไรก็ตาม ภายในกลุ่มของเหตุการณ์นี้ การติดตามสแต็กที่นำไปสู่ความล้มเหลวอาจแตกต่างออกไป การติดตามสแต็กที่แตกต่างกันอาจหมายถึงสาเหตุหลักที่แตกต่างกัน เพื่อแสดงความแตกต่างที่เป็นไปได้นี้ภายในปัญหา ตอนนี้เราสร้าง ตัวแปร ภายในปัญหา - แต่ละตัวแปรคือกลุ่มย่อยของเหตุการณ์ในปัญหาที่มีจุดล้มเหลวเดียวกัน และ การติดตามสแต็กที่คล้ายกัน เมื่อใช้ตัวแปร คุณสามารถดีบักสแต็กเทรซที่พบได้บ่อยที่สุดภายในปัญหาหนึ่งๆ และพิจารณาว่าสาเหตุหลักที่แตกต่างกันทำให้เกิดความล้มเหลวหรือไม่
สิ่งที่คุณจะได้สัมผัสกับการปรับปรุงเหล่านี้มีดังนี้
ข้อมูลเมตาที่ปรับปรุงใหม่ซึ่งแสดงอยู่ในแถวปัญหา
ตอนนี้คุณเข้าใจและแยกแยะปัญหาในแอปได้ง่ายขึ้นปัญหาที่ซ้ำกันน้อยลง
การเปลี่ยนแปลงหมายเลขบรรทัดไม่ได้ส่งผลให้เกิดปัญหาใหม่แก้ไขจุดบกพร่องของปัญหาที่ซับซ้อนได้ง่ายขึ้นด้วยสาเหตุต่างๆ
ใช้ตัวแปรเพื่อดีบักสแต็กเทรซที่พบมากที่สุดในปัญหาหนึ่งๆการแจ้งเตือนและสัญญาณที่มีความหมายมากขึ้น
ปัญหาใหม่แสดงถึงข้อผิดพลาดใหม่การค้นหาที่ทรงพลังยิ่งขึ้น
แต่ละฉบับมีข้อมูลเมตาที่ค้นหาได้มากขึ้น เช่น ประเภทข้อยกเว้นและชื่อแพ็กเกจ
ต่อไปนี้เป็นวิธีการเผยแพร่การปรับปรุงเหล่านี้:
เมื่อเราได้รับกิจกรรมใหม่จากแอปของคุณ เราจะตรวจสอบว่าเหตุการณ์นั้นตรงกับปัญหาที่มีอยู่หรือไม่
หากไม่มีการจับคู่ เราจะใช้อัลกอริทึมการจัดกลุ่มเหตุการณ์ที่ชาญฉลาดกับเหตุการณ์โดยอัตโนมัติ และสร้างปัญหาใหม่ด้วยการออกแบบข้อมูลเมตาที่ปรับปรุงใหม่
นี่เป็นการอัปเดตครั้งใหญ่ครั้งแรกที่เราดำเนินการกับการจัดกลุ่มกิจกรรมของเรา หากคุณมีข้อเสนอแนะหรือพบปัญหาใด ๆ โปรดแจ้งให้เราทราบโดย การยื่นรายงาน
ค่าที่ไม่มีข้อขัดข้องแสดงถึงเปอร์เซ็นต์ของผู้ใช้ที่มีส่วนร่วมกับแอปของคุณแต่ ไม่มี ข้อขัดข้องในช่วงเวลาที่กำหนด
นี่คือสูตรสำหรับการคำนวณเปอร์เซ็นต์ผู้ใช้ที่ไม่ขัดข้อง ค่าอินพุตจัดทำโดย Google Analytics
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
เมื่อเกิดข้อขัดข้อง Google Analytics จะส่งเหตุการณ์ประเภท
app_exceptionและ CRASHED_USERS แสดงถึงจำนวนผู้ใช้ที่เกี่ยวข้องกับเหตุการณ์ประเภทนั้นALL_USERS แสดงถึงจำนวนผู้ใช้ทั้งหมดที่มีส่วนร่วมกับแอปของคุณในช่วงเวลาที่คุณเลือกจากเมนูแบบเลื่อนลงที่ด้านขวาบนของแดชบอร์ด Crashlytics
เปอร์เซ็นต์ผู้ใช้ที่ไม่มีข้อขัดข้อง เป็นการรวมในช่วงเวลาหนึ่ง ไม่ใช่ค่าเฉลี่ย
ตัวอย่างเช่น สมมติว่าแอปของคุณมีผู้ใช้สามคน เราจะเรียกพวกเขาว่าผู้ใช้ A ผู้ใช้ B และผู้ใช้ C ตารางต่อไปนี้แสดงผู้ใช้ที่มีส่วนร่วมกับแอปของคุณในแต่ละวัน และผู้ใช้รายใดที่มีปัญหาในวันนั้น:
| วันจันทร์ | วันอังคาร | วันพุธ | |
|---|---|---|---|
| ผู้ใช้ที่มีส่วนร่วมกับแอปของคุณ | เอ บี ซี | เอ บี ซี | เอ บี |
| ผู้ใช้ที่มีปัญหา | ค | ข | ก |
ในวันพุธ เปอร์เซ็นต์ผู้ใช้ที่ไม่มีข้อขัดข้องคือ 50% (ผู้ใช้ 1 ใน 2 คนไม่มีข้อขัดข้อง)
ผู้ใช้ 2 รายมีส่วนร่วมกับแอปของคุณในวันพุธ แต่มีเพียง 1 รายเท่านั้น (ผู้ใช้ B) ที่ไม่มีข้อขัดข้องในช่วง 2 วันที่ผ่านมา เปอร์เซ็นต์ผู้ใช้ที่ไม่มีข้อขัดข้องคือ 33.3% (ผู้ใช้ 1 ใน 3 รายไม่มีข้อขัดข้อง)
ผู้ใช้ 3 รายมีส่วนร่วมกับแอปของคุณในช่วง 2 วันที่ผ่านมา แต่มีเพียง 1 รายเท่านั้น (ผู้ใช้ C) ที่ไม่มีข้อขัดข้องในช่วง 3 วันที่ผ่านมา เปอร์เซ็นต์ผู้ใช้ที่ไม่มีข้อขัดข้องคือ 0% (ผู้ใช้ 0 ใน 3 รายไม่มีข้อขัดข้อง)
ผู้ใช้ 3 รายมีส่วนร่วมกับแอปของคุณในช่วง 3 วันที่ผ่านมา แต่ผู้ใช้ 0 รายไม่มีข้อขัดข้อง
หมายเหตุช่วยให้สมาชิกโครงการแสดงความคิดเห็นในประเด็นเฉพาะเกี่ยวกับคำถาม การอัปเดตสถานะ ฯลฯ
เมื่อสมาชิกโครงการโพสต์บันทึก จะมีป้ายกำกับเป็นอีเมลของบัญชี Google ของพวกเขา ที่อยู่อีเมลนี้จะมองเห็นได้พร้อมกับบันทึกย่อสำหรับสมาชิกโครงการทุกคนที่มีสิทธิ์เข้าถึงเพื่อดูบันทึกย่อ
ข้อมูลต่อไปนี้จะอธิบายการเข้าถึงที่จำเป็นในการดู เขียน และลบโน้ต:
สมาชิกโครงการที่มีบทบาทใดๆ ต่อไปนี้สามารถดูและลบบันทึกย่อที่มีอยู่และเขียนบันทึกใหม่เกี่ยวกับปัญหาได้
สมาชิกโครงการที่มีบทบาทใดๆ ต่อไปนี้สามารถดูบันทึกที่โพสต์เกี่ยวกับปัญหา แต่ไม่สามารถลบหรือเขียนบันทึกได้
- Project Viewer , Firebase Viewer , Quality Viewer หรือ Crashlytics Viewer
การบูรณาการ
หากโปรเจ็กต์ของคุณใช้ Crashlytics ร่วมกับ SDK โฆษณาบนอุปกรณ์เคลื่อนที่ของ Google อาจเป็นไปได้ว่าโปรแกรมรายงานข้อขัดข้องกำลังรบกวนเมื่อลงทะเบียนตัวจัดการข้อยกเว้น หากต้องการแก้ไขปัญหา ให้ปิดการรายงานข้อขัดข้องใน SDK โฆษณาบนอุปกรณ์เคลื่อนที่โดยเรียก disableSDKCrashReporting
หลังจากที่คุณลิงก์ Crashlytics กับ BigQuery ชุดข้อมูลใหม่ที่คุณสร้างจะอยู่ในสหรัฐอเมริกาโดยอัตโนมัติ ไม่ว่าโครงการ Firebase ของคุณจะอยู่ที่ใด
รองรับแพลตฟอร์ม
ปัญหาที่ถดถอย
ปัญหามีการถดถอยเมื่อคุณปิดปัญหาไปก่อนหน้านี้ แต่ Crashlytics ได้รับรายงานใหม่ว่าปัญหาเกิดขึ้นซ้ำ Crashlytics จะเปิดปัญหาที่ถดถอยเหล่านี้อีกครั้งโดยอัตโนมัติ เพื่อให้คุณสามารถแก้ไขได้ตามความเหมาะสมสำหรับแอปของคุณ
ต่อไปนี้เป็นสถานการณ์ตัวอย่างที่อธิบายวิธีที่ Crashlytics จัดหมวดหมู่ปัญหาเป็นการถดถอย:
- เป็นครั้งแรกที่ Crashlytics ได้รับรายงานข้อขัดข้องเกี่ยวกับข้อขัดข้อง "A" Crashlytics เปิดปัญหาที่เกี่ยวข้องสำหรับข้อขัดข้องนั้น (ฉบับ "A")
- คุณแก้ไขข้อบกพร่องนี้ได้อย่างรวดเร็ว ปิดปัญหา "A" แล้วเผยแพร่แอปเวอร์ชันใหม่
- Crashlytics ได้รับรายงานอีกครั้งเกี่ยวกับปัญหา "A" หลังจากที่คุณปิดปัญหาแล้ว
- หากรายงานมาจากเวอร์ชันแอปที่ Crashlytics ทราบ เมื่อคุณปิดปัญหา (หมายความว่าเวอร์ชันดังกล่าวได้ส่งรายงานข้อขัดข้องสำหรับข้อขัดข้อง ใดๆ เลย) Crashlytics จะไม่ถือว่าปัญหาดังกล่าวเป็นการถดถอย ปัญหาจะยังคงถูกปิด
- หากรายงานมาจากเวอร์ชันแอปที่ Crashlytics ไม่ ทราบ เมื่อคุณปิดปัญหา (หมายความว่าเวอร์ชันนั้น ไม่ เคยส่งรายงาน ข้อ ขัดข้องสำหรับข้อขัดข้องใดๆ เลย) Crashlytics จะพิจารณาปัญหาที่ถดถอยและจะเปิดปัญหาอีกครั้ง .
เมื่อปัญหาถดถอย เราจะส่งการแจ้งเตือนการตรวจหาการถดถอยและเพิ่มสัญญาณการถดถอยไปยังปัญหาเพื่อแจ้งให้คุณทราบว่า Crashlytics ได้เปิดปัญหาอีกครั้ง หากคุณไม่ต้องการให้ปัญหาเปิดขึ้นมาใหม่เนื่องจากอัลกอริธึมการถดถอยของเรา ให้ "ปิดเสียง" ปัญหาแทนการปิด
หากรายงานมาจากแอปเวอร์ชันเก่าซึ่งไม่เคยส่งรายงานข้อขัดข้องใดๆ เลยเมื่อคุณปิดปัญหา Crashlytics จะถือว่าปัญหานั้นถดถอยและจะเปิดปัญหาใหม่อีกครั้ง
สถานการณ์นี้อาจเกิดขึ้นได้ในสถานการณ์ต่อไปนี้: คุณได้แก้ไขข้อบกพร่องและเปิดตัวแอปเวอร์ชันใหม่แล้ว แต่คุณยังมีผู้ใช้เวอร์ชันเก่าที่ไม่มีการแก้ไขข้อบกพร่อง หากบังเอิญ เวอร์ชันเก่าเวอร์ชันหนึ่ง ไม่ เคยส่งรายงานข้อขัดข้องเลยเมื่อคุณปิดปัญหา และผู้ใช้เหล่านั้นเริ่มพบข้อบกพร่อง รายงานข้อขัดข้องเหล่านั้นจะทำให้เกิดปัญหาที่ถดถอย
หากคุณไม่ต้องการให้ปัญหาเปิดขึ้นมาใหม่เนื่องจากอัลกอริธึมการถดถอยของเรา ให้ "ปิดเสียง" ปัญหาแทนการปิด