حول رسائل FCM

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

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

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

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

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

	استخدام السيناريو	كيفية إرسال
رسالة الإخطار	تعرض FCM SDK الرسالة إلى أجهزة المستخدم النهائي نيابة عن تطبيق العميل عندما يكون قيد التشغيل في الخلفية. بخلاف ذلك، إذا كان التطبيق قيد التشغيل في المقدمة عند تلقي الإشعار، فإن رمز التطبيق يحدد السلوك. تحتوي رسائل الإعلام على مجموعة محددة مسبقًا من المفاتيح المرئية للمستخدم وحمولة بيانات اختيارية لأزواج قيمة المفتاح المخصصة.	في بيئة موثوقة مثل Cloud Functions أو خادم التطبيق، استخدم Admin SDK أو HTTP v1 API . اضبط مفتاح notification . قد تحتوي على حمولة بيانات اختيارية. قابلة للطي دائمًا. راجع بعض الأمثلة على عرض الإشعارات وإرسال حمولات الطلب. استخدم مؤلف الإشعارات : أدخل نص الرسالة، والعنوان، وما إلى ذلك، ثم أرسلها. أضف حمولة البيانات الاختيارية من خلال توفير بيانات مخصصة.
رسالة البيانات	تطبيق العميل مسؤول عن معالجة رسائل البيانات. تحتوي رسائل البيانات على أزواج قيمة مفتاح مخصصة فقط بدون أسماء مفاتيح محجوزة (انظر أدناه).	في بيئة موثوقة مثل Cloud Functions أو خادم التطبيق الخاص بك، استخدم 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 للحصول على القائمة الكاملة للمفاتيح المحددة مسبقًا والمتوفرة لإنشاء رسائل الإعلام.

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

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

تأكد من عدم استخدام أي كلمات محجوزة في أزواج القيمة الرئيسية المخصصة لديك. تتضمن الكلمات المحجوزة "from" أو "notification" أو "message_type" أو أي كلمة تبدأ بـ "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 كتاريخ انتهاء الصلاحية.

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

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

• يضبط فترة بقاء طويلة لمنصات Android والويب، مع ضبط أولوية رسائل 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 . للحصول على التفاصيل، راجع الأوصاف الواردة في هذا القسم والوثائق المرجعية ذات الصلة.

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

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

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

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

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

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

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

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

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

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

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

	استخدام السيناريو	كيفية إرسال
غير قابلة للطي	كل رسالة مهمة لتطبيق العميل ويجب تسليمها.	باستثناء رسائل الإعلام، تكون جميع الرسائل غير قابلة للطي بشكل افتراضي.
انهيار	عندما تكون هناك رسالة أحدث تجعل رسالة قديمة ذات صلة غير ذات صلة بتطبيق العميل، تستبدل FCM الرسالة الأقدم. على سبيل المثال: الرسائل المستخدمة لبدء مزامنة البيانات من الخادم، أو رسائل الإشعارات القديمة.	قم بتعيين المعلمة المناسبة في طلب رسالتك: collapseKey على الروبوت apns-collapse-id على أبل 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 وHTTP القديمة في 20 يونيو 2023، وستتم إزالتها في يونيو 2024. إذا كنت تستخدم واجهات برمجة تطبيقات الإرسال القديمة، فنوصي بشدة بالانتقال إلى HTTP v1 API أو فكر في استخدام Admin SDK لإنشاء طلبات الإرسال.

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

بالنسبة للمراسلة الأولية باستخدام XMPP، تحدد FCM عدد الرسائل الأولية بـ 1,500,000/دقيقة لكل مشروع لتجنب التحميل الزائد على خوادم الوجهة الأولية.

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

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

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

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

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

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

يقتصر معدل إضافة/إزالة اشتراك الموضوع على 3000 QPS لكل مشروع.

للتعرف على معدلات إرسال الرسائل، راجع تقييد التوزيع المتشعب .

اختناق المروحة

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

لا تكون النشرة المتشعبة للرسالة فورية، ولذلك يكون لديك في بعض الأحيان عدة نشرات متشعبة قيد التقدم بشكل متزامن. نحن نحدد عدد الرسائل المتشعبة المتزامنة لكل مشروع بـ 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 .

تفاعلات VPN وإمكانية التجاوز

يتخذ Firebase Cloud Messaging خطوات مختلفة للتأكد من أن اتصال المراسلة الفورية من الهاتف إلى الخادم موثوق به ومتاح كلما كان ذلك ممكنًا. يؤدي استخدام VPN إلى تعقيد هذا الجهد.

تقوم شبكات VPN بإخفاء المعلومات الأساسية التي تحتاجها FCM لضبط اتصالها لتحقيق أقصى قدر من الموثوقية وعمر البطارية. في بعض الحالات، تقوم شبكات VPN بفصل الاتصالات الطويلة الأمد بشكل نشط مما يؤدي إلى تجربة مستخدم سيئة بسبب الرسائل الفائتة أو المتأخرة أو ارتفاع تكلفة البطارية. عندما يتم تكوين VPN للسماح لنا بالقيام بذلك، فإننا نتجاوز VPN باستخدام اتصال مشفر (عبر شبكة wifi أو LTE الأساسية) لضمان تجربة موثوقة وصديقة للبطارية. يقتصر استخدام FCM لشبكات VPN القابلة للتجاوز على قناة FCM Push Notification. تستخدم حركة مرور FCM الأخرى، مثل حركة مرور التسجيل، شبكة VPN إذا كانت نشطة. عندما يتجاوز اتصال FCM شبكة VPN، فإنه يفقد المزايا الإضافية التي قد توفرها شبكة VPN، مثل إخفاء IP.

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

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

أوراق اعتماد

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

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