Giới thiệu về thông báo FCM

Firebase Cloud Messaging (FCM) cung cấp nhiều tính năng và tuỳ chọn nhắn tin. Thông tin trong trang này nhằm giúp bạn hiểu các loại thông báo FCM và những việc bạn có thể làm với các thông báo đó.

Loại thông báo

Với FCM, bạn có thể gửi hai loại thông báo đến ứng dụng khách:

• Thông báo, đôi khi được gọi là "thông báo hiển thị". SDK FCM sẽ tự động xử lý các yêu cầu này.
• Thông báo dữ liệu do ứng dụng khách xử lý.

Thông báo chứa một tập hợp các khoá được xác định trước mà người dùng có thể nhìn thấy. Ngược lại, thông báo dữ liệu chỉ chứa các cặp khoá-giá trị tuỳ chỉnh do người dùng xác định. Thông báo có thể chứa một tải trọng dữ liệu không bắt buộc. Trọng tải tối đa cho cả hai loại thông báo là 4096 byte, ngoại trừ khi gửi thông báo từ bảng điều khiển Firebase. Bảng điều khiển này thực thi giới hạn 1000 ký tự.

Hãy sử dụng nội dung thông báo khi bạn muốn SDK FCM xử lý việc hiển thị thông báo tự động khi ứng dụng của bạn đang chạy ở chế độ nền. Sử dụng thông báo dữ liệu khi bạn muốn xử lý thông báo bằng mã ứng dụng khách của riêng mình.

FCM có thể gửi thông báo bao gồm một tải trọng dữ liệu không bắt buộc. Trong những trường hợp như vậy, FCM sẽ xử lý việc hiển thị tải trọng thông báo và ứng dụng khách sẽ xử lý tải trọng dữ liệu.

Thông báo

Để thử nghiệm hoặc để tiếp thị và thu hút người dùng tương tác lại, bạn có thể gửi thông báo bằng bảng điều khiển Firebase. Bảng điều khiển Firebase cung cấp tính năng thử nghiệm A/B dựa trên số liệu phân tích để giúp bạn tinh chỉnh và cải thiện thông điệp tiếp thị.

Để gửi thông báo theo phương thức lập trình bằng SDK quản trị hoặc giao thức FCM, hãy đặt khoá notification bằng tập hợp các tuỳ chọn khoá-giá trị được xác định trước cần thiết cho phần hiển thị với người dùng của thông báo. Ví dụ: đây là một tin nhắn thông báo có định dạng JSON trong một ứng dụng nhắn tin nhanh. Người dùng có thể sẽ thấy một thông báo có tiêu đề "Bồ Đào Nha đấu với Đan Mạch" và văn bản "trận đấu hay!" trên thiết bị:

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

Thông báo được gửi đến khay thông báo khi ứng dụng chạy ở chế độ nền. Đối với các ứng dụng ở nền trước, thông báo được xử lý bằng một hàm gọi lại.

Hãy xem tài liệu tham khảo về đối tượng thông báo Giao thức HTTP phiên bản 1 để biết danh sách đầy đủ các khoá được xác định trước có sẵn để tạo thông báo.

Thông báo dữ liệu

Đặt khoá thích hợp bằng các cặp khoá-giá trị tuỳ chỉnh để gửi tải trọng dữ liệu đến ứng dụng khách.

Ví dụ: đây là một thông báo có định dạng JSON trong cùng một ứng dụng nhắn tin nhanh ở trên, trong đó thông tin được gói gọn trong khoá data chung và ứng dụng khách dự kiến sẽ diễn giải nội dung:

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

Ví dụ trên cho thấy cách sử dụng trường data cấp cao nhất hoặc phổ biến, được các ứng dụng trên tất cả nền tảng nhận được thông báo diễn giải. Trên mỗi nền tảng, ứng dụng khách sẽ nhận được tải trọng dữ liệu trong một hàm gọi lại.

Mã hoá cho thư dữ liệu

Lớp truyền tải Android (xem cấu trúc FCM) sử dụng phương thức mã hoá điểm-điểm. Tuỳ thuộc vào nhu cầu của mình, bạn có thể quyết định thêm tính năng mã hoá hai đầu vào tin nhắn dữ liệu. FCM không cung cấp giải pháp toàn diện. Tuy nhiên, có các giải pháp bên ngoài như Capillary hoặc DTLS.

Tin nhắn thông báo có tải trọng dữ liệu không bắt buộc

Cả theo phương thức lập trình hoặc thông qua bảng điều khiển Firebase, bạn đều có thể gửi tin nhắn thông báo chứa tải trọng không bắt buộc gồm các cặp khoá-giá trị tuỳ chỉnh. Trong Trình soạn thông báo, hãy sử dụng các trường Dữ liệu tuỳ chỉnh trong Tuỳ chọn nâng cao.

Hành vi của ứng dụng khi nhận được thông báo bao gồm cả tải trọng thông báo và dữ liệu phụ thuộc vào việc ứng dụng đang chạy ở chế độ nền hay chế độ nền trước – về cơ bản là ứng dụng có đang hoạt động hay không tại thời điểm nhận.

• Khi ở chế độ nền, ứng dụng sẽ nhận được tải trọng thông báo trong khay thông báo và chỉ xử lý tải trọng dữ liệu khi người dùng nhấn vào thông báo.
• Khi chạy trên nền trước, ứng dụng của bạn sẽ nhận được một đối tượng thông báo có cả hai tải trọng.

Dưới đây là một thông báo có định dạng JSON chứa cả khoá notification và khoá data:

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

Tuỳ chỉnh thông điệp trên nhiều nền tảng

Cả Firebase Admin SDK và giao thức HTTP FCM phiên bản 1 đều cho phép các yêu cầu thông báo của bạn đặt tất cả các trường có sẵn trong đối tượng message. Chẳng hạn như:

• một tập hợp các trường phổ biến để tất cả các thực thể ứng dụng nhận được thông báo diễn giải.
• các nhóm trường dành riêng cho nền tảng, chẳng hạn như AndroidConfig và WebpushConfig, chỉ được các thực thể ứng dụng chạy trên nền tảng đã chỉ định diễn giải.

Các khối dành riêng cho nền tảng giúp bạn linh hoạt tuỳ chỉnh thông báo cho các nền tảng khác nhau để đảm bảo thông báo được xử lý chính xác khi nhận được. Phần phụ trợ FCM sẽ xem xét tất cả các tham số được chỉ định và tuỳ chỉnh thông báo cho từng nền tảng.

Trường hợp sử dụng các trường phổ biến

Sử dụng các trường phổ biến khi bạn:

• Nhắm mục tiêu các phiên bản ứng dụng trên tất cả nền tảng — Apple, Android và web
• Gửi tin nhắn đến chủ đề

Mọi phiên bản ứng dụng, bất kể nền tảng, đều có thể diễn giải các trường phổ biến sau đây:

• message.notification.title
• message.notification.body
• message.data

Trường hợp cần sử dụng các trường dành riêng cho nền tảng

Sử dụng các trường dành riêng cho nền tảng khi bạn muốn:

• Chỉ gửi các trường đến một số nền tảng
• Gửi các trường dành riêng cho nền tảng ngoài các trường phổ biến

Bất cứ khi nào bạn chỉ muốn gửi giá trị đến các nền tảng cụ thể, đừng sử dụng các trường phổ biến; hãy sử dụng các trường dành riêng cho nền tảng. Ví dụ: để chỉ gửi thông báo cho các nền tảng của Apple và web nhưng không gửi cho Android, bạn phải sử dụng hai nhóm trường riêng biệt, một nhóm cho Apple và một nhóm cho web.

Khi bạn gửi thông báo có các tuỳ chọn phân phối cụ thể, hãy sử dụng các trường dành riêng cho nền tảng để đặt các tuỳ chọn đó. Nếu muốn, bạn có thể chỉ định các giá trị khác nhau cho mỗi nền tảng. Tuy nhiên, ngay cả khi muốn đặt cùng một giá trị về cơ bản trên các nền tảng, bạn vẫn phải sử dụng các trường dành riêng cho nền tảng. Điều này là do mỗi nền tảng có thể diễn giải giá trị hơi khác nhau. Ví dụ: thời gian tồn tại được đặt trên Android dưới dạng thời gian hết hạn tính bằng giây, còn trên Apple, giá trị được đặt là ngày hết hạn.

Ví dụ: thông báo có các tuỳ chọn phân phối dành riêng cho nền tảng

Yêu cầu gửi v1 sau đây sẽ gửi tiêu đề và nội dung thông báo chung đến tất cả nền tảng, nhưng cũng gửi một số nội dung ghi đè dành riêng cho nền tảng. Cụ thể, yêu cầu:

• đặt thời gian tồn tại lâu dài cho các nền tảng Android và Web, trong khi đặt mức độ ưu tiên thông báo APN (nền tảng của Apple) thành cài đặt thấp
• thiết lập các khoá thích hợp để xác định kết quả của một lượt nhấn của người dùng vào thông báo trên Android và Apple — tương ứng là click_action và 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"
       }
     }
   }
 }

Hãy xem tài liệu tham khảo HTTP phiên bản 1 để biết thông tin chi tiết đầy đủ về các khoá có sẵn trong các khối dành riêng cho nền tảng trong phần nội dung thư. Để biết thêm thông tin về cách tạo yêu cầu gửi chứa nội dung thư, hãy xem phần Tạo yêu cầu gửi.

Phương thức giao hàng

FCM cung cấp một bộ tuỳ chọn phân phối cụ thể cho các thông báo được gửi đến thiết bị Android, đồng thời cho phép các tuỳ chọn tương tự trên nền tảng Apple và web. Ví dụ: hành vi tin nhắn "có thể thu gọn" được hỗ trợ trên Android thông qua collapse_key của FCM, trên Apple thông qua apns-collapse-id và trên JavaScript/Web thông qua Topic. Để biết thông tin chi tiết, hãy xem nội dung mô tả trong phần này và tài liệu tham khảo liên quan.

Thông báo không thể thu gọn và có thể thu gọn

Thông báo không thể thu gọn cho biết rằng từng thông báo riêng lẻ sẽ được gửi đến thiết bị. Thông báo không thể thu gọn sẽ phân phối một số nội dung hữu ích, trái ngược với thông báo có thể thu gọn như "ping" không có nội dung đến ứng dụng di động để liên hệ với máy chủ nhằm tìm nạp dữ liệu.

Một số trường hợp sử dụng thông thường của tin nhắn không thể thu gọn là tin nhắn trò chuyện hoặc tin nhắn quan trọng. Ví dụ: trong ứng dụng nhắn tin nhanh, bạn sẽ muốn gửi mọi tin nhắn vì mỗi tin nhắn đều có nội dung khác nhau.

Đối với Android, hệ thống có thể lưu trữ tối đa 100 thông báo mà không bị thu gọn. Nếu đạt đến giới hạn, thì tất cả tin nhắn đã lưu trữ sẽ bị loại bỏ. Khi thiết bị kết nối lại với mạng, thiết bị sẽ nhận được một thông báo đặc biệt cho biết đã đạt đến giới hạn. Sau đó, ứng dụng có thể xử lý tình huống đúng cách, thường là bằng cách yêu cầu đồng bộ hoá toàn bộ từ máy chủ ứng dụng.

Thông báo có thể thu gọn là một tin nhắn có thể được thay thế bằng một tin nhắn mới nếu tin nhắn đó chưa được gửi đến thiết bị.

Một trường hợp sử dụng phổ biến của thông báo có thể thu gọn là thông báo dùng để yêu cầu ứng dụng di động đồng bộ hoá dữ liệu từ máy chủ. Ví dụ: ứng dụng thể thao cập nhật cho người dùng về tỷ số mới nhất. Chỉ thư gần đây nhất là có liên quan.

Để đánh dấu một tin nhắn là có thể thu gọn trên Android, hãy đưa tham số collapse_key vào tải trọng tin nhắn. Theo mặc định, khoá thu gọn là tên gói ứng dụng được đăng ký trong bảng điều khiển Firebase. Máy chủ FCM có thể đồng thời lưu trữ 4 thông báo có thể thu gọn khác nhau trên mỗi thiết bị, mỗi thông báo có một khoá thu gọn khác nhau. Nếu bạn vượt quá con số này, thì FCM chỉ giữ lại 4 khoá thu gọn mà không đảm bảo về những khoá sẽ được giữ lại.

Theo mặc định, các thông báo chủ đề không có tải trọng sẽ có thể thu gọn. Thông báo luôn có thể thu gọn và sẽ bỏ qua tham số collapse_key.

Tôi nên sử dụng loại nào?

Thông báo có thể thu gọn là lựa chọn tốt hơn về mặt hiệu suất, miễn là ứng dụng của bạn không cần sử dụng thông báo không thể thu gọn. Tuy nhiên, nếu bạn sử dụng thông báo có thể thu gọn, hãy nhớ rằng FCM chỉ cho phép FCM sử dụng tối đa 4 khoá thu gọn khác nhau cho mỗi mã thông báo đăng ký tại một thời điểm bất kỳ. Bạn không được vượt quá số lượng này, nếu không, điều này có thể gây ra hậu quả khó lường.

Đặt mức độ ưu tiên của tin nhắn

Bạn có hai lựa chọn để chỉ định mức độ ưu tiên phân phối cho các thông báo thứ cấp: bình thường và có mức độ ưu tiên cao. Mặc dù hành vi có khác biệt một chút giữa các nền tảng, nhưng việc phân phối thông báo có mức độ ưu tiên bình thường và cao sẽ hoạt động như sau:

• Mức độ ưu tiên bình thường. Thông báo có mức độ ưu tiên bình thường sẽ được phân phối ngay lập tức khi ứng dụng chạy ở nền trước. Đối với các ứng dụng chạy ở chế độ nền, quá trình phân phối có thể bị trễ. Đối với các thông báo ít quan trọng về thời gian hơn, chẳng hạn như thông báo về email mới, duy trì đồng bộ hoá giao diện người dùng hoặc đồng bộ hoá dữ liệu ứng dụng ở chế độ nền, hãy chọn mức độ ưu tiên gửi thông thường.

• Mức độ ưu tiên cao. FCM cố gắng gửi ngay các thông báo có mức độ ưu tiên cao ngay cả khi thiết bị đang ở chế độ Nghỉ. Thông báo có mức độ ưu tiên cao dành cho nội dung có giới hạn thời gian và người dùng có thể nhìn thấy.

Dưới đây là ví dụ về một thông báo có mức độ ưu tiên thông thường được gửi qua giao thức HTTP phiên bản 1 FCM để thông báo cho người đăng ký tạp chí rằng có thể tải nội dung mới xuống:

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

Để biết thêm thông tin chi tiết theo nền tảng về cách đặt mức độ ưu tiên của thông báo:

• Tài liệu về APN
• Đặt và quản lý mức độ ưu tiên của tin nhắn (Android)
• Sự cấp bách của thông báo đẩy trên web

Các trường hợp sử dụng quan trọng đối với cuộc sống

API FCM không được thiết kế cho cảnh báo khẩn cấp hoặc các hoạt động có rủi ro cao khác, trong đó việc sử dụng hoặc lỗi của API có thể dẫn đến tử vong, thương tích cá nhân hoặc thiệt hại môi trường (chẳng hạn như hoạt động vận hành cơ sở hạt nhân, kiểm soát không lưu hoặc hệ thống hỗ trợ sự sống). Chúng tôi nghiêm cấm mọi hành vi sử dụng như vậy trong Mục 4. a. 7 của Điều khoản dịch vụ. Bạn hoàn toàn chịu trách nhiệm quản lý việc tuân thủ Điều khoản của ứng dụng và mọi thiệt hại phát sinh từ việc không tuân thủ. Google cung cấp các API "nguyên trạng" và giữ quyền ngừng cung cấp các API hoặc bất kỳ phần hoặc tính năng nào hoặc quyền truy cập của bạn vào các API đó, vì bất kỳ lý do gì và vào bất kỳ thời điểm nào, mà không chịu trách nhiệm pháp lý hoặc nghĩa vụ nào khác đối với bạn hoặc người dùng của bạn.

Đặt thời gian tồn tại của thông báo

FCM thường phân phối tin nhắn ngay sau khi gửi. Tuy nhiên, điều này không phải lúc nào cũng có thể xảy ra. Ví dụ: nếu nền tảng là Android, thì thiết bị có thể bị tắt, ngoại tuyến hoặc không dùng được. Hoặc FCM có thể cố ý trì hoãn thông báo để ngăn ứng dụng tiêu thụ quá nhiều tài nguyên và ảnh hưởng tiêu cực đến thời lượng pin.

Khi điều này xảy ra, FCM sẽ lưu trữ thông báo và phân phối thông báo đó ngay khi có thể. Mặc dù điều này không vấn đề gì trong hầu hết trường hợp, nhưng cũng có một số ứng dụng không gửi được thông báo trễ. Ví dụ: nếu thông báo là cuộc gọi đến hoặc thông báo trò chuyện video, thì thông báo đó chỉ có ý nghĩa trong một khoảng thời gian ngắn trước khi cuộc gọi kết thúc. Hoặc nếu thư là lời mời tham dự một sự kiện, thì thư đó sẽ vô dụng nếu được nhận sau khi sự kiện kết thúc.

Trên Android và Web/JavaScript, bạn có thể chỉ định thời gian tồn tại tối đa của một thông báo. Giá trị này phải có thời lượng từ 0 đến 2.419.200 giây (28 ngày) và tương ứng với khoảng thời gian tối đa mà FCM lưu trữ và cố gắng gửi thông báo. Các yêu cầu không chứa trường này sẽ mặc định có thời hạn tối đa là 4 tuần.

Dưới đây là một số cách sử dụng tính năng này:

• Cuộc gọi đến trong trò chuyện video
• Sự kiện hết hạn của lời mời
• Sự kiện trên lịch

Một lợi thế khác của việc chỉ định thời gian tồn tại của thông báo là FCM không áp dụng tính năng điều tiết thông báo có thể thu gọn cho các thông báo có thời gian tồn tại là 0 giây. FCM cung cấp khả năng xử lý tốt nhất cho các thông báo phải được gửi "ngay hoặc không bao giờ". Xin lưu ý rằng giá trị time_to_live là 0 có nghĩa là những tin nhắn không thể gửi ngay lập tức sẽ bị loại bỏ. Tuy nhiên, vì các thông báo như vậy không bao giờ được lưu trữ, nên điều này mang lại độ trễ tốt nhất để gửi thông báo.

Dưới đây là ví dụ về một yêu cầu có 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"
      }
    }
  }
}

Vòng đời của một thông báo

Khi máy chủ ứng dụng đăng một thông báo lên FCM và nhận lại mã thông báo, điều đó không có nghĩa là thông báo đã được gửi đến thiết bị. Thay vào đó, trạng thái này có nghĩa là đơn đặt hàng đã được chấp nhận để giao hàng. Điều gì xảy ra với thông báo sau khi được chấp nhận phụ thuộc vào nhiều yếu tố.

Trong trường hợp tốt nhất, nếu thiết bị được kết nối với FCM, màn hình đang bật và không có hạn chế về việc điều tiết, thì thông báo sẽ được phân phối ngay lập tức.

Nếu thiết bị được kết nối nhưng ở chế độ Nghỉ, thì FCM sẽ lưu trữ thông báo có mức độ ưu tiên thấp cho đến khi thiết bị thoát khỏi chế độ Nghỉ. Đó cũng là nơi cờ collapse_key đóng vai trò: nếu đã có một thông báo có cùng một khoá thu gọn (và mã thông báo đăng ký) được lưu trữ và đang chờ gửi, thì thông báo cũ sẽ bị loại bỏ và tin nhắn mới sẽ thay thế (tức là thông báo cũ sẽ bị thu gọn bởi thông báo mới). Tuy nhiên, nếu bạn không đặt khoá thu gọn, cả thông báo mới và cũ đều được lưu trữ để phân phối trong tương lai.

Nếu thiết bị không được kết nối với FCM, thông báo sẽ được lưu trữ cho đến khi kết nối được thiết lập (lại tuân thủ các quy tắc về phím thu gọn). Khi một kết nối được thiết lập, FCM sẽ phân phối tất cả thông báo đang chờ xử lý đến thiết bị. Nếu thiết bị không bao giờ được kết nối lại (ví dụ: nếu thiết bị được đặt lại về trạng thái ban đầu), thì thông báo sẽ hết thời gian chờ và bị loại bỏ khỏi bộ nhớ FCM. Thời gian chờ mặc định là 4 tuần, trừ phi bạn đặt cờ time_to_live.

Để biết thêm thông tin chi tiết về việc phân phối thư:

Để biết thêm thông tin chi tiết về việc phân phối thông báo trên nền tảng Android hoặc Apple, hãy xem trang tổng quan báo cáo FCM. Trang tổng quan này ghi lại số lượng thông báo đã gửi và được mở trên thiết bị Apple và Android, cùng với dữ liệu về "lượt hiển thị" (số thông báo mà người dùng đã xem) cho ứng dụng Android.

Đối với các thiết bị Android đã bật tính năng nhắn tin qua kênh trực tiếp, nếu thiết bị không kết nối với FCM trong hơn một tháng, thì FCM vẫn chấp nhận tin nhắn nhưng sẽ loại bỏ tin nhắn đó ngay lập tức. Nếu thiết bị kết nối trong vòng 4 tuần kể từ khi bạn gửi tin nhắn dữ liệu gần đây nhất cho thiết bị, thì ứng dụng của bạn sẽ nhận được lệnh gọi lại onDeletedMessages(). Sau đó, ứng dụng có thể xử lý tình huống đúng cách, thường là bằng cách yêu cầu đồng bộ hoá toàn bộ từ máy chủ ứng dụng.

Cuối cùng, khi FCM cố gắng gửi một thông báo đến thiết bị và ứng dụng đã bị gỡ cài đặt, FCM sẽ loại bỏ thông báo đó ngay lập tức và vô hiệu hoá mã thông báo đăng ký. Các lần thử gửi thông báo đến thiết bị đó trong tương lai sẽ dẫn đến lỗi NotRegistered.

Hạn mức và điều tiết

Mục tiêu của chúng tôi là luôn chuyển phát mọi tin nhắn gửi qua FCM. Tuy nhiên, việc phân phối mọi thông báo đôi khi sẽ khiến trải nghiệm tổng thể của người dùng không tốt. Trong các trường hợp khác, chúng ta cần đặt ra giới hạn để đảm bảo rằng FCM cung cấp dịch vụ có thể mở rộng cho tất cả người gửi. Các loại giới hạn và hạn mức được mô tả trong phần này giúp chúng tôi cân bằng những yếu tố quan trọng này.

Điều tiết thông báo về sau

API HTTP phiên bản 1 đã giới thiệu hạn mức mỗi phút, mỗi dự án cho tính năng nhắn tin xuống. Hạn mức mặc định là 600 nghìn tin nhắn mỗi phút áp dụng cho hơn 99% nhà phát triển FCM, đồng thời bảo vệ độ ổn định của hệ thống và giảm thiểu tác động của các dự án có số lượng yêu cầu tăng đột biến.

Mô hình lưu lượng truy cập tăng đột biến có thể dẫn đến lỗi vượt quá hạn mức. Trong trường hợp vượt hạn mức, hệ thống sẽ phân phát mã trạng thái HTTP 429 (QUOTA_EXCEEDED) cho đến khi hạn mức được nạp lại trong phút tiếp theo. Phản hồi 429 cũng có thể được trả về trong các trường hợp quá tải, vì vậy, bạn nên xử lý dữ liệu 429 theo các đề xuất đã xuất bản.

Xin lưu ý:

• Hạn mức sau này đo lường tin nhắn, chứ không phải yêu cầu.
• Lỗi máy khách (mã trạng thái HTTP 400-499) được tính (ngoại trừ 429).
• Hạn mức được tính theo phút, nhưng các phút này không được căn chỉnh theo đồng hồ.

Hạn mức giám sát

Bạn có thể xem hạn mức, mức sử dụng và lỗi trên Google Cloud Console:

1. Chuyển đến bảng điều khiển Google Cloud
2. Chọn API và dịch vụ
3. Trong danh sách bảng, hãy chọn Firebase Cloud Messaging API
4. Chọn QUOTA & SYSTEM LIMITS (HẠN MỨC VÀ HẠN CHẾ HỆ THỐNG).

LƯU Ý: Các biểu đồ này không được căn chỉnh chính xác theo thời gian với số phút hạn mức, nghĩa là lỗi 429 có thể được phân phát khi lưu lượng truy cập có vẻ như thấp hơn hạn mức.

Yêu cầu tăng hạn mức

Trước khi yêu cầu tăng hạn mức, hãy đảm bảo rằng:

• Mức sử dụng của bạn thường xuyên ≥ 80% hạn mức trong ít nhất 5 phút liên tiếp mỗi ngày.
• Tỷ lệ lỗi ứng dụng của bạn < 5%, đặc biệt là trong thời gian lưu lượng truy cập cao điểm.
• Bạn tuân thủ các phương pháp hay nhất để gửi tin nhắn trên quy mô lớn.

Nếu đáp ứng các tiêu chí này, bạn có thể gửi yêu cầu tăng hạn mức lên đến +25% và FCM sẽ nỗ lực hết sức để thực hiện yêu cầu này (không thể đảm bảo việc tăng hạn mức).

Nếu bạn cần thêm hạn mức nhắn tin xuống dòng do một sự kiện tạm thời hoặc đợt ra mắt sắp tới, hãy yêu cầu hạn mức trước ít nhất 15 ngày để có đủ thời gian xử lý yêu cầu. Đối với các yêu cầu lớn (>18 triệu tin nhắn mỗi phút), bạn phải thông báo trước ít nhất 30 ngày. Các yêu cầu khởi chạy và sự kiện đặc biệt vẫn phải tuân theo tỷ lệ lỗi ứng dụng và các yêu cầu về phương pháp hay nhất.

Xem thêm phần Câu hỏi thường gặp về hạn mức FCM.

Giới hạn tin nhắn theo chủ đề

Tốc độ thêm/xoá gói thuê bao chủ đề bị giới hạn ở mức 3.000 QPS cho mỗi dự án.

Để biết tốc độ gửi thông báo, hãy xem phần Giới hạn tốc độ gửi thông báo.

Điều tiết fanout

Fanout tin nhắn là quá trình gửi thông báo đến nhiều thiết bị, chẳng hạn như khi bạn nhắm đến các chủ đề và nhóm, hoặc khi bạn sử dụng trình soạn thông báo để nhắm đến đối tượng hoặc phân khúc người dùng.

Sự kiện khuấy động thông báo không diễn ra ngay lập tức nên đôi khi bạn có nhiều lượt chia sẻ đang diễn ra cùng lúc. Chúng tôi giới hạn số lượng tin nhắn phân tán đồng thời trên mỗi dự án ở mức 1.000. Sau đó, chúng tôi có thể từ chối các yêu cầu phân nhánh bổ sung hoặc trì hoãn việc phân nhánh các yêu cầu cho đến khi một số yêu cầu phân nhánh đang diễn ra hoàn tất.

Tỷ lệ phân nhánh thực tế có thể đạt được chịu ảnh hưởng của số lượng dự án yêu cầu phân nhánh cùng một lúc. Tốc độ phân nhánh là 10.000 QPS cho một dự án riêng lẻ không phải là hiếm, nhưng con số đó không phải là đảm bảo và là kết quả của tổng tải trên hệ thống. Điều quan trọng cần lưu ý là dung lượng quạt ra hiện có được chia cho các dự án chứ không phải theo các yêu cầu của fanout. Vì vậy, nếu dự án của bạn có hai fanout đang diễn ra, thì mỗi fanout sẽ chỉ thấy một nửa tốc độ fanout hiện có. Bạn nên tăng tối đa tốc độ quạt chạy trong mỗi lần hoạt động.

Điều tiết tin nhắn có thể thu gọn

Như đã mô tả ở trên, tin nhắn có thể thu gọn là những thông báo không có nội dung, được thiết kế để thu gọn chồng lên nhau. Trong trường hợp nhà phát triển lặp lại cùng một thông báo cho một ứng dụng quá thường xuyên, chúng tôi sẽ trì hoãn (điều tiết) thông báo để giảm tác động đến pin của người dùng.

Ví dụ: nếu bạn gửi một lượng lớn yêu cầu đồng bộ hoá email mới đến một thiết bị, chúng tôi có thể trì hoãn yêu cầu đồng bộ hoá email tiếp theo vài phút để thiết bị có thể đồng bộ hoá ở tốc độ trung bình thấp hơn. Việc điều tiết này được thực hiện nghiêm ngặt để hạn chế tác động của pin đối với người dùng.

Nếu trường hợp sử dụng của bạn yêu cầu mẫu gửi hàng loạt có mức độ cao, thì tin nhắn không thể thu gọn có thể là lựa chọn phù hợp. Đối với các thông báo như vậy, hãy nhớ đưa nội dung vào các thông báo đó để giảm chi phí pin.

Chúng tôi giới hạn số lượng tin nhắn có thể thu gọn ở mức 20 tin nhắn cho mỗi ứng dụng trên mỗi thiết bị, với việc bổ sung 1 tin nhắn mỗi 3 phút.

Chế độ điều tiết máy chủ XMPP

Chúng tôi giới hạn tốc độ kết nối với máy chủ XMPP của FCM ở mức 400 kết nối mỗi phút trên mỗi dự án. Đây không phải là vấn đề đối với việc gửi thư, nhưng điều này rất quan trọng để đảm bảo tính ổn định của hệ thống. Đối với mỗi dự án, FCM cho phép 2500 kết nối song song.

Đối với tính năng nhắn tin ngược dòng bằng XMPP, FCM giới hạn thông báo ngược dòng ở mức 1.500.000/phút/dự án để tránh làm quá tải máy chủ đích ngược dòng.

Chúng tôi giới hạn số lượng tin nhắn truyền lên trên mỗi thiết bị ở mức 1.000/phút để bảo vệ pin khỏi tình trạng tiêu hao do hành vi xấu của ứng dụng.

Tốc độ nhắn tin tối đa cho một thiết bị

Đối với Android, bạn có thể gửi tối đa 240 tin nhắn/phút và 5.000 tin nhắn/giờ tới một thiết bị. Ngưỡng cao này nhằm cho phép lưu lượng truy cập tăng đột biến trong thời gian ngắn, chẳng hạn như khi người dùng tương tác nhanh chóng qua tính năng trò chuyện. Giới hạn này ngăn các lỗi trong việc gửi logic vô tình làm tiêu hao pin trên thiết bị.

Đối với iOS, chúng tôi sẽ trả về lỗi khi tốc độ vượt quá giới hạn của APN.

Cổng FCM và tường lửa

Nếu tổ chức của bạn có tường lửa để hạn chế lưu lượng truy cập đến hoặc từ Internet, bạn cần định cấu hình tường lửa đó để cho phép thiết bị di động kết nối với FCM để các thiết bị trên mạng của bạn nhận được thông báo. FCM thường sử dụng cổng 5228, nhưng đôi khi cũng sử dụng 443, 5229 và 5230.

Đối với các thiết bị kết nối trên mạng của bạn, FCM không cung cấp IP cụ thể vì dải IP của chúng tôi thay đổi quá thường xuyên và các quy tắc tường lửa của bạn có thể đã lỗi thời, ảnh hưởng đến trải nghiệm của người dùng. Tốt nhất là nên cung cấp các cổng 5228-5230 và 443 trong danh sách cho phép mà không có giới hạn về IP. Tuy nhiên, nếu phải có hạn chế về IP, bạn nên thêm tất cả các địa chỉ IP có trong goog.json vào danh sách cho phép. Danh sách lớn này được cập nhật thường xuyên và bạn nên cập nhật các quy tắc của mình hằng tháng. Các vấn đề do các quy định hạn chế về IP của tường lửa gây ra thường xảy ra không liên tục và khó chẩn đoán.

Chúng tôi cung cấp một bộ tên miền có thể được đưa vào danh sách cho phép thay vì địa chỉ IP. Các tên máy chủ đó được liệt kê bên dưới. Nếu bắt đầu sử dụng thêm tên máy chủ, chúng tôi sẽ cập nhật danh sách tại đây. Việc sử dụng tên miền cho quy tắc tường lửa có thể hoạt động hoặc không hoạt động trong thiết bị tường lửa.

Cổng TCP cần mở:

• 5228
• 5229
• 5230
• 443

Tên máy chủ sẽ mở:

• 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

Tường lửa Dịch địa chỉ mạng và/hoặc Kiểm tra gói có trạng thái:

Nếu mạng của bạn triển khai tính năng Dịch địa chỉ mạng (NAT) hoặc Kiểm tra gói có trạng thái (SPI), hãy triển khai thời gian chờ từ 30 phút trở lên cho các kết nối của chúng tôi qua cổng 5228-5230. Điều này cho phép chúng tôi cung cấp khả năng kết nối đáng tin cậy trong khi giảm mức tiêu thụ pin của thiết bị di động của người dùng.

Hoạt động tương tác và khả năng bỏ qua VPN

Firebase Cloud Messaging thực hiện nhiều bước để đảm bảo rằng kết nối thông báo đẩy từ điện thoại đến máy chủ đáng tin cậy và hoạt động thường xuyên nhất có thể. Việc sử dụng VPN sẽ khiến việc này trở nên phức tạp.

VPN che giấu thông tin cơ bản mà FCM cần để điều chỉnh kết nối nhằm tối đa hoá độ tin cậy và thời lượng pin. Trong một số trường hợp, VPN chủ động ngắt các kết nối có thời gian tồn tại lâu, dẫn đến trải nghiệm người dùng không tốt do bỏ lỡ hoặc trễ tin nhắn hoặc tốn nhiều pin. Khi VPN được định cấu hình để cho phép chúng tôi làm như vậy, chúng tôi sẽ bỏ qua VPN bằng cách sử dụng kết nối được mã hoá (trên mạng Wi-Fi hoặc LTE cơ sở) để đảm bảo trải nghiệm đáng tin cậy và thân thiện với pin. Việc FCM sử dụng VPN có thể bỏ qua là dành riêng cho kênh Thông báo đẩy FCM. Các lưu lượng truy cập FCM khác (chẳng hạn như lưu lượng đăng ký) sử dụng VPN nếu lưu lượng đó đang hoạt động. Khi kết nối FCM bỏ qua VPN, VPN sẽ mất các lợi ích bổ sung mà VPN có thể cung cấp, chẳng hạn như che giấu IP.

Các VPN khác nhau sẽ có phương thức riêng để kiểm soát xem có thể bỏ qua hay không. Hãy tham khảo tài liệu về VPN cụ thể của bạn để biết hướng dẫn.

Nếu VPN không được định cấu hình để có thể bỏ qua, thì Firebase Cloud Messaging sẽ sử dụng mạng VPN để kết nối với máy chủ. Điều này có thể dẫn đến khoảng thời gian thông báo bị trì hoãn và có thể dẫn đến mức sử dụng pin nhiều hơn vì Cloud Messaging hoạt động để duy trì kết nối qua kết nối VPN.

Thông tin đăng nhập

Tuỳ thuộc vào tính năng FCM mà bạn triển khai, bạn có thể cần các thông tin xác thực sau đây từ dự án Firebase: