דף זה תורגם על ידי Cloud Translation API.

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

בדף הזה תוכלו למצוא עזרה בפתרון בעיות ותשובות לשאלות נפוצות שאלות על השימוש ב-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 ורואים מעקבים אחרי סטאק ללא סימון, נסו את הפעולות הבאות:

ודאו שאתם משתמשים בגרסה 8.6.1 ואילך של Unity SDK ‏Crashlytics.
צריך לוודא שה-CLI של Firebase מוגדר ומפעילים אותו הפקודה crashlytics:symbols:upload כדי ליצור ולהעלות את הסמל חדש.

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

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

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

עליך לוודא שנעשה שימוש בגרסה 8.6.0 ואילך של Crashlytics Unity SDK.
משלימים את המשימות הנדרשות לפלטפורמה:
- באפליקציות לפלטפורמת Apple: לא נדרשות פעולות מיוחדות. ל-Apple הפלטפורמה של Firebase, הפלאגין של Firebase Unity Editor מגדיר באופן אוטומטי בפרויקט ה-Xcode שלך כדי להעלות סמלים.
- באפליקציות ל-Android: צריך לוודא שהמכשיר מוכן ומופעל. פקודת Firebase crashlytics:symbols:upload של ה-CLI כדי ליצור מעלים את קובץ הסמל.
  
  צריך להריץ את הפקודה הזו במסוף בכל פעם שיוצרים גרסה זמינה ל-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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שילובים

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

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

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

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

בעיות שחוזרות על עצמן

מהי רגרסיה (רגרסיה) בעיה?

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

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

בפעם הראשונה אי פעם, Crashlytics מקבל דוח קריסה לגבי קריסה "A". Crashlytics פותח בעיה תואמת לקריסה הזו (בעיה 'א').
מתקנים את הבאג במהירות, סוגרים את בעיה א' ולאחר מכן מפרסמים גרסה חדשה של באפליקציה שלך.
Crashlytics מקבל דיווח נוסף על בעיה 'א' אחרי שסגרתם את הבעיה.
- אם הדוח מגיע מגרסת אפליקציה שה-Crashlytics יודע/ת עליה כשסגרת את הבעיה (כלומר, הגרסה שלחה קריסה דיווח על קריסה כלשהי בכלל), ואז Crashlytics לא יתייחס לקריסה בחזרה למצב הקודם. הבעיה תישאר סגורה.
- אם הדוח מגיע מגרסה של האפליקציה ש-Crashlytics לא ידעה עליה כשסגרתם את הבעיה (כלומר, הגרסה אף פעם לא שלחה אף דוח קריסה לגבי קריסה כלשהי), Crashlytics תתייחס לבעיה כאל חזרה לאחור ותפתח מחדש את הבעיה.

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

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

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

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

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

דיווח על חריגות שלא זוהו כמקרים חמורים

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

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

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

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

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

כדי ש-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
    //
}