不使用Firebase前提下Flutter搭配Node.js实现稳定推送的最佳方案咨询

核心实现逻辑 #

要实现应用被强制关闭后仍能接收通知，必须依赖各平台的系统级推送通道，第三方应用自建的后台长连接会被系统回收，无法在进程销毁后存活，不需要FCM即可完成全链路实现。

端侧适配方案 #

• Android端：对接国内各厂商的系统推送服务，包含小米推送、华为推送、OPPO推送、VIVO推送、荣耀推送，所有厂商均提供不依赖FCM的独立推送通道，应用被强制关闭后系统级服务仍可正常分发通知。可直接使用flutter_push_kit这类封装了多厂商推送能力的Flutter库，无需单独适配每个厂商的原生SDK。
• iOS端：直接对接APNs（苹果官方推送通知服务），这是iOS唯一认可的系统级推送通道，应用销毁后也能正常接收通知，无需依赖Firebase中转。
• 前台通知优化：应用在前台运行时，监听系统推送的回调事件，收到推送后主动调用本地通知API弹出提示，避免系统默认策略限制前台通知展示；同时可搭配应用层WebSocket长连接做补充，前台运行时优先走WebSocket通道，延迟可控制在100ms以内，断连时自动降级到系统推送通道。

Node.js服务端实现 #

• 维护设备标识映射表：用户登录时将Android端的厂商推送token、iOS端的APNs device token上报到服务端，和用户ID绑定存储。
• 多通道推送适配：
  • 针对Android设备，直接调用对应厂商的服务端HTTP推送接口发送通知，所有厂商均提供公开的服务端API，可直接对接。
  • 针对iOS设备，使用npm包apns2直接对接APNs服务，无需经过第三方服务中转。
• 推送路由逻辑：根据设备类型自动选择对应推送通道，高优先级通知可同时下发WebSocket和系统通道，避免出现漏收情况。

注意事项 #

• Android端需要引导用户开启应用的通知权限、自启动权限，部分厂商默认禁止第三方应用的后台推送和通知弹出。
• iOS端需要用户主动同意通知权限，否则APNs无法正常下发通知。
• 不要单独依赖纯应用层的长连接方案（如WebSocket、MQTT）实现强制关闭后的推送，所有非系统级进程都会在应用被强制杀死后被系统回收，无法接收消息。

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