نمای کلی معماری FCM
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
FCM بر مجموعه اجزای زیر متکی است که پیام‌ها را می‌سازند، انتقال می‌دهند و دریافت می‌کنند:
ابزاری برای نوشتن یا ساخت درخواست های پیام. Notifications composer یک گزینه مبتنی بر رابط کاربری گرافیکی برای ایجاد درخواست‌های اعلان ارائه می‌کند. برای اتوماسیون کامل و پشتیبانی از همه انواع پیام ، باید درخواست‌های پیام را در یک محیط سرور قابل اعتماد ایجاد کنید که از Firebase Admin SDK یا پروتکل سرور FCM پشتیبانی می‌کند. این محیط می تواند Cloud Functions برای Firebase، App Engine یا سرور برنامه خودتان باشد.
پشتیبان FCM، که (در میان سایر عملکردها) درخواست های پیام را می پذیرد، پیام ها را از طریق موضوعات انجام می دهد و ابرداده پیام مانند شناسه پیام را تولید می کند.
یک لایه انتقال در سطح پلت فرم، که پیام را به دستگاه مورد نظر هدایت می‌کند، تحویل پیام را مدیریت می‌کند و در صورت لزوم پیکربندی پلتفرم خاص را اعمال می‌کند. این لایه انتقال شامل:
FCM SDK در دستگاه کاربر، جایی که اعلان نمایش داده می‌شود یا پیام بر اساس وضعیت پیش‌زمینه/پس‌زمینه برنامه و هر منطق برنامه مربوطه مدیریت می‌شود.
جریان چرخه حیات
- دستگاه ها را برای دریافت پیام از FCM ثبت کنید . نمونه‌ای از برنامه مشتری برای دریافت پیام‌ها ثبت می‌شود و یک نشانه ثبت‌نام را به دست می‌آورد که به طور منحصربه‌فرد نمونه برنامه را شناسایی می‌کند.
- ارسال و دریافت پیام های پایین دست .
- ارسال پیام. سرور برنامه پیام هایی را به برنامه مشتری ارسال می کند:
- پیام یا در آهنگساز Notifications یا یک محیط قابل اعتماد نوشته می‌شود و یک درخواست پیام به پشتیبان FCM ارسال می‌شود.
- پشتیبان FCM درخواست پیام را دریافت می کند، شناسه پیام و سایر ابرداده ها را تولید می کند و آن را به لایه انتقال خاص پلت فرم می فرستد.
- هنگامی که دستگاه آنلاین است، پیام از طریق لایه انتقال ویژه پلت فرم به دستگاه ارسال می شود.
- در دستگاه، برنامه مشتری پیام یا اعلان را دریافت می کند.
جز در مواردی که غیر از این ذکر شده باشد،محتوای این صفحه تحت مجوز Creative Commons Attribution 4.0 License است. نمونه کدها نیز دارای مجوز Apache 2.0 License است. برای اطلاع از جزئیات، به خطمشیهای سایت Google Developers مراجعه کنید. جاوا علامت تجاری ثبتشده Oracle و/یا شرکتهای وابسته به آن است.
تاریخ آخرین بهروزرسانی 2025-08-15 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-08-15 بهوقت ساعت هماهنگ جهانی."],[],[],null,["\u003cbr /\u003e\n\nFCM relies on the following set of components that build, transport, and receive\nmessages:\n\n1. Tooling to compose or build message requests. The Notifications composer\n provides a GUI-based option for creating notification requests.\n For full automation and support for all\n [message types](https://firebase.google.com/docs/cloud-messaging/concept-options#notifications_and_data_messages),\n you must build message requests in a trusted\n [server environment](https://firebase.google.com/docs/cloud-messaging/server)\n that supports the Firebase Admin SDK or the FCM server protocol.\n This environment could be Cloud Functions for Firebase, App Engine,\n or your own app server.\n\n2. The FCM backend, which (among other functions) accepts message requests,\n performs fanout of messages via topics, and generates message metadata such\n as the message ID.\n\n3. A platform-level transport layer, which routes the message to the targeted\n device, handles message delivery, and applies platform-specific\n configuration where appropriate. This transport layer includes:\n\n - Android transport layer (ATL) for Android devices with Google Play services\n - Apple Push Notification service (APNs) for Apple devices\n - Web push protocol for web apps\n\n | **Note:** Platform-level transport layers are outside the core FCM product. FCM messages routed to a platform-level transport layer may be subject to terms specific to that platform rather than FCM's terms of service. Android message routing via ATL falls under the [Google APIs terms of service](https://www.google.com/url?q=https://developers.google.com/terms/&sa=D&ust=1558536676246000&usg=AFQjCNFrlRMLv51d1S9NkWxD0IoYSqJ2Ng).\n4. The FCM SDK on the user's device, where the notification is displayed or\n the message is handled according to the app's foreground/background state\n and any relevant application logic.\n\nLifecycle flow\n\n- **Register devices to receive messages from FCM**. An instance of a client app registers to receive messages, obtaining a registration token that uniquely identifies the app instance.\n- **Send and receive downstream messages** .\n - Send a message. The app server sends messages to the client app:\n 1. The message is composed, either in the Notifications composer or a trusted environment, and a message request is sent to the FCM backend.\n 2. The FCM backend receives the message request, generates a message ID and other metadata, and sends it to the platform specific transport layer.\n 3. When the device is online, the message is sent via the platform-specific transport layer to the device.\n 4. On the device, the client app receives the message or notification."]]
