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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי להעלות את קובצי ה-dSYM של הפרויקט ולקבל פלט מפורט, צריך לבדוק את הפרטים הבאים:

  1. חשוב לוודא ששלב ה-build של הפרויקט מכיל את סקריפט ההפעלה Crashlytics, שמאפשר ל-Xcode להעלות את קובצי ה-dSYM של הפרויקט בזמן ה-build (הוראות להוספת הסקריפט מפורטות במאמר הפעלת Crashlytics). אחרי שמעדכנים את הפרויקט, צריך לגרום לקריסה ולוודא שהקריסה מופיעה בלוח הבקרה Crashlytics.

  2. אם מופיעה ההתראה 'חסר קובץ dSYM' במסוף Firebase, צריך לבדוק ב-Xcode אם הוא יוצר קובצי dSYM בצורה תקינה ל-build.

  3. אם Xcode יוצר קובצי dSYM כראוי ועדיין חסרים קובצי dSYM, סביר להניח שהכלי להרצת סקריפטים נתקע בזמן העלאת קובצי ה-dSYM. במקרה כזה, צריך לנסות לבצע את הפעולות הבאות:

    • צריך לוודא שמשתמשים בגרסה העדכנית ביותר של Crashlytics.

    • מעלים באופן ידני את קובצי ה-dSYM החסרים:

      • אפשרות 1: משתמשים באפשרות 'גרירה ושחרור' במסוף, בכרטיסייה dSYMs, כדי להעלות ארכיון zip שמכיל את קובצי ה-dSYM החסרים.
      • אפשרות 2: משתמשים בסקריפט upload-symbols כדי להעלות את קובצי ה-dSYM החסרים, עבור מזהי ה-UUID שצוינו בכרטיסייה dSYMs.
  4. אם עדיין חסרים קובצי dSYM או שההעלאות עדיין נכשלות, פנו אל התמיכה של Firebase וודאו לכלול את היומנים.

אם נראה שהסמלים של נתיבי הסטאק לא נכונים, כדאי לבדוק את הדברים הבאים:

  • אם בפריימים מהספרייה של האפליקציה אין הפניות לקוד של האפליקציה, צריך לוודא שהערך -fomit-frame-pointer לא מוגדר כדגל הידור.

  • אם מופיעים כמה מסגרות (Missing) בספרייה של האפליקציה, צריך לבדוק אם יש קובצי dSYM אופציונליים שחסרים (לגרסה של האפליקציה שמושפעת) בכרטיסייה Crashlytics dSYMs במסוף Firebase. אם כן, פועלים לפי השלב 'אזהרה על חסר dSYM' במאמר שאלות נפוצות בנושא קבצים מסוג dSYM חסרים או לא מועלים בדף הזה. חשוב לזכור שהעלאת קובצי ה-dSYM האלה לא תבצע הנגשת דוח קריסה בשפה אנושית לקריסות שכבר קרו, אבל היא תעזור להבטיח הנגשת דוח קריסה בשפה אנושית לקריסות עתידיות.

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

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

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

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

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

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

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

שילובים

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

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

תמיכה בפלטפורמה

כן, אפשר להטמיע את Crashlytics בפרויקטים של macOS ו-tvOS. חשוב לכלול את גרסת 8.9.0 ואילך של Firebase SDK עבור Google Analytics, כדי שלתאונות תהיה גישה למדדים שנאספים על ידי Google Analytics (משתמשים ללא תאונות, הגרסה האחרונה, התראות על מהירות ורשומות של נתיב ניווט).

מעכשיו אפשר לדווח על קריסות של כמה אפליקציות בפרויקט Firebase אחד, גם אם האפליקציות נוצרו לפלטפורמות שונות של Apple (למשל, iOS,‏ tvOS ו-Mac Catalyst). בעבר, אם אפליקציות הכילו את אותו מזהה חבילת אפליקציות, היה צריך להפריד אותן לפרויקטים נפרדים ב-Firebase.

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

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

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

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

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

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

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

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