Catch up on highlights from Firebase at Google I/O 2023. Learn more

דף זה תורגם על ידי Cloud Translation API.

לגבי הודעות FCM

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

סוגי הודעות

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

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

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

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

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

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

הודעות התראה

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

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

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

הצפנה עבור הודעות נתונים

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

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

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

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

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

הנה הודעה בפורמט 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 v1 FCM מאפשרים לבקשות ההודעה שלך להגדיר את כל השדות הזמינים באובייקט message . זה כולל:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הודעות בלתי מתקפלות ומתקפלות

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

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

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

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

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

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

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

באיזה עליי להשתמש?

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

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

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

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

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

בעת שליחת הודעות נתונים למכשירי Apple, העדיפות חייבת להיות מוגדרת ל-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"
      }
    }
  }
}

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

קביעת תוחלת החיים של הודעה

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

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

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

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

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

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

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

מצערת ושינוי קנה מידה

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

מניעת הודעה מתקפלת

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

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

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

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

מצערת שרת XMPP

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

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

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

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

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

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

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

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

לשיעורי שליחת הודעות, ראה Fanout Throttling .

מצערת מנאוט

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

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

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

חומות אש של תרגום כתובות רשת ו/או בדיקת מנות מדינה:

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

אישורים

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

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