דף זה מספק עזרה בפתרון בעיות ותשובות לשאלות נפוצות לגבי השימוש ב-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 שלך ( iOS+ | Android ).
בדוק במיוחד שאתה משתמש לפחות בגרסאות הבאות של Firebase SDK עבור Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ עבור macOS ו-tvOS) | אנדרואיד - v17.2.3+(BoM v24.7.1+) .
ייתכן שתבחין בשני פורמטים שונים לבעיות המפורטות בטבלת הבעיות שלך במסוף Firebase. הנה למה!
Crashlytics מנתחת את כל האירועים מהאפליקציה שלך - קריסות, קריסות, לא קטלניות ומקרי ANR - ומקבצת אירועים דומים לבעיות נפרדות. בינואר 2023, השקנו מנוע ניתוח משופר לקיבוץ אירועים על סמך קוד האפליקציה שלך ועיצוב מעודכן להצגת בעיות חדשות.
הנה מה שתחווה עם השיפורים האלה:
מטא נתונים מחודשים מוצגים בשורת הבעיה
עכשיו קל יותר להבין ולבדוק בעיות באפליקציה שלך.פחות בעיות כפולות
שינוי מספר שורה אינו גורם לבעיה חדשה.התראות ואותות משמעותיים יותר
בעיה חדשה מייצגת למעשה באג חדש.חיפוש חזק יותר
כל בעיה מכילה יותר מטא נתונים שניתנים לחיפוש, כמו סוג חריג ושם חבילה.
כך מתגלגלים השיפורים האלה:
כשנקבל אירועים חדשים מהאפליקציה שלך, נבדוק אם הם תואמים לבעיה קיימת.
אם אין התאמה, נחיל אוטומטית את אלגוריתם קיבוץ האירועים החכם יותר שלנו על האירוע וניצור בעיה חדשה עם עיצוב המטא-נתונים המחודש.
זהו העדכון הגדול הראשון שאנו מבצעים לקבוצת האירועים שלנו. אם יש לך משוב או נתקלת בבעיות כלשהן, אנא הודע לנו על ידי הגשת דוח.
הערך ללא קריסה מייצג את אחוז המשתמשים שהיו מעורבים באפליקציה שלך אך לא קרסו במהלך פרק זמן מסוים.
הנה הנוסחה לחישוב אחוז המשתמשים ללא התרסקות. ערכי הקלט שלו מסופקים על ידי Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
כאשר מתרחשת קריסה, Google Analytics שולח סוג אירוע
app_exception, ו- CRASHED_USERS מייצג את מספר המשתמשים המשויכים לסוג האירוע הזה.ALL_USERS מייצג את המספר הכולל של משתמשים שהיו מעורבים באפליקציה שלך במהלך תקופת הזמן שבחרת מהתפריט הנפתח בפינה השמאלית העליונה של מרכז השליטה של Crashlytics.
אחוז המשתמשים ללא קריסות הוא צבירה לאורך זמן , לא ממוצע.
לדוגמה, דמיינו לאפליקציה שלכם שלושה משתמשים; נקרא להם משתמש א', משתמש ב' ומשתמש ג'. הטבלה הבאה מציגה אילו משתמשים היו מעורבים באפליקציה שלך בכל יום ואיזה מהמשתמשים הללו קרסה באותו יום:
| יוֹם שֵׁנִי | יוֹם שְׁלִישִׁי | יום רביעי | |
|---|---|---|---|
| משתמשים שהיו מעורבים באפליקציה שלך | א ב ג | א ב ג | א, ב |
| משתמש שעבר קריסה | ג | ב | א |
ביום רביעי, אחוז המשתמשים ללא קריסות שלך הוא 50% (1 מכל 2 משתמשים היה ללא קריסות).
שניים מהמשתמשים שלך עסקו באפליקציה שלך ביום רביעי, אבל רק לאחד מהם (משתמש B) לא היו קריסות.במשך היומיים האחרונים, אחוז המשתמשים ללא קריסות שלך הוא 33.3% (1 מתוך 3 משתמשים היה ללא קריסות).
שלושה מהמשתמשים שלך היו מעורבים באפליקציה שלך במהלך היומיים האחרונים, אבל רק לאחד מהם (משתמש C) לא היו קריסות.במשך 3 הימים האחרונים, אחוז המשתמשים ללא קריסות שלך הוא 0% (0 מתוך 3 משתמשים היו ללא קריסות).
שלושה מהמשתמשים שלך היו מעורבים באפליקציה שלך במהלך שלושת הימים האחרונים, אבל לאפס מהם לא היו קריסות.
הערות מאפשרות לחברי הפרויקט להגיב על בעיות ספציפיות בשאלות, עדכוני סטטוס וכו'.
כאשר חבר בפרויקט מפרסם הערה, היא מסומנת עם האימייל של חשבון Google שלו. כתובת דוא"ל זו גלויה, יחד עם ההערה, לכל חברי הפרויקט בעלי גישה לצפות בהערה.
להלן מתאר את הגישה הנדרשת לצפייה, כתיבה ומחיקה של הערות:
חברי פרויקט עם כל אחד מהתפקידים הבאים יכולים להציג ולמחוק הערות קיימות ולכתוב הערות חדשות בנושא.
חברי פרויקט בעלי כל אחד מהתפקידים הבאים יכולים להציג את ההערות שפורסמו בנושא, אך הם אינם יכולים למחוק או לכתוב הערה.
- Project Viewer , Firebase Viewer , Quality Viewer או Crashlytics Viewer
אינטגרציות
אם הפרויקט שלך משתמש ב-Crashlytics לצד Google Mobile Ads SDK, סביר להניח שכתבי הקריסה מתערבים ברישום מטפלי חריגים. כדי לפתור את הבעיה, כבה את דיווח קריסה ב-SDK של מודעות לנייד על ידי קריאה disableSDKCrashReporting .
לאחר שתקשר את Crashlytics ל-BigQuery, מערכי נתונים חדשים שתיצור ממוקמים אוטומטית בארצות הברית, ללא קשר למיקום פרויקט Firebase שלך.
תמיכה בפלטפורמה
בעיות נסוגו
לבעיה הייתה רגרסיה כאשר סגרת את הבעיה בעבר, אך Crashlytics מקבל דיווח חדש שהבעיה התרחשה מחדש. Crashlytics פותחת מחדש אוטומטית את הבעיות הללו שנגרמו כדי שתוכל לטפל בהן בהתאם לאפליקציה שלך.
להלן תרחיש לדוגמה המסביר כיצד Crashlytics מסווג בעיה כרגרסיה:
- בפעם הראשונה אי פעם, Crashlytics מקבל דוח התרסקות על התרסקות "A". Crashlytics פותחת בעיה מתאימה לאותה התרסקות (גיליון "A").
- אתה מתקן את הבאג הזה במהירות, סוגר את נושא "A" ואז משחרר גרסה חדשה של האפליקציה שלך.
- Crashlytics מקבל דיווח נוסף על בעיה "A" לאחר שסגרת את הנושא.
- אם הדוח הוא מגרסת אפליקציה ש-Cashlytics ידעה עליה כשסגרת את הבעיה (כלומר שהגרסה שלחה דוח קריסה לכל קריסה בכלל), אז Crashlytics לא תתייחס לבעיה כשגרה. הנושא יישאר סגור.
- אם הדוח הוא מגרסת אפליקציה ש-Cashlytics לא ידעה עליה כשסגרת את הבעיה (כלומר שהגרסה מעולם לא שלחה דוח קריסה עבור קריסה כלשהי ), אז Crashlytics מחשיבה את הבעיה כנסגרת ותפתח מחדש את הבעיה .
כאשר בעיה חוזרת, אנו שולחים התראת זיהוי רגרסיה ומוסיפים אות רגרסיה לבעיה כדי ליידע אותך ש-Crashlytics פתחה מחדש את הבעיה. אם אינך רוצה שבעיה תיפתח מחדש עקב אלגוריתם הרגרסיה שלנו, "השתיק" את הבעיה במקום לסגור אותה.
אם דוח הוא מגרסת אפליקציה ישנה שמעולם לא שלחה דוחות קריסה בכלל כשסגרת את הבעיה, אז Crashlytics מחשיבה את הבעיה כנסגרת ותפתח את הבעיה מחדש.
מצב זה יכול לקרות במצב הבא: תיקנת באג והוצאת גרסה חדשה של האפליקציה שלך, אבל עדיין יש לך משתמשים בגרסאות ישנות יותר ללא תיקון הבאג. אם, במקרה, אחת מאותן גרסאות ישנות יותר מעולם לא שלחה דוחות קריסה בכלל כשסגרת את הבעיה, והמשתמשים האלה מתחילים להיתקל בבאג, אז דוחות קריסה אלה היו מפעילים בעיה שנגרמה.
אם אינך רוצה שבעיה תיפתח מחדש עקב אלגוריתם הרגרסיה שלנו, "השתיק" את הבעיה במקום לסגור אותה.