APNs vs FCM cho thông báo push iOS và Android

Những gì bạn đang so sánh (và tại sao nó quan trọng)

APNs (Apple Push Notification service) và FCM (Firebase Cloud Messaging) là các đường truyền đưa tin từ server của bạn tới điện thoại. Chúng không quyết định ứng dụng của bạn làm gì với tin nhắn, nhưng ảnh hưởng mạnh tới việc tin nhắn có đến được hay không, đến nhanh thế nào và phải có định dạng ra sao.

Khi mọi người nói một thông báo push “hoạt động trên Android nhưng không trên iOS” (hoặc ngược lại), hiếm khi chỉ do một lỗi duy nhất. iOS và Android xử lý công việc nền, tiết kiệm pin, quyền truy cập và mức ưu tiên tin nhắn khác nhau. Cùng một tin nhắn có thể bị trì hoãn, bị thay thế bởi tin mới hơn, hiển thị không có âm thanh, hoặc không bao giờ hiện nếu app không thể thức dậy để xử lý.

So sánh này tập trung vào những phần gây bất ngờ nhất trong thực tế: token thiết bị thay đổi thế nào theo thời gian, kích thước payload tối đa và cấu trúc cần có, kỳ vọng về việc gửi nhận, và các lý do phổ biến khiến thông báo có vẻ bị mất.

Điều này không bao gồm lựa chọn giao diện provider push, chiến lược marketing, hay xây dựng pipeline phân tích đầy đủ. Mục tiêu ở đây là độ tin cậy và tìm lỗi nhanh hơn.

Một vài thuật ngữ dùng xuyên suốt:

• Token: địa chỉ thiết bị bạn gửi tới, do APNs hoặc FCM cấp.
• Topic: địa chỉ nhóm (chủ yếu dùng với FCM) nơi nhiều thiết bị đăng ký.
• Channel: một loại thông báo trên Android điều khiển âm thanh, mức quan trọng và hành vi.
• Collapse key: cách thay thế các tin chờ cũ bằng tin mới hơn.
• TTL (time to live): thời gian tin có thể chờ để được gửi trước khi hết hạn.

Nắm vững những cơ bản này sẽ tiết kiệm nhiều giờ đoán mò khi một “push đơn giản” hành xử khác nhau giữa iOS và Android.

Hoạt động cơ bản của APNs và FCM

APNs và FCM đều là trung gian giữa server của bạn và điện thoại người dùng. App của bạn không thể gửi thông báo push trực tiếp đáng tin cậy tới thiết bị qua internet, vì vậy nó giao việc đó cho Apple (APNs) hoặc Google (FCM), những bên đã duy trì các kết nối tin cậy tới thiết bị.

Luồng tổng thể tương tự: app lấy token, backend gửi tin tới dịch vụ push dùng token đó, và dịch vụ push chuyển tiếp tới thiết bị.

APNs nói một cách đơn giản

Trên iOS, app đăng ký nhận remote notifications và (thường) hỏi người dùng cấp quyền. Apple cung cấp device token. Backend của bạn (thường gọi là “provider”) gửi yêu cầu push tới APNs gồm token và payload. APNs quyết định có thể gửi hay không và chuyển tiếp thông báo tới thiết bị.

Backend của bạn xác thực với APNs, thường dùng xác thực dựa trên token (khóa ký). Cấu hình cũ hơn dùng chứng chỉ.

FCM nói một cách đơn giản

Trên Android, instance của app đăng ký với FCM và nhận registration token. Backend gửi tin tới FCM, và FCM định tuyến tới thiết bị đúng. Tùy thuộc trạng thái app và loại tin, FCM có thể tự động hiển thị thông báo hoặc chuyển data cho app xử lý.

Backend xác thực với FCM bằng thông tin xác thực server (API key hoặc service account).

Bạn kiểm soát: mã app, khi yêu cầu quyền, lưu trữ token, logic backend, và payload gửi đi. Apple và Google kiểm soát: mạng lưới phân phối, độ tiếp cận, quy tắc giới hạn, và nhiều điều kiện cuối cùng như tiết kiệm pin và chính sách hệ thống.

Vòng đời token: token được cấp, làm mới và vô hiệu hóa thế nào

Khác biệt lớn nhất trong APNs vs FCM là token không phải “gán một lần mãi mãi.” Hãy coi chúng như địa chỉ có thể thay đổi bất ngờ.

Trên iOS, device token APNs gắn với thiết bị, app của bạn và cấu hình developer Apple. Nó có thể thay đổi sau khi cài lại app, khôi phục thiết bị, một số bản cập nhật hệ điều hành, hoặc khi chuyển môi trường push (sandbox vs production) trong quá trình phát triển.

Trên Android, registration token FCM có thể làm mới khi app được khôi phục trên thiết bị mới, người dùng xóa dữ liệu app, Google xoay token, hoặc khi cài lại app. App của bạn nên lắng nghe sự kiện refresh và gửi token mới lên server ngay.

Một quy tắc đơn giản: luôn upsert token, không “insert và quên.” Khi lưu token, giữ đủ ngữ cảnh để tránh trùng lặp và gửi nhầm mục tiêu:

• ID người dùng hoặc tài khoản (nếu có)
• Bundle/package app và môi trường
• Nền tảng (iOS/Android)
• Giá trị token và timestamp lần cuối thấy
• Trạng thái opt-in (quyền đã cấp/không)

Xóa cũng quan trọng. Thường bạn biết token đã chết từ lỗi gửi, chứ không phải từ tín hiệu “gỡ cài đặt” rõ ràng. Nếu APNs trả lỗi như Unregistered (thường với status 410), hoặc FCM báo NotRegistered/Unregistered, xóa token đó ngay để ngừng thử lại mãi.

Một cách dễ làm rò rỉ cập nhật riêng tư: khách hàng đăng xuất và người khác đăng nhập trên cùng điện thoại. Nếu bạn không xóa hoặc ánh xạ lại token khi đăng xuất, bạn có thể gửi thông báo tới người sai mặc dù việc gửi “hoạt động.”

Giới hạn payload và khác biệt về cấu trúc tin

Khác biệt thực tế lớn nhất giữa APNs và FCM là bạn có thể nhét được bao nhiêu trong một tin và điện thoại xử lý nó ra sao khi nhận.

Hầu hết đội dev chỉ dùng một tập trường nhỏ:

• Tiêu đề và nội dung
• Số badge (iOS)
• Âm thanh (mặc định hoặc tùy chỉnh)
• Dữ liệu key-value tùy chỉnh (ví dụ order_id, status)

Giới hạn kích thước: giữ push nhỏ

Cả hai dịch vụ có giới hạn kích thước payload, và giới hạn bao gồm dữ liệu tùy chỉnh của bạn. Khi vượt ngưỡng, gửi có thể thất bại hoặc tin sẽ không hoạt động như bạn mong.

Một mô hình đáng tin cậy là gửi thông báo ngắn kèm ID, rồi lấy chi tiết từ backend:

Ví dụ: thay vì gửi tóm tắt đơn hàng đầy đủ, gửi { "type": "order_update", "order_id": "123" } và để app gọi API của bạn để tải trạng thái mới nhất.

Dữ liệu-only vs hành vi notification

Trên Android, một tin FCM có payload “notification” thường được hệ thống hiển thị khi app ở background. Tin chỉ có data sẽ được chuyển cho mã app, nhưng có thể bị trì hoãn hoặc chặn bởi giới hạn nền và cài đặt tiết kiệm pin.

Trên iOS, alerts (tiêu đề/nội dung) đơn giản hơn, nhưng cập nhật nền nghiêm ngặt hơn. Một push nền không đảm bảo mã của bạn sẽ chạy ngay. Hãy coi nó như gợi ý để làm mới, không phải trình kích hoạt thời gian thực.

Nếu cần độ tin cậy, giữ payload tối giản, kèm định danh ổn định, và thiết kế app để đồng bộ trạng thái khi mở hoặc tiếp tục.

Kỳ vọng về việc gửi và những gì có thể ngăn thông báo

Với cả APNs và FCM, việc gửi là best-effort. Provider sẽ cố gửi tin, nhưng không đảm bảo thiết bị sẽ hiển thị nó.

Khả năng tiếp cận (reachability) là giới hạn đầu tiên. Bạn gửi thông báo với TTL hoặc expiry. Nếu thiết bị online trở lại sau cửa sổ đó, push bị bỏ. Nếu TTL dài, người dùng có thể thấy cảnh báo cũ sau đó, trông như lỗi.

Mức ưu tiên ảnh hưởng tới thời gian, nhưng không phải miễn phí. High priority giúp tin nhạy thời gian tới nhanh hơn, đặc biệt khi thiết bị đang ngủ. Dùng quá nhiều có thể dẫn tới throttling, hao pin, hoặc OS coi app của bạn là gây nhiễu.

Cả hai hệ thống hỗ trợ collapsing để tin mới thay thế tin cũ thay vì xếp chồng. APNs dùng collapse identifier, FCM dùng collapse key. Nếu bạn collapse theo order_status, người dùng có thể chỉ thấy trạng thái mới nhất, không phải mọi bước.

Ngay cả khi provider gửi thành công, điện thoại vẫn có thể ngăn người dùng thấy nó:

• Chế độ Do Not Disturb hoặc Focus có thể giữ im lặng hoặc ẩn cảnh báo
• Cài đặt thông báo của app có thể bị tắt hoặc đặt thành hiển thị im lặng
• Các kênh thông báo Android có thể bị tắt cho một hạng mục cụ thể
• Hạn chế nền hoặc tiết kiệm pin có thể trì hoãn gửi
• OS có thể ngăn lặp lại nếu app bạn đăng nhiều cảnh báo giống nhau

Hãy coi push như một kênh không đáng tin cậy: giữ trạng thái quan trọng trên backend và khiến app làm mới trạng thái khi mở, ngay cả khi thông báo không bao giờ hiện.

Quyền và cài đặt thiết bị ảnh hưởng đến việc hiển thị

Nhiều “vấn đề gửi” thực ra là vấn đề quyền và cài đặt.

Trên iOS, lời nhắc quyền đầu tiên rất quan trọng. Nếu người dùng chọn “Don’t Allow”, thông báo không hiện cho tới khi họ đổi trong Settings. Ngay cả sau khi cho phép, họ có thể tắt Lock Screen, Notification Center, banners, âm thanh, hoặc badges. Focus modes và Scheduled Summary cũng có thể ẩn hoặc trì hoãn cảnh báo.

Trên Android, yêu cầu tùy thuộc phiên bản OS. Phiên bản mới yêu cầu quyền thông báo runtime, vì vậy cập nhật app có thể khiến thông báo ngừng hiện cho tới khi người dùng duyệt lại. Khả năng hiển thị còn phụ thuộc kênh thông báo. Nếu kênh bị tắt hoặc đặt độ ưu tiên thấp, push có thể tới nhưng không gây chú ý.

Hạn chế nền cũng làm vỡ kỳ vọng. Low Power Mode trên iOS và tối ưu pin trên Android có thể trì hoãn công việc nền, chặn dữ liệu nền, hoặc ngăn app xử lý tin chỉ có data.

Để xác nhận, ghi log những gì thiết bị thấy, không chỉ những gì backend gửi:

• Log trong app: “permission granted,” “token registered,” “notification received,” “notification displayed”
• Chỉ báo OS: trạng thái cài đặt thông báo (enabled/muted/độ quan trọng của channel) và chế độ pin
• Callbacks push: app có nhận tin ở foreground/background hay không

Ngay cả khi backend của bạn xây bằng công cụ no-code, logging ở client vẫn là thứ tách “tin chưa tới” khỏi “đã tới nhưng bị chặn.”

Các bước khắc phục khi thông báo biến mất

Khi push bị mất, coi nó như một chuỗi: token, provider, payload, và hành vi app. Triệu chứng có thể giống nhau trên iOS và Android, nên kiểm tra theo cùng một thứ tự.

• Xác nhận bạn gửi tới token hiện tại. So sánh token trên server với token app báo gần nhất. Log thời điểm nhận token.
• Xác thực payload trước khi gửi. Giữ dưới giới hạn nền tảng, dùng trường cần thiết và tránh JSON bị lỗi. Nếu gửi data-only, xác nhận app có xử lý.
• Kiểm tra thông tin xác thực provider và môi trường. Với APNs, xác nhận key/chứng chỉ, team, bundle ID, và bạn đang nhắm môi trường sandbox hay production. Với FCM, xác nhận credentials dự án đúng.

Rồi thu hẹp xem lỗi do nội dung tin hay thiết bị/app:

• Gửi một thông báo kiểm tra tối thiểu. Tiêu đề/nội dung ngắn giúp xác nhận transport hoạt động.
• Xác minh handler phía app và hành vi foreground. Nhiều “push mất” thực ra đã đến nhưng không được hiển thị. Một số app tự tắt banner khi ở foreground.
• Thay đổi từng biến một. Thử thiết bị khác, phiên bản OS khác, Wi‑Fi vs di động, và tài khoản người dùng khác. Nếu chỉ một tài khoản lỗi, thường do token cũ hoặc nhắm mục tiêu server lỗi.

Một mẫu thực tế: nếu người dùng iOS báo mất nhưng Android ổn, bắt đầu gửi alert tối thiểu trên iOS. Nếu hoạt động, tập trung vào cấu trúc payload và xử lý app. Nếu không, kiểm tra token và thông tin xác thực APNs/môi trường.

Sai lầm phổ biến khiến im lặng

Hầu hết lỗi push không phải là sự cố hệ thống. Chúng là những sai lệch nhỏ giữa mong đợi của app và điều APNs hoặc FCM chấp nhận, hoặc điều điện thoại cho phép.

Thông thường nhất là gửi tới token không còn hợp lệ. Token thay đổi sau khi cài lại, khôi phục hoặc refresh. Nếu server dùng giá trị cũ, push đi vào hư không.

Một lỗi nữa là coi việc gửi push là đảm bảo. Best-effort nghĩa là tin muộn hoặc mất là bình thường khi thiết bị offline hoặc trong chế độ tiết kiệm pin. Với sự kiện quan trọng (cập nhật đơn hàng, cảnh báo bảo mật), bạn cần dự phòng trong app như fetch trạng thái khi mở.

Nguyên nhân thường gặp khiến thông báo mất:

• Token iOS/Android cũ còn lưu sau khi cài lại/refresh
• Vượt giới hạn payload (dữ liệu tùy chỉnh quá nhiều, hình ảnh quá lớn, chuỗi quá dài)
• Dựa vào delivery nền cho cập nhật im lặng, rồi bị OS giới hạn
• Trộn môi trường iOS (development vs production) khiến token và endpoint APNs không khớp
• Bỏ qua opt-out của người dùng, Focus/Do Not Disturb, kênh thông báo bị tắt (Android), hoặc quyền thông báo app

Ví dụ: app bán lẻ gửi alert “đơn đã gửi” kèm một blob JSON lớn chứa lịch sử theo dõi. Gọi gửi có vẻ ổn, nhưng payload bị từ chối hoặc cắt, và người dùng không thấy gì. Giữ push nhỏ và đặt chi tiết sau API.

Checklist nhanh trước khi đổ lỗi cho APNs hoặc FCM

Trước khi nghĩ provider có lỗi, chạy kiểm tra sau:

• Xác nhận token đúng cho người dùng và thiết bị. Nó tồn tại, được cập nhật gần đây, và ánh xạ đúng phiên.
• Xác thực credentials provider hiện còn hợp lệ. Kiểm tra key/cert APNs và credentials FCM khớp app/project đúng.
• Xác nhận hình dạng và kích thước payload. Ở dưới giới hạn và dùng trường đúng.
• Đặt TTL, priority và collapse có chủ đích. TTL thấp có thể hết hạn trước khi điện thoại online. Priority thấp có thể trì hoãn. Collapse có thể thay thế tin trước.
• Tách “server accepted” khỏi “device displayed.” So sánh log server (request/response/message ID) với log client (token dùng, handler gọi).

Rồi làm kiểm tra nhanh trên thiết bị: thông báo được cho phép cho app, kênh/nhóm đúng (kênh Android là một lỗi phổ biến), Focus/Do Not Disturb, và hạn chế nền.

Ví dụ: chẩn đoán thông báo cập nhật đơn bị mất

Một nhân viên hỗ trợ bấm “Send order update” cho Đơn #1842. Backend log hiện “notification sent,” nhưng khách hàng không thấy gì trên iPhone hoặc Android.

Bắt đầu từ backend. Hầu hết “thông báo mất” là do tin không bao giờ được provider chấp nhận, hoặc provider chấp nhận nhưng sau đó bị bỏ vì thiết bị không thể (hoặc không muốn) hiển thị.

Kiểm tra backend trước

Tìm một lần gửi có thể truy vết (một cập nhật đơn nên tạo một yêu cầu push). Rồi xác minh:

• Token dùng là token mới nhất lưu cho người dùng và thiết bị đó.
• Phản hồi của provider là success, và bạn lưu mã lỗi nếu có.
• Payload tuân thủ quy tắc nền tảng (giới hạn kích thước, trường cần, JSON hợp lệ).
• Auth hợp lệ (APNs key/cert và team/bundle IDs, hoặc credentials FCM).
• Bạn nhắm đúng môi trường iOS (sandbox vs production).

Nếu log chứa rejection như “unregistered/invalid token,” đó là vấn đề vòng đời token. Nếu provider chấp nhận tin nhưng không có gì đến, tập trung vào loại payload và hành vi hệ điều hành.

Kiểm tra trên điện thoại

Xác minh điện thoại được phép hiện alert:

• Thông báo được bật cho app (và cho Lock Screen/Banners).
• Focus/Do Not Disturb hoặc notification summaries không đang ẩn.
• Chế độ tiết kiệm pin không hạn chế công việc nền (thường hơn trên Android).
• Trạng thái app khớp loại tin bạn gửi (xử lý foreground có thể nuốt alert).

Kết quả phổ biến: token ổn, nhưng tin là data-only (Android) hoặc thiếu cấu hình iOS cho xử lý nền, nên OS không hiển thị alert. Cách sửa là gửi đúng loại payload cho mục tiêu (hiển thị alert vs cập nhật nền) và lưu log sạch về cập nhật token và phản hồi provider.

Bước tiếp theo: làm cho push đáng tin hơn trong sản phẩm của bạn

Push có vẻ đơn giản cho đến khi nó trở thành tính năng cốt lõi. Độ tin cậy đến từ những phần bạn kiểm soát: quản lý token, kỷ luật payload, và đường lui.

Lên kế hoạch cho thất bại. Push tốt cho các khoảnh khắc “xem ngay,” nhưng không nên là con đường duy nhất cho sự kiện quan trọng. Một inbox trong app giúp người dùng bắt kịp sau, và email hoặc SMS có thể đảm bảo hành động giá trị cao như đặt lại mật khẩu hay vấn đề thanh toán.

Giữ payload gọn. Xem payload như lời nhắc, không phải tin đầy đủ. Gửi loại sự kiện và ID, rồi lấy chi tiết từ API backend khi app mở hoặc khi nhận cập nhật nền phù hợp.

Viết runbook ngắn cho team để việc gỡ lỗi nhất quán: trạng thái opt-in, độ mới token, mã phản hồi provider, kích thước/hình dạng payload, và môi trường/credentials.

Nếu bạn xây với AppMaster (appmaster.io), nó có thể tiện để gom lưu token, audit log và logic kích gửi push trong một backend, trong khi vẫn phát hành app iOS và Android native xử lý APNs và FCM đúng cách.