מידע על הודעות FCM

‫Firebase Cloud Messaging (FCM) מציע מגוון רחב של אפשרויות ויכולות לשליחת הודעות. המידע בדף הזה נועד לעזור לכם להבין את הסוגים השונים של הודעות FCM ומה אפשר לעשות איתן.

סוגי הודעות

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

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

הודעות ההתראה מכילות קבוצה מוגדרת מראש של מפתחות שגלויים למשתמשים. לעומת זאת, הודעות נתונים מכילות רק זוגות של מפתח/ערך בהתאמה אישית שהוגדרו על ידי המשתמש. הודעות ההתראה יכולות להכיל מטען ייעודי (Payload) של נתונים. המטען הייעודי המקסימלי לשני סוגי ההודעות הוא 4,096 בייטים, למעט כששולחים הודעות ממסוף Firebase, שבו יש מגבלה של 1,000 תווים.

	תרחיש שימוש	איך שולחים
הודעה לידיעה	‫FCM SDK מציג את ההודעה במכשירים של משתמשי הקצה בשם אפליקציית הלקוח כשהיא פועלת ברקע. אחרת, אם האפליקציה פועלת בחזית כשההתראה מתקבלת, הקוד של האפליקציה קובע את ההתנהגות. להודעות התראה יש קבוצה מוגדרת מראש של מפתחות שגלויים למשתמשים ומטען ייעודי (payload) אופציונלי של נתונים שכולל צמדים מותאמים אישית של מפתח/ערך.	בסביבה מהימנה כמו Cloud Functions או שרת האפליקציות שלכם, משתמשים ב-Admin SDK או ב-HTTP v1 API. מגדירים את המפתח notification. יכול להיות שיש לו מטען נתונים אופציונלי. תמיד אפשר לכווץ. דוגמאות להתראות לרשת המדיה ומטענים של בקשות לשליחה משתמשים ב כלי ליצירת התראות: מזינים את טקסט ההודעה, הכותרת וכו' ושולחים. אפשר להוסיף מטען ייעודי (payload) של נתונים אופציונליים על ידי ציון נתונים מותאמים אישית.
הודעת נתונים	אפליקציית הלקוח אחראית לעיבוד הודעות הנתונים. הודעות נתונים כוללות רק צמדי מפתח/ערך מותאמים אישית ללא שמות מפתחות שמורים (ראו בהמשך).	בסביבה מהימנה כמו Cloud Functions או שרת האפליקציה, משתמשים ב-Admin SDK או בפרוטוקולים של שרת FCM. בבקשת השליחה, מגדירים את המפתח data.

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

‫FCM יכול לשלוח הודעת התראה שכוללת מטען ייעודי (Payload) של נתונים (אופציונלי). במקרים כאלה, FCM מטפל בהצגת מטען הייעודי (payload) של ההתראה, ואפליקציית הלקוח מטפלת במטען הייעודי (payload) של הנתונים.

הודעות לידיעה

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

כדי לשלוח הודעות התראה באופן פרוגרמטי באמצעות Admin SDK או פרוטוקולי FCM, צריך להגדיר את המפתח notification עם קבוצה מוגדרת מראש של אפשרויות של זוגות מפתח/ערך עבור החלק של הודעת ההתראה שגלוי למשתמש. לדוגמה, הנה הודעת התראה בפורמט JSON באפליקציית צ'אט. המשתמש יכול לצפות לראות במכשיר הודעה עם הכותרת Portugal vs. Denmark והטקסט great match!:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    }
  }
}

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

רשימה מלאה של מפתחות מוגדרים מראש שזמינים ליצירת הודעות התראה מופיעה במאמרי העזרה בנושא אובייקט התראה של פרוטוקול HTTP v1.

הודעות נתונים

מגדירים את המפתח המתאים עם צמדי המפתח/ערך המותאמים אישית כדי לשלוח מטען ייעודי (payload) של נתונים לאפליקציית הלקוח.

חשוב לוודא שלא משתמשים במילים שמורות בצמדי מפתח/ערך מותאמים אישית. מילים שמורות כוללות את המילים from,‏ notification,‏ message_type או כל מילה שמתחילה ב-google או ב-gcm.

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

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    }
  }
}

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

הצפנה של הודעות עם נתונים

שכבת התעבורה של Android (ראו ארכיטקטורת FCM) משתמשת בהצפנה מקצה לקצה. בהתאם לצרכים שלכם, יכול להיות שתחליטו להוסיף הצפנה מקצה לקצה להודעות עם נתונים. ‫FCM לא מספק פתרון מקצה לקצה. עם זאת, יש פתרונות חיצוניים כמו Capillary או DTLS.

הודעות התראה עם מטען נתונים אופציונלי

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

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

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

הנה הודעה בפורמט JSON שמכילה גם את המפתח notification וגם את המפתח data:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

התאמה אישית של הודעה בפלטפורמות שונות

גם Firebase Admin SDK וגם פרוטוקול HTTP‏ FCM v1 מאפשרים לבקשות ההודעות להגדיר את כל השדות שזמינים באובייקט message. בין המקורות האלה:

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

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

מתי כדאי להשתמש בשדות נפוצים

כדאי להשתמש בשדות נפוצים כשמבצעים את הפעולות הבאות:

• טירגוט מופעים של אפליקציות בכל הפלטפורמות – Apple,‏ Android ואינטרנט
• שליחת הודעות לנושאים

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

• message.notification.title
• message.notification.body
• message.data

מתי כדאי להשתמש בשדות ספציפיים לפלטפורמה

משתמשים בשדות ספציפיים לפלטפורמה כשרוצים:

• שליחת שדות רק לפלטפורמות מסוימות
• שליחת שדות ספציפיים לפלטפורמה בנוסף לשדות המשותפים

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

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

דוגמה: הודעה עם אפשרויות מסירה ספציפיות לפלטפורמה

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

• מגדיר זמן חיים ארוך לפלטפורמות Android ואינטרנט, ומגדיר את העדיפות של הודעות APNs (פלטפורמות Apple) לערך נמוך
• מגדיר את המפתחות המתאימים כדי להגדיר את התוצאה של הקשה של משתמש על ההתראה ב-Android וב-Apple – click_action ו-category, בהתאמה.

{
  "message":{
     "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
     "notification":{
       "title":"Match update",
       "body":"Arsenal goal in added time, score is now 3-0"
     },
     "android":{
       "ttl":"86400s",
       "notification"{
         "click_action":"OPEN_ACTIVITY_1"
       }
     },
     "apns": {
       "headers": {
         "apns-priority": "5",
       },
       "payload": {
         "aps": {
           "category": "NEW_MESSAGE_CATEGORY"
         }
       }
     },
     "webpush":{
       "headers":{
         "TTL":"86400"
       }
     }
   }
 }

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

אפשרויות משלוח

FCM מספקת קבוצה ספציפית של אפשרויות לשליחת הודעות למכשירי Android, ומאפשרת אפשרויות דומות בפלטפורמות של אפל ובאינטרנט. לדוגמה, התנהגות של הודעה 'ניתנת לצמצום' נתמכת ב-Android באמצעות FCMcollapse_key, ב-Apple באמצעות apns-collapse-id וב-JavaScript/Web באמצעות Topic. לפרטים נוספים, אפשר לעיין בתיאורים שבקטע הזה ובמאמרי העזרה שקשורים אליו.

הודעות שלא ניתן לכווץ והודעות שניתן לכווץ

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

FCM לא מבטיח את סדר המסירה.

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

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

הודעה שניתן לכווץ היא הודעה שאולי תוחלף בהודעה חדשה אם היא עדיין לא נמסרה למכשיר.

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

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

הודעות בנושאים ללא מטען ייעודי (Payload) ניתנות לכיווץ כברירת מחדל. הודעות התראה תמיד ניתנות לצמצום, והמערכת תתעלם מהפרמטר collapse_key.

באיזו מהן כדאי להשתמש?

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

	תרחיש שימוש	איך שולחים
לא ניתן לכווץ	כל הודעה חשובה לאפליקציית הלקוח וצריך להעביר אותה.	חוץ מהודעות התראה, כל ההודעות לא ניתנות לכיווץ כברירת מחדל.
ניתן לכיווץ	אם יש הודעה חדשה יותר שהופכת הודעה ישנה יותר שקשורה אליה ללא רלוונטית לאפליקציית הלקוח, FCM מחליפה את ההודעה הישנה יותר. לדוגמה: הודעות שמשמשות ליזום סנכרון נתונים מהשרת, או הודעות התראה לא עדכניות.	מגדירים את הפרמטר המתאים בבקשת ההודעה: ‫collapseKey ב-Android apns-collapse-id ב-Apple Topic באתר collapse_key בפרוטוקולים מדור קודם (כל הפלטפורמות)

הגדרת העדיפות של הודעה

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

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

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

כששולחים הודעות נתונים למכשירי אפל, צריך להגדיר את העדיפות ל-5, או לעדיפות רגילה. הודעות שנשלחות עם עדיפות גבוהה נדחות על ידי קצה העורפי FCM עם השגיאה INVALID_ARGUMENT.

הנה דוגמה להודעה עם עדיפות רגילה שנשלחה באמצעות פרוטוקול FCM HTTP v1 כדי להודיע למנוי של מגזין שתוכן חדש זמין להורדה:

{
  "message":{
    "topic":"subscriber-updates",
    "notification":{
      "body" : "This week's edition is now available.",
      "title" : "NewsMagazine.com",
    },
    "data" : {
      "volume" : "3.21.15",
      "contents" : "http://www.news-magazine.com/world-week/21659772"
    },
    "android":{
      "priority":"normal"
    },
    "apns":{
      "headers":{
        "apns-priority":"5"
      }
    },
    "webpush": {
      "headers": {
        "Urgency": "high"
      }
    }
  }
}

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

• מסמכי תיעוד של APNs
• הגדרת העדיפות של ההודעות וניהול שלהן (Android)
• דחיפות של הודעות מדפי אינטרנט

תרחישי שימוש קריטיים

ממשקי ה-API של FCM לא מיועדים להתרעות על מצבי חירום או לפעילויות אחרות בסיכון גבוה שבהן השימוש בממשקי ה-API או תקלה בהם עלולים לגרום למוות, לנזקי גוף או לנזק סביבתי (כמו הפעלה של מתקנים גרעיניים, בקרה אווירית או מערכות מצילות חיים). כל שימוש כזה אסור באופן מפורש במסגרת סעיף 4. א. ‫7 בתנאים ובהגבלות. אתם האחראים הבלעדיים לניהול התאימות של האפליקציה שלכם לתנאים, ולכל נזק שנובע מאי-תאימות. ‫Google מספקת את ממשקי ה-API "כמו שהם", ושומרת לעצמה את הזכות להפסיק את השימוש בממשקי ה-API או בכל חלק או תכונה שלהם, או להפסיק את הגישה שלך אליהם מכל סיבה שהיא ובכל זמן, ללא אחריות או מחויבות אחרת כלפיך או כלפי המשתמשים שלך.

הגדרת אורך החיים של הודעה

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

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

ב-Android וב-Web/JavaScript, אפשר לציין את משך החיים המקסימלי של הודעה. הערך צריך להיות משך זמן בין 0 ל-2,419,200 שניות (28 ימים), והוא מייצג את התקופה המקסימלית שבה FCM מאחסן את ההודעה ומנסה למסור אותה. אם הבקשות לא מכילות את השדה הזה, ברירת המחדל היא התקופה המקסימלית של ארבעה שבועות.

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

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

יתרון נוסף של הגדרת משך החיים של הודעה הוא ש-FCM לא מחיל על הודעות עם ערך של 0 שניות לזמן החיים (TTL) הגבלת קצב של הודעות שניתנות לצמצום. ‫FCM מספק טיפול מיטבי בהודעות שחייבות להימסר 'עכשיו או לעולם לא'. חשוב לזכור שערך של time_to_live 0 מציין שהודעות שלא ניתן למסור באופן מיידי יימחקו. עם זאת, מכיוון שהודעות כאלה אף פעם לא מאוחסנות, הן מספקות את השהייה הכי נמוכה בשליחת הודעות התראה.

דוגמה לבקשה שכוללת TTL:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    },
    "apns":{
      "headers":{
        "apns-expiration":"1604750400"
      }
    },
    "android":{
      "ttl":"4500s"
    },
    "webpush":{
      "headers":{
        "TTL":"4500"
      }
    }
  }
}

משך החיים של הודעה

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

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

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

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

כדי לקבל תובנות נוספות לגבי מסירת הודעה:

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

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

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

ויסות נתונים ומכסות

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

הערה: יכול להיות שיהיו שינויים במגבלות שמוזכרות בקטע הזה.

הגבלת קצב העברת הודעות (throttling) ב-Downstream

ב-HTTP v1 API הוספנו מכסות לכל פרויקט ולכל דקה לשליחת הודעות במורד הזרם. מכסת ברירת המחדל של 600,000 הודעות לדקה מכסה יותר מ-99% מהמפתחים, תוך שמירה על יציבות המערכת ומזעור ההשפעה של פרויקטים עם עליות חדות.FCM

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

חשוב לדעת:

• המכסה במורד הזרם מתייחסת להודעות ולא לבקשות.
• שגיאות לקוח (קוד סטטוס HTTP‏ 400-499) נספרות (לא כולל 429).
• המכסות הן לדקה, אבל הדקות האלה לא תואמות לשעון.

מכסת המעקב

אפשר לראות את המכסה, השימוש והשגיאות במסוף Google Cloud:

1. עוברים אל מסוף Google Cloud
2. בוחרים באפשרות APIs & services (ממשקי API ושירותים).
3. ברשימת הטבלאות, בוחרים באפשרות Firebase Cloud Messaging API.
4. בוחרים באפשרות QUOTA & SYSTEM LIMITS (מכסות ומגבלות מערכת).

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

איך מבקשים להגדיל את המכסות?

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

• השימוש שלכם הוא באופן קבוע ≥ 80% מהמכסה למשך 5 דקות רצופות לפחות בכל יום.
• שיעור השגיאות בצד הלקוח הוא פחות מ-5%, במיוחד בזמן שיא התנועה.
• אתם פועלים לפי השיטות המומלצות לשליחת הודעות בהיקף גדול.

אם אתם עומדים בקריטריונים האלה, אתם יכולים לשלוח בקשה להגדלת המכסה בעד 25% +, וצוות FCM יעשה כל מאמץ מעשי כדי למלא את הבקשה (אין ערובה להגדלת המכסה).

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

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

מגבלת ההודעות בנושא

קצב ההוספה או ההסרה של מינוי לנושא מוגבל ל-3,000 בקשות לשנייה לכל פרויקט.

מידע על קצב שליחת הודעות מופיע במאמר Fanout Throttling.

ויסות נתונים (throttle) של fanout

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

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

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

הגבלת קצב השליחה של הודעות שניתנות לכיווץ

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

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

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

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

קצב ההודעות המקסימלי למכשיר יחיד

ב-Android, אפשר לשלוח עד 240 הודעות בדקה ו-5,000 הודעות בשעה למכשיר אחד. הסף הגבוה הזה נועד לאפשר פרצי תנועה לטווח קצר, למשל כשמשתמשים מנהלים שיחות צ'אט בקצב מהיר. המגבלה הזו מונעת שגיאות בלוגיקת השליחה שגורמות לניקוז הסוללה במכשיר בטעות.

ב-iOS, אנחנו מחזירים שגיאה כשהקצב חורג מהמגבלות של APNs.

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

יציאות FCM וחומת האש

אם בארגון שלכם יש חומת אש שמגבילה את התנועה אל האינטרנט או ממנו, אתם צריכים להגדיר אותה כך שתאפשר למכשירים ניידים להתחבר אל FCM כדי שמכשירים ברשת שלכם יוכלו לקבל הודעות. ‫FCM בדרך כלל משתמש ביציאה 5228, אבל לפעמים הוא משתמש ביציאות 443, 5229 ו-5230.

במכשירים שמתחברים לרשת שלכם, FCM לא מספקת כתובות IP ספציפיות כי טווח כתובות ה-IP שלנו משתנה בתדירות גבוהה מדי, וכללי חומת האש שלכם עלולים להיות לא עדכניים, מה שישפיע על חוויית המשתמש. מומלץ להוסיף לרשימת ההיתרים את היציאות 5228-5230 ו-443 ללא הגבלות IP. עם זאת, אם אתם חייבים להגביל את הגישה באמצעות כתובת IP, עליכם להוסיף לרשימת ההיתרים את כל כתובות ה-IP שמופיעות בקובץ goog.json. הרשימה הגדולה הזו מתעדכנת באופן קבוע, ומומלץ לעדכן את הכללים שלכם מדי חודש. בעיות שנגרמות בגלל הגבלות על כתובות IP בחומת אש הן לרוב לסירוגין וקשה לאבחן אותן.

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

יציאות TCP שצריך לפתוח:

• 5228
• 5229
• 5230
• 443

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

• mtalk.google.com
• mtalk4.google.com
• mtalk-staging.google.com
• mtalk-dev.google.com
• alt1-mtalk.google.com
• alt2-mtalk.google.com
• alt3-mtalk.google.com
• alt4-mtalk.google.com
• alt5-mtalk.google.com
• alt6-mtalk.google.com
• alt7-mtalk.google.com
• alt8-mtalk.google.com
• android.apis.google.com
• device-provisioning.googleapis.com
• firebaseinstallations.googleapis.com

חומות אש של תרגום כתובות רשת (NAT) או בדיקת חבילות עם שמירת מצב (SPI):

אם ברשת שלכם מיושם תרגום כתובות רשת (NAT) או בדיקת חבילות עם שמירת מצב (SPI), צריך להטמיע פסק זמן של 30 דקות או יותר לחיבורים שלנו דרך יציאות 5228-5230. כך אנחנו יכולים לספק קישוריות אמינה תוך צמצום צריכת הסוללה במכשירים הניידים של המשתמשים.

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

אינטראקציות עם VPN ואפשרות לעקוף אותו

‫Firebase Cloud Messaging מבצע פעולות שונות כדי לוודא שחיבור ההודעות בדחיפה מהטלפון לשרת יהיה אמין וזמין כמה שיותר. השימוש ב-VPN מסבך את המאמץ הזה.

רשתות VPN מסתירות את המידע הבסיסי ש-FCM צריך כדי להתאים את החיבור שלו ולמקסם את האמינות ואת חיי הסוללה. במקרים מסוימים, רשתות VPN מנתקות באופן פעיל חיבורים ארוכי טווח, מה שמוביל לחוויית משתמש גרועה בגלל הודעות שלא מתקבלות או מתקבלות באיחור, או בגלל צריכת סוללה גבוהה. אם ה-VPN מוגדר כך שמאפשר לנו לעשות זאת, אנחנו עוקפים את ה-VPN באמצעות חיבור מוצפן (דרך רשת הבסיס Wi-Fi או LTE) כדי להבטיח חוויה אמינה שלא מבזבזת את הסוללה. השימוש של FCM ב-VPN שאפשר לעקוף אותו ספציפי לערוץ ההתראות.FCM תנועה אחרת של FCM, כמו תנועת הרשמה, משתמשת ב-VPN אם הוא פעיל. כשחיבור FCM עוקף את ה-VPN, הוא מאבד יתרונות נוספים שה-VPN עשוי לספק, כמו הסתרת כתובת ה-IP.

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

אם ה-VPN לא מוגדר כך שאפשר לעקוף אותו, Firebase Cloud Messaging ישתמש ברשת ה-VPN כדי להתחבר לשרת. יכול להיות שיהיו תקופות שבהן ההודעות יתעכבו, וגם שהשימוש בסוללה יהיה גבוה יותר כי Cloud Messaging יפעל כדי לשמור על החיבור דרך חיבור ה-VPN.

פרטי כניסה

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

מזהה פרויקט	מזהה ייחודי של פרויקט Firebase, שמשמש בבקשות אל FCM נקודת הקצה v1 HTTP. הערך הזה זמין בחלונית הגדרות במסוף Firebase.
טוקן רישום	מחרוזת טוקן ייחודית שמזהה כל מופע של אפליקציית לקוח. טוקן הרישום נדרש לשליחת הודעות למכשיר יחיד ולקבוצת מכשירים. הערה: חשוב לשמור את טוקני הרישום בסודיות.
מזהה השולח	ערך מספרי ייחודי שנוצר כשיוצרים את פרויקט Firebase. הערך הזה זמין בחלונית הגדרות בכרטיסייה Cloud Messaging במסוף Firebase. מזהה השולח משמש לזיהוי כל שולח שיכול לשלוח הודעות לאפליקציית הלקוח.
טוקן גישה	אסימון לטווח קצר מסוג OAuth 2.0 שמאשר בקשות ל-HTTP v1 API. האסימון הזה משויך לחשבון שירות ששייך לפרויקט Firebase שלכם. כדי ליצור אסימוני גישה ולבצע רוטציה שלהם, פועלים לפי השלבים שמתוארים במאמר הרשאת שליחת בקשות.
מפתח שרת (לפרוטוקולים מדור קודם שהוצאו משימוש)	מפתח שרת שמאשר לשרת האפליקציות שלכם גישה לשירותי Google, כולל שליחת הודעות באמצעות פרוטוקולי Legacy שיצאו משימוש Firebase Cloud Messaging. חשוב: אל תכללו את מפתח השרת בשום מקום בקוד הלקוח. בנוסף, חשוב להשתמש רק במפתחות שרת כדי לאשר את שרת האפליקציות שלכם. מפתחות של Android, של פלטפורמת Apple ושל דפדפנים נדחים על ידי FCM.