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