移动应用Twilio Video/Calling推送不稳定 寻求可靠实时通话方案

呼叫发起层的替代/补充方案 #

• FCM+本地长连接双路兜底：不要完全依赖FCM，自行搭建轻量WebSocket长连接服务，用户应用在前台或后台存活时，走WebSocket发送呼叫信令，只有当WebSocket断连超过30s时才 fallback 到FCM推送。信令需携带唯一呼叫ID、发起方信息、Twilio Room名，接收方收到任意一路信令都可触发呼叫弹窗，避免单路推送丢失的问题。
• 呼叫信令做幂等和重试：呼叫发起后，前15s每2s重发一次WebSocket信令，FCM推送也至少发2次（间隔3s），接收方收到重复信令后根据唯一呼叫ID去重，不会重复触发弹窗。
• 优先用Twilio自带的信令通道做存活设备触达：Twilio Video本身提供了DataTrack API，双方如果已经在之前的会话中建立过连接、或在线状态已同步到服务端，可以直接用DataTrack发送呼叫请求，延迟比FCM低很多，可靠性也更高。

接收方后台/进程被杀死场景的处理方案 #

• 后台存活场景：安卓端需申请FOREGROUND_SERVICE权限，应用退后台后启动轻量前台服务保活WebSocket连接，同时监听FCM的高优先级推送，安卓12及以上的高优先级推送默认可以唤醒应用的呼叫组件，不需要应用在前台。iOS端需配置VoIP推送，不要用普通远程推送，VoIP推送是苹果专门为实时通话场景设计的，优先级最高，只要设备没有把应用彻底拉黑，就算应用在后台也会触发PKPushRegistry的回调，可在回调里直接弹出呼叫界面，不需要用户手动点击推送。
• 进程被杀死场景：安卓端FCM的高优先级推送可以直接拉起应用进程，在推送的服务回调里直接初始化呼叫模块弹出呼入界面即可，国内安卓定制ROM要额外适配各个厂商的推送通道（小米、华为、OPPO、VIVO的厂商推送），替换FCM作为兜底推送通道，避免国产ROM对谷歌服务的限制导致推送收不到。iOS端的VoIP推送也支持在进程被杀死的场景下拉起应用进程，只需在Xcode里开启Background Modes的Voice over IP权限，就可以在收到VoIP推送后直接唤起呼叫界面。
• 异常情况处理：如果接收方设备离线、或推送/长连接都触达失败，发起方等待20s后自动提示呼叫无人接听，同时给接收方发送一条未接来电的普通推送，等用户上线后可以看到呼叫记录。

最佳实践注意点 #

• 所有呼叫信令的超时时间统一设置为20s，超过时间直接结束呼叫流程，避免两边状态不一致。
• 服务端要维护所有用户的在线状态（WebSocket连接状态、最近活跃时间），发起呼叫的时候优先走在线用户的长连接通道，只有离线用户才走推送通道，可以减少不必要的推送资源消耗，也能提升呼叫响应速度。
• 安卓端要针对国产ROM做保活和推送权限的引导，提示用户把应用加入自启动白名单、关闭电池优化，进一步提升后台触达的成功率。

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