Firebase Cloud Messaging (FCM) cung cấp nhiều lựa chọn và chức năng nhắn tin. Thông tin trên 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 2 loại thông báo cho khách hàng:
- Thông báo, đôi khi được coi là "thông báo hiển thị". SDK FCM sẽ tự động xử lý những việc này.
- Thông báo dữ liệu do ứng dụng xử lý.
Thông báo chứa một tập hợp 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 trọng tải dữ liệu không bắt buộc. Tải trọng tối đa cho cả hai loại thông báo là 4096 byte, trừ trường hợp gửi thông báo từ bảng điều khiển Firebase. Bảng điều khiển này áp dụng giới hạn 1000 ký tự.
| Trường hợp sử dụng | Cách gửi | |
|---|---|---|
| Thông báo | FCM SDK hiển thị thông báo cho các thiết bị của người dùng cuối thay cho ứng dụng khách khi ứng dụng này đang chạy ở chế độ nền. Nếu không, nếu ứng dụng đang chạy ở nền trước khi nhận được thông báo, thì mã của ứng dụng sẽ xác định hành vi. Thông báo có một tập hợp khoá được xác định trước mà người dùng có thể thấy và một tải trọng dữ liệu không bắt buộc gồm các cặp khoá-giá trị tuỳ chỉnh. |
|
| Thông báo dữ liệu | Ứng dụng khách chịu trách nhiệm xử lý thông báo dữ liệu. Thông báo dữ liệu chỉ có các cặp khoá-giá trị tuỳ chỉnh mà không có tên khoá dành riêng (xem bên dưới). | Trong một môi trường đáng tin cậy như
Cloud Functions
hoặc máy chủ ứng dụng của bạn, hãy sử dụng Admin SDK hoặc FCM Server Protocols. Trong yêu cầu gửi, hãy đặt khoá data.
|
Sử dụng thông báo khi bạn muốn SDK FCM xử lý việc tự động hiển thị thông báo 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 một thông báo, trong đó có phần tải 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
Để kiểm thử hoặc để tiếp thị và thu hút lại người dùng, 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 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 Admin SDK hoặc giao thức FCM, hãy đặt khoá notification với bộ khoá-giá trị được xác định trước cần thiết cho phần thông báo mà người dùng nhìn thấy của thông báo. Ví dụ: sau đây là một thông báo được định dạng JSON trong ứng dụng nhắn tin tức thời. Người dùng có thể thấy một thông báo có tiêu đề "Bồ Đào Nha gặp Đ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 trong nền. Đối với các ứng dụng ở nền trước, thông báo sẽ đượ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ụ: sau đây là một thông báo ở định dạng JSON trong cùng một ứng dụng nhắn tin tức thời như trên, trong đó thông tin được đóng gói 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 trường chung. Trường này được các ứng dụng diễn giải trên mọi nền tảng nhận được thông báo.
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ông báo dữ liệu
Tầng 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, 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, vẫn có các giải pháp bên ngoài, chẳng hạn như Capillary hoặc DTLS.
Thông báo có tải trọng dữ liệu không bắt buộc
Bằng cả phương thức lập trình hoặc thông qua bảng điều khiển Firebase, bạn có thể gửi thông báo chứa một tải trọng tuỳ chọn 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 những thông báo có 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ế độ nền hay chế độ nền trước – về cơ bản, liệu ứng dụng có đang hoạt động tại thời điểm nhận hay không.
- Khi ở chế độ nền, các ứ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 ở 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.
Sau đâ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 về thông báo của bạn đặt tất cả các trường có trong đối tượng message. Chẳng hạn như:
- một tập hợp các trường chung mà tất cả các phiên bản ứng dụng nhận được thông báo sẽ diễn giải.
- các tập hợp trường dành riêng cho nền tảng, chẳng hạn như
AndroidConfigvàWebpushConfig, chỉ được các thực thể ứng dụng diễn giải khi chạy trên nền tảng đã chỉ định.
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 rằng thông báo được xử lý đúng cách 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 chung
Sử dụng các trường phổ biến khi bạn:
- Nhắm đến các phiên bản ứng dụng trên tất cả các nền tảng – Apple, Android và web
- Gửi thông báo đến các chủ đề
Tất cả các phiên bản ứng dụng, bất kể nền tảng nào, đều có thể diễn giải các trường chung sau:
Trường hợp nên sử dụng các trường dành riêng cho nền tảng
Hãy 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 cụ thể
- Gửi các trường dành riêng cho nền tảng ngoài các trường chung
Bất cứ khi nào bạn chỉ muốn gửi giá trị đến các nền tảng cụ thể, hãy không sử dụng các trường chung mà 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 đến các nền tảng của Apple và web mà không gửi đến Android, bạn phải sử dụng 2 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ư có lựa 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 lựa chọn đó. Bạn có thể chỉ định các giá trị khác nhau cho mỗi nền tảng nếu muốn. Tuy nhiên, ngay cả khi muốn đặt cùng một giá trị 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ị này theo cách 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, trong khi trên Apple, thời gian này được đặt dưới dạng ngày hết hạn.
Ví dụ: thông báo có các lựa 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ả các nền tảng, nhưng cũng gửi một số chế độ ghi đè dành riêng cho nền tảng. Cụ thể, yêu cầu:
- đặt thời gian tồn tại dài cho các nền tảng Android và Web, đồng thời đặt mức độ ưu tiên của thông báo APNs (nền tảng Apple) thành mức thấp
- đặt 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 – lần lượt là
click_actionvà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 đầy đủ thông tin chi tiết về các khoá có trong các khối dành riêng cho nền tảng trong nội dung thông báo. Để biết thêm thông tin về cách tạo yêu cầu gửi có 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ộ lựa chọn phân phối cụ thể cho những tin nhắn được gửi đến thiết bị Android, đồng thời cho phép các lựa chọn tương tự trên nền tảng Apple và web. Ví dụ: hành vi của thông báo "có thể thu gọn" được hỗ trợ trên Android thông qua FCM's collapse_key, 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 phần mô tả trong phần này và tài liệu tham khảo có liên quan.
Thông báo không thể thu gọn và thông báo có thể thu gọn
Thông báo không thu gọn cho biết từng thông báo riêng lẻ được gửi đến thiết bị. Một thông báo không thu gọn sẽ cung cấp một số nội dung hữu ích, không giống như một thông báo có thể thu gọn như một "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 gặp của thông báo không thu gọn là thông báo trò chuyện hoặc thông báo quan trọng. Ví dụ: trong một ứng dụng nhắn tin tức thời, bạn sẽ muốn gửi mọi thông báo vì mỗi thông báo có nội dung khác nhau.
Đối với Android, giới hạn là 100 tin nhắn có thể được lưu trữ mà không bị thu gọn. Nếu đạt đến giới hạn, tất cả các thông báo đã lưu trữ sẽ bị loại bỏ. Khi thiết bị kết nối lại với Internet, 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 này một cách thích hợp, 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à thông báo có thể được thay thế bằng một thông báo mới nếu thông báo đó 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ụ: một ứng dụng thể thao cập nhật cho người dùng điểm số mới nhất. Chỉ có thông báo gần đây nhất là phù hợp.
Để đánh dấu một thông báo là có thể thu gọn trên Android, hãy thêm tham số collapse_key vào tải trọng thông báo. 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 cho mỗi thiết bị, mỗi thông báo có một khoá thu gọn riêng. Nếu bạn vượt quá số này, FCM sẽ chỉ giữ lại 4 khoá thu gọn mà không đảm bảo khoá nào sẽ được giữ lại.
Theo mặc định, các thông báo theo 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 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ề 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ố này, nếu không, điều đó có thể gây ra những hậu quả khó lường.
| Trường hợp sử dụng | Cách gửi | |
|---|---|---|
| Không thể thu gọn | Mọi thông báo đều quan trọng đối với ứng dụng khách và cần được gửi. | Ngoại trừ thông báo, theo mặc định, tất cả các thông báo đều không thể thu gọn. |
| Có thể thu gọn | Khi có một thông báo mới hơn khiến một thông báo cũ hơn, có liên quan trở nên không liên quan đến ứng dụng khách, FCM sẽ thay thế thông báo cũ hơn. Ví dụ: các thông báo dùng để bắt đầu đồng bộ hoá dữ liệu từ máy chủ hoặc các thông báo đã lỗi thời. | Đặt tham số thích hợp trong yêu cầu thông báo:
|
Đặt mức độ ưu tiên của thư
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 truyền xuống: mức độ ưu tiên bình thường và mức độ ưu tiên cao. Mặc dù có sự khác biệt nhỏ về hành vi trên 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 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 gửi ngay khi ứng dụng chạy ở nền trước. Đối với các ứng dụng chạy ở chế độ nền, việc gửi có thể bị chậm trễ. Đối với những thông báo ít khẩn cấp hơn, chẳng hạn như thông báo về email mới, việc giữ cho giao diện người dùng của bạn luôn đồng bộ hoá hoặc đồng bộ hoá dữ liệu ứng dụng ở chế độ nền, hãy chọn mức độ ưu tiên phân phối bình 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ị ở 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 bình 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ó nội dung mới có thể tả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 cụ thể theo nền tảng về cách đặt mức độ ưu tiên cho 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)
- Mức độ khẩn cấp của thông báo đẩy trên web
Các trường hợp sử dụng quan trọng trong cuộc sống
Các 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 mà 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 huỷ hoại môi trường (chẳng hạn như việc vận hành cơ sở hạt nhân, hệ thống kiểm soát không lưu hoặc hệ thống trợ sinh). Mọi hành vi sử dụng như vậy đều bị nghiêm cấm theo 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 do việc không tuân thủ của bạn gây ra. 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 hay tính năng nào hoặc quyền truy cập của bạn vào đó, vì bất kỳ lý do gì và tại bất kỳ thời điểm nào mà không phải chịu trách nhiệm pháp lý hoặc nghĩa vụ khác 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 gửi tin nhắn ngay sau khi tin nhắn được gửi. Tuy nhiên, không phải lúc nào bạn cũng có thể làm được điều này. Ví dụ: nếu nền tảng là Android, thì thiết bị có thể đã tắt, không có mạng hoặc không dùng được. Hoặc FCM có thể cố ý trì hoãn các 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à gửi thông báo đó ngay khi có thể. Mặc dù điều này không sao trong hầu hết các trường hợp, nhưng có một số ứng dụng mà thông báo đến muộn cũng có thể không bao giờ được gửi. Ví dụ: nếu thông báo là thông báo về cuộc gọi đến hoặc cuộc gọi 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 là lời mời tham dự một sự kiện, thì thông báo đó sẽ vô ích nếu bạn nhận được sau khi sự kiện kết thúc.
Trên Android và Web/JavaScript, bạn có thể chỉ định tuổi thọ tối đa của một thông báo. Giá trị phải là khoảng thời gian 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. Những yêu cầu không có trường này sẽ mặc định là khoảng thời gian tối đa 4 tuần.
Dưới đây là một số cách có thể sử dụng tính năng này:
- Cuộc gọi đến qua tính năng trò chuyện video
- Sự kiện lời mời hết hạn
- 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 một 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ó giá trị thời gian tồn tại là 0 giây.
FCM cung cấp cách xử lý tốt nhất cho những thông báo phải được gửi "ngay lập tức". Xin lưu ý rằng giá trị time_to_live bằng 0 có nghĩa là những thông báo không được gửi ngay sẽ bị loại bỏ. Tuy nhiên, vì những 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ễ thấp nhất khi gửi thông báo.
Sau đâ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"
}
}
}
}Thời gian tồn tại của một thông báo
Khi một máy chủ ứng dụng đăng một thông báo lên FCM và nhận lại một mã nhận dạng 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 đó, điều này có nghĩa là yêu cầu đã được chấp nhận để phân phối. Đ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ế nào về việc điều tiết, thì thông báo sẽ được gử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ữ một thông báo có mức độ ưu tiên thấp cho đến khi thiết bị thoát khỏi chế độ Nghỉ. Đó là lúc cờ collapse_key đóng vai trò: nếu đã có một thông báo có cùng khoá thu gọn (và mã thông báo đăng ký) được lưu trữ và đang chờ được gửi, thì thông báo cũ sẽ bị loại bỏ và thông báo mới sẽ thay thế thông báo cũ (tức là thông báo mới sẽ thu gọn thông báo cũ). 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ữ để gửi trong tương lai.
Nếu thiết bị không 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 (vẫn tuân theo các quy tắc về khoá thu gọn). Khi một kết nối được thiết lập, FCM sẽ gửi tất cả tin nhắn đang chờ xử lý đến thiết bị. Nếu thiết bị không bao giờ 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.
Cách xem thêm thông tin chi tiết về việc gửi tin nhắn:
Để hiểu rõ hơn về việc gửi tin nhắn trên nền tảng Android hoặc Apple, hãy xem FCM trang tổng quan báo cáo. Trang tổng quan này ghi lại số lượng tin nhắn đã gửi và đã mở trên thiết bị Apple và Android, cùng với dữ liệu về "lượt hiển thị" (thông báo mà người dùng nhìn thấy) cho các ứng dụng Android.
Đối với các thiết bị Android đã bật tính năng nhắn tin trực tiếp qua kênh, nếu thiết bị không kết nối với FCM trong hơn một tháng, FCM vẫn chấp nhận tin nhắn nhưng sẽ loại bỏ ngay lập tức. Nếu thiết bị kết nối trong vòng 4 tuần kể từ tin nhắn dữ liệu gần đây nhất mà bạn đã gửi 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 này một cách thích hợp, 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ý. Những lần sau khi bạn cố gắng gửi tin nhắn đến thiết bị đó sẽ dẫn đến lỗi NotRegistered.
Điều chỉnh và hạn mức
Mục tiêu của chúng tôi là luôn phân phối mọi thông báo được gửi qua FCM. Tuy nhiên, việc gửi mọi thông báo đôi khi sẽ mang lại trải nghiệm tổng thể không tốt cho người dùng. Trong những trường hợp khác, chúng tôi cần cung cấp các giới hạn để đảm bảo FCM cung cấp dịch vụ có thể mở rộng cho tất cả người gửi. Các loại hạn mức và hạn ngạch đượ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.
Hạn chế số lượng tin nhắn truyền xuống
API HTTP phiên bản 1 đã giới thiệu hạn mức mỗi phút cho mỗi dự án đối với hoạt động nhắn tin xuôi dòng. Hạn mức mặc định là 600.000 thông báo mỗi phút, đủ cho hơn 99% nhà phát triển FCM, đồng thời bảo vệ tính ổn định của hệ thống và giảm thiểu tác động của các dự án có mức sử dụng tăng đột biến.
Mô hình lưu lượng truy cập đột biến có thể dẫn đến lỗi vượt quá hạn mức. Trong trường hợp vượt quá 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 vào phút tiếp theo. Phản hồi 429 cũng có thể được trả về trong trường hợp quá tải, vì vậy, bạn nên xử lý các phản hồi 429 theo các đề xuất đã xuất bản.
Xin lưu ý rằng:
- Hạn mức hạ lưu đo lường thư chứ không đo lường yêu cầu.
- Lỗi phía 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 tính theo thời gian đồ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:
- Chuyển đến bảng điều khiển Google Cloud
- Chọn API và dịch vụ
- Trong danh sách bảng, hãy chọn Firebase Cloud Messaging API
- Chọn HẠN MỨC VÀ GIỚI HẠN 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 hạn mức phút, tức là có thể xảy ra lỗi 429 khi lưu lượng truy cập có vẻ 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 tục mỗi ngày.
- Bạn có tỷ lệ lỗi phía máy khách < 5%, đặc biệt là trong thời gian lưu lượng truy cập cao nhất.
- Bạn tuân thủ các phương pháp hay nhất để gửi thông báo 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 để đáp ứng yêu cầu (không đảm bảo tăng hạn mức).
Nếu bạn cần thêm hạn mức tin nhắn xuôi dòng do sắp ra mắt hoặc sự kiện tạm thời, hãy yêu cầu hạn mức ít nhất 15 ngày trước để có đủ thời gian xử lý yêu cầu. Đối với các yêu cầu lớn (>18 triệu thông báo 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 về sự kiện đặc biệt và việc ra mắt vẫn phải tuân thủ các yêu cầu về tỷ lệ lỗi của ứng dụng và các phương pháp hay nhất.
Bạn cũng có thể xem 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á lượt đăng ký 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 Điều tiết Fanout.
Điều tiết fanout
Phân phối tin nhắn là quá trình gửi một tin nhắn đế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ảo thông báo để nhắm đến đối tượng hoặc phân khúc người dùng.
Quá trình truyền tin nhắn không diễn ra ngay lập tức, vì vậy, đôi khi bạn có nhiều quá trình truyền tin nhắn đang diễn ra đồng thời. Chúng tôi giới hạn số lượng thông báo truyền tin đồng thời cho mỗi dự án là 1.000. Sau đó, chúng tôi có thể từ chối các yêu cầu truyền tin bổ sung hoặc hoãn truyền tin các yêu cầu cho đến khi một số yêu cầu truyền tin đang diễn ra hoàn tất.
Tốc độ phân phối 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 phối cùng một lúc. Tốc độ phân phối 10.000 QPS cho một dự án riêng lẻ không phải là hiếm, nhưng con số đó không được đả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 phân phối có sẵn được chia cho các dự án chứ không phải cho các yêu cầu phân phối. Vì vậy, nếu dự án của bạn có 2 fanout đang diễn ra, thì mỗi fanout sẽ chỉ thấy một nửa tốc độ fanout có sẵn. Cách được đề xuất để tối đa hoá tốc độ phân phối là chỉ có một hoạt động phân phối đang diễn ra tại một thời điểm.
Điều tiết thông báo có thể thu gọn
Như mô tả ở trên, thông báo 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) các 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 số lượng lớn yêu cầu đồng bộ hoá email mới đến một thiết bị duy nhất, chúng tôi có thể trì hoãn yêu cầu đồng bộ hoá email tiếp theo trong 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 đến pin mà người dùng gặp phải.
Nếu trường hợp sử dụng của bạn yêu cầu các mẫu gửi hàng loạt có tốc độ cao, thì thông báo không thu gọn có thể là lựa chọn phù hợp. Đối với những thông báo như vậy, hãy nhớ đưa nội dung vào những thông báo đó để giảm chi phí pin.
Chúng tôi giới hạn số lượng thông báo có thể thu gọn ở mức 20 thông báo cho mỗi ứng dụng trên mỗi thiết bị, với tần suất 1 thông báo sau mỗi 3 phút.
Tốc độ gửi tin nhắn tối đa đến 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ờ đến 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 cuộc trò chuyện. Giới hạn này giúp ngăn chặn các lỗi trong logic gửi 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 APNs.
FCM cổng 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 đi 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 nhằm giúp các thiết bị trên mạng của bạn nhận được tin nhắn. FCM thường dùng cổng 5228, nhưng đôi khi dùng cổ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ể trở nên lỗi thời, ảnh hưởng đến trải nghiệm của người dùng. Tốt nhất là bạn nên cho phép các cổng 5228-5230 và 443 vào danh sách cho phép mà không có hạn chế về IP. Tuy nhiên, nếu phải có một quy tắc hạn chế IP, bạn nên đưa tất 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 quy tắc hạn chế IP của tường lửa gây ra thường 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ủa bạn.
Các cổng TCP cần mở:
- 5228
- 5229
- 5230
- 443
Tên máy chủ lưu trữ cần 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 tin 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 tin 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ác cổng 5228 – 5230. Điều này giúp chúng tôi cung cấp 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 mà người dùng sử dụng.
Tương tác với VPN và khả năng bỏ qua
Firebase Cloud Messaging thực hiện nhiều bước để đảm bảo rằng kết nối nhắn tin đẩy từ điện thoại đến máy chủ luôn đáng tin cậy và có sẵn thường xuyên nhất có thể. Việc sử dụng VPN sẽ gây khó khăn cho hoạt động này.
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 duy trì lâu dài, dẫn đến trải nghiệm người dùng kém do tin nhắn bị bỏ lỡ hoặc bị trễ hoặc tiêu hao 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 một kết nối được mã hoá (qua Wi-Fi hoặc LTE của mạng cơ sở) để đảm bảo trải nghiệm đáng tin cậy và tiết kiệm pin. Việc FCM sử dụng VPN có thể bỏ qua chỉ dành riêng cho kênh Thông báo đẩy FCM. Lưu lượng truy cập FCM khác, chẳng hạn như lưu lượng truy cập đăng ký, sẽ sử dụng VPN nếu VPN đang hoạt động. Khi kết nối FCMbỏ qua VPN, kết nối đó sẽ mất đi những lợi ích bổ sung mà VPN có thể mang lại, chẳng hạn như che giấu địa chỉ IP.
Mỗi VPN sẽ có một phương thức riêng để kiểm soát việc có thể bỏ qua VPN 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 tình trạng tin nhắn bị trễ trong một khoảng thời gian và có thể khiến pin tiêu hao 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 những tính năng FCM mà bạn triển khai, bạn có thể cần những thông tin đăng nhập sau đây từ dự án Firebase của mình:
| Mã dự án | Giá trị nhận dạng duy nhất cho dự án Firebase của bạn, được dùng trong các yêu cầu đến điểm cuối HTTP FCM v1. Giá trị này có trong ngăn Firebase console Settings (Cài đặt) của. |
| Mã thông báo đăng ký | Một chuỗi mã thông báo duy nhất giúp xác định từng phiên bản ứng dụng khách. Bạn cần có mã thông báo đăng ký để gửi tin nhắn cho một thiết bị và nhóm thiết bị. Xin lưu ý rằng bạn phải giữ bí mật mã thông báo đăng ký. |
| Mã nhận dạng người gửi | Một giá trị bằng số duy nhất được tạo khi bạn tạo dự án Firebase, có trong thẻ Cloud Messaging của bảng điều khiển Firebase trong ngăn Cài đặt. Mã nhận dạng người gửi được dùng để xác định từng người gửi có thể gửi thông báo đến ứng dụng khách. |
| Mã truy cập | Mã thông báo OAuth 2.0 có thời hạn ngắn, cho phép các yêu cầu đến HTTP API phiên bản 1. Mã thông báo này được liên kết với một tài khoản dịch vụ thuộc dự án Firebase của bạn. Để tạo và xoay vòng mã truy cập, hãy làm theo các bước được mô tả trong phần Uỷ quyền yêu cầu gửi. |
| Khoá máy chủ (đối với các giao thức cũ **không được dùng nữa**) | Khoá máy chủ cho phép máy chủ ứng dụng của bạn truy cập vào các dịch vụ của Google, bao gồm cả việc gửi thông báo qua các giao thức cũ Firebase Cloud Messaging không dùng nữa. Quan trọng: Đừng thêm khoá máy chủ vào bất kỳ vị trí nào trong mã ứng dụng của bạn. Ngoài ra, hãy nhớ chỉ sử dụng khoá máy chủ để uỷ quyền cho máy chủ ứng dụng của bạn. Android, nền tảng Apple và các khoá trình duyệt đều bị FCM từ chối. |