שאלות נפוצות ופתרון בעיות ב-Crashlytics

iOS+‎ Android Flutter Unity

בדף הזה מפורטת עזרה בפתרון בעיות ותשובות לשאלות נפוצות בנושא השימוש ב-Crashlytics. אם לא מצאתם את מה שחיפשת או אם אתם זקוקים לעזרה נוספת, תוכלו לפנות אל התמיכה של Firebase.

פתרון בעיות כלליות/שאלות נפוצות

פורמטים שונים (ולפעמים 'וריאנטים') של בעיות מסוימות בטבלה בעיות

יכול להיות שתבחינו בשני פורמטים שונים של בעיות שמופיעות בטבלה בעיות במסוף Firebase. יכול להיות שתבחינו גם בתכונה שנקראת 'וריאנטים' בחלק מהבעיות. זו הסיבה!

בתחילת 2023 השקנו מנוע ניתוח משופר לקיבוץ אירועים, עיצוב מעודכן ותכונות מתקדמות לבעיות חדשות (כמו וריאנטים). כל הפרטים מפורטים בפוסט הזה בבלוג, אבל בהמשך מפורטים הדברים העיקריים.

Crashlytics מנתח את כל האירועים מהאפליקציה (כמו קריסות, אירועים לא קטלניים ומקרי ANR) ויוצר קבוצות של אירועים שנקראות בעיות – לכל האירועים בבעיה יש נקודת כשל משותפת.

כדי לקבץ אירועים לבעיות האלה, מנוע הניתוח המשודרג בוחן עכשיו היבטים רבים של האירוע, כולל המסגרות בניתוח סטאק, הודעת החריגה, קוד השגיאה ומאפיינים אחרים של פלטפורמה או של סוג השגיאה.

עם זאת, בתוך קבוצת האירועים הזו, יכול להיות שנתוני מעקב הסטאק שיובילו לכשלים יהיו שונים. אם דוח אחר של נתוני סטאק יהיה שונה, יכול להיות שמדובר בגורם אחר לבעיה. כדי לייצג את ההבדל האפשרי הזה בתוך בעיה, אנחנו יוצרים עכשיו וריאציות בתוך בעיות – כל וריאנט הוא קבוצת משנה של אירועים בבעיה שיש להם את אותו נקודת כשל וגם נתיב סטאק דומה. בעזרת וריאנטים תוכלו לנפות באגים בנתוני המעקב הנפוצים ביותר בבעיה, ולבדוק אם יש סיבות שונות לבעיה.

אלה השיפורים שתוכלו ליהנות מהם:

• מטא-נתונים מעודכנים שמוצגים בשורת הבעיה
  עכשיו קל יותר להבין את הבעיות באפליקציה ולתעדף אותן.

• פחות בעיות כפולות
  שינוי של מספר שורה לא יוצר בעיה חדשה.

• ניפוי באגים קל יותר של בעיות מורכבות עם גורמי שורש שונים
  אפשר להשתמש בוריאנטים כדי לנפות באגים בנתוני המעקב הנפוצים ביותר בבעיה.

• התראות וסמנים משמעותיים יותר
  בעיה חדשה היא למעשה באג חדש.

• חיפוש יעיל יותר
  כל בעיה מכילה יותר מטא-נתונים שאפשר לחפש, כמו סוג החריגה ושם החבילה.

כך השיפורים האלה ייכנסו לתוקף:

• כשנקבל אירועים חדשים מהאפליקציה שלכם, נבדוק אם הם תואמים לבעיה קיימת.

• אם לא נמצאה התאמה, נחיל באופן אוטומטי על האירוע את האלגוריתם החכם יותר שלנו לקיבוץ אירועים, ונוצר בעיה חדשה עם העיצוב המחודש של המטא-נתונים.

זהו העדכון המשמעותי הראשון שאנחנו מבצעים לקיבוץ האירועים. אם יש לכם משוב או אם נתקלת בבעיות, אפשר לשלוח דיווח .

לא מוצגים מדדים של נסיעות ללא תאונות או התראות על מהירות

אם המדדים של'ללא קריסות' (כמו משתמשים וסשנים ללא קריסות) ו/או ההתראות לגבי מהירות לא מוצגים, צריך לוודא שאתם משתמשים ב- Crashlytics SDK 11.7.0 ואילך.

היומנים של נתיבי הניווט לא מוצגים

אם יומני הלחם לא מופיעים, מומלץ לבדוק את ההגדרות של האפליקציה לגבי Google Analytics. צריך לעמוד בדרישות הבאות:

• הפעלתם את Google Analytics בפרויקט Firebase.

• הפעלתם את האפשרות שיתוף נתונים עבור Google Analytics. מידע נוסף על ההגדרה הזו זמין במאמר ניהול של הגדרות שיתוף הנתונים מ-Analytics

• הוספת Firebase SDK ל-Google Analytics לאפליקציה. צריך להוסיף את ה-SDK הזה בנוסף ל-SDK של Crashlytics.

• אתם משתמשים ב הגרסאות האחרונות של Firebase SDK בכל המוצרים שבהם אתם משתמשים באפליקציה.

הצגת מעקב סטאק ללא סימון לאפליקציות ל-Android בלוח הבקרה Crashlytics

אם אתם משתמשים ב-Unity IL2CPP ורואים מעקבים אחרי סטאק ללא סימון, נסו את הפעולות הבאות:

1. ודאו שאתם משתמשים בגרסה 8.6.1 ואילך של Unity SDK ‏Crashlytics.

2. חשוב לוודא שהגדרתם את הפקודה crashlytics:symbols:upload ב-CLI של Firebase ושהיא פועלת, כדי ליצור ולהעלות את קובץ הסמלים.

   צריך להריץ את הפקודה הזו במסוף בכל פעם שיוצרים גרסה זמינה ל-build או כל build שרוצים לראות בו מעקב סמלי אחר סטאק במסוף Firebase. מידע נוסף זמין בדף קבלת דוחות קריסה שניתנים לקריאה.

האם אפשר להשתמש ב-Crashlytics עם אפליקציות שמשתמשות ב-IL2CPP?

כן, אפשר להשתמש ב-Crashlytics כדי להציג מעקב סמלי אחרי סטאק באפליקציות שמשתמשות ב-IL2CPP. היכולת הזו זמינה לאפליקציות שפורסמו בפלטפורמות Android או Apple. כך עושים זאת:

1. חשוב לוודא שאתם משתמשים ב-Unity SDK של Crashlytics בגרסה 8.6.0 ואילך.

2. משלימים את המשימות הנדרשות לפלטפורמה:

   • באפליקציות לפלטפורמת Apple: לא נדרשות פעולות מיוחדות. באפליקציות לפלטפורמות של Apple, הפלאגין של Firebase Unity Editor מגדיר באופן אוטומטי את הפרויקט ב-Xcode להעלאת סמלים.

   • לאפליקציות ל-Android: מוודאים שהגדרתם את הפקודה crashlytics:symbols:upload ב-CLI של Firebase והפעלתם אותה כדי ליצור את קובץ הסמלים ולהעלות אותו.

     צריך להריץ את הפקודה הזו במסוף בכל פעם שיוצרים גרסה זמינה ל-build או כל build שרוצים לראות בו מעקב סמלי אחר סטאק במסוף 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 עשוי לפעמים להיות שונה מהערך שבו אנחנו משתמשים בחישוב האחוז של המשתמשים שלא נתקלו בתאונות.

אחוז המשתמשים ללא קריסות הוא צבירה לאורך זמן, ולא ממוצע.

לדוגמה, נניח שיש באפליקציה שלכם שלושה משתמשים, ונקרא להם משתמש א', משתמש ב' ומשתמש ג'. בטבלה הבאה מוצגים המשתמשים שהתעניינו באפליקציה בכל יום, ואלה מביניהם שחלה אצלם קריסה באותו יום:

	שני	שלישי	רביעי
משתמשים שהיו להם אינטראקציות עם האפליקציה	א', ב', ג'	א', ב', ג'	א', ב'
משתמש שחלה בו קריסה	C	B	A

• ביום רביעי, אחוז המשתמשים שהאפליקציה לא קרסה אצלם הוא 50% (משתמש אחד מתוך שניים לא חווה קריסה).
  שניים מהמשתמשים שלכם קיימו אינטראקציה עם האפליקציה ביום רביעי, אבל רק אצל אחד מהם (משתמש ב') לא היו קריסות.

• ב-2 הימים האחרונים, אחוז המשתמשים שלא חוו קריסה הוא 33.3% (משתמש אחד מתוך 3 לא חווה קריסה).
  שלושה מהמשתמשים שלכם היו פעילים באפליקציה בימים האחרונים, אבל רק אצל אחד מהם (משתמש ג') לא היו קריסות.

• ב-3 הימים האחרונים, אחוז המשתמשים שהאפליקציה שלהם לא קרסה הוא 0% (0 מתוך 3 משתמשים לא חוו קריסה).
  שלושה מהמשתמשים שלכם היו פעילים באפליקציה ב-3 הימים האחרונים, אבל אף אחד מהם לא דיווח על קריסה.

אין להשוות את הערך 'משתמשים ללא קריסות' בין תקופות זמן שונות. ככל שמשתמש יחיד משתמש באפליקציה יותר פעמים, כך עולה הסבירות שהוא יחווה קריסה. לכן, סביר להניח שהערך של משתמשים ללא קריסות יהיה נמוך יותר בפרקי זמן ארוכים יותר.

הערה: אם תסננו את סוג האירוע כך שיכלול רק בעיות לא קטלניות, יוצג כרטיס ריק של נתונים סטטיסטיים ללא קריסות. אחוז המשתמשים שהאפליקציה שלהם לא קרסה מחושב רק לגבי אירועים קטלניים.

מי יכול לראות, לכתוב ולמחוק הערות בבעיה?

הערות מאפשרות למשתתפי הפרויקט להגיב על בעיות ספציפיות, לשאול שאלות, לעדכן את הסטטוס וכו'.

כשחבר בצוות פרויקט מפרסם הערה, היא מסומנת בכתובת האימייל של חשבון Google שלו. כתובת האימייל הזו, יחד עם ההערה, גלויות לכל חברי הפרויקט שיש להם גישה להערה.

הרשאות הגישה הנדרשות כדי להציג, לכתוב ולמחוק הערות:

• חברי צוות בפרויקט עם אחד מהתפקידים הבאים יכולים להציג ולמחוק הערות קיימות ולכתוב הערות חדשות בבעיה.

  • בעלים או עורך של הפרויקט, אדמין ב-Firebase, אדמין איכות או אדמין ב-Crashlytics

• חברי פרויקט עם אחד מהתפקידים הבאים יכולים לראות את ההערות שפורסמו בבעיה, אבל הם לא יכולים למחוק או לכתוב הערה.

  • צפייה בפרויקט, צפייה ב-Firebase, צפייה בנתוני איכות או צפייה ב-Crashlytics

איך מחושבים המשתמשים ללא קריסות?

הסבר על המדדים ללא קריסות

מי יכול לראות, לכתוב ולמחוק הערות בבעיה?

הערות מאפשרות למשתתפי הפרויקט להגיב על בעיות ספציפיות, לשאול שאלות, לעדכן את הסטטוס וכו'.

כשחבר בצוות פרויקט מפרסם הערה, היא מסומנת בכתובת האימייל של חשבון Google שלו. כתובת האימייל הזו, יחד עם ההערה, גלויות לכל חברי הפרויקט שיש להם גישה להערה.

הרשאות הגישה הנדרשות כדי להציג, לכתוב ולמחוק הערות:

• חברי צוות בפרויקט עם אחד מהתפקידים הבאים יכולים להציג ולמחוק הערות קיימות ולכתוב הערות חדשות בבעיה.

  • בעלים או עורך של הפרויקט, אדמין ב-Firebase, אדמין איכות או אדמין ב-Crashlytics

• חברי פרויקט עם אחד מהתפקידים הבאים יכולים לראות את ההערות שפורסמו בבעיה, אבל הם לא יכולים למחוק או לכתוב הערה.

  • צפייה בפרויקט, צפייה ב-Firebase, צפייה בנתוני איכות או צפייה ב-Crashlytics

שילובים

באפליקציה נעשה שימוש גם ב-SDK של Google Mobile Ads, אבל לא מתרחשות קריסות

אם בפרויקט שלכם נעשה שימוש ב-Crashlytics לצד ה-SDK של Google Mobile Ads, סביר להניח שדיווחי הקריסות מפריעים לרישום של מנהלי החריגות. כדי לפתור את הבעיה, צריך להשבית את הדיווח על קריסות ב-SDK של Mobile Ads באמצעות קריאה ל-disableSDKCrashReporting.

איפה נמצא מערך הנתונים שלי ב-BigQuery?

אחרי שמקשרים את Crashlytics ל-BigQuery, מערכי נתונים חדשים שיצרתם ממוקמים באופן אוטומטי בארצות הברית, ללא קשר למיקום של פרויקט Firebase.

בעיות שחוזרות

מהי בעיה שהתרחשה שוב?

הבעיה חוזרת אם סגרתם אותה בעבר, אבל Crashlytics מקבל דיווח חדש על כך שהבעיה חוזרת. Crashlytics פותח מחדש באופן אוטומטי את הבעיות האלה כדי שתוכלו לטפל בהן בהתאם לאפליקציה שלכם.

הנה תרחיש לדוגמה שמסביר איך Crashlytics מסווג בעיה כרגרסיה:

1. בפעם הראשונה, Crashlytics מקבל דוח קריסה לגבי 'תאונה א'. Crashlytics פותח בעיה תואמת לקריסה הזו (בעיה 'א').
2. אתם מתקנים את הבאג במהירות, סוגרים את הבעיה 'א' ומפיצים גרסה חדשה של האפליקציה.
3. Crashlytics מקבל דיווח נוסף על בעיה 'א' אחרי שסגרתם את הבעיה.
   • אם הדוח מגיע מגרסה של האפליקציה ש-Crashlytics ידעה עליה כשסגרתם את הבעיה (כלומר, הגרסה שלחה דוח קריסה לגבי כל קריסה), Crashlytics לא תתייחס לבעיה כאל חזרה לאחור. הבעיה תישאר סגורה.
   • אם הדוח מגיע מגרסה של האפליקציה ש-Crashlytics לא ידעה עליה כשסגרתם את הבעיה (כלומר, הגרסה אף פעם לא שלחה אף דוח קריסה לגבי קריסה כלשהי), Crashlytics תתייחס לבעיה כאל חזרה לאחור ותפתח מחדש את הבעיה.

הערה: לפני פברואר 2022, Crashlytics סיווג בעיה כרגרסיה אם היא התרחשה שוב בכל גרסה של האפליקציה, גם בגרסאות של האפליקציה שידענו עליהן כשסגרתם את הבעיה. כתוצאה מכך, לפעמים Crashlytics מזהה רגרסיות באופן לא מדויק. עכשיו אנחנו משתמשים במסורת שמתוארת למעלה.

כשבעיה חוזרת, אנחנו שולחים התראה על זיהוי רגרסיה ומוסיפים לבעיה אות רגרסיה כדי להודיע לכם ש-Crashlytics פתח אותה מחדש. אם אתם לא רוצים שהבעיה תיפתח מחדש בגלל אלגוריתם הרגרסיה שלנו, תוכלו להשתיק את הבעיה במקום לסגור אותה.

למה אני רואה בעיות בגרסאות ישנות יותר של האפליקציה?

אם הדיווח מגיע מגרסה ישנה של האפליקציה שמעולם לא שלחה דוחות קריסה בכלל כשסגרתם את הבעיה, Crashlytics תתייחס לבעיה כאל חזרה לאחור ותפתח אותה מחדש.

המצב הזה יכול לקרות במצב הבא: תיקנתם באג ושחררתם גרסה חדשה של האפליקציה, אבל עדיין יש משתמשים בגרסאות ישנות יותר של האפליקציה בלי תיקון הבאג. אם במקרה אחת מהגרסאות הישנות האלה אף פעם לא שלחה דוחות קריסה כשסגרתם את הבעיה, והמשתמשים האלה מתחילים להיתקל בבאג, דוחות הקריסה האלה יגרמו לבעיה של נסיגה לאחור.

אם אתם לא רוצים שהבעיה תיפתח מחדש בגלל אלגוריתם הרגרסיה שלנו, תוכלו להשתיק אותה במקום לסגור אותה.

הערה: לפני פברואר 2022, Crashlytics סיווג בעיה כרגרסיה אם היא התרחשה שוב בכל גרסה של האפליקציה, גם בגרסאות של האפליקציה שידענו עליהן כשסגרתם את הבעיה. כתוצאה מכך, לפעמים Crashlytics מזהה רגרסיות באופן לא מדויק. עכשיו אנחנו משתמשים במסורת שמתוארת למעלה.

אם אתם רואים הרבה אירועי רגרסיה שזוהו בטעות לפני פברואר 2022, אתם יכולים לסגור אותם מחדש כדי למנוע פתיחה חוזרת שלהם.

דיווח על חריגות שלא נלכדו כחריגות קטלניות

Crashlytics יכול לדווח על חריגות שלא נלכדו כחריגות קריטיות (החל מ-v10.4.0 של Unity SDK). כדי להבין את ההיגיון מאחורי התכונה הזו ואת השיטות המומלצות לשימוש בה, כדאי לעיין בשאלות הנפוצות הבאות.

למה אפליקציה צריכה לדווח על חריגות שלא נלכדו כחריגות קריטיות?

דיווח על חריגות שלא תפסתם כחריגות קטלניות נותן לכם אינדיקציה מציאותית יותר לגבי החריגות שעלולות לגרום לכך שלא תהיה אפשרות לשחק במשחק – גם אם האפליקציה ממשיכה לפעול.

לתשומת ליבכם: אם תתחילו לדווח על קריסות קטלניות, סביר להניח שאחוז המשתמשים ללא קריסות (CFU) יקטן, אבל המדד CFU יהיה מייצג יותר את חוויית המשתמשים באפליקציה.

חשוב: דיווח על חריגות שלא נלכדו כחריגות קטלניות לא משפיע על מדדי תפקוד האפליקציה ב-Android. דיווחים על שגיאות קטלניות ב-Crashlytics גלויים רק לכם, כדי שתוכלו לזהות ולתקן בעיות באפליקציות ובמשחקים.

אילו חריגות ידווחו כקריטיות?

כדי ש-Crashlytics ידווח על חריגה שלא תפסה כחריגה קטלנית, צריכים להתקיים שני התנאים הבאים:

• במהלך האינטראקציה הראשונית באפליקציה, צריך להגדיר את המאפיין ReportUncaughtExceptionsAsFatal לערך true.

• האפליקציה (או ספרייה כלולה) גורמת להשלכת חריגה שלא נלכדת. חריג שנוצר אבל לא הופעל לא נחשב כחריג שלא נתפס.

אחרי שהפעלתי דיווח על חריגות שלא נלכדו כקריסות קטלניות, יש לי עכשיו הרבה קריסות קטלניות חדשות. איך מטפלים כראוי בחריגות האלה?

כשמתחילים לקבל דוחות על חריגות שלא תועדו כקריטיות, הנה כמה אפשרויות לטיפול בחריגות האלה:

• כדאי לחשוב איך אפשר להתחיל לתפוס את החריגות האלה ולטפל בהן.
• כדאי לבחון אפשרויות שונות לרישום חריגות ביומן במסוף ניפוי הבאגים של Unity וב-Crashlytics.

איך לתפוס חריגים שהושלכו ולטפל בהם

חריגות נוצרות ומשוחררות כדי לשקף מצבים לא צפויים או חריגים. כדי לפתור את הבעיות שמוצגות על ידי חריגה שהושמה, צריך להחזיר את התוכנית למצב ידוע (תהליך שנקרא טיפול בחריגות).

מומלץ לזהות ולטפל בכל החריגות הצפויות, אלא אם אי אפשר להחזיר את התוכנית למצב ידוע.

כדי לקבוע אילו סוגים של חריגות יתגלו ויטופלו על ידי איזה קוד, צריך לעטוף קוד שעלול ליצור חריגה בבלוק 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 Diagnostics, אפשר להשתמש ב-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
    //
}