我已经实现了基于推送的调用，效果很好，但这似乎完全破坏了后台调用。
当他们在后台有应用程序但未关闭时调用另一个用户时，他们会按预期收到本地通知。
从这个通知启动应用程序时，在中继本地通知后，调用者应用程序立即尝试通过 shouldSendPushNotifications 启动推送调用： - 疯狂的是这个方法被快速连续调用 10 次。
然后，这将通过接收者 - 现在我们有两个电话要处理，这最终会破坏我的 UI。我已经破解了它以阻止我的应用程序崩溃，我现在检查客户端是否已经初始化（它将在处理本地通知时，而不是在处理推送时），这似乎解决了这个问题。
有谁知道为什么会发生这种情况？只有在 Sinch 客户端中同时启用了 push 和 local 时才会发生这种情况。
shouldSendPushNotifications:多次调用的问题，可能使用相同的数据提供（相同的推送数据和推送有效负载）来自每一对可能代表特定用户 ID 的一个应用程序安装。因此，如果您在同一设备上多次卸载/安装了该应用程序，并且在设备上设置了不同的选项SINClient（例如setSupportPushNotifications，使用“否”然后是“是”），这可能是该问题的一部分。尽管我们 Sinch 正在为此研究解决方案，但这将消除具有相同信息的回调。
即使其他客户端已开始应答呼叫，您也可能会看到被调用的事实shouldSendPushNotifications:是因为推送机制旨在基于其他客户端在特定时间窗口内缺乏响应/确认来触发。如果另一个客户端在后台但启用了 VoIP 模式，它会尽快发送一个 ACK，这应该会阻止推送机制触发。但是，如果在时间窗口内没有收到该 ACK，则触发推送机制。因此，当与 VoIP 模式结合使用时，推送机制可以被认为是一种尽力而为的回退机制。尽管在您的情况下，我怀疑与上一节中描述的每个应用程序安装功能有关，我们正在努力改进这一点。
尽管如此，因为推送机制也可能在网络条件过慢的情况下触发，并且来自另一个客户端的 ACK 花费的时间比“预期的最坏情况”（当前为 4 秒）要长，因此您的应用程序必须处理即使在收到 didReceiveIncomingCall-callback 后不久也收到远程推送通知的情况。这里的关键是它实际上不是两个不同的调用，但您可以使用SINNotificationResultand-[SINCallNotificationResult callId]来识别它是同一个调用。例如，如果您首先收到一个didReceiveIncomingCall:-callback 并最终使用-[SINClient relayLocalNotification:]，那么在您收到推送通知并将其传递给 ] 后不久-[SINClient relayRemotePushNotificationPayload:，您将看到两个“通知结果”将包含相同的内容callId，您可以使用它来适当地管理您的 UI。
感谢您对 Sinch SDK 的出色反馈，我们 Sinch 将研究简化推送通知和本地通知处理的方法。