Nhắn tin qua đám mây Firebase (FCM) cung cấp nhiều tùy chọn và khả năng nhắn tin. Thông tin trong trang này nhằm giúp bạn hiểu các loại thông báo FCM khác nhau và bạn có thể làm gì với chúng.
loại tin nhắn
Với FCM, bạn có thể gửi hai loại tin nhắn cho khách hàng:
- Tin nhắn thông báo, đôi khi được coi là "tin nhắn hiển thị". Chúng được FCM SDK xử lý tự động.
- Thông báo dữ liệu, được xử lý bởi ứng dụng khách.
Thông báo thông báo chứa một bộ khóa người dùng có thể nhìn thấy được xác định trước. Ngược lại, thông báo dữ liệu chỉ chứa các cặp khóa-giá trị tùy chỉnh do người dùng xác định. Tin nhắn thông báo có thể chứa tải trọng dữ liệu tùy chọn. Tải trọng tối đa cho cả hai loại tin nhắn là 4000 byte, ngoại trừ khi gửi tin nhắn từ bảng điều khiển Firebase, thực thi giới hạn 1024 ký tự.
| sử dụng kịch bản | Làm cách nào để gửi | |
|---|---|---|
| Tin nhắn 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 mặt cho ứng dụng khách khi ứng dụng này đang chạy trong nền. Mặt khác, 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 thông báo có một bộ khóa người dùng có thể nhìn thấy được xác định trước và tải trọng dữ liệu tùy chọn của các cặp khóa-giá trị tùy chỉnh. |
|
| thông điệp dữ liệu | Ứng dụng khách chịu trách nhiệm xử lý thông điệp dữ liệu. Thông báo dữ liệu chỉ có các cặp khóa-giá trị tùy chỉnh không có tên khóa dành riêng (xem bên dưới). | Trong môi trường đáng tin cậy 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 quản trị hoặc Giao thức máy chủ FCM : Chỉ đặt khóa data . |
Sử dụng tin nhắn 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 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 mình.
FCM có thể gửi tin nhắn thông báo bao gồm tải trọng dữ liệu tùy chọn. Trong những trường hợp như vậy, FCM xử lý 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à thu hút lại người dùng, bạn có thể gửi tin nhắn 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 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 chương trình bằng SDK quản trị hoặc giao thức FCM, hãy đặt khóa notification với bộ tùy chọn khóa-giá trị được xác định trước cần thiết cho phần người dùng có thể nhìn thấy của tin nhắn thông báo. Ví dụ: đây là thông báo thông báo có định dạng JSON trong ứng dụng IM. Người dùng có thể thấy một thông báo có tiêu đề "Bồ Đào Nha vs. Đan Mạch" và nội dung "trận đấu tuyệt 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ế độ nền. Đối với các ứng dụng ở nền trước, các thông báo được xử lý bằng chức năng gọi lại.
Xem tài liệu tham khảo để biết danh sách đầy đủ các khóa được xác định trước có sẵn để tạo thông báo thông báo:
- Đối tượng thông báo Giao thức HTTP v1
- Tải trọng thông báo Giao thức HTTP kế thừa
- Tải trọng thông báo Giao thức XMPP
Thông điệp dữ liệu
Đặt khóa thích hợp với các cặp khóa-giá trị tùy chỉnh của bạn để gửi trọng tải dữ liệu đến ứng dụng khách.
Ví dụ: đây là một thông báo có định dạng JSON trong cùng một ứng dụng IM như trên, trong đó thông tin được gói gọn trong khóa data chung và ứng dụng khách 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 chung hoặc cấp cao nhất, đượ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 nhận được tải trọng dữ liệu trong chức năng gọi lại.
Mã hóa cho thông điệp dữ liệu
Android Transport Layer (xem kiến trúc FCM ) sử dụng mã hóa điểm-điểm. Tùy thuộc vào nhu cầu của mình, bạn có thể quyết định thêm mã hóa đầu cuối vào tin nhắn dữ liệu. FCM không cung cấp giải pháp đầu cuối. Tuy nhiên, có sẵn các giải pháp bên ngoài như Capillary hoặc DTLS .
Tin nhắn thông báo với tải trọng dữ liệu tùy chọn
Bằng cách lập trình hoặc thông qua bảng điều khiển Firebase, bạn có thể gửi tin nhắn thông báo chứa tải trọng tùy chọn của các cặp khóa-giá trị tùy chỉnh. Trong Trình tổng hợp thông báo , hãy sử dụng các trường Dữ liệu tùy chỉnh trong Tùy chọn nâng cao .
Hành vi của ứng dụng khi nhận thông báo bao gồm cả tải trọng thông báo và dữ liệu phụ thuộc vào việc ứng dụng ở chế độ nền hay 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ó sẵn cả hai tải trọng.
Đây là một thông báo có định dạng JSON chứa cả khóa notification và khóa data :
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
},
"data" : {
"Nick" : "Mario",
"Room" : "PortugalVSDenmark"
}
}
}Tùy chỉnh một tin nhắn trên các nền tảng
SDK quản trị Firebase và giao thức HTTP FCM v1 đều cho phép yêu cầu tin nhắn của bạn đặt tất cả các trường có sẵn trong đối tượng message . Điêu nay bao gôm:
- một tập hợp các trường chung sẽ được giải thích bởi tất cả các phiên bản ứng dụng nhận được thông báo.
- 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 khối dành riêng cho nền tảng cho phép bạn linh hoạt tùy chỉnh thư cho các 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. Chương trình phụ trợ FCM sẽ tính đến tất cả các tham số được chỉ định và tùy chỉnh thông báo cho từng nền tảng.
Khi nào nên sử dụng các trường chung
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 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 phổ biến sau:
Khi nào nên sử dụng các trường dành riêng cho nền tảng
Sử dụng các trường dành riêng cho nền tảng khi bạn muốn:
- Chỉ gửi các trường đến các 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 phổ biến
Bất cứ khi nào bạn chỉ muốn gửi giá trị đến các nền tảng cụ thể, đừng sử dụng các trường chung; 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 tới nền tảng Apple và web chứ không gửi tới Android, bạn phải sử dụng hai bộ trường riêng biệt, một cho Apple và một cho web.
Khi bạn gửi thư với các tùy 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 chúng. 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 bạn muốn đặt cùng một giá trị trên các nền tảng, bạ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 là 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 là ngày hết hạn .
Ví dụ: tin nhắn thông báo với các tùy chọn gửi dành riêng cho nền tảng
Yêu cầu gửi v1 sau đây gửi tiêu đề và nội dung thông báo chung cho tất cả các nền tảng, nhưng cũng gửi một số 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 nền tảng Android và Web, đồng thời đặt mức độ ưu tiên của thông báo APN (nền tảng 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 việc 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 HTTP v1 để biết chi tiết đầy đủ về các khóa có sẵn trong các khối dành riêng cho nền tảng trong nội dung thư. Để biết thêm thông tin về việc xây dựng yêu cầu gửi có chứa nội dung thư, hãy xem Xây dựng yêu cầu gửi .
tùy chọn giao hàng
FCM cung cấp một bộ tùy chọn gửi cụ thể cho các tin nhắn được gửi tới thiết bị Android và cho phép các tùy chọn tương tự trên nền tảng và web của Apple. Ví dụ: hành vi tin nhắn "có thể thu gọn" được hỗ trợ trên Android thông qua collapse_key của FCM, trên Apple thông qua apns-collapse-id và trên JavaScript/Web thông qua Topic . Để biết chi tiết, xem 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à có thể thu gọn
Tin nhắn không thể thu gọn biểu thị rằng từng tin nhắn riêng lẻ được gửi đến thiết bị. Một tin nhắn không thể thu gọn cung cấp một số nội dung hữu ích, trái ngược với một tin nhắn có thể thu gọn như "ping" không có nội dung tới ứng dụng dành cho thiết bị di động để liên hệ với máy chủ để tìm nạp dữ liệu.
Một số trường hợp sử dụng điển hình 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 IM, bạn muốn gửi mọi tin nhắn vì mỗi tin nhắn có nội dung khác nhau.
Đối với Android, có giới hạn 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 tin nhắn được lưu trữ sẽ bị hủy. Khi thiết bị trực tuyến trở lại, thiết bị sẽ nhận được một thông báo đặc biệt cho biết rằng đã đạt đến giới hạn. Sau đó, ứng dụng có thể xử lý tình huống đúng cách, thường bằng cách yêu cầu đồng bộ hóa hoàn toàn từ máy chủ ứng dụng.
Tin nhắn có thể thu gọn là một tin nhắn có thể được thay thế bằng một tin nhắn mới nếu 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 sử dụng để yêu cầu ứng dụng dành cho thiết bị di động đồng bộ hóa dữ liệu từ máy chủ. Một ví dụ sẽ là một ứng dụng thể thao cập nhật cho người dùng điểm số mới nhất. Chỉ tin nhắn gần đây nhất có liên quan.
Để đánh dấu một tin nhắn là có thể thu gọn trên Android, hãy bao gồm thông số collapse_key trong phần tải tin nhắn. Theo mặc định, phím thu gọn là tên gói ứng dụng đã đăng ký trong bảng điều khiển Firebase. Máy chủ FCM có thể lưu trữ đồng thời bốn thông báo có thể thu gọn khác nhau trên mỗi thiết bị, mỗi thông báo có một phím thu gọn khác nhau. Nếu bạn vượt quá con số này, FCM chỉ giữ lại bốn khóa thu gọn, không đảm bảo những khóa nào sẽ được giữ lại.
Thông báo chủ đề không có tải trọng có thể thu gọn theo mặc định. Thông báo 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ái nào?
Tin nhắn 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 sử dụng tin nhắn 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 bốn khóa thu gọn khác nhau cho mỗi mã thông báo đăng ký tại bất kỳ thời điểm nào. Bạn không được vượt quá con số này, nếu không sẽ gây ra những hậu quả khó lường.
| sử dụng kịch bản | Làm cách nào để gửi | |
|---|---|---|
| không thể thu gọn | Mỗi tin nhắn đều quan trọng đối với ứng dụng khách và cần được gửi. | Ngoại trừ các tin nhắn thông báo, tất cả các tin nhắn đều không thể thu gọn theo mặc định. |
| có thể thu gọn | Khi có một thông báo mới hơn hiển thị một thông báo 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ũ hơn. Ví dụ: tin nhắn được sử dụng để bắt đầu đồng bộ hóa dữ liệu từ máy chủ hoặc tin nhắn thông báo lỗi thời. | Đặt tham số thích hợp trong yêu cầu tin nhắn của bạn:
|
Đặt mức độ ưu tiên của tin nhắn
Bạn có hai tùy chọn để chỉ định mức độ ưu tiên gửi cho thư xuôi dòng: mức độ ưu tiên bình thường và mức độ ưu tiên cao. Mặc dù hành vi hơi khác nhau giữa các nền tảng, nhưng việc gửi thông báo bình thường và có mức độ ưu tiên cao hoạt động như sau:
Ưu tiên bình thường. Thông báo ưu tiên bình thường được gửi ngay lập tức khi ứng dụng ở phía trước. Đối với các ứng dụng chạy nền, quá trình gửi có thể bị chậm. Đối với các tin nhắn ít nhạy cảm hơn về thời gian, chẳng hạn như thông báo về email mới, đồng bộ hóa giao diện người dùng của bạn hoặc đồng bộ hóa dữ liệu ứng dụng trong nền, hãy chọn mức độ ưu tiên gửi bình thường.
Ưu tiên cao. FCM cố gắng gửi tin nhắn ưu tiên cao ngay lập tức ngay cả khi thiết bị ở chế độ Ngủ gật. Các thông báo có mức độ ưu tiên cao dành cho nội dung hiển thị của người dùng, nhạy cảm với thời gian.
Dưới đây là một ví dụ về thông báo ưu tiên bình thường được gửi qua giao thức FCM HTTP v1 để thông báo cho người đăng ký tạp chí rằng có sẵn 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 chi tiết cụ thể về nền tảng về cài đặt mức độ ưu tiên của tin nhắn:
Đặt tuổi thọ của tin nhắn
FCM thường gửi tin nhắn ngay sau khi chúng được gửi đi. Tuy nhiên, điều này có thể không phải lúc nào cũng có thể. Ví dụ: nếu nền tảng là Android, thiết bị có thể bị tắt, ngoại tuyến hoặc không khả dụng. Hoặc FCM có thể cố tình trì hoãn các tin nhắn để 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ữ tin nhắn và gửi tin nhắn đó ngay khi 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 mà thông báo muộn cũng có thể không bao giờ được gửi. Ví dụ: nếu tin nhắn là thông báo cuộc gọi đến hoặc trò chuyện video, tin nhắn đó 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 tin nhắn là lời mời tham gia một sự kiện, 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 tuổi thọ tối đa của một tin nhắn. 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 tin nhắn. Các yêu cầu không chứa trường này mặc định có thời hạn tối đa là bốn tuần.
Dưới đây là một số cách sử dụng có thể cho tính năng này:
- Trò chuyện video cuộc gọi đến
- Sự kiện lời mời hết hạn
- lịch sự kiện
Một ưu điểm khác của việc chỉ định tuổi thọ của một tin nhắn là FCM không bao giờ điều chỉnh các tin nhắn có giá trị thời gian tồn tại là 0 giây. Nói cách khác, FCM đảm bảo nỗ lực tốt nhất cho các thông điệp phải được gửi "bây giờ hoặc không bao giờ". Hãy nhớ rằng giá trị time_to_live bằng 0 có nghĩa là những thư không thể gửi ngay lập tức sẽ bị hủy. Tuy nhiên, vì những tin nhắn như vậy không bao giờ được lưu trữ nên điều này mang lại độ trễ tốt nhất để gửi tin nhắn thông báo.
Dưới đây là một ví dụ về yêu cầu bao gồm 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"
}
}
}
}Tuổi thọ 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 ID tin nhắn, điều đó không có nghĩa là tin nhắn đó đã được gửi đến thiết bị. Thay vào đó, nó có nghĩa là nó đã được chấp nhận để giao hàng. Điều gì xảy ra với tin nhắn sau khi nó đượ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 bật và không có giới hạn điều chỉnh, 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ế độ Ngủ gật, thông báo có mức ưu tiên thấp sẽ được FCM lưu trữ cho đến khi thiết bị hết Chế độ ngủ gật. Và đó là nơi mà cờ collapse_key đóng vai trò: nếu đã có một thông báo có cùng khóa thu gọn (và mã thông báo đăng ký) được lưu trữ và chờ gửi, thì thông báo cũ sẽ bị loại bỏ và thông báo mới sẽ thế chỗ (nghĩa là thông báo cũ tin nhắn bị thu gọn bởi tin nhắn mới). Tuy nhiên, nếu phím thu gọn không được đặt, thì cả thư mới và thư 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, thông báo sẽ được lưu trữ cho đến khi kết nối được thiết lập (một lần nữa tôn trọng quy tắc phím thu gọn). Khi kết nối được thiết lập, FCM sẽ gửi tất cả các tin nhắn đ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 khôi phục cài đặt gốc), thông báo cuối cùng sẽ hết thời gian chờ và bị hủy khỏi bộ lưu trữ FCM. Thời gian chờ mặc định là bốn tuần, trừ khi cờ time_to_live được đặt.
Để hiểu rõ hơn 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 bảng điều khiển báo cáo FCM , 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ề "số lần hiển thị" (thông báo mà người dùng đã xem) cho Ứng dụng Android.
Đối với các thiết bị Android có bật tính năng nhắn tin 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 bốn tuần kể từ khi bạn gửi tin nhắn dữ liệu cuối cùng cho thiết bị, ứng dụng khách 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 bằng cách yêu cầu đồng bộ hóa hoàn toàn 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 nỗ lực gửi tin nhắn đến thiết bị đó trong tương lai sẽ dẫn đến lỗi NotRegistered .
Điều chỉnh và mở rộng quy mô
Mục tiêu của chúng tôi là luôn cung cấp mọi tin nhắn được 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 người dùng tổng thể kém. 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 rằng FCM cung cấp dịch vụ có thể mở rộng cho tất cả người gửi.
Điều chỉnh tin nhắn có thể thu gọn
Như đã mô tả ở trên, thông báo có thể thu gọn là 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 chỉnh) thông báo để giảm tác động đến pin của người dùng.
Ví dụ: nếu bạn gửi một số lượng lớn yêu cầu đồng bộ hóa email mới tới một thiết bị, chúng tôi có thể trì hoãn yêu cầu đồng bộ hóa email tiếp theo trong vài phút để thiết bị có thể đồng bộ hóa ở tốc độ trung bình thấp hơn. Việc điều chỉnh 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 kiểu gửi liên tụ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 những tin nhắn như vậy, hãy đảm bảo bao gồm nội dung trong những tin nhắn đó để giảm chi phí pin.
Chúng tôi giới hạn các tin nhắn có thể thu gọn thành một loạt 20 tin nhắn trên mỗi ứng dụng trên mỗi thiết bị, với việc nạp lại 1 tin nhắn cứ sau 3 phút.
Điều chỉnh máy chủ XMPP
Chúng tôi giới hạn tốc độ mà bạn có thể kết nối với các máy chủ FCM XMPP ở mức 400 kết nối mỗi phút cho mỗi dự án. Đây không phải là vấn đề đối với việc gửi thư nhưng điều quan trọng là đảm bảo tính ổn định của hệ thống của chúng tôi.
Đối với mỗi dự án, FCM cho phép 2500 kết nối song song.
Tốc độ 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ờ tới một thiết bị. Ngưỡng cao này nhằm cho phép các đợt bùng nổ 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 trò chuyện. Giới hạn này ngăn các lỗi trong quá trình gửi logic vô tình làm cạn kiệt 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 ngược dòng
Chúng tôi giới hạn các tin nhắn ngược dòng ở mức 1.500.000/phút cho mỗi dự án để tránh làm quá tải các máy chủ đích ngược dòng.
Chúng tôi giới hạn các tin nhắn ngược dòng trên mỗi thiết bị ở mức 1.000/phút để tránh tình trạng hao pin do hành vi xấu của ứng dụng.
Giới hạn tin nhắn chủ đề
Tỷ lệ thêm/xóa đăng ký chủ đề được giới hạn ở 3.000 QPS cho mỗi dự án.
Để biết tốc độ gửi tin nhắn, hãy xem Điều chỉnh Fanout .
điều chỉnh quạt ra
Phân phát 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 các chủ đề và nhóm hoặc khi bạn sử dụng trình tổng hợp Thông báo để nhắm mục tiêu đối tượng hoặc phân khúc người dùng.
Quá trình phân phát tin nhắn không diễn ra ngay lập tức và do đó, đôi khi bạn có nhiều quá trình phân phát đồng thời. Chúng tôi giới hạn số lần 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 phân bổ bổ sung hoặc trì hoãn việc phân bổ các yêu cầu cho đến khi hoàn tất một số yêu cầu phân phối đang diễn ra.
Tỷ lệ phân xuất thực tế có thể đạt được bị ảnh hưởng bởi số lượng dự án yêu cầu phân xuất cùng một lúc. Tỷ lệ phân tán 10.000 QPS cho một dự án riêng lẻ không phải là hiếm, nhưng con số đó không đả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 phân xuất hiện có được phân chia cho các dự án chứ không phải cho các yêu cầu phân xuất. Vì vậy, nếu dự án của bạn có hai lần phân phối đang diễn ra, thì mỗi lần phân xuất sẽ chỉ thấy một nửa tốc độ phân xuất hiện có. Cách khuyến nghị để tối đa hóa tốc độ phân xuất của bạn là chỉ có một quá trình phân xuất đang hoạt động tại một thời điểm.
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ường lửa đó để cho phép các thiết bị di động kết nối với FCM để các thiết bị trên mạng của bạn nhận được 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 các IP cụ thể vì dải IP của chúng tôi thay đổi quá thường xuyên và các quy tắc tường lửa của bạn có thể đã lỗi thời, ảnh hưởng đến trải nghiệm của người dùng. Lý tưởng nhất là các cổng trong danh sách cho phép 5228-5230 & 443 không có giới hạn IP. Tuy nhiên, nếu bạn phải có giới hạn IP, thì bạn nên đưa tất cả địa chỉ IP được liệt kê 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 hạn chế IP của 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 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. Những tên máy chủ được liệt kê dưới đây. Nếu chúng tôi bắt đầu sử dụng 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ủa bạn có thể có hoặc không hoạt động trong thiết bị tường lửa của bạn.
Cổng TCP để mở:
- 5228
- 5229
- 5230
- 443
Tên máy chủ để 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
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 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ờ 30 phút hoặc lâu hơ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 cho phép chúng tôi cung cấp kết nối đáng tin cậy đồng thời giảm mức tiêu thụ pin trên thiết bị di động của người dùng.
thông tin đăng nhập
Tùy thuộc vào các 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:
| ID dự án | Mã định danh duy nhất cho dự án Firebase của bạn, được sử dụng trong các yêu cầu tới điểm cuối HTTP FCM v1. Giá trị này có sẵn trong ngăn Cài đặt bảng điều khiển 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à nhắn tin nhóm thiết bị. Lưu ý rằng mã thông báo đăng ký phải được giữ bí mật. |
| ID 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 tab Nhắn tin qua đám mây của ngăn Cài đặt bảng điều khiển Firebase. ID người gửi được sử dụng để xác định từng người gửi có thể gửi tin nhắn đến ứng dụng khách. |
| Truy cập thẻ | Mã thông báo OAuth 2.0 tồn tại trong thời gian ngắn cho phép các yêu cầu đối với API HTTP v1. Mã thông báo này được liên kết với tài khoản dịch vụ thuộc dự án Firebase của bạn. Để tạo và xoay mã thông báo 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 . |
| Khóa máy chủ (đối với các giao thức kế thừa) | Khóa 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 gửi tin nhắn qua các giao thức cũ của Nhắn tin qua đám mây Firebase. Bạn lấy khóa máy chủ khi tạo dự án Firebase. Bạn có thể xem nó trong tab Nhắn tin qua đám mây của ngăn Cài đặt bảng điều khiển Firebase. Quan trọng: Không bao gồm khóa máy chủ ở bất kỳ đâu trong mã máy khách của bạn. Ngoài ra, hãy đảm bảo chỉ sử dụng các khóa máy chủ để ủy quyền cho máy chủ ứng dụng của bạn. FCM từ chối nền tảng Android, nền tảng Apple và trình duyệt. |