Google is committed to advancing racial equity for Black communities. See how.
ترجمت واجهة Cloud Translation API‏ هذه الصفحة.
Switch to English

حول رسائل FCM

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

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

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

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

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

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

    شاهد بعض الأمثلة على إخطارات العرض وإرسال حمولات الطلب.

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

استخدم رسائل الإعلام عندما تريد من FCM التعامل مع عرض إشعار نيابة عن تطبيق العميل الخاص بك. استخدم رسائل البيانات عندما تريد معالجة الرسائل على تطبيق العميل الخاص بك.

يمكن لـ FCM إرسال رسالة إشعار تتضمن حمولة بيانات اختيارية. في مثل هذه الحالات ، يتعامل FCM مع عرض حمولة الإشعارات ، ويتعامل تطبيق العميل مع حمولة البيانات.

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

للاختبار أو للتسويق وإعادة تفاعل المستخدم ، يمكنك إرسال رسائل إعلام باستخدام وحدة تحكم Firebase . توفر وحدة تحكم Firebase اختبار A / B المستند إلى التحليلات لمساعدتك على تحسين الرسائل التسويقية وتحسينها.

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

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    }
  }
}

يتم تسليم رسائل الإعلام إلى درج الإشعارات عندما يكون التطبيق في الخلفية. بالنسبة للتطبيقات في المقدمة ، تتم معالجة الرسائل بواسطة وظيفة رد الاتصال.

راجع الوثائق المرجعية للحصول على القائمة الكاملة للمفاتيح المحددة مسبقًا المتاحة لبناء رسائل الإعلام:

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

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

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

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

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

رسائل إعلام مع حمولة بيانات اختيارية

سواء برمجيًا أو عبر وحدة تحكم 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 ، مثل AndroidConfig و WebpushConfig ، يتم تفسيرها فقط من خلال مثيلات التطبيق التي تعمل على النظام الأساسي المحدد.

تمنحك الكتل الخاصة بالمنصة المرونة لتخصيص الرسائل لأنظمة أساسية مختلفة لضمان التعامل معها بشكل صحيح عند استلامها. ستأخذ الواجهة الخلفية FCM جميع المعلمات المحددة في الاعتبار وتخصيص الرسالة لكل منصة.

متى تستخدم الحقول المشتركة

استخدم الحقول المشتركة عندما تكون:

  • استهداف مثيلات التطبيق على جميع الأنظمة الأساسية - iOS و Android والويب
  • إرسال رسائل إلى المواضيع

يمكن لجميع مثيلات التطبيق ، بغض النظر عن النظام الأساسي ، تفسير الحقول المشتركة التالية:

متى تستخدم الحقول الخاصة بالنظام الأساسي

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

  • إرسال الحقول إلى منصات معينة فقط
  • أرسل الحقول الخاصة بالمنصة بالإضافة إلى الحقول المشتركة

عندما تريد إرسال القيم إلى أنظمة أساسية معينة فقط ، لا تستخدم الحقول المشتركة ؛ استخدام الحقول الخاصة بالمنصة. على سبيل المثال ، لإرسال إشعار إلى iOS والويب فقط وليس إلى Android ، يجب عليك استخدام مجموعتين منفصلتين من الحقول ، واحدة لنظام iOS والأخرى للويب.

عندما ترسل رسائل بخيارات تسليم محددة ، استخدم الحقول الخاصة بالنظام الأساسي لتعيينها. يمكنك تحديد قيم مختلفة لكل نظام أساسي إذا كنت تريد ذلك. ومع ذلك ، حتى عندما تريد تعيين نفس القيمة بشكل أساسي عبر الأنظمة الأساسية ، يجب عليك استخدام الحقول الخاصة بالنظام الأساسي. وذلك لأن كل نظام أساسي قد يفسر القيمة بشكل مختلف قليلاً - على سبيل المثال ، يتم تعيين وقت البقاء على Android كوقت انتهاء الصلاحية بالثواني ، بينما يتم تعيينه على نظام iOS كتاريخ انتهاء الصلاحية.

مثال: رسالة إعلام بخيارات تسليم خاصة بمنصة

يرسل طلب الإرسال التالي v1 عنوانًا ومحتوى إعلامًا مشتركًا إلى جميع الأنظمة الأساسية ، ولكنه يرسل أيضًا بعض التجاوزات الخاصة بالمنصة. على وجه التحديد ، الطلب:

  • يعيّن وقتًا طويلاً للعيش لمنصات Android والويب ، مع ضبط أولوية رسالة APN (iOS) على إعداد منخفض
  • يضبط المفاتيح المناسبة لتحديد نتيجة نقر المستخدم على الإشعار على Android و iOS - 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 ، ويسمح بخيارات مماثلة على iOS والويب. على سبيل المثال، يتم اعتماد "للطي" سلوك رسالة على الروبوت عبر FCM في collapse_key ، على دائرة الرقابة الداخلية عبر apns-collapse-id ، والجافا سكريبت / الانترنت عبر Topic . للحصول على التفاصيل ، راجع الأوصاف في هذا القسم والوثائق المرجعية ذات الصلة.

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

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

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

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

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

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

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

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

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

استخدام السيناريو كيف ترسل
غير قابل للطي كل رسالة مهمة لتطبيق العميل ويجب تسليمها. باستثناء رسائل التنبيه ، تكون جميع الرسائل غير قابلة للطي افتراضيًا.
انهيار عندما تكون هناك رسالة أحدث تعرض رسالة قديمة ذات صلة غير ذات صلة بتطبيق العميل ، فإن FCM تستبدل الرسالة القديمة. على سبيل المثال: الرسائل المستخدمة لبدء مزامنة البيانات من الخادم ، أو رسائل الإعلام القديمة. قم بتعيين المعلمة المناسبة في طلب الرسالة الخاص بك:
  • collapseKey على Android
  • apns-collapse-id على iOS
  • Topic على الويب
  • collapse_key في البروتوكولات القديمة (جميع الأنظمة الأساسية)

تحديد أولوية الرسالة

لديك خياران لتعيين أولوية التسليم للرسائل النهائية على Android: الأولوية العادية والعالية. يعمل تسليم الرسائل العادية وذات الأولوية العالية على النحو التالي:

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

    عند تلقي رسالة أولوية عادية على Android تطلب مزامنة بيانات الخلفية لتطبيقك ، يمكنك جدولة مهمة مع WorkManager للتعامل معها عندما تكون الشبكة متاحة.

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

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

في ما يلي مثال على رسالة ذات أولوية عادية تم إرسالها عبر بروتوكول 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 الرسائل فور إرسالها. ومع ذلك ، قد لا يكون هذا ممكنًا دائمًا. على سبيل المثال ، إذا كان النظام الأساسي هو 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 لعدة أطراف بإرسال رسائل إلى نفس تطبيق العميل. على سبيل المثال ، لنفترض أن تطبيق العميل عبارة عن مجمّع مقالات يضم عدة مساهمين ، ويجب أن يتمكن كل منهم من إرسال رسالة عند نشر مقالة جديدة. قد تحتوي هذه الرسالة على عنوان URL حتى يتمكن تطبيق العميل من تنزيل المقالة. بدلاً من الاضطرار إلى مركزية جميع أنشطة الإرسال في مكان واحد ، يمنحك FCM القدرة على السماح لكل من هؤلاء المساهمين بإرسال رسائله الخاصة.

لتمكين هذه الميزة ، تأكد من أن لديك معرف المرسل الخاص بكل مرسل . عند طلب التسجيل ، يجلب تطبيق العميل الرمز المميز عدة مرات ، في كل مرة بمعرف مرسل مختلف في حقل الجمهور ، باستخدام طريقة استرداد الرمز المميز للنظام الأساسي المحدد:

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

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

لاحظ أن هناك حدًا يبلغ 100 مرسل متعدد.

عمر الرسالة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

اختناق خادم XMPP

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

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

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

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

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

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

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

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

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

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

خنق Fanout

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

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

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

منافذ FCM وجدار الحماية الخاص بك

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

بالنسبة إلى الاتصالات الصادرة ، لا توفر FCM عناوين IP محددة لأن نطاق IP الخاص بنا يتغير كثيرًا وقد تصبح قواعد جدار الحماية قديمة مما يؤثر على تجربة المستخدمين لديك. من الناحية المثالية ، ستقوم بإدراج المنافذ 5228-5230 في القائمة البيضاء بدون قيود IP. ومع ذلك ، إذا كان يجب أن يكون لديك تقييد IP ، فيجب أن تقوم بإدراج جميع عناوين IP في القائمة البيضاء في كتل IPv4 و IPv6 المدرجة في ASN الخاص بـ Google لـ 15169 . هذه قائمة كبيرة ويجب أن تخطط لتحديث قواعدك شهريًا. غالبًا ما تكون المشكلات الناتجة عن قيود IP لجدار الحماية متقطعة ويصعب تشخيصها.

المنافذ المراد فتحها للرسائل الواردة:

  • 5228
  • 5229
  • 5230
  • 443

منافذ للسماح بالاتصالات الصادرة:

أحد هذه (يفضل الخيار رقم 1):

  1. لا توجد قيود IP
  2. جميع عناوين IP الموجودة في كتل IP المدرجة في ASN الخاص بـ Google لـ 15169 . لا تنس تحديث هذا مرة واحدة على الأقل في الشهر.

ترجمة عنوان الشبكة و / أو جدران الحماية الخاصة بفحص الحزم:

إذا كانت شبكتك تنفذ ترجمة عنوان الشبكة (NAT) أو فحص الحزمة ذات الحالة (SPI) ، فنفذ مهلة 30 دقيقة أو أكبر لاتصالاتنا عبر المنافذ 5228-5230. يتيح لنا ذلك توفير اتصال موثوق مع تقليل استهلاك بطارية الأجهزة المحمولة الخاصة بالمستخدمين.

شهاداته

بناءً على ميزات 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 و iOS والمتصفح بواسطة FCM.