حول رسائل FCM

تقدم Firebase Cloud Messaging (FCM) مجموعة واسعة من خيارات وإمكانيات المراسلة. تهدف المعلومات الواردة في هذه الصفحة إلى مساعدتك في فهم الأنواع المختلفة لرسائل FCM وما يمكنك فعله بها.

أنواع الرسائل

باستخدام FCM ، يمكنك إرسال نوعين من الرسائل إلى العملاء:

• رسائل الإعلام ، يُعتقد أحيانًا أنها "رسائل عرض". يتم التعامل مع هذه بواسطة FCM SDK تلقائيًا.
• رسائل البيانات التي يتعامل معها تطبيق العميل.

تحتوي رسائل الإعلام على مجموعة محددة مسبقًا من المفاتيح المرئية للمستخدم. على النقيض من ذلك ، تحتوي رسائل البيانات فقط على أزواج قيمة المفتاح المخصصة المعرفة من قبل المستخدم. يمكن أن تحتوي رسائل الإعلام على حمولة بيانات اختيارية. الحد الأقصى للحمولة لكلا نوعي الرسائل هو 4000 بايت ، باستثناء عند إرسال رسائل من وحدة تحكم Firebase ، والتي تفرض حدًا يبلغ 1024 حرفًا.

	استخدام السيناريو	كيف ترسل
رسالة إعلام	تعرض FCM SDK الرسالة إلى أجهزة المستخدم النهائي نيابة عن تطبيق العميل عندما يتم تشغيله في الخلفية. بخلاف ذلك ، إذا كان التطبيق قيد التشغيل في المقدمة عند تلقي الإشعار ، فإن كود التطبيق يحدد السلوك. تحتوي رسائل الإعلام على مجموعة محددة مسبقًا من المفاتيح المرئية للمستخدم وحمولة بيانات اختيارية لأزواج مخصصة من المفاتيح والقيمة.	في بيئة موثوقة مثل وظائف السحابة أو خادم التطبيق الخاص بك ، استخدم Admin SDK أو بروتوكولات خادم FCM : اضبط مفتاح notification . قد تحتوي على حمولة بيانات اختيارية. دائما قابلة للطي. اطلع على بعض الأمثلة على إشعارات العرض وإرسال حمولات الطلب. استخدم منشئ الإشعارات : أدخل نص الرسالة والعنوان وما إلى ذلك ، وأرسلها. أضف حمولة بيانات اختيارية من خلال توفير بيانات مخصصة.
رسالة البيانات	تطبيق العميل مسؤول عن معالجة رسائل البيانات. تحتوي رسائل البيانات على أزواج مخصصة فقط من المفاتيح والقيمة بدون أسماء مفاتيح محجوزة (انظر أدناه).	في بيئة موثوقة مثل وظائف السحابة أو خادم التطبيق الخاص بك ، استخدم Admin SDK أو بروتوكولات خادم FCM : اضبط مفتاح data فقط.

استخدم رسائل الإشعارات عندما تريد أن تتعامل 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
• حمولة إشعار بروتوكول HTTP القديم
• حمولة إعلام بروتوكول XMPP

رسائل البيانات

قم بتعيين المفتاح المناسب مع أزواج قيمة المفتاح المخصصة لإرسال حمولة بيانات إلى تطبيق العميل.

تأكد من عدم استخدام أي كلمات محجوزة في أزواج قيمة المفتاح المخصصة. تتضمن الكلمات المحجوزة "من" أو "إشعار" أو "نوع_رسالة" أو أي كلمة تبدأ بـ "google" أو "gcm".

على سبيل المثال ، إليك رسالة بتنسيق JSON في نفس تطبيق المراسلة الفورية على النحو الوارد أعلاه ، حيث يتم تغليف المعلومات في مفتاح data المشترك ومن المتوقع أن يقوم تطبيق العميل بتفسير المحتوى:

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

يوضح المثال أعلاه استخدام حقل data ذي المستوى الأعلى أو المشترك ، والذي يتم تفسيره بواسطة العملاء على جميع الأنظمة الأساسية التي تتلقى الرسالة. في كل نظام أساسي ، يتلقى تطبيق العميل حمولة البيانات في وظيفة رد الاتصال.

تشفير رسائل البيانات

تستخدم طبقة نقل 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 وبروتوكول FCM v1 HTTP لطلبات الرسائل الخاصة بك بتعيين جميع الحقول المتاحة في كائن 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 . للحصول على التفاصيل ، راجع الأوصاف في هذا القسم والوثائق المرجعية ذات الصلة.

الرسائل غير القابلة للطي والقابلة للطي

تشير الرسالة غير القابلة للطي إلى تسليم كل رسالة فردية إلى الجهاز. تقدم الرسالة غير القابلة للطي بعض المحتوى المفيد ، على عكس الرسائل القابلة للطي مثل "اختبار الاتصال" الخالي من المحتوى إلى تطبيق الهاتف المحمول للاتصال بالخادم لجلب البيانات.

لا تضمن FCM طلب التسليم.

بعض حالات الاستخدام النموذجية للرسائل غير القابلة للطي هي رسائل الدردشة أو الرسائل الهامة. على سبيل المثال ، في تطبيق المراسلة الفورية ، قد ترغب في تسليم كل رسالة ، لأن كل رسالة لها محتوى مختلف.

بالنسبة إلى Android ، هناك حد أقصى يبلغ 100 رسالة يمكن تخزينها دون طي. إذا تم الوصول إلى الحد الأقصى ، يتم تجاهل جميع الرسائل المخزنة. عندما يتصل الجهاز بالإنترنت مرة أخرى ، يتلقى رسالة خاصة تشير إلى الوصول إلى الحد الأقصى. يمكن للتطبيق بعد ذلك معالجة الموقف بشكل صحيح ، عادةً عن طريق طلب مزامنة كاملة من خادم التطبيق.

الرسالة القابلة للطي هي رسالة يمكن استبدالها برسالة جديدة إذا لم يتم تسليمها إلى الجهاز بعد.

حالات الاستخدام الشائعة للرسائل القابلة للطي هي الرسائل المستخدمة لإخبار تطبيق الهاتف المحمول بمزامنة البيانات من الخادم. من الأمثلة على ذلك تطبيق رياضي يقوم بتحديث المستخدمين بأحدث النقاط. فقط أحدث رسالة ذات صلة.

لوضع علامة على رسالة كرسالة قابلة للطي على Android ، قم بتضمين معلمة collapse_key في حمولة الرسالة. بشكل افتراضي ، يكون مفتاح الطي هو اسم حزمة التطبيق المسجل في وحدة تحكم Firebase. يمكن لخادم FCM تخزين أربع رسائل مختلفة قابلة للطي في نفس الوقت لكل جهاز ، ولكل منها مفتاح تصغير مختلف. إذا تجاوزت هذا الرقم ، فإن FCM يحتفظ فقط بأربعة مفاتيح تصغير ، مع عدم وجود ضمانات حول أي منها يتم الاحتفاظ به.

رسائل الموضوع التي لا تحتوي على حمولة قابلة للطي بشكل افتراضي. رسائل الإعلام قابلة للطي دائمًا وستتجاهل المعلمة collapse_key .

ما الذي يجب علي استخدامه؟

تعد الرسائل القابلة للطي خيارًا أفضل من وجهة نظر الأداء ، بشرط ألا يحتاج تطبيقك إلى استخدام رسائل غير قابلة للطي. ومع ذلك ، إذا كنت تستخدم رسائل قابلة للطي ، فتذكر أن FCM تسمح فقط باستخدام أربعة مفاتيح تصغير مختلفة كحد أقصى بواسطة FCM لكل رمز مميز للتسجيل في أي وقت محدد. يجب ألا تتجاوز هذا الرقم ، وإلا فقد يتسبب ذلك في عواقب غير متوقعة.

	استخدام السيناريو	كيف ترسل
غير قابل للطي	كل رسالة مهمة لتطبيق العميل ويجب تسليمها.	باستثناء رسائل التنبيه ، تكون جميع الرسائل غير قابلة للطي افتراضيًا.
انهيار	عندما تكون هناك رسالة أحدث تعرض رسالة قديمة ذات صلة غير ذات صلة بتطبيق العميل ، فإن FCM تستبدل الرسالة القديمة. على سبيل المثال: الرسائل المستخدمة لبدء مزامنة البيانات من الخادم ، أو رسائل التنبيه القديمة.	قم بتعيين المعلمة المناسبة في طلب الرسالة الخاص بك: collapseKey على Android 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"
      }
    }
  }
}

لمزيد من التفاصيل الخاصة بالنظام الأساسي حول تحديد أولوية الرسالة:

• وثائق APNs
• تعيين وإدارة أولوية الرسالة (Android)
• إلحاح رسالة دفع الويب

تحديد عمر الرسالة

عادةً ما يسلم 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 ، فإن الشاشة قيد التشغيل ولا توجد قيود تقييدية ، يتم تسليم الرسالة على الفور.

إذا كان الجهاز متصلاً ولكن في Doze ، يتم تخزين رسالة ذات أولوية منخفضة بواسطة FCM حتى يخرج الجهاز من Doze. وهذا هو المكان الذي تلعب فيه علامة collapse_key دورًا: إذا كانت هناك بالفعل رسالة بنفس مفتاح الانهيار (ورمز التسجيل المميز) مخزنة وتنتظر التسليم ، يتم تجاهل الرسالة القديمة وتحل الرسالة الجديدة مكانها (أي القديمة الرسالة الجديدة مطوية). ومع ذلك ، إذا لم يتم تعيين مفتاح التصغير ، فسيتم تخزين الرسائل الجديدة والقديمة للتسليم في المستقبل.

إذا لم يكن الجهاز متصلاً بـ FCM ، يتم تخزين الرسالة حتى يتم إنشاء اتصال (مع مراعاة قواعد مفتاح الانهيار مرة أخرى). عند إنشاء اتصال ، يقوم FCM بتسليم جميع الرسائل المعلقة إلى الجهاز. إذا لم يتم توصيل الجهاز مرة أخرى (على سبيل المثال ، إذا تم إعادة ضبط المصنع) ، تنتهي مهلة الرسالة في النهاية ويتم تجاهلها من وحدة تخزين FCM. المهلة الافتراضية هي أربعة أسابيع ، ما لم يتم تعيين علامة time_to_live .

للحصول على مزيد من المعلومات حول تسليم الرسالة:

للحصول على مزيد من المعلومات حول تسليم الرسائل على منصات Android أو Apple ، راجع لوحة تحكم تقارير FCM ، التي تسجل عدد الرسائل المرسلة والمفتوحة على أجهزة Apple و Android ، إلى جانب بيانات "مرات الظهور" (الإشعارات التي يراها المستخدمون) تطبيقات الأندرويد.

بالنسبة لأجهزة Android التي تم تمكين مراسلة القناة المباشرة بها ، إذا لم يكن الجهاز متصلاً بـ FCM لأكثر من شهر واحد ، فلا يزال FCM يقبل الرسالة ولكنه يتجاهلها على الفور. إذا كان الجهاز يتصل في غضون أربعة أسابيع من آخر رسالة بيانات أرسلتها إليه ، يتلقى العميل رد الاتصال onDeletedMessages () . يمكن للتطبيق بعد ذلك معالجة الموقف بشكل صحيح ، عادةً عن طريق طلب مزامنة كاملة من خادم التطبيق.

أخيرًا ، عندما تحاول FCM تسليم رسالة إلى الجهاز وتم إلغاء تثبيت التطبيق ، تتجاهل FCM هذه الرسالة على الفور وتُبطل رمز التسجيل المميز. تؤدي المحاولات المستقبلية لإرسال رسالة إلى هذا الجهاز إلى حدوث خطأ NotRegistered .

الخنق والقشور

هدفنا هو تسليم كل رسالة يتم إرسالها عبر FCM دائمًا. ومع ذلك ، يؤدي توصيل كل رسالة في بعض الأحيان إلى تجربة سيئة للمستخدم بشكل عام. في حالات أخرى ، نحتاج إلى توفير حدود للتأكد من أن FCM توفر خدمة قابلة للتطوير لجميع المرسلين.

ملاحظة: الحدود التي تمت مناقشتها في هذا القسم عرضة للتغيير.

اختناق الرسائل القابلة للطي

كما هو موضح أعلاه ، الرسائل القابلة للطي عبارة عن إشعارات خالية من المحتوى مصممة للانهيار فوق بعضها البعض. في حالة تكرار أحد المطورين للرسالة نفسها إلى تطبيق ما بشكل متكرر ، فإننا نقوم بتأخير (خنق) الرسائل لتقليل التأثير على بطارية المستخدم.

على سبيل المثال ، إذا أرسلت عددًا كبيرًا من طلبات مزامنة البريد الإلكتروني الجديدة إلى جهاز واحد ، فقد نؤخر طلب مزامنة البريد الإلكتروني التالي بضع دقائق حتى يتمكن الجهاز من المزامنة بمعدل متوسط ​​أقل. يتم إجراء هذا الاختناق بشكل صارم للحد من تأثير البطارية الذي يعاني منه المستخدم.

إذا كانت حالة الاستخدام الخاصة بك تتطلب أنماط إرسال متقطعة عالية ، فقد تكون الرسائل غير القابلة للطي هي الخيار الصحيح. لمثل هذه الرسائل ، تأكد من تضمين المحتوى في هذه الرسائل لتقليل تكلفة البطارية.

نحن نحصر الرسائل القابلة للطي في سلسلة من 20 رسالة لكل تطبيق لكل جهاز ، مع إعادة تعبئة رسالة واحدة كل 3 دقائق.

اختناق خادم XMPP

لقد حددنا معدل اتصالك بخوادم FCM XMPP بـ 400 اتصال في الدقيقة لكل مشروع. لا ينبغي أن تكون هذه مشكلة في توصيل الرسائل ، ولكنها مهمة لضمان استقرار نظامنا.

لكل مشروع ، يسمح FCM بـ 2500 وصلة على التوازي.

الحد الأقصى لمعدل الرسائل لجهاز واحد

بالنسبة إلى Android ، يمكنك إرسال ما يصل إلى 240 رسالة / دقيقة و 5000 رسالة / ساعة إلى جهاز واحد. تهدف هذه العتبة العالية إلى السماح بدفقات قصيرة المدى لحركة المرور ، كما هو الحال عندما يتفاعل المستخدمون بسرعة عبر الدردشة. يمنع هذا الحد الأخطاء في إرسال المنطق من استنزاف بطارية الجهاز عن غير قصد.

بالنسبة لنظام iOS ، نرجع خطأ عندما يتجاوز المعدل حدود APNs.

تحذير: لا ترسل رسائل بشكل روتيني بالقرب من هذا المعدل الأقصى. قد يؤدي هذا إلى إهدار موارد المستخدمين النهائيين ، وقد يتم وضع علامة على تطبيقك على أنه مسيء.

حد الرسائل المنبع

نحن نحد من الرسائل الأولية عند 1500000 / دقيقة لكل مشروع لتجنب التحميل الزائد على الخوادم الوجهة المنبع.

نحن نحد من إرسال الرسائل الصادرة لكل جهاز عند 1000 / دقيقة للحماية من استنزاف البطارية من السلوك السيئ للتطبيق.

حد رسالة الموضوع

معدل إضافة / إزالة الاشتراك في الموضوع محدد بـ 3،000 QPS لكل مشروع.

لمعرفة معدلات إرسال الرسائل ، راجع Fanout Throttling .

خنق Fanout

توزيع الرسائل هو عملية إرسال رسالة إلى أجهزة متعددة ، مثل عندما تستهدف مواضيع ومجموعات ، أو عندما تستخدم مؤلف الإشعارات لاستهداف الجماهير أو شرائح المستخدمين.

لا يتم نشر الرسائل بشكل فوري ، ولذلك في بعض الأحيان يكون لديك العديد من المعجبين قيد التقدم بشكل متزامن. لقد حددنا عدد رسائل الترجيح المتزامنة لكل مشروع بـ 1000. بعد ذلك ، قد نرفض طلبات المعجبين الإضافية أو نؤجل توزيع الطلبات حتى تكتمل بعض عمليات التوزيع الجارية بالفعل.

يتأثر معدل الانتشار الفعلي الذي يمكن تحقيقه بعدد المشاريع التي تطلب توزيعات في نفس الوقت. معدل الانتشار 10000 QPS لمشروع فردي ليس نادرًا ، لكن هذا الرقم ليس ضمانًا وهو نتيجة للحمل الإجمالي على النظام. من المهم ملاحظة أن سعة التوزيع المتاحة مقسمة بين المشاريع وليس عبر طلبات الجماهير. لذلك ، إذا كان مشروعك يحتوي على اثنين من المعاصرين قيد التقدم ، فلن يرى كل فرد سوى نصف معدل التوزيع المتاح. الطريقة الموصى بها لزيادة سرعة الجماهير إلى أقصى حد هي أن يكون لديك قناة انتخابية نشطة واحدة قيد التقدم في كل مرة.

منافذ 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. يتيح لنا ذلك توفير اتصال موثوق مع تقليل استهلاك بطارية الأجهزة المحمولة الخاصة بالمستخدمين.

ملاحظة: إذا كنت تتلقى إشعارات عبر APNs ، فتأكد من أنك فتحت أيضًا المنافذ المحددة بواسطة Apple .

أوراق اعتماد

بناءً على ميزات FCM التي تنفذها ، قد تحتاج إلى بيانات الاعتماد التالية من مشروع Firebase:

معرف المشروع	معرّف فريد لمشروع Firebase ، يُستخدم في الطلبات إلى نقطة نهاية FCM v1 HTTP. هذه القيمة متاحة في جزء إعدادات وحدة تحكم Firebase .
رمز التسجيل	سلسلة رمز مميز فريد تحدد كل مثيل تطبيق عميل. رمز التسجيل مطلوب لجهاز واحد ومراسلة مجموعة الجهاز. لاحظ أنه يجب الاحتفاظ بسرية الرموز المميزة للتسجيل.
هوية المرسل	قيمة عددية فريدة تم إنشاؤها عند إنشاء مشروع Firebase الخاص بك ، وهي متوفرة في علامة التبويب Cloud Messaging في جزء إعدادات وحدة تحكم Firebase. يتم استخدام معرف المرسل لتحديد كل مرسل يمكنه إرسال رسائل إلى تطبيق العميل.
رمز وصول	رمز OAuth 2.0 مميز قصير العمر يسمح بالطلبات لواجهة برمجة تطبيقات HTTP v1. يرتبط هذا الرمز المميز بحساب خدمة ينتمي إلى مشروع Firebase الخاص بك. لإنشاء رموز الوصول وتدويرها ، اتبع الخطوات الموضحة في تفويض إرسال الطلبات .
مفتاح الخادم (للبروتوكولات القديمة)	مفتاح خادم يصرح لخادم التطبيق بالوصول إلى خدمات Google ، بما في ذلك إرسال الرسائل عبر بروتوكولات Firebase Cloud Messaging القديمة. تحصل على مفتاح الخادم عند إنشاء مشروع Firebase. يمكنك عرضه في علامة التبويب Cloud Messaging في جزء إعدادات وحدة تحكم Firebase. هام: لا تقم بتضمين مفتاح الخادم في أي مكان في رمز العميل الخاص بك. تأكد أيضًا من استخدام مفاتيح الخادم فقط لتفويض خادم التطبيق الخاص بك. يتم رفض مفاتيح Android و Apple Platform والمتصفح بواسطة FCM.