iOS（Objective-C）：新Firebase推送通知到来时清除所有旧通知

这确实是个挺头疼的推送时序问题——网络波动导致旧通知“迟到”，一下子堆在通知栏里，用户体验肯定不好。只清角标确实治标不治本，下面分Android和iOS两个平台给你具体的实现建议：

Android端实现方案 #

1. 用固定通知ID覆盖旧通知 #

Android的通知系统本身就支持同ID替换：只要你给所有推送通知设置同一个固定ID，新通知送达时会直接覆盖掉之前所有用这个ID发送的旧通知。

比如在FirebaseMessagingService的onMessageReceived方法里，构建通知后用同一个ID发送：

// 定义一个固定的通知ID，比如10001
private const val NOTIFICATION_ID = 10001

override fun onMessageReceived(remoteMessage: RemoteMessage) {
    // 构建你的通知内容
    val notification = NotificationCompat.Builder(this, CHANNEL_ID)
        .setContentTitle(remoteMessage.notification?.title)
        .setContentText(remoteMessage.notification?.body)
        .setSmallIcon(R.drawable.ic_notification)
        .build()

    // 用固定ID发送，新通知会直接替换旧通知
    NotificationManagerCompat.from(this).notify(NOTIFICATION_ID, notification)
}

如果需要按业务类型分组（比如消息通知和系统通知分开处理），也可以给不同类型设置不同的固定ID，保证同类型的通知互相覆盖。

2. 收到新通知时主动清空所有旧通知 #

如果需要更彻底的清空（不管类型，新通知一来就清空所有旧通知），可以在发送新通知前，先调用cancelAll()清除所有应用通知：

override fun onMessageReceived(remoteMessage: RemoteMessage) {
    // 先清空所有已展示的通知
    NotificationManagerCompat.from(this).cancelAll()
    
    // 再构建并发送新通知
    val notification = NotificationCompat.Builder(this, CHANNEL_ID)
        // ... 通知配置
        .build()
    NotificationManagerCompat.from(this).notify(NOTIFICATION_ID, notification)
}

iOS端实现方案 #

1. 利用APNS的apns-collapse-id字段（推荐） #

iOS的APNS服务原生支持通知合并，你只需要在后端发送推送请求时，带上apns-collapse-id字段。当APNS收到同一个用户的多条带相同collapse-id的推送时，只会保留最新的那条推送到设备，旧的未送达通知会被直接丢弃，从根源上解决滞后问题。

比如用Firebase Admin SDK发送推送时，设置这个字段：

// Node.js示例
admin.messaging().sendToDevice(token, {
    notification: {
        title: "新通知",
        body: "这是最新的通知内容"
    },
    apns: {
        payload: {
            aps: {
                // 其他APNS配置
            }
        },
        headers: {
            "apns-collapse-id": "user_12345" // 用用户ID作为collapse-id，保证同一用户的通知合并
        }
    }
});

这个方案不需要客户端做额外处理，由APNS直接管控，是最省心的方式。

2. 客户端收到通知时清除旧通知 #

如果需要在客户端主动处理，可以在收到新通知前，清空本地通知中心的所有已送达通知：

前台/后台活跃场景（AppDelegate）

func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any]) async -> UIBackgroundFetchResult {
    // 清空所有旧通知
    UNUserNotificationCenter.current().removeAllDeliveredNotifications()
    
    // 处理新通知（如果需要手动展示）
    let content = UNMutableNotificationContent()
    content.title = userInfo["title"] as? String ?? ""
    content.body = userInfo["body"] as? String ?? ""
    let request = UNNotificationRequest(identifier: UUID().uuidString, content: content, trigger: nil)
    UNUserNotificationCenter.current().add(request)
    
    return .newData
}

后台静默推送/通知扩展场景（Notification Service Extension）

如果推送是静默通知或者需要修改通知内容，可以在Extension里先清空旧通知：

override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) {
    // 清空所有旧通知
    UNUserNotificationCenter.current().removeAllDeliveredNotifications()
    
    // 处理新通知内容
    let modifiedContent = request.content.mutableCopy() as! UNMutableNotificationContent
    // ... 修改通知内容
    contentHandler(modifiedContent)
}

额外注意事项 #

• 后端配合是关键：不管是Android的通知ID还是iOS的apns-collapse-id，建议在后端统一设置，避免客户端不同版本处理不一致。
• 按需分组清除：如果你的应用有不同类型的通知（比如聊天消息和系统公告），可以按类型设置不同的ID/collapse-id，只清除同类型的旧通知，不要一刀切清空所有。
• 测试延迟场景：可以用Firebase Console的延迟发送功能，或者后端工具模拟推送延迟，验证你的方案是否能正确覆盖/清除旧通知。

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