Ionic开发安卓点餐APP后台/进程被杀时新订单响铃方案咨询

问题背景 #

• 业务场景：网站在线点餐系统配套安卓员工端APP，核心需求为新订单到达时循环播放提示音
• 技术栈：基于Ionic + Vue.js + Capacitor开发，原有实现采用WebSocket做实时通信，搭配音频插件播放提示音，前台活跃状态下功能正常，切后台/进程被杀后无法触发提示
• 已尝试的无效方案：
  • 接入Insomnia插件阻止APP休眠：仅能实现屏幕常亮，设备持续充电状态下运行一段时间后，新订单到达仍无法触发音频播放
  • 接入Background插件开启后台运行模式：无可见常驻通知，运行一段时间后APP仍会被系统杀死

上述两类方案均属于绕开安卓系统管控规则的非正规实现，无法作为长期稳定方案使用：Insomnia仅控制屏幕休眠逻辑，没有解决安卓对后台进程的CPU调度限制、网络权限限制；普通第三方后台插件启动的是隐式后台服务，从Android 9版本开始，这类无用户感知的后台服务切后台1分钟左右就会被系统主动回收，国内定制ROM的管控规则更严格，回收速度更快。

推荐正规实现方案 #

方案1：系统级推送通道+前台通知/前台服务（首选，支持APP进程被杀场景） #

这是安卓官方认可的、稳定性最高的实现方式，完全不需要依赖APP进程保活：

• 核心逻辑：放弃依赖APP端维护WebSocket长连接收消息的逻辑，改为新订单生成时，由服务端直接向设备推送高优先级系统级推送消息。推送通道走各厂商系统自带的长连接服务（海外设备走FCM，国内设备分别对接华为、小米、OPPO、vivo等主流厂商的官方推送SDK），这类长连接由系统核心进程维护，哪怕APP进程完全被杀死，只要设备联网就能收到消息。
• 提示音实现逻辑：
  • 推送消息携带自定义订单提醒铃声，消息到达后系统会自动弹出通知并播放第一遍提示音
  • 如果需要实现循环播放，有两种可选实现：
    1. 用户点击通知唤起APP后，触发APP内的循环播放逻辑，直到员工手动确认接单后停止
    2. 收到推送后启动官方合规的Foreground Service（前台服务），服务必须在通知栏常驻"待处理新订单"的可见通知（用户可感知，不能隐藏），在服务内触发循环音频播放，员工确认接单后停止服务、移除通知
• 适配注意事项：
  • 必须使用厂商通道的高优先级推送类型，不要用普通优先级消息，否则会被系统做延迟投递、消息限速，甚至直接拦截
  • 国内发售的安卓设备大多没有预装谷歌服务，FCM通道可用性极低，必须对接对应设备厂商的官方推送SDK才能保证到达率

方案2：独立前台服务承载WebSocket连接（备选，无需对接多厂商推送） #

如果不想对接多个厂商的推送SDK，可以把核心连接和提醒逻辑从WebView层拆到原生前台服务中运行：

• 不要使用第三方后台插件的隐式后台服务，直接在Capacitor中编写原生安卓代码实现独立前台服务：
  • 服务启动后立刻在通知栏常驻"接单服务运行中"的可见通知，标记为正在进行的前台服务类型
  • 将WebSocket连接维护、新订单消息监听、音频触发逻辑全部放到该前台服务进程中，不依赖Ionic WebView的运行状态
  • 新订单到达时，服务直接弹出通知、触发循环提示音，不需要唤起APP主界面
• 适配注意事项：
  • 首次启动时需要引导用户手动给APP开启自启动、后台活动无限制、关闭电池优化三个权限，国内定制ROM如果不开这三个权限，前台服务仍可能在锁屏后被系统杀死
  • 该方案稳定性弱于系统推送方案，极端省电模式、内存极度紧张场景下仍存在被回收的可能

方案3：轻量原生端替代思路（跨端适配成本过高时可选） #

如果Ionic框架下做原生适配的成本过高，可以直接开发一个功能极简的原生安卓APP，只保留推送接收、新订单通知、循环提示音、接单确认四个核心功能，订单数据通过服务端接口同步即可。原生APP的后台管控适配成本远低于跨端套壳APP，体积小、运行稳定，整体开发量并不高。

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