Firebase Cloud Messaging (FCM) は、幅広いメッセージング オプションと機能を提供します。このページの情報は、さまざまな種類の FCM メッセージと、そのメッセージでできることを理解するのに役立つことを目的としています。
メッセージの種類
FCM を使用すると、次の 2 種類のメッセージをクライアントに送信できます。
- 通知メッセージ。「表示メッセージ」と見なされることもあります。これらは、FCM SDK によって自動的に処理されます。
- クライアント アプリによって処理されるデータ メッセージ。
通知メッセージには、事前に定義されたユーザーに表示されるキーのセットが含まれています。対照的に、データ メッセージには、ユーザー定義のカスタム キーと値のペアのみが含まれます。通知メッセージには、オプションのデータ ペイロードを含めることができます。両方のメッセージ タイプの最大ペイロードは 4000 バイトですが、1024 文字の制限が適用される Firebase コンソールからメッセージを送信する場合を除きます。
| 使用シナリオ | どのように送信します | |
|---|---|---|
| 通知メッセージ | FCM は、クライアント アプリに代わってエンド ユーザー デバイスにメッセージを自動的に表示します。通知メッセージには、定義済みのユーザーに表示されるキーのセットと、カスタム キーと値のペアのオプションのデータ ペイロードがあります。 |
|
| データメッセージ | クライアント アプリは、データ メッセージの処理を担当します。データ メッセージには、予約済みのキー名を持たないカスタム キーと値のペアのみが含まれます (以下を参照)。 | Cloud Functionsやアプリ サーバーなどの信頼できる環境では、 Admin SDKまたはFCM サーバー プロトコルを使用します。 dataキーのみを設定します。 |
クライアント アプリに代わって FCM で通知の表示を処理する場合は、通知メッセージを使用します。クライアント アプリでメッセージを処理する場合は、データ メッセージを使用します。
FCM は、オプションのデータ ペイロードを含む通知メッセージを送信できます。このような場合、FCM は通知ペイロードの表示を処理し、クライアント アプリはデータ ペイロードを処理します。
通知メッセージ
テスト、マーケティング、およびユーザーの再エンゲージメントのために、Firebase コンソールを使用して通知メッセージを送信できます。 Firebase コンソールは、分析ベースの A/B テストを提供し、マーケティング メッセージを改良および改善するのに役立ちます。
Admin SDK または FCM プロトコルを使用してプログラムで通知メッセージを送信するには、通知メッセージのユーザーに表示される部分に必要な事前定義された一連のキーと値のオプションを使用してnotificationキーを設定します。たとえば、IM アプリの JSON 形式の通知メッセージを次に示します。ユーザーは、タイトルが「ポルトガル vs. デンマーク」で、テキストが「素晴らしい試合です!」というメッセージが表示されることを期待できます。デバイス上:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
}
}
}アプリがバックグラウンドにある場合、通知メッセージは通知トレイに配信されます。フォアグラウンドのアプリの場合、メッセージはコールバック関数によって処理されます。
通知メッセージの作成に使用できる定義済みキーの完全なリストについては、リファレンス ドキュメントを参照してください。
データ メッセージ
カスタム キーと値のペアを使用して適切なキーを設定し、クライアント アプリにデータ ペイロードを送信します。
たとえば、上記と同じ IM アプリの JSON 形式のメッセージを次に示します。ここでは、情報が共通dataキーにカプセル化され、クライアント アプリがコンテンツを解釈することが期待されます。
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
}
}
}上記の例は、メッセージを受信するすべてのプラットフォームのクライアントによって解釈されるトップレベルまたは共通dataフィールドの使用法を示しています。各プラットフォームで、クライアント アプリはコールバック関数でデータ ペイロードを受け取ります。
データ メッセージの暗号化
Android Transport Layer ( FCM アーキテクチャを参照) は、ポイントツーポイント暗号化を使用します。必要に応じて、エンド ツー エンドの暗号化をデータ メッセージに追加することができます。 FCM は、エンド ツー エンドのソリューションを提供しません。ただし、キャピラリーやDTLSなどの利用可能な外部ソリューションがあります。
オプションのデータ ペイロードを含む通知メッセージ
プログラムまたは Firebase コンソールを介して、カスタム キーと値のペアのオプションのペイロードを含む通知メッセージを送信できます。 Notifications Composerで、詳細オプションのカスタム データフィールドを使用します。
通知とデータ ペイロードの両方を含むメッセージを受信したときのアプリの動作は、アプリがバックグラウンドにあるかフォアグラウンドにあるかによって異なります。つまり、受信時にアプリがアクティブかどうかです。
- バックグラウンドでは、アプリは通知トレイで通知ペイロードを受け取り、ユーザーが通知をタップしたときにのみデータ ペイロードを処理します。
- フォアグラウンドにある場合、アプリは両方のペイロードが利用可能なメッセージ オブジェクトを受け取ります。
以下は、 notificationキーとdataキーの両方を含む JSON 形式のメッセージです。
{
"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、Web など、すべてのプラットフォームのアプリ インスタンスをターゲットにする
- トピックへのメッセージの送信
プラットフォームに関係なく、すべてのアプリ インスタンスは、次の共通フィールドを解釈できます。
プラットフォーム固有のフィールドをいつ使用するか
次の場合は、プラットフォーム固有のフィールドを使用します。
- フィールドを特定のプラットフォームにのみ送信する
- 共通フィールドに加えてプラットフォーム固有のフィールドを送信する
特定のプラットフォームにのみ値を送信する場合は、共通フィールドを使用しないでください。プラットフォーム固有のフィールドを使用します。たとえば、通知を Apple プラットフォームと Web のみに送信し、Android には送信しない場合は、Apple 用と Web 用の 2 つの別個のフィールド セットを使用する必要があります。
特定の配信オプションを使用してメッセージを送信する場合は、プラットフォーム固有のフィールドを使用して設定します。必要に応じて、プラットフォームごとに異なる値を指定できます。ただし、プラットフォーム間で基本的に同じ値を設定する場合でも、プラットフォーム固有のフィールドを使用する必要があります。これは、プラットフォームごとに値の解釈が若干異なる可能性があるためです。たとえば、time-to-live は、Android では秒単位の有効期限として設定されますが、Apple では有効期限として設定されます。
例: プラットフォーム固有の配信オプションを含む通知メッセージ
次の v1 送信要求は、共通の通知タイトルとコンテンツをすべてのプラットフォームに送信しますが、プラットフォーム固有のオーバーライドも送信します。具体的には、リクエスト:
- Android および Web プラットフォームの有効期間を長く設定し、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 プラットフォームおよび Web でも同様のオプションを使用できます。たとえば、「折りたたみ可能な」メッセージ動作は、Android では FCM のcollapse_keyを介して、Apple apns-collapse-idを介して、JavaScript/Web ではTopicを介してサポートされています。詳細については、このセクションの説明と関連するリファレンス ドキュメントを参照してください。
折りたたみ不可および折りたたみ可能なメッセージ
折りたたみ不可能なメッセージは、個々のメッセージがデバイスに配信されることを示します。サーバーに接続してデータを取得するためにモバイル アプリにコンテンツのない「ping」を送信するような折りたたみ可能なメッセージとは対照的に、折りたたみできないメッセージは、いくつかの有用なコンテンツを配信します。
折りたためないメッセージの典型的な使用例としては、チャット メッセージや重要なメッセージがあります。たとえば、IM アプリでは、すべてのメッセージの内容が異なるため、すべてのメッセージを配信する必要があります。
Android の場合、折りたたまずに保存できるメッセージは 100 件に制限されています。制限に達すると、保存されているすべてのメッセージが破棄されます。デバイスがオンラインに戻ると、制限に達したことを示す特別なメッセージを受け取ります。アプリは、通常、アプリ サーバーから完全な同期を要求することによって、状況を適切に処理できます。
折りたたみ可能なメッセージは、まだデバイスに配信されていない場合に、新しいメッセージに置き換えることができるメッセージです。
折りたたみ可能なメッセージの一般的な使用例は、サーバーからデータを同期するようモバイル アプリに指示するために使用されるメッセージです。例としては、最新のスコアでユーザーを更新するスポーツ アプリがあります。最新のメッセージのみが関連します。
Android でメッセージを折りたたみ可能としてマークするには、メッセージ ペイロードにcollapse_keyパラメーターを含めます。デフォルトでは、折りたたみキーは Firebase コンソールに登録されているアプリ パッケージ名です。 FCM サーバーは、デバイスごとに 4 つの異なる折りたたみ可能なメッセージを同時に保存でき、それぞれに異なる折りたたみキーがあります。この数を超えると、FCM は 4 つの折りたたみキーのみを保持し、どのキーが保持されるかは保証されません。
ペイロードのないトピック メッセージは、デフォルトで折りたたみ可能です。通知メッセージは常に折りたたみ可能で、 collapse_keyパラメータは無視されます。
どちらを使用する必要がありますか?
アプリで折りたたみ不可のメッセージを使用する必要がない場合は、パフォーマンスの観点から折りたたみ可能なメッセージを選択することをお勧めします。ただし、折りたたみ可能なメッセージを使用する場合、FCM では、登録トークンごとに FCM が一度に使用できる異なる折りたたみキーは最大 4 つだけであることに注意してください。この数を超えてはなりません。そうしないと、予期しない結果が生じる可能性があります。
| 使用シナリオ | どのように送信します | |
|---|---|---|
| 折りたたみ不可 | すべてのメッセージはクライアント アプリにとって重要であり、配信する必要があります。 | 通知メッセージを除き、すべてのメッセージはデフォルトで折りたたむことができません。 |
| 折りたたみ可能 | クライアント アプリに関係のない古い関連メッセージをレンダリングする新しいメッセージがある場合、FCM は古いメッセージを置き換えます。例: サーバーからデータ同期を開始するために使用されるメッセージ、または古い通知メッセージ。 | メッセージ リクエストに適切なパラメータを設定します。
|
メッセージの優先度の設定
ダウンストリーム メッセージに配信優先度を割り当てるには、通常優先度と高優先度の 2 つのオプションがあります。動作はプラットフォームによって若干異なりますが、通常のメッセージと優先度の高いメッセージの配信は次のように機能します。
通常の優先度。通常の優先度のメッセージは、アプリがフォアグラウンドにあるときにすぐに配信されます。バックグラウンド アプリの場合、配信が遅れる場合があります。新しいメールの通知、UI の同期の維持、バックグラウンドでのアプリ データの同期など、時間的制約の少ないメッセージの場合は、通常の配信優先度を選択します。
優先度高。デバイスが Doze モードの場合でも、FCM は優先度の高いメッセージをすぐに配信しようとします。優先度の高いメッセージは、時間的制約のあるユーザーに表示されるコンテンツ用です。
次の例は、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 がメッセージを保存して配信を試行する最大期間に対応します。このフィールドを含まないリクエストのデフォルトの最大期間は 4 週間です。
この機能の使用例を次に示します。
- ビデオチャットの着信
- 期限切れの招待イベント
- カレンダーの予定
メッセージの存続期間を指定するもう 1 つの利点は、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 に投稿し、メッセージ ID を受け取ったからといって、そのメッセージが既にデバイスに配信されているわけではありません。むしろ、それは配達が受け入れられたことを意味します。受け入れられた後にメッセージがどうなるかは、多くの要因によって異なります。
最良のシナリオでは、デバイスが FCM に接続されていて、画面がオンで、スロットリングの制限がない場合、メッセージはすぐに配信されます。
デバイスが接続されていても Doze 状態の場合、デバイスが Doze 状態から抜けるまで、優先度の低いメッセージが FCM によって保存されます。そこで、 collapse_keyフラグが役割を果たします。同じ折りたたみキー (および登録トークン) が格納され、配信を待機しているメッセージが既に存在する場合、古いメッセージは破棄され、新しいメッセージが代わりに使用されます (つまり、古いメッセージは新しいメッセージによって折りたたまれます)。ただし、折りたたみキーが設定されていない場合は、将来の配信のために新しいメッセージと古いメッセージの両方が保存されます。
デバイスが FCM に接続されていない場合、メッセージは接続が確立されるまで保存されます (これも折りたたみキーのルールに従います)。接続が確立されると、FCM は保留中のすべてのメッセージをデバイスに配信します。デバイスが再び接続されない場合 (工場出荷時設定にリセットされた場合など)、メッセージは最終的にタイムアウトになり、FCM ストレージから破棄されます。 time_to_liveフラグが設定されていない限り、デフォルトのタイムアウトは 4 週間です。
メッセージの配信についてさらに詳しく知るには、次のようにします。
Android または Apple プラットフォームでのメッセージの配信についてさらに詳しく知るには、 FCM レポート ダッシュボードを参照してください。このダッシュボードには、Apple および Android デバイスで送信および開封されたメッセージの数と、 Android アプリ。
ダイレクト チャネル メッセージングが有効になっている Android デバイスの場合、デバイスが FCM に 1 か月以上接続していない場合、FCM は引き続きメッセージを受け入れますが、すぐに破棄します。最後にデータ メッセージを送信してから 4 週間以内にデバイスが接続した場合、クライアントはonDeletedMessages()コールバックを受け取ります。アプリは、通常、アプリ サーバーから完全な同期を要求することによって、状況を適切に処理できます。
最後に、FCM がデバイスにメッセージを配信しようとしたときにアプリがアンインストールされた場合、FCM はそのメッセージをすぐに破棄し、登録トークンを無効にします。その後、そのデバイスにメッセージを送信しようとすると、 NotRegisteredエラーが発生します。
スロットリングとスケーリング
私たちの目標は、FCM 経由で送信されるすべてのメッセージを常に配信することです。ただし、すべてのメッセージを配信すると、全体的なユーザー エクスペリエンスが低下することがあります。それ以外の場合は、FCM がすべての送信者にスケーラブルなサービスを提供できるように、境界を提供する必要があります。
折りたたみ可能なメッセージ スロットリング
前述のように、折りたたみ可能なメッセージは、互いに重なり合うように設計されたコンテンツのない通知です。開発者がアプリに対して同じメッセージを頻繁に繰り返している場合、ユーザーのバッテリーへの影響を軽減するためにメッセージを遅らせます (調整します)。
たとえば、多数の新しい電子メール同期要求を 1 つのデバイスに送信した場合、デバイスがより低い平均速度で同期できるように、次の電子メール同期要求を数分遅らせることがあります。この調整は、ユーザーが経験するバッテリへの影響を制限するために厳密に行われます。
ユース ケースで高いバースト送信パターンが必要な場合は、折りたたみ不可のメッセージが適切な選択になる可能性があります。このようなメッセージの場合は、バッテリーのコストを削減するために、そのようなメッセージにコンテンツを含めるようにしてください。
折りたたみ可能なメッセージは、デバイスごとのアプリごとに 20 件のメッセージのバーストに制限されており、3 分ごとに 1 件のメッセージが補充されます。
XMPP サーバーのスロットリング
FCM XMPP サーバーに接続できるレートは、プロジェクトごとに 1 分あたり 400 接続に制限されています。これはメッセージ配信の問題ではありませんが、システムの安定性を確保するために重要です。
プロジェクトごとに、FCM は 2500 の並列接続を許可します。
単一デバイスへの最大メッセージ レート
Android の場合、最大 240 メッセージ/分、最大 5,000 メッセージ/時間、1 つのデバイスに送信できます。この高いしきい値は、ユーザーがチャットで迅速にやり取りしている場合など、短期間のトラフィック バーストを許容することを目的としています。この制限により、ロジックを送信する際のエラーによって、デバイスのバッテリーが誤って消耗するのを防ぐことができます。
iOS の場合、レートが APNs の制限を超えるとエラーが返されます。
アップストリーム メッセージの制限
上流の宛先サーバーの過負荷を避けるために、上流のメッセージをプロジェクトごとに 1,500,000/分に制限しています。
アプリの不適切な動作によるバッテリーの消耗を防ぐために、デバイスごとのアップストリーム メッセージを 1,000/分に制限しています。
トピック メッセージの制限
トピック サブスクリプションの追加/削除レートは、プロジェクトあたり 3,000 QPS に制限されています。
メッセージ送信率については、「ファンアウトのスロットリング」を参照してください。
ファンアウトのスロットリング
メッセージ ファンアウトとは、トピックやグループをターゲットにする場合や、通知コンポーザーを使用して対象ユーザーやユーザー セグメントをターゲットにする場合など、複数のデバイスにメッセージを送信するプロセスです。
メッセージのファンアウトは瞬間的ではないため、複数のファンアウトが同時に進行することがあります。プロジェクトあたりの同時メッセージ ファンアウト数は 1,000 に制限されています。その後、追加のファンアウト リクエストを拒否するか、すでに進行中のファンアウトの一部が完了するまで、リクエストのファンアウトを延期する場合があります。
実際に達成可能なファンアウト率は、同時にファンアウトを要求するプロジェクトの数に影響されます。個々のプロジェクトのファンアウト レートが 10,000 QPS であることは珍しくありませんが、その数値は保証ではなく、システムの総負荷の結果です。使用可能なファンアウト容量は、ファンアウト要求全体ではなく、プロジェクト間で分割されることに注意することが重要です。そのため、プロジェクトで 2 つのファンアウトが進行中の場合、各ファンアウトは利用可能なファンアウト レートの半分しか表示されません。ファンアウト速度を最大化するための推奨される方法は、一度に進行中のアクティブなファンアウトを 1 つだけにすることです。
FCM ポートとファイアウォール
組織にインターネットとの間のトラフィックを制限するファイアウォールがある場合は、ネットワーク上のデバイスがメッセージを受信できるように、モバイル デバイスが FCM に接続できるようにファイアウォールを構成する必要があります。 FCM は通常、ポート 5228 を使用しますが、443、5229、および 5230 を使用する場合もあります。
ネットワークに接続しているデバイスの場合、FCM は特定の IP を提供しません。これは、IP 範囲が頻繁に変更され、ファイアウォール ルールが古くなり、ユーザー エクスペリエンスに影響を与える可能性があるためです。理想的には、ポート 5228 ～ 5230 および 443 を IP 制限なしで許可リストに登録します。ただし、IP 制限が必要な場合は、 goog.jsonにリストされているすべての IP アドレスを許可リストに登録する必要があります。この大きなリストは定期的に更新されるため、毎月ルールを更新することをお勧めします。ファイアウォールの 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) が実装されている場合は、ポート 5228 ～ 5230 経由の接続に 30 分以上のタイムアウトを実装してください。これにより、ユーザーのモバイル デバイスのバッテリー消費を抑えながら、信頼性の高い接続を提供できます。
資格情報
実装する FCM 機能によっては、Firebase プロジェクトから次の資格情報が必要になる場合があります。
| プロジェクト ID | FCM v1 HTTP エンドポイントへのリクエストで使用される、Firebase プロジェクトの一意の識別子。この値は、 Firebase コンソールの[設定]ペインで確認できます。 |
| 登録トークン | 各クライアント アプリ インスタンスを識別する一意のトークン文字列。登録トークンは、単一のデバイスおよびデバイス グループのメッセージングに必要です。登録トークンは秘密にしておく必要があることに注意してください。 |
| 送信者 ID | Firebase プロジェクトの作成時に作成される一意の数値。Firebase コンソールの[設定]ペインの [クラウド メッセージング] タブで使用できます。送信者 ID は、クライアント アプリにメッセージを送信できる各送信者を識別するために使用されます。 |
| アクセストークン | HTTP v1 API へのリクエストを承認する有効期間の短い OAuth 2.0 トークン。このトークンは、Firebase プロジェクトに属するサービス アカウントに関連付けられています。アクセス トークンを作成してローテーションするには、 Authorize Send Requestsで説明されている手順に従います。 |
| サーバー キー (レガシー プロトコル用) | Firebase Cloud Messaging レガシー プロトコルを介したメッセージの送信など、Google サービスへのアクセスをアプリ サーバーに許可するサーバー キー。 Firebase プロジェクトを作成するときに、サーバー キーを取得します。これは、Firebase コンソールの[設定]ペインの [クラウド メッセージング] タブで確認できます。 重要:クライアント コードのどこにもサーバー キーを含めないでください。また、アプリ サーバーの認証には必ずサーバー キーのみを使用してください。 Android、Apple プラットフォーム、およびブラウザ キーは FCM によって拒否されます。 |