FCM跨Android、iOS推送异常求助：报错与重复推送问题

Hey there, let’s work through these FCM push notification headaches one by one — I’ve dealt with similar quirks before, so here’s what I’d suggest checking:

First off, that responseSerializationFailed error almost always means your request doesn’t match what Apple’s APNs (or FCM’s iOS handling) expects. Here’s how to troubleshoot:

• Double-check your payload structure: APNs is pickier than FCM for Android. You must include the mandatory aps dictionary, and fields like alert need to be properly nested. Watch out for typos, missing commas, or extra fields that break JSON parsing — even a tiny syntax error can trigger this.
• Verify HTTP headers (if calling APNs directly): If you’re skipping FCM and hitting APNs directly, make sure you’ve got the right headers: Authorization with your server key, Content-Type: application/json, and apns-topic set to your app’s exact bundle ID. If using FCM for iOS, don’t mix in Android-specific payload fields that might confuse the serializer.
• Confirm iOS tokens are valid: iOS device tokens change when the app is reinstalled, the user resets their device, or the token expires. Using an outdated token can lead to APNs rejecting the request, which might cause serialization errors if your code isn’t handling failures cleanly.

That error in your FCM response tells you one of the registration tokens you sent is invalid. Since your result shows one success and one failure, it’s super likely you’re mixing iOS and Android tokens in the same FCM request. Here’s the fix:

• Split tokens by platform: FCM expects Android tokens in its standard endpoint requests, while iOS tokens should be handled separately (either via FCM’s iOS-specific setup or directly to APNs). Don’t put both types in the same registration_ids list — send separate requests for each platform.
• Validate Android tokens: Make sure the Android tokens you’re using are fresh and correctly formatted. Tokens go invalid if the app is uninstalled, the user clears app data, or the token expires. Check that each token is a 152-character string (the standard FCM token length) and hasn’t been revoked.
• Keep an eye on canonical IDs: Even though your response shows canonical_ids:0, remember that if FCM returns a canonical ID later, it means the token has been updated — you’ll need to replace the old one in your database to avoid future errors.

Duplicate pushes on Android usually boil down to three common issues:

• Accidental duplicate server requests: Check your server code to make sure you’re not sending the same push twice. This often happens if a network timeout makes your server think the request failed, so it retries even though FCM already processed it. Add an idempotency key (like using FCM’s collapse_key parameter) to prevent duplicates — FCM will ignore duplicate requests with the same key.
• Client-side token duplication: If your Android app registers for FCM every time it launches without checking if a valid token already exists, you might end up with multiple active tokens for the same device. Update your app to only register for a new token if it doesn’t have one stored, and sync any new tokens to your database right away.
• FCM retry behavior: FCM might resend a push if it doesn’t get an acknowledgment from the device. Make sure your Android app is properly handling notifications and sending the correct receipt back to FCM. If the app crashes immediately after receiving a push, FCM might assume it never arrived and resend it.

内容的提问来源于stack exchange，提问作者Michael