Firebase Cloud Messaging (FCM) 提供多種訊息選項和功能。本頁面提供相關資訊，協助您瞭解不同類型的 FCM 訊息，以及如何運用這些訊息。
通知訊息 (可選用資料酬載)
無論是透過程式輔助或 Firebase 控制台，您都可以傳送通知訊息，其中包含自訂鍵/值組合的選用酬載。在 通知撰寫工具中，使用「進階選項」的「自訂資料」欄位。
應用程式收到同時包含通知和資料酬載的訊息時，會根據應用程式處於背景或前景狀態 (也就是收到訊息時是否處於活動狀態)，採取不同的行為。
- 在背景執行時，應用程式會在通知匣中收到通知酬載，且只會在使用者輕觸通知時處理資料酬載。
- 應用程式在前台運作時，會收到包含兩個酬載的訊息物件。
以下是包含 notification 鍵和 data 鍵的 JSON 格式訊息：
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
},
"data" : {
"Nick" : "Mario",
"Room" : "PortugalVSDenmark"
}
}
}外送選項
FCM 提供一組特定傳送選項，可供傳送訊息至 Android 裝置，並允許在 Apple 平台和網頁上使用類似選項。舉例來說，Android 支援透過 FCM 的 collapse_key 支援「可收合」訊息行為，Apple 則透過 apns-collapse-id 支援，JavaScript/Web 則透過 Topic 支援。詳情請參閱本節中的說明和相關參考文件。
設定郵件優先順序
您可以選擇將一般或高優先順序指派給下游訊息。雖然各平台上的行為略有不同，但一般和高優先順序訊息的傳送方式如下：
一般優先順序。 應用程式在前景運作時，系統會立即傳送優先層級為「一般」的訊息。如果應用程式在背景執行，訊息可能會延遲送達。如果是時間敏感度較低的訊息，例如新電子郵件的通知、保持 UI 同步，或在背景同步處理應用程式資料，請選擇一般傳送優先順序。
高優先順序：即使裝置處於「打盹」模式，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"
}
}
}
}如要進一步瞭解如何設定訊息優先順序，請參閱下列平台專屬詳細資料：
- APNs 說明文件
- 設定及管理訊息優先順序 (Android)
- 網頁推播訊息緊急程度
攸關性命的應用實例
FCM API 不適用於緊急快訊或其他高風險活動，因為使用或無法使用這些 API 可能導致死亡、人身傷害或環境損害 (例如核子設施營運、空中交通管制或維生系統)。根據第 4 節 a. 款規定，我們明確禁止這類使用行為。7 的規定。您必須全權負責管理應用程式，確保符合《條款》規定，並承擔因不符規定而造成的任何損害。Google 提供的 API 均為「現狀」，並保留相關權利，得以隨時基於任何理由停止提供 API 或其中任何部分或功能，或終止您的存取權限，且無須對您或您的使用者承擔責任或履行其他義務。
設定訊息的生命週期
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 並收到訊息 ID 時，並不代表訊息已傳送至裝置。而是指郵件已獲准傳送。訊息接受後會發生什麼情況，取決於許多因素。
在最佳情況下，如果裝置已連上 FCM，且螢幕開啟，沒有任何節流限制，訊息就會立即送達。
如果裝置已連線但處於打盹模式，FCM 會儲存低優先順序訊息，直到裝置離開打盹模式為止。這時 collapse_key 標記就會派上用場：如果系統已儲存具有相同摺疊鍵 (和註冊權杖) 的訊息，並等待傳送，舊訊息就會遭到捨棄，新訊息則會取而代之 (也就是說，舊訊息會由新訊息摺疊)。不過，如果未設定摺疊鍵，系統會儲存新舊訊息，以便日後傳送。
如果裝置未連上 FCM，系統會儲存訊息，直到建立連線為止 (同樣會遵守摺疊鍵規則)。連線建立後，FCM 會將所有待處理訊息傳送至裝置。如果裝置再也不會連上網路 (例如恢復原廠設定)，訊息最終會逾時，並從 FCM 儲存空間中捨棄。除非設定 time_to_live 旗標，否則預設逾時時間為四週。
如要進一步瞭解郵件的傳送情況：
如要進一步瞭解訊息在 Android 或 Apple 平台上的傳送情形，請參閱 FCM報表資訊主頁，其中會記錄在 Apple 和 Android 裝置上傳送及開啟的訊息數量，以及 Android 應用程式的「曝光次數」(使用者看到的通知) 資料。
如果 Android 裝置已啟用直接頻道訊息功能，但超過一個月未連上 FCM，FCM 仍會接收訊息，但會立即捨棄。如果裝置在您傳送最後一則資料訊息後的四週內連線，您的用戶端會收到 onDeletedMessages() 回呼。應用程式接著就能妥善處理這種情況，通常是向應用程式伺服器要求完整同步。
最後，當 FCM 嘗試將訊息傳送至裝置，但應用程式已解除安裝時，FCM 會立即捨棄該訊息並使註冊權杖失效。日後嘗試傳送訊息至該裝置時，會發生 NotRegistered 錯誤。
憑證
視您實作的 FCM 功能而定，您可能需要 Firebase 專案的下列憑證：
| 專案 ID | Firebase 專案的專屬 ID，用於向 FCM v1 HTTP 端點發出要求。這個值位於 Firebase 控制台的「設定」窗格中。 |
| 註冊權杖 | 可識別每個用戶端應用程式執行個體的專屬權杖字串。 單一裝置和裝置群組訊息傳送作業都需要註冊權杖。請注意，註冊權杖必須保密。 |
| 寄件者 ID | 這是您建立 Firebase 專案時產生的專屬數值，可在 Firebase 控制台的「 Cloud Messaging」分頁中，找到「設定」窗格。傳送者 ID 用於識別可傳送訊息給用戶端應用程式的每個傳送者。 |
| 存取權杖 | OAuth 2.0 權杖的效期較短，可授權對 HTTP v1 API 的要求。這個權杖與 Firebase 專案所屬的服務帳戶相關聯。如要建立及輪替存取權杖，請按照「 授權傳送要求」一文中的步驟操作。 |