移动App全状态下向Node.js后端发送实时位置与告警的架构如何设计？

Android 8.0及以上系统对后台长连接、后台服务做了严格的电量优化限制，非白名单应用的后台长连接会在数秒内被系统切断，进程被杀死后Socket连接自然销毁，强行保活的适配成本极高且容易被厂商电量管理策略拦截，因此不建议继续坚持单Socket.io长连接的方案，推荐采用分层传输架构兼顾性能、可靠性与扩展性：

• 端侧分层传输逻辑
  • 前台状态：继续沿用现有Socket.io长连接方案，低延迟传输实时数据，无需改造现有逻辑即可满足前台实时性要求
  • 后台状态：放弃强行维持长连接，改用Android官方推荐的WorkManager实现周期性上报任务，采集到的位置、告警数据先持久化到本地Room数据库，按照业务可接受的延迟（1-5分钟可调）批量调用服务端HTTP接口上报，上报成功后删除对应本地缓存
  • 进程杀死状态：基于谷歌位置服务FusedLocationProviderApi的PendingIntent回调实现唤醒触发，系统检测到位置更新时会主动拉起App组件写入数据到本地缓存，下一次App启动或后台周期任务触发时统一补上报；高优先级告警数据可通过系统级推送通道直接触发上报
• 服务端适配逻辑
  • 新增批量上报HTTP接口，支持单次请求提交多条位置、告警数据，写入MongoDB的逻辑与现有Socket.io上报逻辑复用即可
  • 新增数据去重逻辑，端侧为每条生成唯一UUID作为去重标识，避免同一数据通过多通道重复入库
• 兜底可靠性机制：所有未上报成功的数据全部持久化在端侧本地存储，只要App未被用户卸载，哪怕设备重启，下次App启动后都会自动触发补上报，不会出现数据丢失

• 若你的应用面向海外市场发布，Firebase是性价比极高的选择：
  • 高优先级告警数据可通过Firebase Cloud Messaging(FCM)的系统级透传通道实现上报，无需维持长连接即可在后台、进程杀死状态下传递数据，稳定性远高于自研长连接
  • 可直接使用Firebase Realtime Database/Firestore的端侧离线持久化能力，SDK自动缓存写入的位置、告警数据，网络恢复或App恢复运行时自动同步到云端，无需自行开发本地缓存、重试、补上报逻辑，开发成本极低
  • 管理门户的实时展示需求可直接对接Firebase的实时数据变更推送能力，无需自行开发服务端实时推送服务
• 若你的应用面向国内市场发布，Firebase服务无法正常使用，可采用如下替代方案：
  • 推送通道：接入小米、华为、OPPO、vivo等主流厂商的系统级推送通道，替代FCM实现高优先级告警的跨状态上报
  • 数据同步：可选用国内云厂商的移动开发平台实时数据同步服务，或自行实现上述WorkManager+本地缓存+HTTP接口的自研架构

如果你的业务对位置上报的实时性要求达到秒级，可申请Android前台服务权限，通过常驻通知栏的前台服务维持Socket.io长连接，这是Android官方允许的后台长连接方案，不会被系统主动切断，适合导航、物流调度等强实时性场景，仅需告知用户常驻通知的用途即可。

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