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

איך להציג הודעות ביומן של אירועי ביצועים

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. יכול להיות שיעברו כמה רגעים עד שהנתונים יתעדכנו במרכז הבקרה.

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

הוספתי את ה-SDK לאפליקציה, אבל במסוף עדיין כתוב שצריך להוסיף את ה-SDK

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

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

ב-Console כתוב שערכת ה-SDK זוהתה, אבל לא מוצגים נתונים

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

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

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

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

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

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

      • הוספתם את הפלאגין (apply plugin: 'com.google.firebase.firebase-perf') לקובץ build.gradle של המודול (ברמת האפליקציה).
      • הוספתם את התלות ב-classpath של הפלאגין (classpath 'com.google.firebase:perf-plugin:2.0.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 (גרסה 23.0.1). מעקבי רינדור מסך זמינים רק בגרסה 15.2.0 ואילך.

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

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

   • ‫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:2.0.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:2.0.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 אפשר להגדיר התראות למדדים שחורגים מסף מסוים. כדי למנוע בלבול עם הספים האלה שניתנים להגדרה למדדי ביצועים, הסרנו את האפשרות להגדיר ספים לבעיות.

מה קרה למידע בקטעים "פרטים" ו"מדדים" במסוף Firebase?

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

למה מספר הדגימות שונה ממה שציפיתי?

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

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

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

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

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

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

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

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

מה קרה לכרטיסייה בעיות במסוף?

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

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

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

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

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

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

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

למה מספר הפריימים האיטיים והקפואים שונה ממה שציפיתי?

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

למה אני לא רואה מעקבים אחר מקטעים?

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

איך אפשר להבין אילו עקבות קשורים לפעילויות ולפרגמנטים?

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

למה אני רואה פחות מעקבי מקטעים מאשר מעקבים אחרים?

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

איך מקבלים התראה כשיש בעיה בביצועי הרינדור של האפליקציה?

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

זמני ה-build שלי ארוכים אחרי שהפעלתי את הפלאגין Performance Monitoring של Gradle. איך אפשר לשפר את זה?

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

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

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

כדי לייעל את זמן ה-build, כדאי להפוך את הקוד למודולרי.

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

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

מה עושים אם מקבלים שגיאות build בגלל ספריות שלא תואמות לפלאגין Performance Monitoring של Gradle?

‫Performance Monitoring ל-Android משתמש ב-bytecode instrumentation כדי לספק תכונות מוכנות לשימוש כמו מעקב אחרי בקשות לאחזור מהרשת מסוג 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 זמין במאמר אינסטרומנטציה.

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

לוקח יותר זמן מהצפוי לייצא את נתוני Performance Monitoring ל-BigQuery. האם זה לא בזמן אמת?

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

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

כמה תבניות של כתובות URL מותאמות אישית אפשר ליצור?

אפשר ליצור עד 400 תבניות של כתובות URL מותאמות אישית לכל אפליקציה, ועד 100 תבניות של כתובות URL מותאמות אישית לכל דומיין באפליקציה הזו.

מה המשמעות של נתוני ביצועים "כמעט בזמן אמת"?

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

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

איך אפשר לקבל נתוני ביצועים כמעט בזמן אמת לאפליקציה?

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

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

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

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

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

למה נתוני הביצועים לא מוצגים בזמן אמת?

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

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

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