หน้านี้ให้ความช่วยเหลือในการแก้ปัญหาและคำตอบสำหรับคำถามที่พบบ่อยเกี่ยวกับการใช้ 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 — เวอร์ชัน 17.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 รายไม่มีข้อขัดข้อง)
ผู้ใช้ของคุณสองคนมีส่วนร่วมกับแอปของคุณในวันพุธ แต่มีเพียงหนึ่งในนั้น (ผู้ใช้ B) ที่ไม่มีข้อขัดข้องในช่วง 2 วันที่ผ่านมา เปอร์เซ็นต์ผู้ใช้ที่ไม่พบข้อขัดข้องของคุณคือ 33.3% (ผู้ใช้ 1 ใน 3 ไม่พบข้อขัดข้อง)
ผู้ใช้ของคุณสามคนมีส่วนร่วมกับแอปของคุณในช่วงสองวันที่ผ่านมา แต่มีเพียงหนึ่งในนั้น (ผู้ใช้ C) ที่ไม่มีข้อขัดข้องในช่วง 3 วันที่ผ่านมา เปอร์เซ็นต์ผู้ใช้ที่ไม่พบข้อขัดข้องคือ 0% (ผู้ใช้ 0 จาก 3 รายไม่มีข้อขัดข้อง)
ผู้ใช้ของคุณสามคนมีส่วนร่วมกับแอปของคุณในช่วงสามวันที่ผ่านมา แต่ไม่มีผู้ใช้เลยที่ไม่มีข้อขัดข้อง
ไม่ควรเปรียบเทียบมูลค่าผู้ใช้ที่ไม่พบข้อขัดข้องในช่วงเวลาที่ต่างกัน ความน่าจะเป็นที่ผู้ใช้รายเดียวจะประสบข้อขัดข้องจะเพิ่มขึ้นตามที่พวกเขาใช้แอปของคุณมากขึ้น ดังนั้นมูลค่าผู้ใช้ที่ปราศจากข้อขัดข้องจึงมีแนวโน้มที่จะน้อยลงในระยะเวลานานขึ้น
หมายเหตุช่วยให้สมาชิกโครงการแสดงความคิดเห็นในประเด็นเฉพาะพร้อมคำถาม การอัปเดตสถานะ ฯลฯ
เมื่อสมาชิกโครงการโพสต์บันทึก จะมีป้ายกำกับเป็นอีเมลของบัญชี 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 จะถือว่าปัญหาถดถอยแล้วและจะเปิดปัญหาอีกครั้ง
สถานการณ์นี้อาจเกิดขึ้นได้ในสถานการณ์ต่อไปนี้: คุณได้แก้ไขข้อบกพร่องและเปิดตัวแอปเวอร์ชันใหม่แล้ว แต่คุณยังคงมีผู้ใช้ในเวอร์ชันเก่าที่ไม่มีการแก้ไขข้อบกพร่อง หากบังเอิญว่าหนึ่งในเวอร์ชันเก่าเหล่านั้น ไม่ เคยส่งรายงานข้อขัดข้องใดๆ เลยเมื่อคุณปิดปัญหา และผู้ใช้เหล่านั้นเริ่มพบจุดบกพร่อง รายงานข้อขัดข้องเหล่านั้นก็จะกระตุ้นให้เกิดปัญหาถดถอย
หากคุณไม่ต้องการให้ปัญหาเปิดขึ้นอีกครั้งเนื่องจากอัลกอริทึมการถดถอยของเรา ให้ "ปิดเสียง" ปัญหาแทนการปิด