Giải pháp gửi thông báo qua đám mây của Firebase (FCM) cung cấp nhiều tuỳ 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õ nhiều loại thông báo FCM và những việc bạn có thể làm với những 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 cho khách hàng:
- Nội dung thông báo, đôi khi được coi là "tin nhắn hiển thị". Những vấn đề này được SDK FCM xử lý tự động.
- Thông báo dữ liệu do ứng dụng xử lý.
Các nội dung thông báo chứa một tập hợp các phím hiển thị cho người dùng đị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. Nội dung thông báo có thể chứa tải trọng 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, ngoại trừ khi gửi thông báo từ bảng điều khiển của Firebase (thực thi 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 | FCM SDK thay mặt cho ứng dụng khách hiển thị thông báo cho thiết bị của người dùng cuối 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. Các nội dung thông báo có một tập hợp các khoá mà người dùng nhìn thấy được 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 sẽ chịu trách nhiệm xử lý thông báo về 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, chẳng hạn như
Chức năng đám mây hoặc máy chủ ứng dụng của bạn, 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.
|
Hãy sử dụng nội dung thông báo khi bạn muốn SDK FCM tự động xử lý việc 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 bạn.
FCM có thể gửi tin nhắn thông báo bao gồm cả 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 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 thông báo theo phương thức lập trình bằng SDK quản trị viên hoặc giao thức FCM, hãy đặt khoá notification với 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ị cho người dùng của nội dung thông báo. Ví dụ: đây là một 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!"
}
}
}
Tin nhắn thông báo sẽ được gửi đến khay thông báo khi ứng dụng đang chạy trong nền. Đối với các ứng dụng ở nền trước, thông báo được xử lý bằng hàm callback.
Hãy 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 hiện có để tạo thông báo thông báo.
Thông báo dữ liệu
Đặt khoá thích hợp với 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 ở 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 phổ biến hoặc cấp cao nhất. Trường này được khách hà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 bằng hàm callback.
Mã hoá thông báo dữ liệu
Tầng truyền tải Android (xem kiến trúc FCM) sử dụng phương thức mã hoá điểm này đến điểm khác. 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 thông báo 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 của 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 các thông báo bao gồm cả tải trọng 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 hay không.
- Khi ở chế độ nền, các ứng dụng 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.
Đây là một thông báo theo đị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ả SDK quản trị của Firebase 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 trường phổ biến để tất cả thực thể ứng dụng nhận được 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.
Các quy tắc chặn 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 thông thường khi bạn:
- Nhắm đến các phiên bản ứng dụng trên tất cả nền tảng – Apple, Android và web
- Đang gửi tin nhắn đến các 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:
Trường hợp 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 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ể, khô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 đến các nền tảng và web của Apple nhưng không gửi cho Android, bạn phải sử dụng 2 nhóm trường riêng biệt: một trường dành cho Apple và một trường 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ị này được đặt là ngày hết hạn.
Ví dụ: nội dung thông báo có các lựa chọn gửi dành riêng cho từng nền tảng
Yêu cầu gửi bằng v1 sau đây sẽ gửi một tiêu đề và nội dung thông báo chung cho tất cả nền tảng, đồng thời 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 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
- đặt các phím thích hợp để xác định kết quả của một lần 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"
}
}
}
}
Xem tài liệu tham khảo về HTTP v1 để biết 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 chứa nội dung thông báo, 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 các tin nhắn gửi đến thiết bị Android, đồng thời cho phép các tuỳ chọn tương tự trên web và nền tảng của Apple. Ví dụ: hành vi thông báo "có thể thu gọn" được hỗ trợ trên Android qua collapse_key của FCM, trên Apple thông qua apns-collapse-id và trên JavaScript/Web 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.
Tin nhắn không thể thu gọn và thu gọn
Thông báo không thể thu gọn biểu thị rằng từng tin nhắn riêng lẻ sẽ được gửi đến thiết bị. Một 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 một thông báo có thể thu gọn, chẳng hạn như một thông báo không có nội dung để "ping" ứ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ẽ cầ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, tất cả tin nhắn đã lưu trữ sẽ bị loại bỏ. Khi 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à 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 được 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 điểm số mới nhất cho người dùng. Chỉ thư gần đây nhất là có liên quan.
Để đá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 phần tải trọng của tin nhắn. 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 tin nhắn có thể thu gọn 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, 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, tin nhắn chủ đề không có tải trọng nào có thể thu gọn được. Các 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?
Thông báo có thể thu gọn là lựa chọn tốt hơn từ quan điểm hiệu suất, miễn là ứng dụng của bạn không cần phải 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 lưu ý 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á 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 khách và cần được gửi đi. | Ngoại trừ nội dung thông báo, theo mặc định, bạn không thể thu gọn tất cả tin nhắn. |
| Có thể gấp gọn | Khi có thông báo mới hơn hiển thị một thông báo cũ có liên quan và không liên quan đến ứng dụng khách, thì FCM sẽ thay thế thông báo cũ. Ví dụ: thông báo dùng để bắt đầu quá trình đồ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ư
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 hơi khác trên các nền tảng, nhưng việc gửi các thông báo thông thường và có mức độ ưu tiên 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 khi ứng dụng đang chạy trên nền trước. Đối với các ứng dụng chạy trong nền, việc phân phối có thể bị chậm trễ. Đối với các thư ít tốn thời gian hơn, 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 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ị đ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 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 v1 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 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ư (Android)
- Sự cấp bách của thông báo đẩy trên web
Đặt thời gian tồn tại của thư
FCM thường gửi tin nhắn ngay sau khi được gửi. Tuy nhiên, điều này không phải lúc nào cũng khả thi. Ví dụ: nếu nền tảng là Android, thì thiết bị có thể bị tắt, không có mạng hoặc không hoạt động. Hoặc FCM có thể chủ động trì hoãn thông báo để ngăn một ứng dụng sử dụng quá nhiều tài nguyên cũng như ả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 tin nhắn đó 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 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 đó chỉ có ý nghĩa trong một khoảng thời gian ngắn trước khi cuộc gọi bị chấm dứt. Hoặc nếu tin nhắn là lời mời tham gia một sự kiện, thì sẽ không có tác dụng gì 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 gian tồn tại tối đa của một thông báo. Giá trị này 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. Các yêu cầu không chứa trường này sẽ được đặt mặc định thành khoảng thời gian tối đa là 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 trong trò chuyện video
- Sự kiện 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 thông báo là FCM không áp dụng quy trình điều tiết tin nhắn có thể thu gọn cho các tin nhắn có giá trị thời gian tồn tại là 0 giây.
FCM hỗ trợ khả năng xử lý tốt nhất đối với những tin nhắn phải được gửi "ngay bây giờ hoặc không bao giờ". Lưu ý rằng giá trị time_to_live bằng 0 có nghĩa là các thư không thể gửi ngay lập tức sẽ bị huỷ. Tuy nhiên, vì các thông báo đó không bao giờ được lưu trữ, nên phương thức này sẽ có độ trễ tốt nhất để gửi tin nhắn 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"
}
}
}
}
Thời gian tồn tại của tin nhắn
Khi máy chủ ứng dụng đăng một thông báo lên FCM và nhận lại mã nhận dạng của tin nhắn, thì điều đó không có nghĩa là thông báo đó đã được gửi đến thiết bị. Đúng hơn, điều này có nghĩa là đơn đặt hàng đã được chấp nhận để giao hàng. Những gì sẽ 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 sẽ 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ữ thông báo có mức độ ưu tiên thấp cho đến khi thiết bị hết 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ả tin nhắn mới và tin nhắn cũ đều được lưu trữ để gửi trong tương lai.
Nếu thiết bị chưa được kết nối với FCM, thông báo sẽ được lưu trữ cho đến khi thiết lập kết nối (một lần nữa tuân thủ các quy tắc khoá 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ý tới 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ông tin chi tiết hơn về quá trình gửi thư:
Để biết thêm thông tin chi tiết về cách gửi tin nhắn trên các 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 tin nhắn được 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) đố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ị chưa 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 thông báo dữ liệu gần đây nhất đến 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 gửi tin nhắn đến thiết bị đó trong tương lai sẽ dẫn đến lỗi NotRegistered.
Điều tiết và hạn mức
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 gửi mọi thông báo đôi khi dẫn đế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 cung cấp 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. 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 các 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 đã ra mắt các hạn mức theo phút, theo từng dự án đối với hoạt động nhắn tin tiếp theo. Hạn mức mặc định là 600 nghìn tin nhắn mỗi phút bao gồm 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ó gai.
Mẫu 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 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 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.
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 ứng dụng khách (mã trạng thái HTTP 400-499) được tính (không bao gồm 429 giây).
- Hạn mức được tính theo phút, nhưng những phút này không khớp với đồ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 API nhắn tin qua đám mây của Firebase
LƯU Ý: Các biểu đồ này không được căn chỉnh chính xác về thời gian theo phút hạn mức, nghĩa là 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 đạt ≥ 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 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 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 tới hơn 25% và FCM sẽ cố gắng hết sức để đáp ứng yêu cầu đó (không thể đảm bảo mức tăng).
Nếu bạn cần thêm hạn mức nhắn tin về sau do sắp phát hành hoặc do sự kiện tạm thời, hãy yêu cầu hạn mức của bạn 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 (trên 18 triệu tin nhắn mỗi phút), bạn cần nhận thông báo ít nhất 30 ngày. Các đợt ra mắt và yêu cầu 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ề các phương pháp hay nhất.
Xem thêm Câu hỏi thường gặp về hạn mức FCM.
Giới hạn tin nhắn theo chủ đề
Tỷ lệ thêm/xoá gói thuê bao chủ đề được giới hạn ở mức 3.000 QPS cho mỗi dự án.
Để biết tốc độ gửi tin nhắn, hãy xem phần Điều tiết Fanout.
Điều tiết quạt
Ra mắt 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 đế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.
Lượt chuyển đổi 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 người gửi thông báo đồng thời cho mỗi dự án ở mức 1.000. Sau đó, chúng tôi có thể từ chối các yêu cầu chia sẻ thêm hoặc trì hoãn việc triển khai yêu cầu đó cho đến khi hoàn tất một số yêu cầu đang tiến hành.
Tỷ lệ người hâm mộ thực tế có thể đạt được chịu ảnh hưởng của số lượng dự án yêu cầu có người hâm mộ cùng một lúc. Tỷ lệ fanout 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à sự đảm bảo mà là do 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ó 2 người hâm mộ đang diễn ra, thì mỗi lượt hâm mộ sẽ chỉ thấy một nửa tỷ lệ người hâm mộ 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 thư 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 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 một 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ế mức 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 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 việc gửi một loạt tin nhắn có thể thu gọn là 20 tin nhắn cho mỗi ứng dụng trên mỗi thiết bị, trong đó mỗi 3 phút sẽ nạp lại 1 tin nhắn.
Điều tiết máy chủ XMPP
Chúng tôi giới hạn tốc độ kết nối mà bạn có thể kết nối với máy chủ XMPP FCM ở mức 400 kết nối mỗi phút cho mỗi dự án. Đây không phải là vấn đề khi gửi thông báo, nhưng điều quan trọng là đảm bảo tính ổn định của hệ thống. Đối với mỗi dự án, FCM cho phép kết nối song song 2500 kết nối.
Đối với thông báo luồng ngược (upstream) bằng XMPP, FCM giới hạn thông báo luồng ngược dòng (upstream) ở mức 1.500.000/phút cho mỗi dự án để tránh làm quá tải máy chủ đích của luồng tải lên.
Chúng tôi giới hạn tốc độ 1.000 thông báo truyền trực tuyến trên mỗi thiết bị/phút để ngăn chặn hành vi xấu trong ứng dụng gây tiêu hao pin.
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 tạo ra các đợt tăng 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 qua cuộc trò chuyện. Giới hạn này ngăn chặ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 của bạn
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 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 nhằm giúp các thiết bị trong 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 sẽ 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ể bị lỗi thời, ảnh hưởng đến trải nghiệm 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 sự cố do các hạn chế về IP tường lửa thường xuất hiện không liên tục và khó chẩn đoán.
Chúng tôi cung cấp một tập hợp các 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 các tên máy chủ bổ sung, 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 sẽ 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 trạng thái (stateful Packet Inspection):
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ối thiểu là 30 phút cho các kết nối của chúng ta qua các 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 vẫn giảm mức tiêu thụ pin trên 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
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ủ đá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.
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 tồn tại lâu, dẫn đến trải nghiệm người dùng kém do bỏ lỡ hoặc bị trì hoãn thông báo hay chi phí pin cao. Khi định cấu hình VPN để cho phép chúng tôi làm như vậy, chúng tôi bỏ qua VPN bằng cách sử dụng một kết nối đã mã hoá (qua Wi-Fi mạng cơ sở hoặc LTE) để đảm bảo trải nghiệm đáng tin cậy, tiết kiệm pin. FCM sử dụng VPN có thể bỏ qua 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 đă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 để được hướng dẫn.
Nếu bạn không định cấu hình VPN để 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 khoảng thời gian tin nhắn bị trì hoãn và có thể dẫn đến mức sử dụng pin nhiều hơn vì Giải pháp gửi thông báo qua đám mây cố gắ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 những 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 FCM v1. Giá trị này có trong ngăn Bảng điều khiển Cài đặt của Firebase. |
| Mã thông báo đăng ký | Chuỗi mã thông báo duy nhất xác định từng phiên bản ứng dụng khách. Bạn phải có mã thông báo đăng ký để nhắn tin theo nhóm một thiết bị và thiết bị. Xin lưu ý rằng mã thông báo đăng ký phải được giữ bí mật. |
| Mã người gửi | Một giá trị số duy nhất được tạo khi bạn tạo dự án Firebase, có sẵn 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 của 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 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 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**) | Một 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 tính năng Giải pháp gửi thông báo qua đám mây của Firebase (không được dùng nữa). Lưu ý quan trọng: Đừng đưa khoá máy chủ vào bất cứ đâu 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. FCM từ chối các khoá của nền tảng Android, Apple và trình duyệt. |