لمحة عن رسائل "المراسلة عبر السحابة الإلكترونية من Firebase"

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

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

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

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

تحتوي رسائل الإشعارات على مجموعة محدّدة مسبقًا من المفاتيح المرئية للمستخدم. وعلى النقيض من ذلك، لا تحتوي رسائل البيانات إلا على أزواج المفتاح/القيمة المخصّصة التي يحددها المستخدم. يمكن أن تحتوي رسائل الإشعارات على حمولة بيانات اختيارية. الحد الأقصى لحمولة كلا النوعين من الرسائل هو 4096 بايت، إلا عند إرسال رسائل من وحدة تحكم Firebase، الذي يفرض حدًا، وهو 1000 حرف.

سيناريو الاستخدام كيفية الإرسال
رسالة إشعار تعرض حزمة تطوير البرامج (SDK) للمراسلة عبر السحابة الإلكترونية من Firebase الرسالة الموجَّهة إلى أجهزة المستخدمين نيابةً عن تطبيق العميل عند تشغيله في الخلفية. وبخلاف ذلك، إذا كان التطبيق يعمل في المقدّمة عند تلقّي الإشعار، سيحدِّد رمز التطبيق سلوكه. تحتوي رسائل الإشعارات على مجموعة محدّدة مسبقًا من المفاتيح المرئية للمستخدم وحمولة بيانات اختيارية من أزواج المفتاح/القيمة المخصّصة.
  1. في بيئة موثوقة مثل Cloud Functions أو خادم تطبيقك، استخدِم حزمة SDK للمشرف أو HTTP v1 API. اضبط مفتاح notification. قد تكون هناك حمولة بيانات اختيارية. قابلة للتصغير دائمًا

    يمكنك الاطّلاع على بعض أمثلة على عرض الإشعارات وإرسال حمولات بيانات الطلبات.

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

استخدِم رسائل الإشعارات إذا كنت تريد من حزمة تطوير البرامج (SDK) للمراسلة عبر السحابة الإلكترونية من Firebase معالجة عرض إشعار تلقائيًا عندما يكون تطبيقك قيد التشغيل في الخلفية. استخدِم رسائل البيانات عندما تريد معالجة الرسائل باستخدام رمز تطبيق العميل.

يمكن للمراسلة عبر السحابة الإلكترونية من Firebase إرسال رسالة إشعار تتضمّن حمولة بيانات اختيارية. وفي هذه الحالات، تتعامل خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" مع عرض حمولة الإشعارات، ويعالج تطبيق العميل حمولة البيانات.

رسائل الإشعارات

لأغراض الاختبار أو للتسويق وإعادة جذب المستخدمين، يمكنك إرسال رسائل الإشعارات باستخدام وحدة تحكُّم Firebase. توفّر وحدة تحكُّم Firebase اختبارات A/B مستندة إلى الإحصاءات لمساعدتك في تنقيح الرسائل التسويقية وتحسينها.

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

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

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

راجِع المستندات المرجعية لكائن إشعار بروتوكول HTTP الإصدار 1 للاطّلاع على القائمة الكاملة للمفاتيح المحدَّدة مسبقًا والمتوفّرة في إصدار رسائل الإشعارات.

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

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

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

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

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

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

تستخدم طبقة النقل في Android (راجع بنية "المراسلة عبر السحابة الإلكترونية من Firebase") التشفير من نقطة إلى نقطة. بناءً على احتياجاتك، قد تُقرِّر إضافة التشفير التام بين الأطراف إلى رسائل البيانات. لا توفّر خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" حلّاً شاملاً. ومع ذلك، تتوفر حلول خارجية مثل Capillary أو DTLS.

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

يمكنك إرسال رسائل إشعارات تحتوي على حمولة اختيارية من أزواج المفتاح/القيمة المخصّصة، سواء آليًا أو من خلال وحدة تحكُّم Firebase. في منشئ الإشعارات، استخدِم حقول البيانات المخصَّصة في الخيارات المتقدّمة.

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

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

في ما يلي رسالة بتنسيق JSON تحتوي على كل من المفتاح notification والمفتاح data:

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

تخصيص رسالة على مختلف المنصّات

إنّ حزمة تطوير البرامج (SDK) لمشرف Firebase وبروتوكول HTTP الإصدار 1 من "المراسلة عبر السحابة الإلكترونية من Firebase" تتيحان لطلبات رسائلك ضبط جميع الحقول المتاحة في العنصر message. يشمل ذلك ما يلي:

  • مجموعة مشتركة من الحقول ليتم تفسيرها بواسطة جميع نُسخ التطبيق الافتراضية التي تتلقى الرسالة.
  • مجموعات الحقول الخاصة بالنظام الأساسي، مثل AndroidConfig وWebpushConfig، لا يتم تفسيرها إلا من خلال مثيلات التطبيق التي يتم تشغيلها على النظام الأساسي المحدّد.

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

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

استخدِم الحقول الشائعة عندما:

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

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

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

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

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

عندما تريد إرسال القيم إلى أنظمة أساسية معيّنة فقط، لا تستخدم الحقول الشائعة، بل استخدِم حقولاً خاصة بالنظام الأساسي. على سبيل المثال، لإرسال إشعار إلى أنظمة Apple الأساسية وعلى الويب فقط وليس إلى Android، عليك استخدام مجموعتَين منفصلتَين من الحقول، إحداهما لموقع Apple والأخرى للويب.

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

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

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

  • ضبط مدة زمنية طويلة للأنظمة الأساسية لـ Android والويب، مع ضبط أولوية رسائل أسماء نقاط الوصول (APN) على إعداد منخفض
  • تحدِّد هذه السياسة المفاتيح المناسبة لتحديد نتيجة نقر المستخدم على الإشعار في نظامَي التشغيل 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 للاطّلاع على تفاصيل كاملة حول المفاتيح المتاحة في المجموعات الخاصة بالنظام الأساسي في نص الرسالة. لمزيد من المعلومات حول إنشاء طلبات الإرسال التي تحتوي على نص الرسالة، يرجى الاطّلاع على إنشاء طلبات الإرسال.

خيارات التوصيل

توفّر خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" مجموعة محدّدة من خيارات التسليم للرسائل المرسلة إلى أجهزة Android، وتسمح بخيارات مشابهة على أنظمة Apple الأساسية والويب. على سبيل المثال، يتوفّر سلوك الرسائل "القابلة للتصغير" على أجهزة Android من خلال collapse_key في خدمة "المراسلة عبر السحابة الإلكترونية من Firebase"، وفي Apple من خلال apns-collapse-id، وفي JavaScript/الويب من خلال Topic. للحصول على تفاصيل، يُرجى الاطّلاع على الأوصاف الواردة في هذا القسم والمستندات المرجعية ذات الصلة.

الرسائل غير القابلة للتصغير والتصغير

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

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

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

الرسالة القابلة للتصغير هي رسالة قد يتم استبدالها برسالة جديدة إذا لم يتم تسليمها إلى الجهاز بعد.

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

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

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

أيهما أستخدم؟

الرسائل القابلة للتصغير هي خيار أفضل من ناحية الأداء، بشرط أنّ تطبيقك لا يحتاج إلى استخدام رسائل غير قابلة للتصغير. مع ذلك، إذا كنت تستخدم الرسائل القابلة للتصغير، يُرجى العِلم أنّ ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" تسمح فقط باستخدام أربعة مفاتيح تصغير مختلفة كحد أقصى من "المراسلة عبر السحابة الإلكترونية من Firebase" لكل رمز مميّز للتسجيل في أي وقت. يجب عدم تجاوز هذا الرقم، وإلا فقد يؤدي ذلك إلى عواقب غير متوقعة.

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

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

لديك خياران لتعيين أولوية التسليم للرسائل التي تظهر عند استلام الرسائل، وهما: أولوية عادية وأولوية عالية. على الرغم من أنّ السلوك يختلف قليلاً من منصة إلى أخرى، يتم إرسال الرسائل العادية والعالية الأولوية على النحو التالي:

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

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

في ما يلي مثال على رسالة ذات أولوية عادية يتم إرسالها عبر بروتوكول HTTP v1 من "المراسلة عبر السحابة الإلكترونية من Firebase" لإبلاغ مشترك في مجلة بأنّ المحتوى الجديد متاح للتنزيل:

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

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

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

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

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

على نظام التشغيل Android والويب/JavaScript، يمكنك تحديد الحد الأقصى لعمر الرسالة. يجب أن تتراوح القيمة بين 0 و2,419,200 ثانية (28 يومًا)، وأن تكون هذه القيمة مناسبة للحد الأقصى لفترة الوقت التي تخزن فيها خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" الرسالة وتحاول تسليمها. إنّ الطلبات التي لا تحتوي على هذا الحقل يتم ضبطها تلقائيًا على أربعة أسابيع كحد أقصى.

فيما يلي بعض الاستخدامات المحتملة لهذه الميزة:

  • المكالمات الواردة في محادثات الفيديو
  • أحداث الدعوات التي ستنتهي صلاحيتها قريبًا
  • أحداث التقويم

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

في ما يلي مثال على طلب يتضمن مدة البقاء:

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

فترة بقاء الرسالة

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

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

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

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

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

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

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

التقييد والتوسع

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

تقييد الرسائل القابلة للتصغير

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

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

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

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

تقييد خادم XMPP

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

بالنسبة إلى الرسائل المُرسَلة من خلال XMPP، تضع خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" حدودًا لعدد رسائل التحميل على 1,500,000 دقيقة في الدقيقة لكل مشروع، وذلك لتجنّب تحميل عبء زائد على خوادم الوجهة.

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

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

بالنسبة إلى Android، يمكنك إرسال ما يصل إلى 240 رسالة في الدقيقة و5,000 رسالة في الساعة إلى جهاز واحد. يهدف هذا الحدّ الأدنى المرتفع إلى السماح بحدوث عدد كبير من الزيارات على المدى القصير، مثلاً عندما يتفاعل المستخدمون بسرعة عبر المحادثة. يمنع هذا الحد أخطاء إرسال منطق من استنزاف بطارية الجهاز عن غير قصد.

بالنسبة إلى نظام التشغيل iOS، نعرض رسالة خطأ عندما يتجاوز المعدّل حدود أسماء نقاط الوصول (APN).

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

يقتصر معدّل إضافة/إزالة الاشتراك في المواضيع على 3,000 طلب في الثانية لكل مشروع.

لمعرفة معدلات إرسال الرسائل، يُرجى الاطّلاع على تقييد نطاق المعجبين.

تقييد التوزيع الموسَّع

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

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

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

منافذ FCM وجدار الحماية

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

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

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

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

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

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

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

بيانات الاعتماد

بناءً على ميزات خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" التي تطبّقها، قد تحتاج إلى بيانات الاعتماد التالية من مشروعك على Firebase:

رقم تعريف المشروع معرّف فريد لمشروعك على Firebase، يُستخدم في طلبات نقطة نهاية HTTP، الإصدار 1 من FCM. وتتوفّر هذه القيمة في جزء الإعدادات في وحدة تحكُّم Firebase.
الرمز المميز للتسجيل

سلسلة رمز مميّز فريدة تحدّد كل مثيل تطبيق عميل يكون الرمز المميّز للتسجيل مطلوبًا للمراسلة الجماعية على جهاز واحد وجهاز واحد. ملاحظة: يجب الحفاظ على سرّية الرموز المميّزة للتسجيل.

معرّف المرسِل قيمة رقمية فريدة يتم إنشاؤها عند إنشاء مشروعك في Firebase، وتتوفّر في علامة التبويب "المراسلة عبر السحابة الإلكترونية" ضمن جزء الإعدادات في "وحدة تحكُّم Firebase". يتم استخدام معرّف المرسِل لتحديد كل مُرسِل يمكنه إرسال الرسائل إلى تطبيق العميل.
رمز الدخول هو رمز OAuth 2.0 مميز قصير الأجل يسمح بالطلبات الموجّهة إلى واجهة برمجة التطبيقات HTTP v1. هذا الرمز المميّز مرتبط بحساب خدمة ينتمي إلى مشروعك على Firebase. لإنشاء رموز الدخول وتدويرها، اتّبِع الخطوات الموضّحة في تفويض طلبات الإرسال.
مفتاح الخادم (للبروتوكولات القديمة **المتوقّفة**)

مفتاح خادم يفوّض خادم تطبيقك بالوصول إلى خدمات Google، بما في ذلك إرسال الرسائل من خلال البروتوكولات القديمة المتوقّفة في خدمة "المراسلة عبر السحابة الإلكترونية من Firebase"

ملاحظة مهمة: لا تضمِّن مفتاح الخادم في أي مكان في رمز العميل. ويجب التأكّد أيضًا من استخدام مفاتيح الخادم فقط لمنح الإذن بخادم تطبيقك. رفضت ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" مفاتيح Android وApple Platform ومفاتيح المتصفّح.