Giải pháp gửi thông báo qua đám mây của Firebase (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 rõ các loại thông báo FCM và những việc bạn có thể làm với các loại thông báo đó.
Loại thông báo
Với FCM, bạn có thể gửi hai loại tin nhắn tới máy khách:
- Tin nhắn thông báo, đôi khi được coi là "hiển thị tin nhắn". Những thao tác này sẽ do SDK FCM xử lý tự động.
- Thông báo dữ liệu do ứng dụng xử lý.
Tin nhắn thông báo chứa một tập hợp các khoá người dùng nhìn thấy được định sẵn. 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. Tin nhắn thông báo có thể chứa 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ừ phi gửi thông báo từ bảng điều khiển của Firebase áp dụng giới hạn 1.000 ký tự.
| Trường hợp sử dụng | Cách gửi | |
|---|---|---|
| Tin nhắn thông báo | SDK FCM sẽ hiển thị thông báo tới thiết bị của người dùng cuối thay mặt cho ứng dụng khi ứng dụng đang chạy ở chế độ nền. Ngược lại, 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. Tin nhắn thông báo có một tập hợp các khoá mà người dùng nhìn thấy được xác định trước và một phần tải 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 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, hãy sử dụng SDK dành cho quản trị viên hoặc Giao thức máy chủ FCM. Trong yêu cầu gửi, hãy đặt khoá data.
|
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 tin nhắn thông báo, bao gồm cả trọng 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 còn ứng dụng khách sẽ xử lý tải trọng dữ liệu.
Tin nhắn thông báo
Để thử nghiệm hoặc để tiếp thị và tương tác lại với người dùng, bạn có thể gửi thông báo bằng bảng điều khiển của Firebase. Bảng điều khiển của 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 tin nhắn thông báo theo phương thức lập trình bằng SDK dành cho quản trị viên hoặc giao thức FCM, hãy đặt khoá notification với bộ tuỳ chọn khoá-giá trị được xác định trước cần thiết cho phần mà người dùng hiển thị trong 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ể 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 "rất hợp với" trên thiết bị:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
}
}
}
Tin nhắn 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 callback (gọi lại).
Xem tài liệu tham khảo về đối tượng thông báo Giao thức HTTP v1 để 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.
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.
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 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 việc sử dụng trường data cấp cao nhất hoặc trường phổ biến. Trường này được ứng dụng diễn giải trên tất cả các 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 hàm gọi lại.
Mã hoá thông báo dữ liệu
Lớp truyền tải Android (xem nội dung Kiến trúc FCM) sử dụng phương thức mã hoá điểm đến điểm. Tuỳ thuộc vào nhu cầu của mình, bạn có thể quyết định thêm phương thức mã hoá hai đầu vào các thông báo 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 có sẵn 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 lẫn thông qua bảng điều khiển của Firebase, bạn đều có thể gửi thông báo chứa tải trọng (không bắt buộc) của 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ả thông báo và tải trọng dữ liệu phụ thuộc vào việc ứng dụng đó đang chạy ở chế độ nền hay nền trước (về cơ bản là ứng dụng có đang hoạt động tại thời điểm nhận thông báo 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 chạy ở nền trước, ứng dụng 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 báo trên nhiều nền tảng
Cả SDK quản trị của Firebase và giao thức HTTP FCM v1 đề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. Trong đó có:
- một tập hợp các trường phổ biến sẽ được tất cả thực thể ứng dụng nhận thông báo 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 diễn giải bởi các thực thể ứng dụng chạy trên nền tảng đã chỉ định.
Quy tắc chặn dành riêng cho nền tảng cho phé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ý 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
Hãy 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ả cá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 nào, đều có thể diễn giải các trường phổ biến sau đây:
Thời điểm 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
Mỗi khi bạn chỉ muốn gửi giá trị đến một số nền tảng cụ thể, 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 và web của Apple 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 cho Apple và một cho web.
Khi bạn gửi tin nhắn bằng các tuỳ chọn gửi cụ thể, hãy sử dụng các trường dành riêng cho nền tảng để đặt các tin nhắ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, trong khi trên Apple, giá trị này được đặt là ngày hết hạn.
Ví dụ: tin nhắn thông báo có các lựa chọn gửi dành riêng cho nền tảng
Yêu cầu gửi v1 sau đây sẽ gửi một tiêu đề và nội dung thông báo phổ biến đến tất cả các nền tảng, nhưng cũng gửi một số cơ 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 lâu cho các nền tảng Android và Web, trong khi đặt mức độ ưu tiên của thông báo APN (nền tảng của Apple) ở mức thấp
- đặt các phím thích hợp để xác định kết quả khi người dùng nhấn vào thông báo trên Android và Apple —
click_actionvàcategorytương ứng.
{
"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 về HTTP v1 để 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ề việc 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.
Giao hàng
FCM cung cấp một tập hợp các tuỳ chọn gửi cụ thể cho tin nhắn gửi đến thiết bị Android và cho phép các tuỳ chọn tương tự trên các nền tảng của Apple và web. Ví dụ: hành vi thông báo "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ư không thể thu gọn và thư có thể thu gọn
Thông báo không thể thu gọn biểu thị rằng từng thông báo riêng lẻ được gửi đến thiết bị. Thông báo không thể thu gọn sẽ cung cấp một số nội dung hữu ích, trái ngược với thông báo có thể thu gọn, chẳng hạn như lệnh "ping" không có nội dung để gửi đế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 tin nhắn không thể thu gọn phổ biến là tin nhắn trò chuyện hoặc tin nhắn quan trọng. Ví dụ: trong một ứng dụng nhắn tin nhanh, bạn nên gửi mọi tin nhắn vì mỗi tin nhắn lại có nội dung riêng.
Đối với Android, bạn có thể lưu trữ tối đa 100 thông báo mà không cần thu gọn. Nếu đạt đến giới hạn, tất cả tin nhắn đã lưu trữ sẽ bị loại bỏ. Khi có kết nối mạng trở lại, 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 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ụ: ứng dụng thể thao cập nhật tỷ số mới nhất cho người dùng. Chỉ tin nhắn 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 đưa 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 đã đăng ký trong bảng điều khiển của Firebase. Máy chủ FCM có thể lưu trữ đồng thời 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 phím thu gọn riêng. Nếu bạn vượt quá con số này, FCM chỉ giữ lại 4 phím thu gọn mà không đảm bảo sẽ giữ lại các phím nào.
Theo mặc định, các tin nhắn theo chủ đề không có tải trọng đều có thể thu gọn. Tin nhắ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 công cụ nào?
Xét về mặt hiệu suất, thông báo có thể thu gọn là lựa chọn tốt hơn, 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 dùng các tin nhắn 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 riêng biệt 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á con số này, nếu không thì có thể gây ra hậu quả ngoài dự đoán.
| 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 và cần được gửi đi. | Ngoại trừ các thông báo, theo mặc định, tất cả thông báo đều không thể thu gọn. |
| Có thể gấp gọn | Khi có một thông báo mới hơn hiển thị thông báo cũ hơn có liên quan và không liên quan đến ứng dụng, FCM sẽ thay thế thông báo cũ. Ví dụ: tin nhắn dùng để bắt đầu đồng bộ hoá dữ liệu từ máy chủ hoặc nội dung thông báo lỗi thời. | Đặt thông số thích hợp trong lời mời nhắn tin của bạn:
|
Đặt mức độ ưu tiên của thông báo
Bạn có 2 lựa chọn để chỉ định mức độ ưu tiên phân phối cho các thông báo tiếp theo: mức độ ưu tiên bình thường và mức độ ưu tiên cao. Mặc dù hành vi trên các nền tảng có sự khác biệt một chút, nhưng việc gử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 thông thường sẽ được gử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ị chậm trễ. Đối với các thư ít tốn nhiều thời gian (chẳng hạn như thông báo về email mới, đồ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 bình thường.
Mức độ ưu tiên cao. FCM cố gắng gửi các thông báo có mức độ ưu tiên cao ngay lập tức ngay cả khi thiết bị đang ở chế độ Nghỉ. Tin nhắn có mức độ ưu tiên cao là dành cho nội dung có giới hạn về thời gian mà 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 HTTP v1 của FCM để thông báo cho người đăng ký tạp chí rằng có nội dung mới để 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 chi tiết dành riêng cho từng nền tảng về cách đặt mức độ ưu tiên của thông báo, hãy làm như sau:
- Tài liệu về APN
- Đặt và quản lý mức độ ưu tiên của thông báo (Android)
- Tính cấp bách của thông báo đẩy trên web
Đặt thời gian tồn tại của một 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 điều này cũng có thể thực hiện. Ví dụ: nếu nền tảng là Android, thì thiết bị có thể bị tắt, không kết nối mạng hoặc không hoạt động. Hoặc FCM có thể cố ý trì hoãn tin nhắn để ngăn ứng dụng dùng 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ữ tin nhắn và gửi đi ngay khi có thể. Mặc dù điều này là bình thường trong hầu hết các trường hợp, nhưng có một số ứng dụng có thể không bao giờ gửi được thông báo trễ. Ví dụ: nếu tin nhắn là thông báo cuộc gọi đến hoặc cuộc trò chuyện video, thì tin nhắn này 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ông báo là lời mời tham gia một sự kiện, thì thông báo đó sẽ vô ích nếu nhận được sau khi sự kiện đó đã kết thúc.
Trên Android và Web/JavaScript, bạn có thể chỉ định thời lượng tối đa của một thông báo. Giá trị phải nằm trong khoả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 theo mặc định trong khoảng thời gian tối đa là 4 tuần.
Sau đây là một số cách sử dụng có thể cho tính năng này:
- Cuộc gọi đến trong 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 ưu điểm 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 chế độ điều tiết thông báo có thể thu gọn đối với những tin nhắn có giá trị thời gian tồn tại là 0 giây.
FCM cung cấp khả năng xử lý tốt nhất các tin nhắn phải được gửi "ngay bây giờ hoặc không bao giờ". Xin lưu ý rằng giá trị time_to_live bằng 0 có nghĩa là các tin nhắn không thể gửi ngay 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 thời gian gửi thông báo là tối ưu.
Dưới đây là ví dụ về một yêu cầu có chứa 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 tin nhắn
Khi máy chủ ứng dụng đăng một tin nhắn lên FCM và nhận lại mã nhận dạng tin nhắn, điều đó không có nghĩa là tin nhắn đã được gửi tới thiết bị. Đúng hơn, trạng thái này có nghĩa là sản phẩm đã được chấp nhận để phân phối. Những 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ế điều tiết nào thì thông báo sẽ được gửi ngay lập tức.
Nếu thiết bị đã kết nối nhưng ở chế độ Nghỉ, một tin nhắn có mức độ ưu tiên thấp sẽ được FCM lưu trữ cho đến khi thiết bị không ở chế độ Nghỉ. Đó cũng chính 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ờ gửi, thì thông báo cũ sẽ bị loại bỏ và thông báo mới sẽ xuất hiện (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 phím thu gọn, thì cả tin nhắn mới và tin nhắn cũ đều sẽ được lưu trữ để gửi sau này.
Nếu thiết bị không kết nối với FCM, tin nhắn sẽ được lưu trữ cho đến khi thiết lập kết nối (lại tuân thủ các quy tắc phím thu gọn). Khi thiết lập kết nối, FCM sẽ gử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ì cuối cùng thông báo sẽ hết hạn và bị huỷ 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.
Để hiểu rõ hơn về việc gửi tin nhắn, hãy làm như sau:
Để hiểu rõ hơn về hoạt động gửi tin nhắn trên nền tảng Android hoặc Apple, hãy xem trang tổng quan báo cáo FCM. Trang này ghi lại số lượng tin nhắn đã gửi và mở trên các thiết bị Apple và Android, cùng với dữ liệu về "số lượt hiển thị" (thông báo mà người dùng nhìn thấy) đối với các ứ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, 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ừ thông báo dữ liệu gần đây nhất bạn gửi tới thiết bị, thì ứng dụng 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ử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ý. Trong tương lai, các nỗ lực gửi thông báo đến thiết bị đó sẽ dẫn đến lỗi NotRegistered.
Điều tiết và chuyển tỷ lệ
Mục tiêu của chúng tôi là luôn gửi mọi tin nhắn được gửi qua FCM. Tuy nhiên, việc phân phối mọi thông báo đôi khi sẽ mang đến trải nghiệm tổng thể không tốt cho người dùng. Trong các trường hợp khác, chúng tôi cần đưa ra các ranh giới để đảm bảo FCM cung cấp dịch vụ có thể mở rộng cho tất cả người gửi.
Chế độ điều tiết thư có thể thu gọn
Như đã mô tả ở trên, thông báo có thể thu gọn là các 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 số 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 đế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 lớn, 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 đảm bảo đư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 thông báo có thể thu gọn là 20 thông báo trên mỗi ứng dụng trên mỗi thiết bị, với tần suất nạp lại 1 thông báo mỗi 3 phút.
Chế độ điều tiết của máy chủ SAML
Chúng tôi giới hạn tốc độ kết nối với máy chủ FCM FCM ở mức 400 kết nối mỗi phút cho mỗi dự án. Điều này không ảnh hưởng đến việc gửi thông báo nhưng rất quan trọng đối với việc đả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 thông báo ngược dòng (upstream) bằng API (Giao thức truyền tải dữ liệu), FCM sẽ giới hạn thông báo ngược dòng ở tốc độ 1.500.000/phút cho mỗi dự án để tránh làm quá tải máy chủ đích đến ở luồng lên.
Chúng tôi giới hạn tốc độ thông báo ngược dòng (upstream) cho mỗi thiết bị ở mức 1.000/phút để tránh hiện tượng tiêu hao pin do hành vi xấu của ứng dụng.
Tốc độ tin nhắn tối đa tới 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 các đợt lưu lượng truy cập ngắn hạ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 ngăn lỗi khi 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 trả về lỗi khi tốc độ vượt quá giới hạn APN.
Giới hạn tin nhắn theo chủ đề
Tỷ lệ thêm/xoá gói thuê bao chủ đề được giới hạn ở 3.000 QPS cho mỗi dự án.
Để biết tần suất gửi tin nhắn, hãy xem phần Điều tiết tốc độ gửi tin nhắn.
Chế độ điều tiết Fanout
Fanout thông báo 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 mục tiêu các chủ đề và nhóm hoặc khi bạn sử dụng Trình soạn thông báo để nhắm mục tiêu đối tượng hoặc phân khúc người dùng.
Tình trạng fanout thông báo không diễn ra ngay lập tức và đôi khi, bạn có nhiều fanout được tiến hành đồng thời. Chúng tôi giới hạn số lượt chia sẻ tin nhắn đồng thời cho mỗi dự án ở mức 1.000. Sau đó, chúng tôi có thể từ chối thêm các yêu cầu khác hoặc trì hoãn các yêu cầu đó cho đến khi một số yêu cầu đã được ra mắt hoàn tất.
Tỷ lệ fanout thực tế có thể đạt được chịu ảnh hưởng của số lượng dự án yêu cầu fanout cùng lúc. Tỷ lệ fanout 10.000 QPS đối với một dự án riêng lẻ không phải là hiếm, nhưng con số đó không phải là sự đả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à khả năng lưu trữ lượng người hâm mộ hiện có được phân chia giữa các dự án chứ không phải trên các yêu cầu fanout. 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ỷ lệ fanout hiện có. Bạn nên áp dụng cách tối đa hoá tốc độ fanout ở mỗi thời điểm.
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 vào hoặc đi từ Internet, thì 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 và các thiết bị trên mạng của bạn nhận được thư. FCM thường sử dụng cổng 5228, nhưng đôi khi sử 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ể do dải IP của chúng tôi thay đổi quá thường xuyên và các quy tắc về tường lửa của bạn có thể bị lỗi thời, ảnh hưởng đến trải nghiệm của người dùng. Tốt nhất là hãy đưa 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 bạn phải đặt giới hạn IP, bạn nên đưa tất cả các địa chỉ IP được liệt kê trong tệp 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 sự cố do việc hạn chế IP tường lửa thường không liên tục và khó chẩn đoán.
Chúng tôi cung cấp một nhóm tên miền có thể đưa vào danh sách cho phép thay vì địa chỉ IP. Các tên máy chủ này được liệt kê bên dưới. Nếu bắt đầu sử dụng tên máy chủ khác, 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ổng TTCP 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 tường lửa Kiểm tra gói 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 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 qua cổng 5228-5230. Điều này cho phé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 của người dùng.
Khả năng bỏ qua và tương tác VPN
Giải pháp gửi thông báo qua đám mây của Firebase 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ủ là đáng tin cậy và hoạt động thường xuyên nhất có thể. Việc sử dụng VPN khiến công việc này trở nên phức tạp hơn.
VPN che giấu thông tin cơ bản mà FCM cần điều chỉnh kết nối để tối đa hoá độ tin cậy và thời lượng pin. Trong một số trường hợp, VPN chủ động làm hỏng các kết nối lâu dài, dẫn đến trải nghiệm người dùng kém do thông báo bị bỏ lỡ hoặc bị trễ hoặc gây tốn pin. Khi VPN được định cấu hình để cho phép chúng tôi làm điều đó, chúng tôi sẽ bỏ qua VPN bằng cách sử dụng kết nối được mã hoá (qua mạng Wi-Fi cơ sở hoặc LTE) để đảm bảo trải nghiệm đáng tin cậy và thân thiện với pin. Mức sử dụng VPN có thể bỏ qua của FCM 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 đang hoạt động. Khi kết nối FCM bỏ qua VPN, kết nối này 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ó các phương thức khác nhau để kiểm soát xem 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 để được hướng dẫn.
Nếu bạn không định cấu hình VPN là có thể bỏ qua, thì Giải pháp gửi thông báo qua đám mây của Firebase 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 một khoảng thời gian các tin nhắn bị trễ và có thể dẫn đến mức sử dụng pin nhiều hơn vì tính năng Gửi thông báo qua đám mây hoạt động để duy trì kết nối qua kết nối VPN.
Thông tin xác thực
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 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, dùng trong các yêu cầu đến điểm cuối HTTP dành cho FCM v1. Giá trị này có trong ngăn Cài đặt trên bảng điều khiển của Firebase. |
| Mã thông báo đăng ký | Một chuỗi mã thông báo duy nhất xác định từng phiên bản ứng dụng. Bạn phải có mã thông báo đăng ký để nhắn tin cho một thiết bị và nhóm thiết bị. Xin lưu ý rằng mã thông báo đăng ký phải được giữ bí mật. |
| Mã nhận dạng người gửi | Một giá trị số duy nhất được tạo khi bạn tạo dự án Firebase, có trong thẻ Gửi thông báo qua đám mây của ngăn Cài đặt trên bảng điều khiển Firebase. 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 tin nhắn đến ứng dụng. |
| Mã truy cập | Mã thông báo OAuth 2.0 ngắn hạn cho phép các yêu cầu đến API HTTP v1. 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 bài viết Cho phép gửi yêu cầu. |
| Khoá máy chủ (đối với các giao thức cũ **không 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 tin nhắn qua các giao thức cũ của Giải pháp gửi thông báo qua đám mây của Firebase (đã bị ngừng sử dụng). Lưu ý 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. FCM từ chối thiết bị Android, nền tảng Apple và khoá trình duyệt. |