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 nhắn tin và khả năng. Thông tin trên trang này nhằm giúp bạn nắm được các loại thông báo FCM và nội dung có thể làm với chúng.
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 khoá-giá trị tuỳ chỉnh do người dùng xác định cặp. Nội dung thông báo có thể chứa thông tin tuỳ chọn tải trọng dữ liệu. 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 (sẽ thực thi 1.000 ký tự tối đa.
| Trường hợp sử dụng | Cách gửi | |
|---|---|---|
| Tin nhắn thông báo | FCM SDK hiển thị thông báo cho thiết bị của người dùng cuối thay mặt cho ứng dụng khách 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, 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 phím hiển thị cho người dùng được xác định trước và một tải trọng dữ liệu không bắt buộc của 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 như
Hàm đá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 của máy chủ FCM. Trong yêu cầu gửi, hãy thiết lập 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ị tự động gửi thông báo khi ứng dụng của bạn đang chạy trong 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ả dữ liệu không bắt buộc tải trọng. Trong những trường hợp như vậy, FCM sẽ xử lý việc hiển thị thông báo và ứ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à 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 của Firebase. Bảng điều khiển của Firebase cung cấp Thử nghiệm A/B để giúp bạn tinh chỉnh và cải thiện thông điệp tiếp thị.
Để gửi thư 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
FCM, hãy đặt khoá notification bằng
tập hợp các tuỳ chọn khoá-giá trị cần thiết được xác định trước để người dùng nhìn thấy
của nội dung thông báo. Ví dụ: đây là định dạng JSON
tin nhắn thông báo trong ứng dụng IM. Người dùng có thể thấy
thông báo có tiêu đề "Bồ Đào Nha đấu với Đan Mạch" và văn bản
"rất phù hợp!" 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ế độ 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.
Xem đối tượng thông báo Giao thức HTTP v1 tài liệu tham khảo để xem danh sách đầy đủ các khoá được xác định trước có sẵn cho thông báo toà nhà tin nhắn.
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 khách.
Ví dụ: đây là
Tin nhắn theo định dạng JSON trong cùng một ứng dụng nhắn tin nhanh như ở trên,
nơi thông tin được gói gọn trong khoá data chung và
ứng dụng khách cầ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 diễn giải bởi khách hàng 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 callback.
Mã hoá thông báo dữ liệu
Lớp truyền tải Android (xem cấu trúc FCM) sử dụng mã hoá điểm này. Tùy thuộc vào của mình, bạn có thể quyết định thêm phương thức 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ó những giải pháp bên ngoài như dưới dạng 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
Bạn có thể gửi thông báo theo cách lập trình hoặc thông qua bảng điều khiển của Firebase thông báo có chứa tải trọng không bắt buộc gồm các cặp khoá-giá trị tuỳ chỉnh. Ngang bằng 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 chứa cả thông báo và dữ liệu phụ thuộc vào việc ứng dụng chạy ở chế độ nền hay nền trước – về cơ bản, cho dù ứng dụng đó có đang hoạt động tại thời điểm biên 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 ở nền trước, ứng dụng nhận được một thông báo có sẵn 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 v1 đều cho phép thông báo của bạn
yêu cầu đặt tất cả các trường có sẵn trong
message
. Điều này bao gồm:
- một tập hợp trường chung để tất cả phiên bản ứng dụng diễn giải nhận được tin nhắn.
- tập hợp các 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 phiên bản ứng dụng chạy trên nền tảng đã chỉ định.
Các quy tắc chặn theo nền tảng cụ thể giúp bạn linh hoạt tuỳ chỉnh thông báo cho nền tảng khác nhau để đảm bảo rằng chúng được xử lý chính xác khi nhận được. Chiến lược phát hành đĩa đơn Phần phụ trợ FCM sẽ xem xét tất cả các tham số được chỉ định và tuỳ chỉnh 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ủ đề
Tất cả phiên bản ứng dụng, bất kể nền tảng, đều có thể diễn giải các thuật ngữ phổ biến sau trường:
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ể, đừng sử dụng các trường chung; sử dụng các trường dành riêng cho nền tảng. Ví dụ: để gửi thông báo chỉ dành cho các nền tảng và web của Apple nhưng không dành cho Android, bạn phải sử dụng hai nhóm một trường cho Apple và một trường cho web.
Khi bạn gửi thông báo bằng những các lựa chọn phân phối, sử dụng các trường dành riêng cho nền tảng để đặt chúng. Bạn có thể chỉ định các giá trị khác nhau cho mỗi nền tảng nếu bạn muốn. Tuy nhiên, ngay cả khi bạn muốn đặt cùng một giá trị trên nền tảng, bạn phải sử dụng các trường dành riêng cho nền tảng. Lý do là 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 là thời gian hết hạn được đặt trên Android tính bằng giây, còn trên Apple, thời gian hết hạn được đặt là date 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 đề thông báo chung và nội dung cho 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
- đặ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"
}
}
}
}
Hãy xem tài liệu tham khảo về HTTP phiên bản 1 để biết toàn bộ thông tin chi tiết về các khoá có sẵn 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ề tạo các yêu cầu gửi chứa nội dung thư, xem Tạo yêu cầu gửi.
Phương thức giao hàng
FCM cung cấp một tập hợp cụ thể các tuỳ chọn gửi cho các tin nhắn được gửi tới
Thiết bị Android và cho phép áp dụng các tuỳ chọn tương tự trên
Các nền tảng và web của Apple. Ví dụ: "có thể thu gọn" hành vi tin nhắn được hỗ trợ trên
Android qua collapse_key của FCM, trên Apple qua
apns-collapse-id và trên JavaScript/Web thông qua Topic. Để biết thông tin chi tiết, hãy xem
mô tả trong phần này và tài liệu tham khảo có 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 mỗi thông báo riêng lẻ phân phối đến thiết bị. Thông báo không thể thu gọn sẽ mang lại một số thông tin hữu ích nội dung, trái ngược với một 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 thông điệp 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 thư đều có nội dung khác nhau.
Đối với Android, bạn có thể lưu trữ tối đa 100 tin nhắn mà không cần thu gọn. Nếu đã đạt đến giới hạn, tất cả thư đã lưu sẽ bị huỷ. Khi thiết bị được khôi phục trực tuyến thì 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á 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 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 tin nhắn có thể thu gọn là tin nhắn được dùng để cho biết một ứng dụng di động để đồng bộ hoá dữ liệu từ máy chủ. Một 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 tin nhắn là có thể thu gọn trên Android, hãy thêm
Tham số collapse_key ở
tải trọng 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 bốn tin nhắn có thể thu gọn khác nhau cho
mỗi thiết bị có một phím thu gọn riêng. Nếu 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. Tin nhắn thông báo
luôn có thể thu gọn và sẽ bỏ qua thông 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 xét trên khía cạnh hiệu suất, miễn là ứng dụng của bạn không cần 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 sử dụng tối đa 4 phím thu gọn khác nhau theo FCM mỗi mã thông báo đăng ký vào bất kỳ thời điểm nào. Bạn không được vượt quá con số này hoặc 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 điệp đều quan trọng đối với ứng dụng khách và cần phải đã gửi. | Ngoại trừ tin nhắn thông báo, bạn không thể thu gọn tất cả tin nhắn bằng mặc định. |
| Có thể gấp gọn | Khi có thư mới hơn hiển thị một thư cũ hơn, có liên quan không liên quan đến ứng dụng khách, FCM sẽ thay thế thông báo cũ. Ví dụ: thông báo được dùng để bắt đầu đồng bộ hoá dữ liệu từ máy chủ hoặc thông báo đã lỗi thời tin nhắn thông báo. | Đặ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 tiếp theo: mức độ ưu tiên cao và bình thường. Mặc dù hành vi hơi khác nhau nền tảng, gửi tin nhắn có mức độ ưu tiên thông thường và tin nhắn có mức độ ưu tiên cao 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 ở nền trước. Đối với các ứng dụng chạy trong nền, quá trình 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 trong nền, 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 cung cấp mức độ ưu tiên cao ngay lập tứ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ề thông báo có mức độ ưu tiên bình thường được gửi qua FCM Giao thức HTTP v1 để thông báo cho tạp chí người đăng ký 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, thiết bị có thể đã bị tắt, không có 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 một ứng dụng sử dụng quá nhiều tài nguyên cũng như tiêu cực ảnh hưởng đến thời lượng pin.
Khi trường hợp này xảy ra, FCM sẽ lưu trữ tin nhắn và gửi tin nhắn đó sớm nhất có thể nếu khả thi. Mặc dù điều này tốt trong hầu hết các trường hợp, nhưng có một số ứng dụng dành cho mà một tin nhắn trễ cũng có thể không bao giờ được gửi đi. 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, 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 bị chấm dứt. Hoặc nếu tin nhắn là một lời mời tham gia sự kiện, 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 . 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 đưa ra thông báo. Yêu cầu không chứa đoạn mã này mặc định là khoảng thời gian tối đa là bốn 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 xác định thời gian tồn tại của thông báo là
FCM không áp dụng chế độ đ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ợ xử lý tốt nhất những tin nhắn phải
phân phối "ngay bây giờ hoặc không bao giờ". Xin lưu ý rằng
Giá trị time_to_live của
0 có nghĩa là thư không thể gửi ngay sẽ bị huỷ. Tuy nhiên,
vì các thông báo đó không bao giờ được lưu trữ, nên điều này tạo độ trễ tốt nhất cho
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ột máy chủ ứng dụng đăng một thông báo lên FCM và nhận được một tin nhắn nhận dạng, thì điều này không có nghĩa là thư đã đượ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. Điều 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 đang bật và không có hạn chế điều tiết, thông báo là được giao ngay lập tức.
Nếu thiết bị đã được kết nối nhưng ở chế độ Nghỉ, thì thông báo có mức độ ưu tiên thấp sẽ được lưu trữ
bằng FCM cho đến khi thiết bị hết chế độ Nghỉ. và
đó là nơi cờ collapse_key có vai trò: nếu có
đã lưu trữ một thông báo có cùng khoá thu gọn (và mã thông báo đăng ký)
và đang chờ
phân phối, thư cũ sẽ bị huỷ và thư mới sẽ thay thế
(tức là tin nhắn cũ bị thu gọn bởi tin nhắn mới). Tuy nhiên, nếu sự sụp đổ
khoá chưa được đặt, 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ị không được kết nối với FCM, tin nhắn sẽ được lưu trữ cho đến
kết nối được thiết lập (một lần nữa tôn trọng các quy tắc khoá thu gọn). Khi một
đã thiết lập kết nối, FCM 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 được đặt lại về trạng thái ban đầu), thông báo rồi 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 đặ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 nền tảng Android hoặc Apple, hãy xem Trang tổng quan báo cáo FCM, nơi ghi lại số thư đượ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 ứng dụng Android.
Đối với 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 thư nhưng huỷ thư đó ngay lập tức. Nếu thiết bị của bạn sẽ kết nối trong vòng bốn tuần kể từ khi thông báo dữ liệu gần đây nhất bạn gửi đến thiết bị đó, ứng dụng của bạn 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á từ máy chủ ứng dụng.
Cuối cùng, khi FCM cố gắng gửi 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à
làm mất hiệu lực mã thông báo đăng ký. Những lần thử gửi tin nhắn đến dịch vụ đó trong tương lai
thiết bị 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, thì việc gửi mọi thông báo đôi khi dẫn đến trải nghiệm tổng thể kém cho người dùng. Trong các trường hợp khác, chúng ta 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. 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 được ra mắt theo từng dự án, hạn mức theo phút cho hạ nguồn nhắn tin. 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ệ sự ổn định của hệ thống và giảm thiểu tác động của các dự án có gai nhọ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. Vượt hạn mức trong trường hợp, hệ thống phân phát mã trạng thái HTTP 429 (QUOTA_EXCEEDED) cho đến khi hạn mức sẽ được nạp lại trong phút sau. 429 câu trả lời cũng có thể được trả về trong các tình huống quá tải, vì vậy, bạn nên xử lý lỗi 429 theo đề 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 & các dịch vụ
- Trong danh sách bảng, hãy chọn API nhắn tin qua đám mây của Firebase
- Chọn QUOTA & GIỚI HẠN HỆ THỐNG.
LƯU Ý: Những biểu đồ này không được căn chỉnh chính xác về thời gian theo hạn mức phút, có nghĩa là Video 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 thường xuyên của bạn đạt ≥ 80% hạn mức trong ít nhất 5 phút liên tiếp mỗi ngày.
- Bạn có < Tỷ lệ lỗi ứng dụng là 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 để tối đa +25% và FCM sẽ nỗ lực thiết thực để đáp ứng yêu cầu này (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 ra mắt hoặc 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 để cho phép 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), ít nhất Bạn phải thông báo trước 30 ngày. Đợt ra mắt và yêu cầu sự kiện đặc biệt vẫn đang phải tuân theo các yêu cầu về tỷ lệ lỗi ứng dụng 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
Fanout tin nhắn là quá trình gửi tin nhắn đến nhiều thiết bị, chẳng hạn như khi bạn nhắm mục tiêu theo chủ đề và nhóm hay 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.
Tính năng gửi tin nhắn không hoạt động ngay lập tức nên đôi khi bạn có nhiều đang diễn ra đồng thời các đợt hâm mộ. Chúng tôi giới hạn số lượng thông báo đồng thời số người hâm mộ cuồng nhiệt trên mỗi dự án lên đến 1.000. Sau đó, có thể chúng tôi sẽ từ chối những người hâm mộ khác hoặc trì hoãn việc ngừng thực hiện các yêu cầu cho đến khi một số yêu cầu đã được đã hoàn tất quá trình hâm mộ tiến trình.
Số lượng dự án ảnh hưởng đến tỷ lệ người hâm mộ thực tế có thể đạt được yêu cầu người hâm mộ chia sẻ cùng một lúc. Tỷ lệ fanout 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à sự bảo đảm và chỉ là 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 dành cho fanout được chia thành các dự án, chứ không phải trên fanout yêu cầu. Vì vậy, nếu dự án của bạn có hai lượt xem đang diễn ra thì mỗi lượt xem sẽ được thực hiện chỉ thấy một nửa tỷ lệ fanout hiện có. Cách được đề xuất để tối đa hoá tốc độ quạt ra chỉ diễn ra mỗi lần một quạt 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à thông báo không có nội dung và được thiết kế nằm chồng lên nhau. Trong trường hợp nhà phát triển đang lặp lại cùng một tin nhắn đến 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 mức 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 để có thể đồng bộ hoá ở tốc độ trung bình thấp hơn. Việc điều tiết này chỉ nhằm 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ì các tin nhắn không thu gọn được có thể sẽ là lựa chọn đúng đắn. Đối với những thư như vậy, hãy nhớ đưa nội dung vào các tin nhắn đó nhằm giảm chi phí pin.
Chúng tôi giới hạn việc gửi tin nhắn có thể thu gọn thành một nhóm gồm 20 tin nhắn trong mỗi ứng dụng trên mỗi thiết bị, với mỗi 3 phút gửi 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 là 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ư, nhưng là 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 kết nối song song 2500 kết nối.
Đối với nhắn tin ngược dòng bằng XMPP, giới hạn FCM tin nhắn ngược dòng với tốc độ 1.500.000/phút cho mỗi dự án để tránh làm quá tải máy chủ đích ở thượng nguồn.
Chúng tôi giới hạn tốc độ tin nhắn ngược dòng trên mỗi thiết bị là 1.000 tin nhắn/phút để bảo vệ pin làm tiêu hao 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ị thiết bị. Ngưỡng cao này có nghĩa là cho phép tạo ra các đợt lưu lượng truy cập trong thời gian ngắ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 giúp tránh xảy ra lỗi trong việc gửi logic trong việc 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, bạn cần định cấu hình tài khoản này để cho phép thiết bị di động kết nối bằng FCM để các thiết bị trong mạng của bạn có thể nhận được tin nhắn. FCM thường sử dụng cổng 5228, nhưng đôi khi nó 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ể do 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, gây ảnh hưởng đến của bạn. Tốt nhất là bạn nên thêm vào danh sách cho phép cổng 5228-5230 & 443 mà không có giới hạn về IP. Tuy nhiên, nếu bạn phải có một IP hạn chế, bạn nên đưa 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 quy tắc hằng tháng. Vấn đề do Các hạn chế IP của tường lửa thường gián đoạn và khó chẩn đoán.
Chúng tôi cung cấp một nhóm tên miền có thể được đưa vào danh sách cho phép thay vì IP của bạn. Các tên máy chủ đó được liệt kê bên dưới. Nếu chúng tôi bắt đầu sử dụng các thành phần tên máy chủ, chúng tôi sẽ cập nhật danh sách tại đây. Sử dụng tên miền cho tường lửa của bạn 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 Gói trạng thái Kiểm tra (SPI), triển khai thời gian chờ tối thiểu là 30 phút 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 trong khi giảm mức tiêu thụ pin của di động thiết bị.
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 thông báo đẩy kết nối 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 tinh 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 vẫn hoạt động ngắt kết nối lâu dài dẫn đến trải nghiệm người dùng kém do bỏ lỡ hoặc tin nhắn bị trễ hoặc tốn pin cao. Khi VPN được định cấu hình để 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 kết nối đã mã hoá (qua mạng cơ sở wifi hoặc LTE) để đảm bảo mạng đáng tin cậy, thân thiện với pin của bạn. FCM sử dụng VPN có thể bỏ qua cụ thể 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ử dụng VPN nếu lưu lượng đó đang hoạt động. Khi FCM kết nối bỏ qua VPN. Mạng này sẽ làm 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 pháp khác nhau để kiểm soát xem VPN có thể có thể bỏ qua. 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 để có thể bỏ qua, 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ễ và có thể làm tiêu hao pin nhiều hơn khi sử dụng giải pháp Gửi thông báo qua đám mây nhằm duy trì kết nối qua VPN kết nối.
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 sau đây từ dự án Firebase của bạn:
| 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 tới Điểm cuối HTTP FCM v1. Giá trị này là có sẵn trong Ngăn Cài đặt trên bảng điều khiển 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. Cần có mã thông báo đăng ký cho một thiết bị và thiết bị nhắn tin theo nhóm. 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 bảng điều khiển của Firebase Ngăn Cài đặt. Mã nhận dạng người gửi được dùng để xác định mỗi người gửi có thể gửi tin nhắn tới ứng dụng khách. |
| Mã truy cập | Mã thông báo OAuth 2.0 ngắn hạn cho phép yêu cầu đến HTTP phiên bản 1 API. 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 về 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 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 máy chủ cho phép máy chủ ứng dụng của bạn quyền truy cập vào các dịch vụ của Google, bao gồm gửi tin nhắn qua Giải pháp gửi thông báo qua đám mây của Firebase (Firebase Messaging) không dùng nữa giao thức cũ. Lưu ý quan trọng: Đừng thêm khoá máy chủ ở bất cứ đâu trong mã khách hàng của bạn. Ngoài ra, hãy đảm bảo chỉ sử dụng khoá máy chủ để cấp quyền máy chủ ứng dụng. Android, nền tảng Apple và các khoá trình duyệt bị từ chối bởi FCM. |