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

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

סוגי הודעות

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

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

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

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

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

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

הודעות התראה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ברקע, אפליקציות מקבלות את המטען הייעודי (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

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

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

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

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

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

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

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

• מגדירה אורך חיים ממושך לפלטפורמות Android ואינטרנט, וקביעת עדיפות של הודעות APN (בפלטפורמות של 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, ומאפשר אפשרויות דומות בפלטפורמות של Apple ובאינטרנט. לדוגמה, התנהגות של הודעות 'ניתנות לכווץ' נתמכת ב-Android באמצעות collapse_key של FCM, ב-Apple באמצעות apns-collapse-id וב-JavaScript/Web באמצעות Topic. למידע נוסף, תוכלו לקרוא את התיאורים בקטע הזה ואת מאמרי העזרה הרלוונטיים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זוהי דוגמה להודעה בעדיפות רגילה שנשלחה באמצעות פרוטוקול 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"
      }
    }
  }
}

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

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

תרחישים קריטיים לחיים

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

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

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

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

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

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

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

יתרון נוסף של ציון משך החיים של הודעה הוא ש-FCM לא מחילה ויסות הודעות ניתנות לכיווץ על הודעות שערך אורך החיים שלהן הוא 0 שניות. 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 עדיין תקבל את ההודעה אבל תמחק אותה מיד. אם המכשיר מתחבר תוך ארבעה שבועות מהודעת הנתונים האחרונה ששלחת אליו, הלקוח שלך יקבל את הקריאה החוזרת של ondeleteMessages(). כך האפליקציה יכולה לטפל בבעיה בצורה נכונה, בדרך כלל על ידי בקשה לסנכרון מלא משרת האפליקציות.

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

ויסות נתונים (throttle) ומכסות

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

ויסות הודעות במורד הזרם (downstream)

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

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

חשוב לזכור:

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

מעקב אחרי המכסות

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

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

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

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

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

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

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

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

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

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

שיעור ההוספה/הסרה של מינויים לנושאים מוגבל ל-3,000 QPS לכל פרויקט.

לקבלת מידע על שיעורי שליחת הודעות, ראו הגבלת קצב העברת הודעות.

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

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

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

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

הגבלת התקשורת של הודעות שניתן לכיווץ

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

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

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

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

הגבלת רוחב הפס של שרת XMPP

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

להעברת הודעות upstream באמצעות XMPP, FCM מגביל את הודעות ה-upstream ל-1,500,000 לדקה בכל פרויקט, כדי למנוע עומס יתר על שרתי היעד ב-upstream.

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

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

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

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

יציאות 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

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

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

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

Firebase Cloud Messaging נוקט אמצעים שונים כדי להבטיח שחיבור ה-push בין הטלפון לשרת הוא אמין וזמין בתדירות גבוהה ככל האפשר. השימוש ב-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. המזהה הזה משמש בבקשות לנקודת הקצה v1 של HTTP מסוג FCM. הערך הזה זמין בחלונית Settings במסוף Firebase.
אסימון רישום	מחרוזת אסימון ייחודית שמזהה כל מופע של אפליקציית לקוח. אסימון הרישום נדרש כדי לשלוח הודעות ברמה של מכשיר יחיד ושל קבוצה {/1} חשוב לזכור שאסור לחשוף את אסימוני הרישום.
מזהה השולח	ערך מספרי ייחודי שנוצר כשיוצרים את פרויקט Firebase. הערך זמין בכרטיסייה Cloud Messaging בחלונית Settings במסוף Firebase. מזהה השולח משמש לזיהוי כל שולח שיכול לשלוח הודעות לאפליקציית הלקוח.
אסימון גישה	אסימון OAuth 2.0 לטווח קצר שמאשר בקשות ל-API של HTTP v1. האסימון הזה משויך לחשבון שירות ששייך לפרויקט שלכם ב-Firebase. כדי ליצור אסימוני גישה ולבצע רוטציה שלהם, פועלים לפי השלבים שמפורטים בקטע אימות בקשות שליחה.
מפתח שרת (לפרוטוקולים מדור קודם **הוצא משימוש**)	מפתח שרת שמעניק הרשאה לשרת האפליקציה לגשת לשירותי Google, כולל שליחת הודעות באמצעות הפרוטוקולים הקודמים של Firebase Cloud Messaging שכבר הוצאו משימוש. חשוב: אל תכללו את מפתח השרת בשום מקום בקוד הלקוח. בנוסף, חשוב להשתמש רק במפתחות שרת כדי לאשר את שרת האפליקציה. מפתחות של Android, פלטפורמת Apple ומפתחות דפדפן נדחים על ידי FCM.