درباره پیام های FCM

Firebase Cloud Messaging (FCM) طیف گسترده ای از گزینه ها و قابلیت های پیام رسانی را ارائه می دهد. اطلاعات موجود در این صفحه به شما کمک می کند تا انواع مختلف پیام های FCM و کارهایی که می توانید با آنها انجام دهید را درک کنید.

انواع پیام

با FCM، می توانید دو نوع پیام به مشتریان ارسال کنید:

  • پیام های اعلان، که گاهی اوقات به عنوان "پیام های نمایش داده شده" در نظر گرفته می شود. اینها توسط FCM SDK به طور خودکار مدیریت می شوند.
  • پیام های داده، که توسط برنامه مشتری مدیریت می شود.

پیام های اعلان شامل مجموعه ای از کلیدهای از پیش تعریف شده قابل مشاهده توسط کاربر است. در مقابل، پیام‌های داده فقط شامل جفت‌های کلید-مقدار سفارشی تعریف‌شده توسط کاربر هستند. پیام‌های اعلان می‌توانند حاوی یک بار داده اختیاری باشند. حداکثر بار برای هر دو نوع پیام 4000 بایت است، به جز زمانی که پیام‌ها از کنسول Firebase ارسال می‌شود که محدودیت 1024 کاراکتری را اعمال می‌کند.

از سناریو استفاده کنید نحوه ارسال
پیام اعلان FCM به‌طور خودکار پیام را از طرف برنامه مشتری به دستگاه‌های کاربر نهایی نمایش می‌دهد. پیام‌های اعلان دارای مجموعه‌ای از کلیدهای قابل مشاهده برای کاربر از پیش تعریف‌شده و یک بار داده اختیاری از جفت‌های کلید-مقدار سفارشی هستند.
  1. در یک محیط مطمئن مانند توابع ابری یا سرور برنامه‌تان، از Admin SDK یا پروتکل‌های سرور FCM استفاده کنید: کلید notification را تنظیم کنید. ممکن است بار داده اختیاری داشته باشد. همیشه تاشو

    نمونه هایی از اعلان های نمایش و ارسال بارهای درخواستی را مشاهده کنید.

  2. از آهنگساز اعلان ها استفاده کنید: متن پیام، عنوان و غیره را وارد کرده و ارسال کنید. با ارائه داده های سفارشی، بار داده اختیاری را اضافه کنید.
پیام داده برنامه مشتری مسئول پردازش پیام های داده است. پیام های داده فقط دارای جفت های کلید-مقدار سفارشی بدون نام کلید رزرو شده هستند (به زیر مراجعه کنید). در یک محیط مطمئن مانند توابع Cloud یا سرور برنامه خود، از Admin SDK یا پروتکل‌های سرور FCM استفاده کنید: فقط کلید data را تنظیم کنید.

هنگامی که می خواهید FCM نمایش اعلان را از طرف برنامه مشتری شما انجام دهد، از پیام های اعلان استفاده کنید. زمانی که می‌خواهید پیام‌ها را در برنامه مشتری خود پردازش کنید، از پیام‌های داده استفاده کنید.

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

هنگامی که برنامه در پس‌زمینه است، پیام‌های اعلان به سینی اعلان تحویل داده می‌شوند. برای برنامه‌هایی که در پیش‌زمینه قرار دارند، پیام‌ها توسط یک عملکرد پاسخ به تماس مدیریت می‌شوند.

برای فهرست کامل کلیدهای از پیش تعریف شده موجود برای پیام های اعلان ساختمان، به مستندات مرجع مراجعه کنید:

پیام های داده

کلید مناسب را با جفت های کلید-مقدار سفارشی خود تنظیم کنید تا یک بار داده به برنامه مشتری ارسال شود.

به عنوان مثال، در اینجا یک پیام با فرمت JSON در همان برنامه IM مانند بالا وجود دارد، که در آن اطلاعات در کلید data مشترک کپسوله می شود و انتظار می رود برنامه مشتری محتوا را تفسیر کند:

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

مثال بالا استفاده از فیلد data سطح بالا یا رایج را نشان می دهد که توسط کلاینت ها در تمام پلتفرم هایی که پیام را دریافت می کنند تفسیر می شود. در هر پلتفرم، برنامه سرویس گیرنده بار داده را در یک تابع تماس دریافت می کند.

رمزگذاری برای پیام های داده

لایه انتقال Android (به معماری FCM مراجعه کنید) از رمزگذاری نقطه به نقطه استفاده می کند. بسته به نیاز خود، ممکن است تصمیم بگیرید که رمزگذاری سرتاسری را به پیام های داده اضافه کنید. FCM راه حل سرتاسری ارائه نمی دهد. با این حال، راه حل های خارجی مانند مویرگی یا DTLS وجود دارد.

پیام‌های اعلان با بار داده اختیاری

هم به صورت برنامه نویسی و هم از طریق کنسول Firebase، می توانید پیام های اعلان ارسال کنید که حاوی یک بار اختیاری از جفت های کلید-مقدار سفارشی است. در آهنگساز Notifications ، از فیلدهای داده سفارشی در گزینه های پیشرفته استفاده کنید.

رفتار برنامه در هنگام دریافت پیام‌هایی که شامل اعلان‌ها و بارهای داده می‌شوند به این بستگی دارد که آیا برنامه در پس‌زمینه یا پیش‌زمینه باشد – اساساً فعال بودن یا نبودن آن در زمان دریافت.

  • در پس‌زمینه ، برنامه‌ها بار اعلان را در سینی اعلان دریافت می‌کنند و تنها زمانی که کاربر روی اعلان ضربه می‌زند، محموله داده را مدیریت می‌کنند.
  • وقتی برنامه شما در پیش زمینه است، یک شیء پیام با هر دو بار در دسترس دریافت می کند.

در اینجا یک پیام با فرمت JSON حاوی کلید notification و کلید data :

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

سفارشی کردن پیام در پلتفرم ها

Firebase Admin SDK و پروتکل FCM v1 HTTP هر دو به درخواست های پیام شما اجازه می دهند تمام فیلدهای موجود در شی message را تنظیم کنند. این شامل:

  • مجموعه مشترکی از فیلدها که باید توسط تمام نمونه های برنامه ای که پیام را دریافت می کنند تفسیر شوند.
  • مجموعه‌هایی از فیلدهای مخصوص پلتفرم، مانند AndroidConfig و WebpushConfig ، که فقط توسط نمونه‌های برنامه اجرا شده در پلتفرم مشخص شده تفسیر می‌شوند.

بلوک‌های مخصوص پلتفرم به شما انعطاف‌پذیری می‌دهند تا پیام‌ها را برای پلتفرم‌های مختلف سفارشی کنید تا اطمینان حاصل کنید که هنگام دریافت به‌درستی با آنها برخورد می‌شود. باطن FCM تمام پارامترهای مشخص شده را در نظر می گیرد و پیام را برای هر پلتفرم سفارشی می کند.

زمان استفاده از فیلدهای مشترک

وقتی هستید از فیلدهای مشترک استفاده کنید:

  • هدف قرار دادن نمونه های برنامه در همه پلتفرم ها - اپل، اندروید و وب
  • ارسال پیام به موضوعات

همه نمونه های برنامه، صرف نظر از پلتفرم، می توانند فیلدهای مشترک زیر را تفسیر کنند:

زمان استفاده از فیلدهای مخصوص پلتفرم

زمانی که می خواهید از فیلدهای مخصوص پلتفرم استفاده کنید:

  • فیلدها را فقط به پلتفرم های خاص ارسال کنید
  • علاوه بر فیلدهای مشترک، فیلدهای مخصوص پلتفرم را ارسال کنید

هر زمان که می‌خواهید مقادیر را فقط به پلتفرم‌های خاصی ارسال کنید، از فیلدهای مشترک استفاده نکنید . از فیلدهای مخصوص پلتفرم استفاده کنید. به عنوان مثال، برای ارسال یک نوتیفیکیشن فقط به پلتفرم‌های اپل و وب اما نه برای اندروید، باید از دو مجموعه فیلد جداگانه، یکی برای اپل و دیگری برای وب استفاده کنید.

هنگامی که پیام هایی با گزینه های تحویل خاص ارسال می کنید، از فیلدهای مخصوص پلتفرم برای تنظیم آنها استفاده کنید. در صورت تمایل می توانید مقادیر مختلفی را برای هر پلتفرم مشخص کنید. با این حال، حتی زمانی که می‌خواهید اساساً مقدار یکسانی را در بین پلتفرم‌ها تنظیم کنید، باید از فیلدهای مخصوص پلتفرم استفاده کنید. این به این دلیل است که هر پلتفرم ممکن است مقدار را کمی متفاوت تفسیر کند - برای مثال، زمان برای زندگی در Android به عنوان زمان انقضا بر حسب ثانیه تنظیم می شود، در حالی که در اپل به عنوان تاریخ انقضا تنظیم می شود.

مثال: پیام اعلان با گزینه های تحویل پلت فرم خاص

درخواست ارسال v1 زیر یک عنوان اعلان و محتوای مشترک را به همه پلتفرم‌ها ارسال می‌کند، اما برخی موارد لغو خاص پلتفرم را نیز ارسال می‌کند. به طور خاص، درخواست:

  • مدت زمان طولانی را برای پلتفرم‌های اندروید و وب تعیین می‌کند، در حالی که اولویت پیام APN (پلتفرم‌های اپل) را روی تنظیمات کم تنظیم می‌کند.
  • کلیدهای مناسب را برای تعیین نتیجه ضربه زدن کاربر بر روی اعلان در اندروید و اپل تنظیم می کند — به 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 از طریق collapse_key FCM، در Apple از طریق apns-collapse-id و در JavaScript/Web از طریق Topic پشتیبانی می‌شود. برای جزئیات، به توضیحات در این بخش و مستندات مرجع مرتبط مراجعه کنید.

پیام های تاشو و غیر قابل جمع شدن

یک پیام غیرقابل جمع شدن نشان می دهد که هر پیام جداگانه به دستگاه تحویل داده می شود. یک پیام غیرقابل جمع کردن، محتوای مفیدی را ارائه می‌کند، برخلاف پیام‌های جمع‌شدنی مانند «پینگ» بدون محتوا به برنامه تلفن همراه برای تماس با سرور برای واکشی داده‌ها.

برخی از موارد استفاده معمول از پیام‌های غیرقابل جمع شدن، پیام‌های چت یا پیام‌های مهم هستند. به عنوان مثال، در یک برنامه IM، می خواهید هر پیامی را تحویل دهید، زیرا هر پیام دارای محتوای متفاوتی است.

برای اندروید محدودیت 100 پیام وجود دارد که می توان آنها را بدون جمع کردن ذخیره کرد. در صورت رسیدن به حد مجاز، همه پیام های ذخیره شده حذف می شوند. هنگامی که دستگاه دوباره آنلاین می شود، یک پیام ویژه دریافت می کند که نشان می دهد به محدودیت رسیده است. سپس برنامه می‌تواند وضعیت را به درستی مدیریت کند، معمولاً با درخواست همگام‌سازی کامل از سرور برنامه.

پیام تاشو پیامی است که اگر هنوز به دستگاه ارسال نشده باشد، ممکن است با یک پیام جدید جایگزین شود.

موارد استفاده رایج از پیام‌های جمع‌شونده، پیام‌هایی هستند که به برنامه تلفن همراه می‌گویند داده‌های سرور را همگام‌سازی کند. یک مثال می تواند یک برنامه ورزشی باشد که کاربران را با آخرین امتیاز به روز می کند. فقط جدیدترین پیام مرتبط است.

برای علامت‌گذاری پیام به‌عنوان قابل جمع‌شدگی در Android، پارامتر collapse_key را در بار پیام اضافه کنید. به طور پیش‌فرض، کلید collapse نام بسته برنامه ثبت شده در کنسول Firebase است. سرور FCM می تواند به طور همزمان چهار پیام جمع شونده مختلف را در هر دستگاه ذخیره کند که هر کدام دارای یک کلید جمع کردن متفاوت است. اگر از این تعداد تجاوز کنید، FCM فقط چهار کلید جمع شدنی را نگه می‌دارد، بدون اینکه تضمینی در مورد نگه داشتن آنها وجود داشته باشد.

پیام‌های موضوعی بدون محموله به‌طور پیش‌فرض قابل جمع‌شوندگی هستند. پیام های اعلان همیشه قابل جمع شدن هستند و پارامتر collapse_key را نادیده می گیرند.

از کدوم استفاده کنم؟

پیام های جمع شونده از نقطه نظر عملکرد انتخاب بهتری هستند، مشروط بر اینکه برنامه شما نیازی به استفاده از پیام های غیرقابل جمع شدن نداشته باشد. با این حال، اگر از پیام‌های جمع‌شونده استفاده می‌کنید، به یاد داشته باشید که FCM تنها اجازه می‌دهد تا حداکثر چهار کلید جمع‌کردن مختلف توسط FCM در هر کد ثبت‌نام در هر زمان معین استفاده شود. شما نباید از این تعداد تجاوز کنید، در غیر این صورت ممکن است عواقب غیر قابل پیش بینی ایجاد کند.

از سناریو استفاده کنید نحوه ارسال
غیر قابل جمع شدن هر پیامی برای برنامه مشتری مهم است و باید تحویل داده شود. به جز پیام های اعلان، همه پیام ها به طور پیش فرض غیرقابل جمع شدن هستند.
تاشو وقتی پیام جدیدتری وجود دارد که پیام قدیمی‌تر و مرتبط‌تر را بی‌ربط به برنامه مشتری نشان می‌دهد، FCM جایگزین پیام قدیمی‌تر می‌شود. برای مثال: پیام‌هایی که برای شروع همگام‌سازی داده‌ها از سرور استفاده می‌شوند یا پیام‌های اعلان قدیمی. پارامتر مناسب را در درخواست پیام خود تنظیم کنید:
  • collapseKey در اندروید
  • apns-collapse-id در اپل
  • Topic در وب
  • collapse_key در پروتکل های قدیمی (همه پلتفرم ها)

تنظیم اولویت یک پیام

شما دو گزینه برای اختصاص دادن اولویت تحویل به پیام های پایین دستی دارید: عادی و اولویت بالا. اگرچه این رفتار در پلتفرم‌ها کمی متفاوت است، تحویل پیام‌های عادی و با اولویت بالا به این صورت عمل می‌کند:

  • اولویت عادی پیام های اولویت عادی بلافاصله زمانی که برنامه در پیش زمینه است، تحویل داده می شود. برای برنامه‌های پس‌زمینه، ممکن است تحویل به تأخیر بیفتد. برای پیام‌هایی که کمتر به زمان حساس هستند، مانند اعلان‌های ایمیل جدید، همگام نگه داشتن رابط کاربری یا همگام‌سازی داده‌های برنامه در پس‌زمینه، اولویت تحویل عادی را انتخاب کنید.

  • اولویت بالا. FCM سعی می‌کند پیام‌های با اولویت بالا را فوراً ارسال کند، حتی اگر دستگاه در حالت Doze باشد. پیام های با اولویت بالا برای محتوای حساس به زمان و قابل مشاهده توسط کاربر هستند.

در اینجا نمونه ای از یک پیام اولویت معمولی است که از طریق پروتکل 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 پیام را ذخیره می‌کند و به محض اینکه امکان پذیر شد، آن را تحویل می‌دهد. در حالی که این در اکثر موارد خوب است، برخی از برنامه‌ها هستند که ممکن است هرگز پیام دیرهنگام برای آنها ارسال نشود. به عنوان مثال، اگر پیام یک تماس ورودی یا اعلان چت تصویری باشد، فقط برای مدت کوتاهی قبل از پایان تماس معنادار است. یا اگر پیام دعوت به یک رویداد باشد، اگر پس از پایان رویداد دریافت شود، بی فایده است.

در اندروید و وب/جاوا اسکریپت، می توانید حداکثر طول عمر یک پیام را مشخص کنید. مدت زمان باید از 0 تا 2419200 ثانیه (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 به چندین طرف اجازه می دهد تا به یک برنامه مشتری پیام ارسال کنند. به عنوان مثال، فرض کنید برنامه مشتری یک جمع‌آورنده مقاله با مشارکت‌کننده‌های متعدد است و هر یک از آنها باید هنگام انتشار یک مقاله جدید بتوانند پیامی ارسال کنند. این پیام ممکن است حاوی یک URL باشد تا برنامه مشتری بتواند مقاله را دانلود کند. FCM به‌جای متمرکز کردن تمام فعالیت‌های ارسال در یک مکان، این امکان را به شما می‌دهد که به هر یک از این مشارکت‌کنندگان اجازه دهید پیام‌های خود را ارسال کنند.

برای فعال کردن این ویژگی، مطمئن شوید که شناسه فرستنده هر فرستنده را دارید. هنگام درخواست ثبت نام، برنامه مشتری چندین بار رمز را واکشی می کند، هر بار با شناسه فرستنده متفاوت در قسمت مخاطب، با استفاده از روش بازیابی رمز برای پلتفرم داده شده:

اطمینان حاصل کنید که چندین شناسه فرستنده را به یک درخواست توکن اضافه نکنید ، زیرا می تواند نتایج غیر قابل پیش بینی داشته باشد. هر تماس را جداگانه، یک بار برای هر شناسه فرستنده برقرار کنید.

در نهایت، رمز ثبت نام را با فرستندگان مربوطه به اشتراک بگذارید، و آنها می توانند با استفاده از کلیدهای احراز هویت خود پیام هایی را به برنامه مشتری ارسال کنند.

توجه داشته باشید که محدودیت 100 فرستنده چندگانه وجود دارد.

طول عمر یک پیام

وقتی یک سرور برنامه پیامی را به FCM ارسال می کند و شناسه پیام را پس می گیرد، به این معنی نیست که پیام قبلاً به دستگاه تحویل داده شده است. بلکه به این معناست که برای تحویل پذیرفته شده است. اینکه پیام بعد از پذیرش چه اتفاقی می افتد به عوامل زیادی بستگی دارد.

در بهترین حالت، اگر دستگاه به FCM متصل باشد، صفحه نمایش روشن باشد و هیچ محدودیتی برای دریچه گاز وجود نداشته باشد، پیام بلافاصله ارسال می شود.

اگر دستگاه متصل باشد اما در Doze باشد، یک پیام با اولویت پایین توسط FCM ذخیره می شود تا زمانی که دستگاه از Doze خارج شود. و اینجاست که پرچم collapse_key نقش بازی می‌کند: اگر قبلاً پیامی با همان کلید کوچک کردن (و رمز ثبت نام) ذخیره شده باشد و منتظر تحویل باشد، پیام قدیمی کنار گذاشته می‌شود و پیام جدید جای آن را می‌گیرد (یعنی پیام قدیمی). پیام توسط پیام جدید جمع می شود). با این حال، اگر کلید کوچک کردن تنظیم نشده باشد، هر دو پیام جدید و قدیمی برای تحویل آینده ذخیره می شوند.

اگر دستگاه به FCM متصل نباشد، پیام تا زمانی که یک اتصال برقرار شود ذخیره می‌شود (دوباره با رعایت قوانین کوچک کردن کلید). هنگامی که یک اتصال برقرار می شود، FCM همه پیام های معلق را به دستگاه تحویل می دهد. اگر دستگاه دیگر هرگز وصل نشود (مثلاً اگر به تنظیمات کارخانه بازنشانی شده باشد)، پیام در نهایت تمام می شود و از حافظه FCM حذف می شود. مهلت زمانی پیش‌فرض چهار هفته است، مگر اینکه پرچم time_to_live تنظیم شده باشد.

برای دریافت بینش بیشتر در مورد تحویل یک پیام:

    برای دریافت اطلاعات بیشتر در مورد تحویل پیام‌ها در پلتفرم‌های Android یا Apple، به داشبورد گزارش FCM مراجعه کنید، که تعداد پیام‌های ارسال‌شده و باز شده در دستگاه‌های Apple و Android را به همراه داده‌های «impressions» (اعلان‌هایی که کاربران مشاهده می‌کنند) را ثبت می‌کند. برنامه های اندروید

برای دستگاه‌های Android با پیام‌رسانی مستقیم کانال فعال، اگر دستگاه بیش از یک ماه به FCM متصل نشده باشد، FCM همچنان پیام را می‌پذیرد اما فوراً آن را نادیده می‌گیرد. اگر دستگاه ظرف چهار هفته پس از آخرین پیام داده ای که به آن ارسال کرده اید متصل شود، کلاینت شما پاسخ تماس ()onDeletedMessages را دریافت می کند. سپس برنامه می‌تواند وضعیت را به درستی مدیریت کند، معمولاً با درخواست همگام‌سازی کامل از سرور برنامه.

در نهایت، زمانی که FCM تلاش می‌کند پیامی را به دستگاه ارسال کند و برنامه حذف شد، FCM فوراً آن پیام را کنار گذاشته و رمز ثبت نام را باطل می‌کند. تلاش‌های بعدی برای ارسال پیام به آن دستگاه منجر به خطای NotRegistered .

دریچه گیری و پوسته پوسته شدن

هدف ما این است که همیشه هر پیامی را که از طریق FCM ارسال می شود، ارائه دهیم. با این حال، ارائه هر پیام گاهی اوقات منجر به تجربه کلی ضعیف کاربر می شود. در موارد دیگر، ما باید مرزهایی را برای اطمینان از اینکه FCM یک سرویس مقیاس پذیر برای همه فرستنده ها ارائه می دهد، ارائه کنیم.

خفه کردن پیام تاشو

همانطور که در بالا توضیح داده شد، پیام‌های جمع‌شونده اعلان‌هایی بدون محتوا هستند که برای جمع شدن روی هم طراحی شده‌اند. در صورتی که یک برنامه‌نویس به طور مکرر همان پیام را برای یک برنامه تکرار کند، پیام‌ها را به تأخیر می‌اندازیم تا تأثیر آن بر باتری کاربر کاهش یابد.

برای مثال، اگر تعداد زیادی درخواست همگام‌سازی ایمیل جدید را به یک دستگاه ارسال کنید، ممکن است درخواست همگام‌سازی ایمیل بعدی را چند دقیقه به تأخیر بیندازیم تا دستگاه بتواند با سرعت متوسط ​​پایین‌تری همگام‌سازی شود. این دریچه گاز به شدت برای محدود کردن تاثیر باتری تجربه شده توسط کاربر انجام می شود.

اگر مورد استفاده شما نیاز به الگوهای ارسال سریع دارد، پیام های غیرقابل جمع شدن ممکن است انتخاب مناسبی باشند. برای چنین پیام‌هایی، حتماً محتوا را در چنین پیام‌هایی قرار دهید تا هزینه باتری کاهش یابد.

ما پیام‌های جمع‌شونده را به 20 پیام در هر برنامه در هر دستگاه محدود می‌کنیم و هر 3 دقیقه یک پیام را دوباره پر می‌کنیم.

خفه کردن سرور XMPP

ما نرخ اتصال شما به سرورهای FCM XMPP را به 400 اتصال در دقیقه در هر پروژه محدود می کنیم. این نباید برای تحویل پیام مشکلی ایجاد کند، اما برای اطمینان از ثبات سیستم ما مهم است.

برای هر پروژه، FCM اجازه 2500 اتصال را به صورت موازی می دهد.

حداکثر نرخ پیام به یک دستگاه

شما می توانید حداکثر 240 پیام در دقیقه و 5000 پیام در ساعت را به یک دستگاه ارسال کنید. این آستانه بالا به این منظور است که اجازه می دهد تا ترافیک کوتاه مدت، مانند زمانی که کاربران در حال تعامل سریع از طریق چت هستند، باشد. این محدودیت از تخلیه ناخواسته باتری روی دستگاه خطا در ارسال منطق جلوگیری می کند.

محدودیت پیام بالادستی

ما پیام‌های بالادستی را در 1500000 در دقیقه در هر پروژه محدود می‌کنیم تا از بارگذاری بیش از حد سرورهای مقصد بالادست جلوگیری کنیم.

ما پیام‌های بالادستی را در هر دستگاه در 1000 در دقیقه محدود می‌کنیم تا در برابر تخلیه باتری در اثر رفتار بد برنامه محافظت کنیم.

محدودیت پیام موضوع

نرخ اضافه/حذف اشتراک موضوع به 3000 QPS در هر پروژه محدود شده است.

برای نرخ‌های ارسال پیام، به Fanout Throttling مراجعه کنید.

دریچه گاز هوا

پیام Fanout فرآیند ارسال پیام به چندین دستگاه است، مانند زمانی که موضوعات و گروه‌ها را هدف قرار می‌دهید، یا زمانی که از سازنده Notifications برای هدف قرار دادن مخاطبان یا بخش‌های کاربر استفاده می‌کنید.

پیام fanout آنی نیست و بنابراین گاهی اوقات شما چندین fanout به طور همزمان در حال انجام است. ما تعداد پیام‌های ارسال پیام همزمان در هر پروژه را به 1000 محدود می‌کنیم. پس از آن، ممکن است درخواست‌های fanout اضافی را رد کنیم یا fanout درخواست‌ها را تا زمانی که برخی از Fanout‌های در حال انجام تکمیل شده اند به تعویق بیاندازیم.

نرخ واقعی fanout قابل دستیابی تحت تأثیر تعداد پروژه هایی است که همزمان درخواست fanout می کنند. نرخ fanout 10000 QPS برای یک پروژه غیر معمول نیست، اما این عدد تضمینی نیست و نتیجه کل بار روی سیستم است. توجه به این نکته مهم است که ظرفیت fanout موجود بین پروژه‌ها تقسیم می‌شود و نه بین درخواست‌های fanout. بنابراین، اگر پروژه شما دارای دو fanout در حال انجام باشد، هر fanout فقط نیمی از نرخ 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

فایروال‌های ترجمه آدرس شبکه و/یا بازرسی بسته دولتی:

اگر شبکه شما ترجمه آدرس شبکه (NAT) یا بازرسی بسته دولتی (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 را می‌دهد. وقتی پروژه Firebase خود را ایجاد می کنید، کلید سرور را به دست می آورید. می توانید آن را در برگه Cloud Messaging در صفحه تنظیمات کنسول Firebase مشاهده کنید.

مهم: کلید سرور را در هیچ کجای کد مشتری خود وارد نکنید. همچنین، مطمئن شوید که فقط از کلیدهای سرور برای مجوز دادن به سرور برنامه خود استفاده می کنید. کلیدهای اندروید، پلتفرم اپل و مرورگر توسط FCM رد می شوند.