Trong quá trình phát triển ứng dụng di động và web, khả năng gửi thông tin đến người dùng đúng thời điểm có ý nghĩa quan trọng đối với trải nghiệm sử dụng. Một ứng dụng có thể cung cấp nhiều tính năng hữu ích, nhưng nếu không thể thông báo về tin nhắn mới, đơn hàng, sự kiện hoặc nội dung cập nhật thì mức độ tương tác thường bị suy giảm. Push notification, hay thông báo đẩy, ra đời để giải quyết vấn đề này bằng cách cho phép máy chủ chủ động gửi thông tin đến thiết bị của người dùng.
Firebase Cloud Messaging, thường được viết tắt là FCM, là dịch vụ nhắn tin đa nền tảng của Google Firebase. FCM cho phép máy chủ gửi thông điệp đến ứng dụng chạy trên Android, iOS và web. Thông điệp có thể được hiển thị dưới dạng thông báo cho người dùng hoặc được chuyển đến mã nguồn của ứng dụng để xử lý theo logic riêng. Theo tài liệu chính thức, FCM hỗ trợ gửi đến một thiết bị, một nhóm thiết bị hoặc các thiết bị đã đăng ký một chủ đề, đồng thời cho phép truyền tải payload có kích thước tối đa 4096 byte trong nhiều trường hợp sử dụng 1.
1. Khái niệm và vai trò của FCM
FCM là lớp trung gian giữa máy chủ ứng dụng và ứng dụng khách trên thiết bị người dùng. Thay vì ứng dụng phải liên tục gửi yêu cầu lên máy chủ để hỏi xem có dữ liệu mới hay không, máy chủ có thể gửi một thông điệp thông qua FCM khi phát sinh sự kiện. Cơ chế này giúp giảm việc thăm dò liên tục, tiết kiệm tài nguyên mạng và rút ngắn thời gian phản hồi.
FCM thường được sử dụng trong nhiều tình huống. Ứng dụng trò chuyện có thể báo tin nhắn mới. Ứng dụng thương mại điện tử có thể thông báo trạng thái đơn hàng. Ứng dụng tin tức có thể gửi bài viết nổi bật. Trò chơi trực tuyến có thể thông báo sự kiện hoặc phần thưởng. Ngoài ra, FCM còn có thể đánh thức ứng dụng để đồng bộ dữ liệu, dù thông điệp đẩy không nên được xem là cơ chế duy nhất để bảo đảm mọi dữ liệu đều được truyền thành công.
Điểm quan trọng là FCM không chỉ là công cụ hiển thị thông báo. Nó còn là một kênh truyền dữ liệu giữa hệ thống phía máy chủ và ứng dụng khách. Nhà phát triển có thể gửi một payload chứa các cặp khóa–giá trị, sau đó để ứng dụng tự quyết định phải làm gì với dữ liệu đó.
2. Kiến trúc và quy trình hoạt động
Một hệ thống FCM cơ bản gồm bốn thành phần chính: công cụ tạo yêu cầu gửi, máy chủ ứng dụng đáng tin cậy, FCM backend và ứng dụng khách có tích hợp FCM SDK. Máy chủ ứng dụng có thể là máy chủ riêng, Cloud Functions for Firebase hoặc một môi trường backend khác. Đây là nơi xây dựng nội dung, xác định người nhận và gửi yêu cầu đến FCM.
Quy trình thường bắt đầu khi một phiên bản ứng dụng đăng ký với FCM. FCM cấp cho phiên bản ứng dụng một registration token. Token này đại diện cho một phiên bản cài đặt cụ thể trên thiết bị và được dùng để gửi thông điệp đến đúng đích. Token có thể thay đổi, vì vậy ứng dụng cần xử lý việc cập nhật token thay vì lưu trữ nó như một giá trị vĩnh viễn.
Khi có sự kiện cần thông báo, máy chủ tạo yêu cầu gửi và chuyển yêu cầu đó đến FCM backend. Backend tiếp nhận yêu cầu, tạo thông tin định danh cho thông điệp và chuyển nó đến lớp vận chuyển phù hợp với nền tảng đích. Android sử dụng lớp vận chuyển dành cho Android, thiết bị Apple liên quan đến APNs, còn ứng dụng web sử dụng giao thức web push. Cuối cùng, FCM SDK trên thiết bị nhận thông điệp và chuyển cho hệ điều hành hoặc mã nguồn ứng dụng xử lý.
Có thể mô tả luồng hoạt động như sau:
- Ứng dụng khách đăng ký với FCM và nhận registration token.
- Ứng dụng gửi token về máy chủ ứng dụng nếu hệ thống cần gửi theo từng thiết bị.
- Máy chủ tạo payload và xác định đích nhận.
- Máy chủ gửi yêu cầu đến FCM bằng Firebase Admin SDK hoặc HTTP v1 API.
- FCM chuyển thông điệp qua lớp vận chuyển của nền tảng.
- Ứng dụng hoặc hệ điều hành nhận và xử lý thông điệp theo trạng thái hiện tại của ứng dụng.
3. Hai loại thông điệp cơ bản
FCM phân biệt hai loại thông điệp chính: notification message và data message.
3.1. Notification message
Notification message chứa các trường đã được FCM định nghĩa cho phần hiển thị, chẳng hạn tiêu đề, nội dung, biểu tượng hoặc đường dẫn mở ứng dụng. Khi ứng dụng Android ở chế độ nền, FCM SDK thường để hệ điều hành hiển thị thông báo trong khay thông báo. Cách làm này phù hợp với các thông báo mà nhà phát triển muốn người dùng nhìn thấy ngay mà không cần tự xây dựng toàn bộ cơ chế hiển thị.
Ví dụ, một yêu cầu gửi notification message có thể có dạng:
{
"message": {
"token": "DEVICE_REGISTRATION_TOKEN",
"notification": {
"title": "Đơn hàng đã được giao",
"body": "Vui lòng kiểm tra trạng thái đơn hàng của bạn."
}
}
}Ưu điểm của notification message là triển khai nhanh và phù hợp với các chiến dịch tương tác người dùng. Tuy nhiên, nhà phát triển có ít quyền kiểm soát hơn đối với cách xử lý trong một số trạng thái của ứng dụng. Khi ứng dụng chạy nền, thông báo có thể được hệ điều hành hiển thị trực tiếp thay vì đi qua hàm xử lý chính của ứng dụng.
3.2. Data message
Data message chỉ chứa các cặp khóa–giá trị do nhà phát triển định nghĩa. Ứng dụng khách chịu trách nhiệm tiếp nhận và quyết định cách xử lý. Loại thông điệp này thích hợp khi máy chủ muốn gửi một sự kiện hoặc một lệnh, chẳng hạn yêu cầu làm mới hộp thư, cập nhật trạng thái cuộc trò chuyện hoặc mở một màn hình cụ thể.
Ví dụ:
{
"message": {
"token": "DEVICE_REGISTRATION_TOKEN",
"data": {
"type": "new_message",
"conversation_id": "conversation_123",
"message_id": "message_456"
}
}
}Data message linh hoạt hơn nhưng đòi hỏi nhiều trách nhiệm hơn ở phía ứng dụng. Nhà phát triển phải kiểm tra dữ liệu, xử lý lỗi, bảo đảm không thực hiện tác vụ quá lâu trong callback và quyết định có cần hiển thị thông báo hay không. Payload cũng không nên chứa thông tin nhạy cảm ở dạng không bảo vệ; FCM không tự động thay thế cho cơ chế mã hóa đầu cuối.
3.3. Thông điệp kết hợp
FCM cũng cho phép kết hợp phần notification và phần data trong cùng một thông điệp. Khi ứng dụng Android chạy nền, phần notification thường được đưa vào khay thông báo, còn dữ liệu tùy chỉnh được chuyển đến ứng dụng khi người dùng tương tác với thông báo. Khi ứng dụng ở tiền cảnh, ứng dụng có thể nhận cả hai phần để tự quyết định cách hiển thị và xử lý 3.
Vì hành vi thay đổi theo trạng thái tiền cảnh hoặc nền, nhà phát triển cần kiểm thử riêng từng trường hợp. Một thông báo hoạt động đúng khi ứng dụng đang mở chưa chắc hoạt động giống hệt khi ứng dụng bị thu nhỏ hoặc thiết bị đang ở trạng thái tiết kiệm pin.
4. Cách triển khai FCM trong ứng dụng Android
Để tích hợp FCM, nhà phát triển thường tạo hoặc liên kết một dự án Firebase với ứng dụng, thêm Firebase SDK tương ứng và cấu hình thông tin ứng dụng. Sau đó, ứng dụng cài đặt một dịch vụ kế thừa FirebaseMessagingService để nhận các callback từ FCM.
Một ví dụ Kotlin rút gọn:
class AppMessagingService : FirebaseMessagingService() {
override fun onNewToken(token: String) {
super.onNewToken(token)
// Gửi token mới về máy chủ ứng dụng nếu cần.
}
override fun onMessageReceived(message: RemoteMessage) {
super.onMessageReceived(message)
val type = message.data["type"]
val content = message.data["content"]
// Kiểm tra dữ liệu và xử lý theo nghiệp vụ của ứng dụng.
if (type == "new_message" && content != null) {
// Có thể tạo thông báo cục bộ hoặc cập nhật giao diện.
}
}
}Theo hướng dẫn Android của Firebase, onMessageReceived được gọi trong nhiều trường hợp, nhưng notification message nhận khi ứng dụng chạy nền thường được đưa thẳng vào khay thông báo. Callback này có khoảng thời gian xử lý ngắn. Vì vậy, các tác vụ kéo dài như gọi nhiều API, tải tệp lớn hoặc truy vấn phức tạp nên được chuyển sang cơ chế phù hợp như WorkManager thay vì thực hiện toàn bộ trong callback 4.
Một ứng dụng thực tế cũng cần xin quyền thông báo trên các phiên bản Android yêu cầu người dùng cấp quyền, xây dựng kênh thông báo, thiết lập biểu tượng phù hợp và xử lý hành động khi người dùng chạm vào thông báo. Bên cạnh đó, ứng dụng phải cập nhật token lên máy chủ khi token thay đổi và loại bỏ các token không còn hợp lệ.
5. Phương thức định tuyến thông điệp
FCM cung cấp nhiều cách xác định người nhận. Cách thứ nhất là gửi đến một registration token cụ thể. Phương thức này phù hợp với thông báo cá nhân, chẳng hạn thông báo riêng cho tài khoản hoặc thiết bị.
Cách thứ hai là gửi đến nhiều thiết bị thông qua danh sách token hoặc nhóm thiết bị. Phương thức này cần được quản lý cẩn thận vì danh sách token có thể lớn và chứa các token đã hết hạn.
Cách thứ ba là sử dụng topic. Thiết bị đăng ký vào một chủ đề như technology, sports hoặc promotions, sau đó máy chủ gửi thông điệp đến chủ đề đó. Topic phù hợp với nội dung chung cho nhiều người dùng. Tuy nhiên, không nên đưa thông tin riêng tư hoặc dữ liệu nhạy cảm vào topic vì việc tham gia topic không phải là cơ chế phân quyền chi tiết.
6. Ưu điểm và hạn chế của FCM
Ưu điểm lớn nhất của FCM là hỗ trợ nhiều nền tảng trong cùng một hệ sinh thái. Nhà phát triển có thể dùng Firebase Console để thử nghiệm nhanh hoặc dùng Admin SDK và HTTP v1 API để tự động hóa việc gửi. FCM cũng cung cấp nhiều hình thức định tuyến, giúp hệ thống gửi đến cá nhân, nhóm hoặc cộng đồng người dùng.
FCM còn giảm đáng kể công sức xây dựng hạ tầng kết nối lâu dài với thiết bị. Ứng dụng không cần tự duy trì một kênh mạng riêng cho từng thiết bị trong các tình huống thông báo thông thường. Việc tích hợp với các dịch vụ khác của Firebase cũng giúp triển khai nhanh các chiến dịch tương tác và theo dõi một số chỉ số liên quan đến thông báo.
Tuy vậy, FCM không bảo đảm rằng mọi thông điệp sẽ luôn được người dùng nhìn thấy ngay. Thiết bị có thể ngoại tuyến, người dùng có thể tắt quyền thông báo, hệ điều hành có thể áp dụng chế độ tiết kiệm pin, hoặc token có thể không còn hợp lệ. Do đó, thông báo đẩy nên được xem là một tín hiệu thúc đẩy đồng bộ chứ không phải nơi lưu trữ dữ liệu duy nhất.
FCM cũng yêu cầu nhà phát triển hiểu sự khác biệt giữa các nền tảng. Hành vi của Android, iOS và trình duyệt không hoàn toàn giống nhau. Việc thiết kế payload chỉ dựa trên một nền tảng dễ dẫn đến lỗi khi mở rộng ứng dụng. Ngoài ra, nếu gửi quá nhiều thông báo hoặc nội dung không phù hợp, ứng dụng có thể làm người dùng khó chịu và bị tắt quyền thông báo.
7. Các nguyên tắc sử dụng FCM hiệu quả
Trước hết, payload nên ngắn gọn và chỉ chứa thông tin cần thiết. Nếu thông báo cần hiển thị dữ liệu mới nhất, ứng dụng có thể nhận một mã định danh rồi tự tải dữ liệu từ máy chủ. Cách này giúp giảm kích thước thông điệp và hạn chế nguy cơ thông tin trong thông báo bị lỗi thời.
Thứ hai, máy chủ phải bảo vệ thông tin xác thực và không đặt khóa bí mật trong ứng dụng khách. Các yêu cầu gửi nên được thực hiện từ môi trường đáng tin cậy như backend hoặc Cloud Functions. Ứng dụng khách chỉ nên nhận token và dữ liệu cần thiết cho chức năng của mình.
Thứ ba, hệ thống cần xử lý khả năng thông điệp bị trễ, bị trùng hoặc không đến nơi. Các nghiệp vụ quan trọng nên có cơ chế đồng bộ lại từ máy chủ. Chẳng hạn, khi mở ứng dụng, app có thể kiểm tra trạng thái mới nhất thay vì giả định rằng mọi thông báo trước đó đã được nhận.
Cuối cùng, nội dung thông báo cần tôn trọng người dùng. Nhà phát triển nên gửi thông báo có giá trị, cho phép người dùng kiểm soát loại nội dung muốn nhận và tránh sử dụng thông báo như một hình thức quảng cáo quá mức. Hiệu quả của FCM không chỉ nằm ở số lượng thông báo gửi đi mà còn ở mức độ phù hợp và hữu ích của từng thông báo.
Kết luận
Firebase Cloud Messaging là một nền tảng quan trọng để xây dựng cơ chế giao tiếp gần như theo thời gian thực giữa máy chủ và ứng dụng khách. FCM hỗ trợ Android, iOS và web, đồng thời cung cấp các phương thức gửi đến từng thiết bị, nhóm thiết bị hoặc topic. Hai loại thông điệp chính, notification message và data message, cho phép nhà phát triển lựa chọn giữa sự tiện lợi của việc hiển thị tự động và quyền kiểm soát của logic xử lý trong ứng dụng.
Tuy nhiên, triển khai FCM hiệu quả không chỉ là gửi một thông báo thành công. Hệ thống cần quản lý registration token, xử lý trạng thái ứng dụng, thiết kế payload hợp lý, bảo vệ dữ liệu và có chiến lược đồng bộ khi thiết bị ngoại tuyến. Khi được sử dụng có kiểm soát, FCM giúp ứng dụng phản hồi nhanh hơn, tăng mức độ tương tác và cung cấp thông tin đúng lúc mà không cần xây dựng toàn bộ hạ tầng nhắn tin từ đầu.
Bài viết khác
Message Broker
1. Message Broker là gì? Message Broker là một thành phần trung gian được sử dụng để tiếp nhận, quản lý và chuyển tiếp thông điệp giữa các ứng dụng hoặc các thành phần trong một hệ thống phần mềm. Công nghệ này thường xuất hiện trong những hệ thống Backend, kiến trúc Microservices và […]
Background Jobs and Queues
1. Background Jobs and Queues là gì? Background Jobs & Queues là hai khái niệm thường gặp trong quá trình phát triển phần mềm, đặc biệt là khi xây dựng các ứng dụng web, ứng dụng di động hoặc những hệ thống cần xử lý nhiều yêu cầu cùng lúc. Hai khái niệm này liên […]
Redis and Caching
1. Caching là gì? Caching là kỹ thuật lưu trữ tạm thời những dữ liệu thường xuyên được sử dụng để có thể truy xuất lại nhanh chóng khi cần thiết. Thay vì mỗi lần người dùng thực hiện một thao tác, hệ thống đều phải truy vấn cơ sở dữ liệu hoặc xử lý […]
Database Migration
1. Database Migration là gì? Database Migration là quá trình quản lý và cập nhật cấu trúc cơ sở dữ liệu theo từng phiên bản trong quá trình phát triển phần mềm. Khi xây dựng một ứng dụng, cơ sở dữ liệu thường xuyên thay đổi để đáp ứng các yêu cầu mới. Ví dụ, […]
Bun ORM
1. Bun ORM là gì? Bun ORM là một thư viện ORM dành cho ngôn ngữ lập trình Go (Golang), được sử dụng để làm việc với cơ sở dữ liệu quan hệ. Bun giúp lập trình viên xây dựng và thực hiện các truy vấn database thông qua những cấu trúc dữ liệu và […]
Date / Number / Currency Formatting
Trong quá trình phát triển phần mềm, đặc biệt là các ứng dụng web và di động phục vụ người dùng ở nhiều quốc gia, việc hiển thị dữ liệu theo đúng định dạng ngày tháng, số và tiền tệ đóng vai trò vô cùng quan trọng. Người dùng không chỉ quan […]
Khoá học lập trình game con rắn cho trẻ em 
