שאלות נפוצות ופתרון בעיות במעקב אחר ביצועים


בדף הזה מפורטים טיפים לפתרון בעיות בתחילת העבודה עם Performance Monitoring או בשימוש בתכונות ובכלים של Performance Monitoring.

הבדיקות הראשונות לפתרון בעיות

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

1. בדיקת הודעות ביומן לגבי אירועי ביצועים

בודקים את הודעות היומן כדי לוודא ש-Performance Monitoring SDK מתעד אירועי ביצועים.

  1. כדי להפעיל רישום ביומן של ניפוי באגים ל-Performance Monitoring בזמן ה-build, מוסיפים את הרכיב <meta-data> לקובץ AndroidManifest.xml של האפליקציה, כך:

    <application>
    <meta-data
      android:name="firebase_performance_logcat_enabled"
      android:value="true" />
</application>

  2. בודקים אם יש הודעות שגיאה בהודעות היומן.

  3. Performance Monitoring מתייג את הודעות היומן שלו באמצעות FirebasePerformance. באמצעות סינון logcat, אפשר להציג באופן ספציפי את הנתונים של זמן המעקב ואת הרישום ביומן של בקשות הרשת מסוג HTTP/S. לשם כך, מריצים את הפקודה הבאה:

    adb logcat -s FirebasePerformance

  4. מחפשים את סוגי היומנים הבאים שמעידים על כך ש-Performance Monitoring מתעד אירועי ביצועים:

    • Logging trace metric: TRACE_NAME, FIREBASE_PERFORMANCE_CONSOLE_URL
    • Logging network request trace: URL

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

אם האפליקציה לא מתעדת ביומן אירועי ביצועים, כדאי לעיין בטיפים לפתרון בעיות.

2. בדיקת לוח הבקרה של סטטוס Firebase

כדאי לבדוק את מרכז השליטה של Firebase לסטטוסים כדי לראות אם יש הפסקה זמנית בשירות של Firebase או של Performance Monitoring.

תחילת העבודה עם Performance Monitoring

אם אתם מתחילים להשתמש ב-Performance Monitoring (iOS+ | Android | אינטרנט), הטיפים הבאים לפתרון בעיות יכולים לעזור לכם בבעיות שקשורות לזיהוי ה-SDK ב-Firebase או להצגת נתוני הביצועים הראשונים במסוף Firebase.

מערכת Firebase יכולה לזהות אם הוספתם את ה-SDK של Performance Monitoring לאפליקציה בהצלחה, כשהיא מקבלת ממנה את פרטי האירועים (כמו אינטראקציות עם האפליקציה). בדרך כלל, תוך 10 דקות ממועד הפעלת האפליקציה, תוצג ההודעה 'זוהה SDK' בלוח הבקרה Performance במסוף Firebase. לאחר מכן, תוך 30 דקות, הנתונים הראשוניים שעברו עיבוד יוצגו במרכז הבקרה.

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

  1. חשוב לוודא שאתם משתמשים ב-Performance Monitoring Android SDK בגרסה 19.1.0 ואילך (או ב-Firebase BoM בגרסה 26.3.0 ואילך). אפשר לעיין בהערה לגרסה.

  2. אם אתם עדיין מפתחים באופן מקומי, נסו ליצור עוד אירועים לאיסוף נתונים:

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

  3. מוודאים שקובץ התצורה של Firebase (google-services.json) נוסף לאפליקציה בצורה נכונה ושלא שיניתם את הקובץ. באופן ספציפי, כדאי לבדוק את הדברים הבאים:

    • שם קובץ התצורה לא מורחב בתווים נוספים, כמו (2).

    • קובץ התצורה נמצא בתיקייה module (ברמת האפליקציה) של האפליקציה.

    • מזהה האפליקציה ב-Firebase ל-Android‏ (mobilesdk_app_id) שמופיע בקובץ התצורה הוא המזהה הנכון של האפליקציה. מזהה האפליקציה ב-Firebase מופיע בכרטיס Your apps (האפליקציות שלך) בProject settings (הגדרות הפרויקט) של .

    אם משהו נראה לא בסדר בקובץ התצורה באפליקציה, נסו את הפעולות הבאות:

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

    2. כך מורידים קובץ תצורה חדש ומוסיפים אותו לאפליקציה ל-Android.

  4. אם ה-SDK מתעד אירועים ונראה שהכול מוגדר בצורה נכונה, אבל עדיין לא מופיעה הודעת הזיהוי של ה-SDK או נתונים שעברו עיבוד (אחרי 10 דקות), פנו לתמיכה של Firebase.

  1. בודקים את ההגדרה של הפלאגין Performance Monitoring Gradle באופן הבא:

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

      • הוספת את הפלאגין (apply plugin: 'com.google.firebase.firebase-perf') לקובץ build.gradle של המודול (ברמת האפליקציה).
      • כללת את התלות ב-classpath של הפלאגין (classpath 'com.google.firebase:perf-plugin:1.4.2') בקובץ build.gradle ברמת הפרויקט.

    2. מוודאים שהפלאגין לא מושבת באמצעות אחד מהדגלים הבאים:

      • instrumentationEnabled בקובץ build.gradle של המודול (ברמת האפליקציה)
      • firebasePerformanceInstrumentationEnabled בקובץ gradle.properties

  2. בודקים ש-ה-SDK של Performance Monitoring לא מושבת באמצעות אחד מהדגלים הבאים בקובץ AndroidManifest.xml:

    • firebase_performance_collection_enabled
    • firebase_performance_collection_deactivated

  3. מוודאים ש-Performance Monitoring לא מושבת במהלך זמן הריצה.

  4. אם לא מצאתם רכיב מושבת באפליקציה, פנו לתמיכה של Firebase.

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

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

פתרון בעיות כלליות

אם הוספתם את ה-SDK בהצלחה ואתם משתמשים ב-Performance Monitoring באפליקציה, הטיפים הבאים לפתרון בעיות יכולים לעזור לכם לפתור בעיות כלליות שקשורות לתכונות ולכלים של Performance Monitoring.

אם לא מוצגות הודעות ביומן לגבי אירועי ביצועים, אפשר לנסות את השלבים הבאים לפתרון בעיות:

  1. בודקים את ההגדרה של הפלאגין Performance Monitoring Gradle באופן הבא:

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

      • הוספת את הפלאגין (apply plugin: 'com.google.firebase.firebase-perf') לקובץ build.gradle של המודול (ברמת האפליקציה).
      • כללת את התלות ב-classpath של הפלאגין (classpath 'com.google.firebase:perf-plugin:1.4.2') בקובץ build.gradle ברמת הפרויקט.

    2. מוודאים שהפלאגין לא מושבת באמצעות אחד מהדגלים הבאים:

      • instrumentationEnabled בקובץ build.gradle של המודול (ברמת האפליקציה)
      • firebasePerformanceInstrumentationEnabled בקובץ gradle.properties

  2. בודקים ש-ה-SDK של Performance Monitoring לא מושבת באמצעות אחד מהדגלים הבאים בקובץ AndroidManifest.xml:

    • firebase_performance_collection_enabled
    • firebase_performance_collection_deactivated

  3. מוודאים ש-Performance Monitoring לא מושבת במהלך זמן הריצה.

  4. אם לא מצאתם רכיב מושבת באפליקציה, פנו לתמיכה של Firebase.

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

  1. חשוב לוודא שאתם משתמשים בגרסה העדכנית ביותר של Android SDK (גרסה 21.0.4). מעקב אחר רינדור המסך זמין רק בגרסה 15.2.0 ואילך.

  2. מוודאים שלא השבתתם ידנית את האפשרות שיפור המהירות באמצעות חומרה במסך.

  3. חשוב לוודא שאתם לא משתמשים ב-DexGuard או ב-Jack. Performance Monitoring לא תואם לסביבות הפיתוח האלה.

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

    • Jack הוצא משימוש, ובדרך כלל לא מומלץ להשתמש בו באפליקציה.

האם נתוני הביצועים מוצגים עבור נתוני מעקב שנאספו באופן אוטומטי אבל לא עבור נתוני מעקב של קוד מותאם אישית? אפשר לנסות את השלבים הבאים לפתרון בעיות:

  1. אם הטמעתם מעקב אחר קוד מותאם אישית באמצעות Trace API, כדאי לבדוק את ההגדרה של המעקב, במיוחד את האפשרויות הבאות:

    • השמות של מעקבים אחר קוד מותאם אישית ומדדים מותאמים אישית חייבים לעמוד בדרישות הבאות: אסור לכלול רווחים לבנים בתחילת השם או בסוף השם, אסור לכלול קו תחתון (_) בתחילת השם, והאורך המקסימלי של השם הוא 32 תווים.
    • צריך להפעיל ולהפסיק את כל המעקבים. כל מעקב שלא הופעל, לא הופסק או הופסק לפני ההפעלה לא יירשם ביומן.

  2. אם הטמעתם מעקב אחר קוד מותאם אישית באמצעות סימון @AddTrace, עליכם לבדוק את ההגדרה של הפלאגין Performance Monitoring Gradle:

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

      • הוספת את הפלאגין (apply plugin: 'com.google.firebase.firebase-perf') לקובץ build.gradle של המודול (ברמת האפליקציה).
      • כללת את התלות ב-classpath של הפלאגין (classpath 'com.google.firebase:perf-plugin:1.4.2') בקובץ build.gradle ברמת הפרויקט.

    2. מוודאים שהפלאגין לא מושבת באמצעות אחד מהדגלים הבאים:

      • instrumentationEnabled בקובץ build.gradle של המודול (ברמת האפליקציה)
      • firebasePerformanceInstrumentationEnabled בקובץ gradle.properties

  3. בודקים את הודעות היומן כדי לוודא ש-Performance Monitoring מתעד את עקבות הקוד המותאמים אישית הצפויים.

  4. אם Performance Monitoring מתעד אירועים ביומן אבל לא מוצגים נתונים אחרי 24 שעות, פנו לתמיכה של Firebase.

אם חסרים נתוני בקשות רשת, אפשר לנסות את השלבים הבאים לפתרון בעיות:

  1. באפליקציות ל-Android, הפלאגין Performance Monitoring של Gradle מאפשר להשתמש בכלי למדידה שמאפשר מעקב אוטומטי אחרי בקשות לרשתות HTTP/S. כדאי לבדוק את הדברים הבאים:

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

      • הוספת את הפלאגין (apply plugin: 'com.google.firebase.firebase-perf') לקובץ build.gradle של המודול (ברמת האפליקציה).
      • כללת את התלות ב-classpath של הפלאגין (classpath 'com.google.firebase:perf-plugin:1.4.2') בקובץ build.gradle ברמת הפרויקט.

    2. מוודאים שהפלאגין לא מושבת באמצעות אחד מהדגלים הבאים:

      • instrumentationEnabled בקובץ build.gradle של המודול (ברמת האפליקציה)
      • firebasePerformanceInstrumentationEnabled בקובץ gradle.properties

  2. בודקים אם יש אי-תאימות בין ספריית הרשת. Performance Monitoring אוסף באופן אוטומטי מדדים של בקשות רשת שמשתמשות בספריות הרשת הבאות: OkHttp 3.x.x,‏ URLConnection של Java ו-Apache HttpClient.

    שימו לב שאפשר להוסיף מעקב מותאם אישית לבקשות רשת.

  3. חשוב לשים לב לנקודות הבאות:

    • בהתאם להתנהגות הקוד ושל ספריות הרשתות שבהן הקוד משתמש, ייתכן ש-Performance Monitoring ידווח רק על בקשות רשת שהושלמו. כלומר, יכול להיות שלא ידווחו חיבורי HTTP/S שנשארים פתוחים.

    • Performance Monitoring לא תואם ל-DexGuard ול-Jack.

      • DexGuard משבית את המעקב אחר בקשות רשת מסוג HTTP/S.
      • Jack הוצא משימוש, ובדרך כלל לא מומלץ להשתמש בו באפליקציה.

    • Performance Monitoring לא מדווחת על בקשות רשת עם כותרות Content-Type לא חוקיות. עם זאת, עדיין יתקבלו בקשות רשת ללא כותרות Content-Type.

כך Performance Monitoring אוסף נתוני בקשות רשת לפי תבניות של כתובות URL.

אתם יכולים גם לנסות דפוסים מותאמים אישית של כתובות URL.

שאלות נפוצות

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

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

מידע נוסף על התראות זמין במאמר הגדרת התראות לגבי בעיות בביצועים.

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

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

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

כדי לנהל את נפח הנתונים שאנחנו אוספים, Performance Monitoring משתמש באפשרויות הדגימה הבאות:

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

  • דגימה דינמית: Performance Monitoring אוסף מדי יום מספר מוגבל של מעקבים אחר קוד ומעקבים אחר בקשות לרשת לכל אפליקציה, מכל המשתמשים באפליקציה. קצב דגימה דינמי מאוחזר במכשירים (באמצעות Firebase Remote Config) כדי לקבוע אם מכשיר אקראי צריך לתעד ולשלוח נתוני מעקב. מכשיר שלא נבחר לצורך דגימה לא שולח אירועים. קצב הדגימה הדינמי ספציפי לאפליקציה, והוא משתנה כדי להבטיח שהנפח הכולל של הנתונים שנאספים יישאר מתחת למגבלה.

    בפרויקטים שהופעל בהם שילוב עם BigQuery, המגבלה על מספר המעקבים אחר בקשות רשת גבוהה יותר.

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

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

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

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

עיצבנו מחדש את הקטע Performance Monitoring במסוף Firebase, כך שכרטיסיית Dashboard מציגה את מדדי המפתח ואת כל המעקבים במרחב אחד. כחלק מהעיצוב החדש, הסרנו את הדפים במכשיר ורשת.

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

אפשר להציג את הטרייסים בכרטיסי המשנה הבאים של טבלת הטרייסים:

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

פרטים על טבלת המעקב ועל הצגת מדדים ונתונים מופיעים בדף הסקירה הכללית של המסוף (iOS+ | Android | אינטרנט).

פריימים עם רינדור איטי ופריימים קפואים מחושבים על סמך ההנחה שקצב הרענון של המכשיר הוא 60Hz. אם קצב הרענון של המכשיר נמוך מ-60Hz, זמן העיבוד של כל פריים יהיה איטי יותר כי עיבוד פחות פריימים מתבצע בכל שנייה. זמני עיבוד איטיים יותר עלולים לגרום לדיווח על יותר פריימים איטיים או קפואים, כי יותר פריימים יעברו עיבוד איטי יותר או יקפאו. עם זאת, אם קצב הרענון של המכשיר גבוה מ-60Hz, זמן הרינדור של כל פריים יהיה מהיר יותר. כתוצאה מכך, פחות פריימים איטיים או קפואים ידווחו. זוהי הגבלה נוכחית ב-SDK של Performance Monitoring.

כדי לראות את הביצועים של קטעי קוד בנוסף לפעילות באפליקציה, צריך לוודא שבאפליקציה שלכם מותקנת גרסת Performance Monitoring Android SDK 20.1.0 ואילך. למידע נוסף, קראו את המאמר הוספת מעקב ביצועים לאפליקציה.

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

Performance Monitoring מבצע דגימת אירועים מכל האירועים שנאספים במכשיר. הגישה הזו מאפשרת לנו לאסוף את מספר האירועים המינימלי שנדרש ממכשירי המשתמשים כדי לספק מדדי ביצועים.

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

ב-Performance Monitoring ל-Android נעשה שימוש במדידה של קוד בייטקס כדי לספק כמה תכונות מוכנות לשימוש, כמו מעקב אחרי בקשות רשת מסוג HTTP/S. כחלק מההדרכה, התהליך כולל חזרה על כל הכיתות של האפליקציה (כולל יחסי התלות) כדי לבדוק את הקוד שחשוב למדידת הביצועים של בקשות הרשת באפליקציה.

ריכזנו כאן כמה גורמים עיקריים להארכת זמן ה-build:

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

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

החל מגרסה 1.3.3 של הפלאגין Performance Monitoring, התמקדנו בשיפורים משמעותיים בעיבוד הגרסת build המצטברת ובאחסון במטמון של הקלט של הספרייה. כדי ליהנות מהשיפורים האחרונים בזמן ה-build, חשוב להשתמש בגרסה האחרונה של הפלאגין (v1.4.2).

הערה: כדי למנוע זמני build ארוכים, אפשר להשבית את הפלאגין Performance Monitoring ב-builds לניפוי באגים באופן מקומי. עם זאת, הגישה הזו לא מומלצת לגרסאות build בסביבת הייצור, כי היא עלולה לגרום לפספס מדידות ביצועים של בקשות הרשת באפליקציה.

ב-Performance Monitoring ל-Android נעשה שימוש במדידה של קוד בייטקס כדי לספק כמה תכונות מוכנות לשימוש, כמו מעקב אחרי בקשות רשת מסוג HTTP/S. כחלק מההדרכה, התהליך כולל חזרה על כל הכיתות של האפליקציה (כולל יחסי התלות) כדי לבדוק את הקוד שחשוב למדידת הביצועים של בקשות הרשת באפליקציה.

אם מופיעות שגיאות build כמו JSR/RET are not supported with computeFrames option או שגיאות דומות אחרי השילוב עם הפלאגין Performance Monitoring, יכול להיות שיש לכם גם תלות בספרייה שאינה תואמת לפלאגין Performance Monitoring של Gradle.

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

  1. מעדכנים לגרסה האחרונה של הפלאגין Performance Monitoring Gradle (גרסה v1.4.0 לפחות).
  2. מעדכנים את הגרסה של הפלאגין של Android Gradle לגרסה 7.2.0 ואילך.
  3. מוסיפים את הדגל הבא לקובץ build.gradle של המודול (ברמת האפליקציה) כדי להחריג את הכיתות או הספריות הלא תואמות מההטמעה: 
    android {
  // ...
  androidComponents {
    onVariants(selector().all(), {
        instrumentation.excludes.add("example.incompatible.library")
    })
  }
}
     מידע נוסף על המאפיין exclude של ממשק ה-API Instrumentation של הפלאגין של Android Gradle זמין במאמר Instrumentation.

אם נתקלתם בשגיאות build בגלל ספריות לא תואמות, עליכם לדווח על הבעיה ב-GitHub כדי שנוכל להחריג אותן מהכלי של הפלאגין Performance Monitoring.

אם הפעלתם את השילוב עם BigQuery ב-Firebase Performance Monitoring, הנתונים ייוּצאו ל-BigQuery 12 עד 24 שעות אחרי סוף היום (לפי שעון החוף המערבי).

לדוגמה, הנתונים של 19 באפריל יהיו זמינים ב-BigQuery ב-20 באפריל בין השעות 12:00 ל-00:00 (כל התאריכים והשעות הם לפי שעון החוף המערבי).

עיבוד נתונים והצגה כמעט בזמן אמת

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

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

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

אלה גרסאות ה-SDK התואמות לזמן אמת:

  • iOS – גרסה 7.3.0 ואילך
  • tvOS – גרסה 8.9.0 ואילך
  • Android – גרסה 19.0.10 ואילך (או Firebase Android BoM גרסה 26.1.0 ואילך)
  • אינטרנט – גרסה 7.14.0 ואילך

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

אלה גרסאות ה-SDK התואמות לעיבוד נתונים בזמן אמת:

  • iOS – גרסה 7.3.0 ואילך
  • tvOS – גרסה 8.9.0 ואילך
  • Android – גרסה 19.0.10 ואילך (או Firebase Android BoM גרסה 26.1.0 ואילך)
  • אינטרנט – גרסה 7.14.0 ואילך

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

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

כן! לא משנה באיזו גרסת SDK משתמשת מופע של אפליקציה, תוכלו לראות נתוני ביצועים מכל המשתמשים.

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

פנייה לתמיכה של Firebase

אם תפנו לתמיכה של Firebase, תמיד צריך לכלול את מזהה האפליקציה ב-Firebase. מזהה האפליקציה ב-Firebase מופיע בכרטיס Your apps (האפליקציות שלך) בקטע Project settings (הגדרות הפרויקט) ב-.