關於 FCM 訊息

Firebase Cloud Messaging (FCM) 提供多種訊息傳送選項和功能。本頁面提供的資訊旨在協助您瞭解不同類型的 FCM 訊息，以及您可以使用這些訊息執行的操作。

訊息類型

您可以使用 FCM 向用戶端傳送兩種類型的訊息：

  • 通知訊息，有時也稱為「顯示訊息」。這些事件會由 FCM SDK 自動處理。
  • 資料訊息由用戶端應用程式處理。

通知訊息包含一組預先定義的使用者可見鍵。相反地，資料訊息只包含使用者定義的自訂鍵/值組合。通知訊息可包含選用的資料酬載。兩種訊息類型的酬載大小上限為 4096 個位元組，但從 Firebase 主控台傳送訊息時，系統會強制限制為 1000 個字元。

使用情境 傳送方式
通知訊息 FCM SDK 會在背景執行時，代表用戶端應用程式向使用者裝置顯示訊息。否則，如果應用程式在收到通知時正在前景執行，則應用程式的程式碼會決定行為。通知訊息包含一組預先定義的使用者可見鍵和 自訂鍵/值組合的選用資料酬載。

  1. 在信任的環境，例如 Cloud Functions 或應用程式伺服器 Admin SDK 或 HTTP v1 API。設定 notification 鍵。 可能具有選用的資料酬載。一律可摺疊。

    查看 顯示通知和傳送要求酬載的範例。

  2. 使用 通知撰寫者：輸入訊息文字、標題等，然後傳送。 提供自訂資料來新增選用資料酬載。
資料訊息 用戶端應用程式負責處理資料訊息。資料訊息只包含自訂鍵/值組合，沒有保留的鍵名 (請參閱下文)。 在 Cloud Functions 或應用程式伺服器等信任環境中，請使用 管理員 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 通訊協定通知物件參考說明文件。

資料訊息

為您的自訂鍵/值組合設定適當的鍵，以便： 將資料酬載傳送至用戶端應用程式

舉例來說 JSON 格式的訊息 (位於與上述相同的 IM 應用程式中) 資訊封裝在通用 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 和網頁)
  • 傳送訊息至主題

所有應用程式執行個體 (無論平台為何) 都可以解讀下列常見元素 欄位：

使用平台專屬欄位的時機

使用平台專屬欄位執行下列操作：

  • 只將欄位傳送至特定平台
  • 除了常用欄位以外，也傳送平台專屬欄位

如要只將值傳送至特定平台，請不要使用通用欄位，而應使用特定平台的欄位。舉例來說，如果您想只將通知傳送給 Apple 平台和網頁，但不傳送給 Android，就必須使用兩組不同的欄位，一組用於 Apple，另一組用於網頁。

傳送含有特定傳送選項的郵件時，請使用特定平台的欄位進行設定。您可以視需要為每個平台指定不同的值。不過，即使您想在各平台上設定相同的值，也必須使用平台專屬欄位。這是因為每個平台 這個值可能無法以略有方式解讀 在 Android 裝置上設為到期時間 (以秒為單位)，在 Apple 上則設為 到期日。

範例：含有平台專屬提交選項的通知訊息

下列 v1 要求會傳送常用通知標題和 同時傳送部分平台專屬覆寫內容 具體來說，要求如下：

  • 為 Android 和網頁平台設定長的有效時間，同時將 APN (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 平台和網站上使用類似的選項。例如「可收合」支援 透過 FCM 的 collapse_key Apple 裝置使用 Android 裝置 apns-collapse-id，以及透過 Topic JavaScript/網頁存取。詳情請參閱 說明及參考文件

不可收合且可收合的訊息

不可收合的訊息表示每則個別訊息都會傳送至裝置。不收折的訊息會提供一些實用的內容，而非收折的訊息則會提供無內容的「ping」訊息，讓行動應用程式與伺服器聯絡，以便擷取資料。

不顯示收合按鈕的訊息常見用途包括即時通訊訊息或重要訊息。舉例來說，在即時通訊應用程式中，您會希望傳送每則訊息，因為每則訊息都有不同的內容。

如果是 Android 系統，最多只能儲存 100 則訊息 收合。如果 達到上限，所有儲存的訊息都會遭到捨棄。裝置重新連上網路後，會收到一則特殊訊息，指出已達到上限。接著，應用程式就能妥善處理情況，通常是透過要求 從應用程式伺服器同步處理

可收合訊息是一種可以由 新訊息。

可收合訊息的常見用途是判斷訊息 用來同步處理伺服器資料的行動應用程式。舉例來說，體育應用程式會向使用者更新最新比分。只有最新的訊息才有參考價值。

如要在 Android 裝置上將郵件標示為可收合，請加入 collapse_key 參數位於 訊息酬載根據預設，摺疊鍵是 Firebase 主控台中登錄的應用程式套件名稱。FCM 伺服器可以 需要同時儲存四則可收合的訊息 每個裝置的收合鍵，且各有不同的收合鍵。如果超過這個上限， FCM 只會保留 四個收合鍵，無法保證保留哪些鍵。

根據預設，沒有酬載的專訊會折疊。通知訊息一律可摺疊，且會忽略 collapse_key 參數。

我該使用哪一個？

從效能的角度來看，可收合訊息更理想 前提是您的應用程式不需要使用不可收合的訊息。不過 使用可收合訊息時 FCM 最多只能使用四個不同的收合鍵 依每 FCM 註冊權杖請勿超過這個數量，否則可能會導致無法預測的後果。

應用情境 傳送方式
不可收合 每則訊息對用戶端應用程式都很重要，因此必須傳送。 除了通知訊息之外，凡是 預設值。
可收合 出現較新的訊息，並顯示較舊相關訊息時 與用戶端應用程式無關，FCM 會取代舊訊息。 例如：用於從伺服器啟動資料同步的訊息，或過期的通知訊息。 請在訊息要求中設定適當的參數：
  • 在 Android 裝置上使用 collapseKey
  • apns-collapse-id on Apple
  • 網頁版 Topic
  • collapse_key 在舊版通訊協定中 (所有平台)

設定郵件優先順序

您可以為下游郵件指派傳送優先順序，有兩種選項：一般和高優先順序。雖然不同平台的行為略有差異，但一般和高優先順序訊息的傳送方式如下：

  • 一般優先順序。 應用程式位於前景時，系統會立即傳送一般優先順序的訊息。對於背景應用程式，傳送作業可能會延遲。適用於較不具時效性的郵件，例如 接收新電子郵件的通知、保持 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"
      }
    }
  }
}

如要進一步瞭解如何設定訊息優先順序，請參閱以下平台專屬詳細說明：

人生重要用途

FCM API 並非設計用於緊急警報或其他高風險活動，因為使用或發生 API 故障可能會導致死亡、人身傷害或環境損害 (例如核子設施、空中交通管制或維生系統的操作)。根據第 4.a 節，我們明確禁止任何這類使用行為。7 服務條款。您必須自行負責管理應用程式是否遵守「條款」，以及因違反「條款」而產生的任何損害。Google 是「照原樣」提供 API並保留 或任何部分/功能或您的存取權 也不會對您或您的使用者承擔任何責任或義務。

設定訊息的效期

FCM 通常會在訊息傳送後立即傳送。不過，這個程序不一定有辦法執行。舉例來說，如果平台是 Android，裝置可能會關閉、離線或無法使用。FCM 也可能會刻意延遲訊息，避免應用程式消耗過多資源，進而影響電池續航力。

發生此情況時，FCM 會儲存訊息並盡快傳送 然後盡可能安排時間雖然在大多數情況下這都沒問題，但有些應用程式可能會導致延遲訊息永遠無法傳送。舉例來說，如果訊息是來電或視訊通話通知，只有在通話結束前短短的一段時間內才有意義。或者，如果訊息是活動邀請，在活動結束後收到這類訊息就沒有用處。

在 Android 和網頁/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， 如果螢幕已開啟且沒有節流限制， 立即配送。

如果裝置已連線，但處於 Doze 模式，FCM 會儲存低優先順序訊息，直到裝置離開 Doze 模式為止。且 這時 collapse_key 旗標就派上用場了：如果有 已經儲存含有相同收合金鑰 (和註冊權杖) 的訊息 等待系統收集 郵件傳送後，舊郵件會遭到捨棄，新訊息也要改寫 (舊訊息會由新郵件收合)。不過，如果廣告處於收合狀態 金鑰未設定，新舊郵件都會儲存以供日後傳送。

如果裝置未連線至 FCM，則系統會在以下期限前儲存訊息： 建立連線 (同樣遵循收合鍵規則)。如果 已建立連線，FCM 會將所有待處理的訊息傳送至 裝置。如果裝置從未再次連線 (例如已恢復原廠設定)，訊息最終會逾時，並從 FCM 儲存空間中捨棄。預設逾時為四週 除非設定了 time_to_live 標記。

如何深入瞭解訊息的傳送情形：

    如要深入瞭解如何在 Android 或 Apple 平台上傳送訊息，請參閱 FCM 報表資訊主頁，當中記錄了 透過 Apple 和 Android 裝置傳送及開啟的訊息數量，以及 「曝光」資料Android 應用程式 (使用者看到的通知)。

對於已啟用直接管道訊息功能的 Android 裝置，如果裝置未連線至 FCM 超過一個月，FCM 仍會接受訊息，但會立即將其捨棄。如果 裝置會在您上次傳送的資料訊息後四週內連線 您的用戶端會收到 onDeletedMessages() 回呼。 應用程式就能妥善處理這種情況，通常會要求應用程式伺服器進行完整同步處理。

最後，當 FCM 嘗試傳送訊息到裝置時， 應用程式已解除安裝，FCM 會立即捨棄該訊息， 會導致註冊憑證失效。日後會嘗試傳送訊息 裝置會導致 NotRegistered 錯誤。

節流和配額

我們的目標是確保每則透過 FCM 傳送的訊息都能送達。不過 傳送每則郵件有時會導致整體使用者體驗不佳。 在其他情況下，我們需要提供界線，以確保 FCM 能夠提供 可擴充的服務上述限制的類型與配額 本節內容 有助於我們平衡這些重要因素

下游訊息節流

HTTP v1 API 為下游訊息引進了專案層級的每分鐘配額。預設配額為每分鐘 60 萬則訊息，可涵蓋 99% 的 FCM 開發人員，同時確保系統穩定性，並盡量減少尖峰專案的影響。

尖峰流量模式可能會導致配額超出錯誤。在配額超出情況下，系統會傳送 HTTP 狀態碼 429 (QUOTA_EXCEEDED)，直到下一個分鐘配額重新填滿為止。在超載情況下，系統也可能會傳回 429 回應，因此強烈建議您按照已發布的最佳化建議處理 429 回應。

注意事項：

  • 下游配額測量的是訊息，而非要求。
  • 用戶端錯誤 (HTTP 狀態碼 400 到 499) 會列入計算 (不含 429)。
  • 配額是以分鐘為單位，但這些分鐘數與時針不一致。

監控配額

您可以在 Google Cloud 控制台中查看配額、用量和錯誤：

  1. 前往 Google Cloud 控制台
  2. 選取「API 與」服務
  3. 在表格中選取「Firebase Cloud Messaging API」。
  4. 選取「配額與系統限制」。

注意：這些圖表並未精確對齊配額分鐘，因此當流量似乎低於配額時，可能會顯示 429 錯誤。

申請提高配額

要求提高配額之前，請確認下列事項：

  • 您的用量通常會達到配額的 80%，且每天至少連續 5 分鐘。
  • 您可以在5% 用戶端錯誤率，尤其是在流量高峰期間。
  • 您遵循大規模傳送訊息的最佳做法。

如果您符合這些條件，可以提交配額調高申請，最多可調高 25%，FCM 會盡力滿足您的要求 (但無法保證一定會調高)。

隨著即將上線，如果您需要更多下游訊息配額，或 為臨時性活動，請至少提前 15 天申請配額，以利系統進行這項作業 有足夠的時間處理要求如果是大型要求 (每分鐘超過 1,800 萬則訊息)，則至少需要 30 天的通知時間。啟動和特殊事件要求仍須遵守用戶端錯誤比率和最佳做法規定。

另請參閱 FCM 配額的常見問題。

主題訊息限制

主題訂閱新增/移除率的上限為每項專案 3,000 QPS。

如需查看訊息傳送率，請參閱跳轉調節。

擴散傳遞熱量

訊息分發是指將訊息傳送至多個裝置的程序，例如指定主題和群組，或是使用通知編寫工具指定目標對象或使用者區隔時。

訊息傳送功能不會立即傳送，因此您偶爾會 同時進行擴散傳遞作業。我們對並行訊息的數量 每項專案各有 1,000 的傳遞流量。之後，我們可能會拒絕額外的分支要求，或將要求的分支延後，直到部分正在進行的分支完成為止。

實際可達的發散率會受到同時要求發散的專案數量影響。個別專案的發散率達到 10,000 QPS 並不少見，但這並非保證，而是系統總負載的結果。請特別注意 可用的擴散器容量會分配給專案，而非擴散傳遞資料 要求。因此，如果專案有兩個正在進行的發散，則每個發散只會看到可用的發散率的一半。若要盡量提高 風扇速度是指一次只能進行一個啟用的擴散傳遞作業。

可收合訊息節流

如上所述，可收合的訊息屬於無內容通知， 即可收合如果開發人員重複 太常發送訊息給應用程式，我們會延遲 (節流) 訊息，以減少 以及可能對使用者電池 造成的影響

舉例來說，假設您傳送大量新的電子郵件同步要求至單一 裝置，我們可能會將下一次電子郵件同步要求延後幾分鐘， 裝置能以較低的平均速率同步。這項節流作業是為了嚴格限制使用者體驗的電池效能。

如果您的用途需要高峰傳送模式，則不應收合訊息可能會是合適的選擇。對於此類郵件，請務必在 以降低電池成本

每個應用程式只能有 20 則可收合訊息，且每個應用程式只能顯示 20 則訊息， 每 3 分鐘補充 1 則訊息。

XMPP 伺服器節流

我們限制您連線到 FCM XMPP 伺服器的頻率，上限為 400 個 每項專案的每分鐘配額這應該不會是郵件傳送時發生的問題，但 確保系統穩定性至關重要每項專案 FCM 允許並行 2500 個連線。

針對使用 XMPP 的上游訊息，FCM 會將上游訊息限制為每個專案每分鐘 1,500,000 個，以免上游目的地伺服器超載。

為防止電池效能，每個裝置每分鐘的上游訊息次數會限制在每分鐘 1,000 次 並排除不良的應用程式行為

單一裝置的訊息傳送頻率上限

以 Android 裝置來說，您每分鐘最多可傳送 240 則訊息，每小時最多傳送 5,000 則訊息至單一訊息 裝置。這個高門檻旨在允許短期流量激增，例如使用者透過即時通訊快速互動時。這項限制可避免發生錯誤 避免不慎消耗裝置電量

在 iOS 中，如果頻率超過 APN 限制，我們會傳回錯誤。

FCM 個通訊埠和您的防火牆

如果貴機構設有防火牆 您必須將其設為允許行動裝置 使用 FCM 才能接收訊息。 FCM 通常使用通訊埠 5228，但有時會使用 443、5229 和 5230。

對於連線至您網路的裝置，FCM 不會提供特定 IP，因為我們的 IP 範圍變動頻繁，防火牆規則可能會過時，進而影響使用者體驗。在理想情況下 通訊埠 5228-5230443，沒有 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)，實作 30 分鐘或更長時間的逾時 通訊埠 5228-5230 之間的連線這可讓我們提供可靠的連線服務，同時降低使用者行動裝置的耗電量。

VPN 互動和略過性

Firebase Cloud Messaging 會採取各種步驟，確保手機與伺服器之間的推播訊息連線可靠且盡可能可用。使用 VPN 會變得複雜

VPN 會遮蓋 FCM 需要調整連線的基礎資訊，以便盡可能提高可靠性和電池續航力。在某些情況下，VPN 會主動 中斷長期連線，導致使用者因錯過或失敗 延遲顯示訊息，或導致電池耗電過高如果 VPN 設定允許 我們使用加密連線 (透過基本網路) 略過 VPN 例如 Wi-Fi 或 LTE)。 無須專人管理FCM 使用可繞過 VPN 的功能，僅限於 FCM 推播通知管道。其他 FCM 流量，例如 註冊流量也會使用 VPN (如果已啟用)。FCM 連線略過 VPN 也不會享有 VPN 提供的額外好處 例如 IP 遮蓋

不同 VPN 能使用不同方法，控制是否 才能被略過如需操作說明，請參閱特定 VPN 的說明文件。

如果未設定略過 VPN，Firebase Cloud Messaging 就會 請使用 VPN 網路連線至伺服器這可能會導致 郵件延遲一段時間且可能增加耗電量 會因為 Cloud Messaging 維持連線 VPN 的連線 以獲得最佳效能和最安全的連線

憑證

視您要實作的 FCM 功能而定，您可能需要 Firebase 專案中的下列憑證：

專案 ID Firebase 專案的專屬 ID，用來向 FCM v1 HTTP 端點。此值為 於 中提供 「Firebase」控制台的「設定」窗格。
註冊權杖

識別每個用戶端應用程式執行個體的專屬權杖字串。 單一裝置和裝置群組訊息需要註冊權杖。請注意，註冊權杖必須保密。
寄件者 ID 您在建立 Firebase 專案時建立的專屬數值。 於 中提供 Cloud Messaging控制台的Firebase標籤 「Settings」(設定) 窗格。傳送者 ID 可用來識別 傳送訊息到用戶端應用程式。
存取權杖 短效 OAuth 2.0 權杖，可授權要求存取 HTTP v1 API。這個權杖與屬於 您的 Firebase 專案。如要建立及輪替存取權權杖，請按照「授權傳送要求」一文中的步驟操作。
伺服器金鑰 (適用於**已淘汰**的舊版通訊協定)

授權應用程式伺服器存取 Google 服務的伺服器金鑰，包括透過已淘汰的 Firebase Cloud Messaging 舊版通訊協定傳送訊息。

重要事項：請勿在 用戶端程式碼。此外，請務必只使用伺服器金鑰授權應用程式伺服器。FCM 會拒絕 Android、Apple 平台和瀏覽器金鑰。