בדף הזה תוכלו למצוא תשובות לשאלות נפוצות על Cloud Messaging ופתרונות לבעיות שקשורות אליו.
מה ההבדל בין הכלי ליצירת התראות לבין FCM?
Firebase Cloud Messaging מספקת קבוצה מלאה של יכולות העברת הודעות באמצעות ערכות ה-SDK ללקוח ופרוטוקול שרת ה-HTTP שלה. אם הפריסות שלכם כוללות דרישות מורכבות יותר לשליחת הודעות,
FCM היא הבחירה הנכונה.
כלי ההתראות הוא פתרון קל משקל להודעות ללא שרת, שמבוסס על Firebase Cloud Messaging. הכלי ליצירת התראות הוא קונסולה גרפית ידידותית למשתמש, עם דרישות קידוד מופחתות. בעזרתו, המשתמשים יכולים לשלוח הודעות כדי לעודד אינטראקציה חוזרת ולשמר משתמשים, לקדם את צמיחת האפליקציה ולתמוך בקמפיינים שיווקיים.
| יכולות |
|
הכלי ליצירת התראות |
Cloud Messaging |
| Target |
מכשיר יחיד |
|
|
|
לקוחות שנרשמו לנושאים
(למשל, מזג האוויר) |
|
|
|
לקוחות בפלח משתמשים מוגדר מראש (אפליקציה, גרסה, שפה) |
|
|
|
לקוחות בקהלים ספציפיים ב-Analytics |
|
|
|
לקוחות בקבוצות מכשירים |
|
|
|
בכיוון מהלקוח לשרת |
|
|
| סוג ההודעה |
התראות עד 2KB |
|
|
|
הודעות נתונים עד 4KB |
|
|
| משלוח |
מיידי |
|
|
|
הזמן המקומי העתידי במכשיר הלקוח |
|
|
| Analytics |
איסוף נתונים מובנה של ניתוח התראות וניתוח משפך |
|
|
האם צריך להשתמש בשירותים אחרים של Firebase כדי להשתמש ב-FCM?
אפשר להשתמש ב-Firebase Cloud Messaging כרכיב עצמאי, בלי להשתמש בשירותים אחרים של Firebase.
למה נראה שהמכשירים המטורגטים שלי לא מקבלים הודעות?
אם נראה שהמכשירים לא קיבלו את ההודעות, כדאי לבדוק קודם את שתי הסיבות האפשריות הבאות:
טיפול בהודעות שמתקבלות כשהאפליקציה פועלת בחזית. באפליקציות לקוח צריך להוסיף לוגיקה לטיפול בהודעות כדי לטפל בהודעות התראה כשהאפליקציה פועלת בחזית במכשיר. פרטים נוספים זמינים במאמרים בנושא iOS ו-Android.
הגבלות בחומת האש של הרשת. אם בארגון שלכם יש חומת אש שמגבילה את התעבורה אל האינטרנט או ממנו, אתם צריכים להגדיר אותה כך שתאפשר קישוריות עם FCM כדי שאפליקציות הלקוח של Firebase Cloud Messaging יוכלו לקבל הודעות. היציאות שצריך לפתוח הן:
FCM בדרך כלל משתמש בפורט 5228, אבל לפעמים הוא משתמש בפורטים 5229 ו-5230.
FCM לא מספקת כתובות IP ספציפיות, ולכן צריך לאפשר לחומת האש לקבל חיבורים יוצאים לכל כתובות ה-IP שכלולות בבלוקים של כתובות ה-IP שמפורטים ב-ASN של Google מספר 15169.
למה הפונקציה onMessageReceived לא מופעלת באפליקציית Android שלי?
כשהאפליקציה פועלת ברקע, הודעות התראה מוצגות במגש המערכת, והפונקציה onMessageReceived לא מופעלת. בהודעות התראה עם מטען נתונים, הודעת ההתראה מוצגת במגש המערכת, ואפשר לאחזר את הנתונים שנכללו בהודעת ההתראה מהכוונה שהופעלה כשהמשתמש מקיש על ההתראה.
מידע נוסף זמין במאמר בנושא קבלת הודעות וטיפול בהן.
למה מופיעה לי שגיאת 404 כשאני שולח הודעות למופע פעיל של אפליקציה ששוחזרה מגיבוי?
מזהה ההתקנה ב-Firebase (FID) הוא המזהה של מופע אפליקציה. כברירת מחדל,
נתוני ההתקנה של Firebase מגובים ומשוחזרים. לכן, במקרה של שחזור, מופע האפליקציה המשוחזר ומופע האפליקציה המקורי חולקים את אותו FID. מכיוון ש-FCM מאחסן רק טוקן אחד לכל FID, אם גם מופע האפליקציה המקורי וגם מופע האפליקציה המשוחזר נמצאים בשימוש, אז כשמופע אחד של האפליקציה נרשם ב-FCM, הטוקן של מופע האפליקציה השני מוסר, וזה גורם לשגיאות 404.
אנחנו ממליצים למפתחים לבצע את הפעולות הבאות באפליקציה שלהם:
- החרגה של נתוני ההתקנה של Firebase בגיבוי. נתוני ההתקנה של Firebase מאוחסנים בקובץ
PersistedInstallation....json. שם הקובץ הוא קבוע לאפליקציה. לדוגמה, <exclude domain="file" path="PersistedInstallation.W0R...GQ.json"
/>
Apple הודיעה שהיא מוציאה משימוש את הפרוטוקול הבינארי מדור קודם עבור APNs. צריך לעשות משהו?
לא. Firebase Cloud Messaging עבר לפרוטוקול APNs שמבוסס על HTTP/2 בשנת 2017.
אם אתם משתמשים ב-FCM כדי לשלוח התראות למכשירי iOS, לא אמורה להידרש פעולה מצידכם.
מכסות ומגבלות של FCM
איך אפשר להודיע למספר גדול של לקוחות תוך 2 דקות?
אין אפשרות לתמוך בתרחיש השימוש הזה. צריך לפזר את התנועה על פני 5 דקות.
האפליקציה שלי שולחת למשתמשים הודעות על אירועים, וההודעות האלה צריכות להישלח באופן מיידי כדי לתמוך במודל העסקי שלי. אפשר לקבל מכסה גדולה יותר?
לצערנו, אנחנו לא יכולים להגדיל את המכסה מהסיבה הזו. כדי למנוע תנועה לא סדירה, צריך לפזר את התנועה על פני 5 דקות.
ההודעות שלי הן לגבי
אירועים מתוזמנים. איך אפשר לשלוח את כל התנועה בתחילת השעה?
מומלץ להתחיל לשלוח את ההתראות לפחות 5 דקות לפני האירוע. אפשרות אחרת היא לשלוח הודעות עם נתונים ולהטמיע את האנלוג של handler onMessageReceived בפלטפורמה כדי לתזמן התראות מקומיות מראש.
איך אפשר לעקוב אחרי השימוש במכסה?
כאן אפשר לקרוא הנחיות של Google Cloud בנושא מיפוי ומעקב אחרי מדדי מכסות.
קשה לי ולעסק שלי להתמודד עם שגיאות 429. אפשר לקבל פטור או מכסה גדולה יותר כדי להימנע מקבלת קודי שגיאה 429?
אנחנו מבינים שמגבלות המכסה יכולות להיות בעייתיות, אבל המכסות חיוניות לשמירה על אמינות השירות, ולכן אנחנו לא יכולים להעניק פטורים. כדאי להשתמש בניסיונות חוזרים כדי לטפל בשגיאות 429 בצורה נכונה.
כמה זמן ייקח עד שהבקשה שלי להגדלת המכסה תאושר?
הבקשה להגדלת המכסה תלויה בשימוש שלכם ב-FCM. בכל מקרה, תקבלו תשובה תוך כמה ימי עסקים. במקרים מסוימים, יכול להיות שיהיו כמה תכתובות לגבי השימוש שלך ב-FCM ונסיבות שונות, מה שיכול להאריך את התהליך. אם עומדים בכל הדרישות, רוב הבקשות מטופלות תוך שבועיים.
אפשר לקבל מכסת אחסון גדולה יותר לאירוע זמני?
אתם יכולים לבקש מכסה נוספת כדי לתמוך באירוע שנמשך עד חודש.
צריך לשלוח את הבקשה לפחות חודש לפני האירוע, ולציין בה בבירור את שעת ההתחלה ושעת הסיום של האירוע. FCM יעשה כל מאמץ מעשי כדי להיענות לבקשה. אם נאשר את ההגדלות האלה במכסה, הן יבוטלו אחרי תאריך הסיום של האירוע.
האם המכסה הנוכחית שלי עשויה להשתנות?
Google לא תעשה זאת בקלות, אבל יכול להיות שהיא תשנה את המכסות לפי הצורך כדי להגן על תקינות המערכת. במידת האפשר, Google תודיע לכם מראש על שינויים כאלה. כדי להגדיל את הסיכוי לקבל הודעות על השירות, חשוב לעדכן את אנשי הקשר שלכם ב-Cloud MSA.
FCM הוצאה משימוש של API מדור קודם
ממשקי API בצד השרת הוצאו משימוש בספטמבר 2026
אילו ממשקי API ותכונות הוצאו משימוש ויושבתו? מה צריך לעשות אם משתמשים בממשקי ה-API האלה?
כל InstanceId server APIs
והתכונה 'קבוצת מכשירים' הוצאו משימוש ויושבתו ב-29 בספטמבר 2027. בטבלה הבאה מפורטים ממשקי ה-API או התכונות שהוצאו משימוש והפעולה הנדרשת.
| שם ה-API
|
נקודת קצה ל-API
|
שימוש מיועד
|
השפעה על הלקוחות
|
נדרשת פעולה
|
| InstanceId info API
|
https://iid.googleapis.com/iid/info
|
קבלת מידע שקשור ל-InstanceId או לטוקן FCM
|
בקשות ל-API הזה יתחילו להיכשל אחרי 29 בספטמבר 2027.
|
לקוחות שמשתמשים ב-API לאימות טוקנים צריכים להשתמש ב-FCM V1 send API ולהגדיר את validate_only כ-true.
לקוחות שמשתמשים ב-API כדי לקבל מידע על מינוי לנושא, צריכים לעבור ל-API החדש למינוי לנושא.
|
| InstanceId topic subscription API
|
https://iid.googleapis.com/iid/v1/…/rel/topics
https://iid.googleapis.com/iid/v1:batchAdd
https://iid.googleapis.com/iid/v1:batchRemove
|
רישום אסימונים למינוי לנושא באמצעות Topics API מדור קודם.
|
בקשות ל-API האלה יתחילו להיכשל אחרי 29 בספטמבר 2027.
|
מעבר ל-API החדש של שרת המינויים לנושא FCM למינוי לנושא וביטול מינוי.
|
| InstanceId batch import API
|
https://iid.googleapis.com/iid/v1:batchImport
|
יצירת אסימוני FCM ל-iOS באצווה בצד השרת.
|
בקשות ל-API הזה יתחילו להיכשל אחרי 29 בספטמבר 2027.
לא תהיה תמיכה ביצירת רישומים של FCM מטוקנים של APNs בצד השרת.
|
אתם יכולים להשתמש בשירות ה-APNs של Apple כדי לשלוח התראות באמצעות אסימוני APNs.
כדי ליהנות מיתרונות נוספים ש-FCM מספקת, צריך לשלב את האפליקציה עם FCM iOS SDK, שיצור רישומים של FCM בלקוח.
|
| Device group management API
|
https://fcm.googleapis.com/fcm/notification
https://fcm.googleapis.com/gcm/notification
https://fcm.googleapis.com/iid/notification
https://fcm.googleapis.com/notification
|
הוספה / הסרה/ אחזור של חברים בקבוצת מכשירים.
|
בקשות ל-API הזה יתחילו להיכשל אחרי 29 בספטמבר 2027.
|
כאן אפשר לקרוא הנחיות להפסקת השימוש בתכונה.
עדיין אפשר לשלוח הודעות לרישומים של FCM בודדים במקום לטוקנים של קבוצות.
|
| שליחה לקבוצת מכשירים
|
https://fcm.googleapis.com/v1/projects/…/messages:send
|
שליחת הודעות לקבוצות מכשירים באמצעות מפתח ההתראה הקבוצתי notification_key.
|
ה-API הזה ימשיך לפעול, אבל הוא לא יתמוך בטוקנים של קבוצות מכשירים אחרי 29 בספטמבר 2027.
|
אם אני משתמש ב-SDK של Firebase לאדמינים כדי לנהל הרשמות לנושאים, האם אהיה מושפע מהפסקת התמיכה? מה לעשות?
אם אתם משתמשים בגרסאות קודמות של SDK של Firebase לאדמינים כדי לנהל הרשמות לנושאים, הפסקת התמיכה תשפיע עליכם.
תצטרכו לשדרג את SDK של Firebase לאדמינים לגרסאות הבאות:
| פלטפורמה
|
גרסת SDK לאדמינים שהושפעה
|
גרסת SDK לאדמינים לשדרוג
|
| Node.js
|
<=14.4.0
|
>=14.5.0
|
| Python
|
<=7.6.0
|
>=7.7.0
|
| Java
|
<=9.10.0
|
>=9.11.0
|
| המשך
|
<=4.21.0
|
>=4.22.0
|
| .NET
|
<=3.6.0
|
>=3.7.0
|
האם תהיה הורדת רמת שירות לפני 29 בספטמבר 2027?
לא. יש לכם 12 חודשים לעבור מ-API שיצא משימוש לחלופות, בלי שיהיה שדרוג לאחור של השירות. מומלץ מאוד לתכנן את ההעברה בהקדם האפשרי כדי שההוצאה משימוש לא תשפיע עליכם.
צפויות שגיאות כשקוראים לממשקי API שהוצאו משימוש אחרי 29 בספטמבר 2027.
האם משתמשים חדשים יכולים להשתמש בתכונות או בממשקי ה-API שהוצאו משימוש לפני ההוצאה הסופית משימוש?
משתמשים חדשים יכולים להצטרף ל-APIs או לתכונות שהוצאו משימוש לפני 1 בינואר 2027.
אחרי 1 בינואר 2027, משתמשים חדשים לא יוכלו להשתמש בממשקי ה-API שהוצאו משימוש.
משתמשים שמשתמשים בממשקי ה-API שהוצאו משימוש יכולים להמשיך להשתמש בהם עד 29 בספטמבר 2027.
