אם אתם מתחילים להשתמש ב-Performance Monitoring (iOS+ | Android | אינטרנט), הטיפים הבאים לפתרון בעיות יכולים לעזור לכם לפתור בעיות שקשורות לזיהוי ה-SDK על ידי Firebase או להצגת נתוני הביצועים הראשונים במסוף Firebase.
הוספתי את ה-SDK לאפליקציה, אבל במסוף עדיין כתוב שצריך להוסיף את ה-SDK
מערכת Firebase יכולה לזהות אם הוספתם בהצלחה את ה-SDK של Performance Monitoring לאפליקציה כשהיא מקבלת מידע על אירועים (כמו אינטראקציות עם האפליקציה) מהאפליקציה. בדרך כלל, בתוך 10 דקות מהפעלת האפליקציה, מרכז הבקרה של Performance במסוף Firebase מציג את ההודעה "SDK detected" (זוהה SDK). אחרי 30 דקות, הנתונים הראשוניים שעובדו יוצגו במרכז הבקרה.
אם עברו יותר מ-10 דקות מאז שהוספתם את הגרסה העדכנית של ה-SDK לאפליקציה, ועדיין לא רואים שינוי, בדקו את הודעות היומן כדי לוודא ש-Performance Monitoring מתעד אירועים. כדי לפתור בעיה שקשורה להודעה על עיכוב בזיהוי ה-SDK, נסו את השלבים המתאימים לפתרון בעיות שמתוארים בהמשך.
האפליקציה מתעדת אירועים: שלבים לפתרון בעיות
אם אתם עדיין מפתחים באופן מקומי, נסו ליצור עוד אירועים לאיסוף נתונים:
ממשיכים לפתח את האפליקציה באמצעות סימולטור או מכשיר בדיקה.
כדי ליצור אירועים, מעבירים את האפליקציה בין הרקע לחזית כמה פעמים, מבצעים פעולות באפליקציה על ידי ניווט בין מסכים ו/או מפעילים בקשות לאחזור מהרשת.
מוודאים שקובץ התצורה של Firebase (Google-Service-Info.plist) נוסף לאפליקציה בצורה נכונה, ושלא שיניתם את הקובץ.
באופן ספציפי, כדאי לבדוק את הדברים הבאים:
שם קובץ התצורה לא כולל תווים נוספים, כמו (2).
קובץ התצורה נמצא בתיקיית השורש של פרויקט ה-XCode ונוסף ליעדים הנכונים.
מזהה האפליקציה של אפל ב-Firebase (GOOGLE_APP_ID) שמופיע בקובץ התצורה מתאים לאפליקציה שלכם. מזהה האפליקציה ב-Firebase מופיע בכרטיס האפליקציות שלך בקטע settingsProject settings.
אם נראה שיש בעיה בקובץ התצורה באפליקציה, נסו את הפעולות הבאות:
מוחקים את קובץ התצורה שקיים כרגע באפליקציה.
כדי להוריד קובץ תצורה חדש ולהוסיף אותו לאפליקציה ל-Apple, פועלים לפי ההוראות האלה.
אם ערכת ה-SDK מתעדת אירועים ונראה שהכול מוגדר כמו שצריך, אבל עדיין לא מופיעה הודעה על זיהוי ה-SDK או נתונים מעובדים (אחרי שעתיים), פנו לתמיכה של Firebase.
אם הוספתם את ה-SDK בהצלחה ואתם משתמשים ב-Performance Monitoring באפליקציה, הטיפים הבאים לפתרון בעיות יכולים לעזור לכם לפתור בעיות כלליות שקשורות לתכונות ולכלים של Performance Monitoring.
אם חסרים נתונים של מעקבי עיבוד מסך, נסו את השלבים הבאים לפתרון בעיות:
בלוח בקרה לביצועי הענן חסרים נתוני מעקב בהתאמה אישית
האם אתם רואים נתוני ביצועים של מעקבים שנאספו באופן אוטומטי אבל לא של מעקבים של קוד בהתאמה אישית? נסו את השלבים הבאים לפתרון בעיות:
בודקים את ההגדרה של מעקבי קוד בהתאמה אישית שנוצרו באמצעות Trace API, ובמיוחד את הדברים הבאים:
השמות של מעקבי קוד בהתאמה אישית ושל מדדים בהתאמה אישית חייבים לעמוד בדרישות הבאות: בלי רווחים לבנים בתחילת השם או בסופו, בלי קו תחתון (_) בתחילת השם, ואורך מקסימלי של 32 תווים.
צריך להפעיל ולהפסיק את כל המעקבים. כל מעקב שלא התחיל, לא הופסק או הופסק לפני שהתחיל לא יתועד ביומן.
בודקים את הודעות היומן כדי לוודא ש-Performance Monitoring מתעד את העקבות הצפויים של הקוד בהתאמה אישית.
אם Performance Monitoring מתעד אירועים, אבל לא מוצגים נתונים אחרי 24 שעות, פנו לתמיכה של Firebase.
לוח בקרה לביצועי הענן חסרים נתונים של בקשות לאחזור מהרשת
אם חסרים לכם נתונים של בקשות לאחזור מהרשת, נסו את השלבים הבאים לפתרון בעיות:
בהתאם להתנהגות של הקוד ושל ספריות הרשת שבהן הקוד משתמש, יכול להיות ש-Performance Monitoring ידווח רק על בקשות לאחזור מהרשת שהושלמו. כלומר, יכול להיות שחיבורי HTTP/S שיישארו פתוחים לא ידווחו.
Performance Monitoring לא מדווח על בקשות לאחזור מהרשת עם כותרות Content-Type לא תקינות. עם זאת, עדיין יתקבלו בקשות לאחזור מהרשת בלי הכותרות Content-Type.
לאן נעלם הקטע "הבעיות המובילות" בכרטיס "ביצועים" בדף הבית של הפרויקט?
החלפנו את הבעיות המובילות בהתראות אחרונות, כהמשך להשקה האחרונה של ההתראות, שמודיעות לכם באופן אוטומטי כשמתרחשת חריגה מהספים שהגדרתם. הוצאנו משימוש את הבעיות והחלפנו אותן בהתראות.
בורר האפליקציות שבחלק העליון של הכרטיס "ביצועים" מסנן את ההתראות שמופיעות בקטע התראות אחרונות. מוצגות רק שלוש ההתראות האחרונות של האפליקציות שנבחרו.
ב-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.
לוקח יותר זמן מהצפוי לייצא את נתוני 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 של 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 לעבד את הנתונים שלכם כמעט בזמן אמת.
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2026-10-16 (שעון UTC)."],[],[]]
