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

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

סוגי הודעות

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

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

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

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

  1. בסביבה מהימנה, כמו Cloud Functions או שרת האפליקציות, משתמשים ב-Admin SDK או ב-HTTP v1 API. מגדירים את המקש notification. יכול להיות מטען ייעודי (payload) אופציונלי של נתונים. תמיד לכווץ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בקשת השליחה של גרסה 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/אינטרנט באמצעות Topic. למידע נוסף, קראו את התיאורים בקטע הזה וחומרי עזר קשורים.

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

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

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

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

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

{
  "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"
      }
    }
  }
}

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

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

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

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

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

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

ויסות נתונים וקנה מידה

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

ויסות הודעות מתכווץ

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

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

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

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

ויסות נתונים (throttle) של שרת XMPP

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

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

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

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

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

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

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

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

למידע על קצב שליחת הודעות, ראו ויסות נתונים (Fanout).

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

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

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

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

יציאות 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), עליכם להגדיר זמן קצוב לתפוגה של 30 דקות או יותר עבור החיבורים שלנו ביציאות 5228-5230. כך אנחנו יכולים לספק קישוריות מהימנה ובמקביל לצמצם את צריכת הסוללה במכשירים הניידים של המשתמשים.

אינטראקציות ויכולת עקיפה של VPN

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

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

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

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

פרטי כניסה

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

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

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

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

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