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

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

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

סוגי הודעות

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

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

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

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

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

הודעות התראה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הגבלת רוחב הפס של הודעות במורד הזרם

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

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

חשוב לזכור:

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

מכסת ניטור

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הגבלת התקשורת של הודעות שכווצו

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

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

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

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

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

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