我一直在研究在 React Native 应用程序中实现消息传递的不同选项，特别是从服务器向客户端代码发送消息。我发现了两个主要选项:推送通知和应用内消息。
推送通知可以通过 Firebase 和 OneSignal 等服务来实现，并且运行良好，但有人声称它们不太可靠，有时消息可能会丢失。推送通知的优点是，无论应用程序处于前台还是后台，它们都可以工作。
应用内消息可以通过事件总线服务实现，例如 SignalR(Azure 或独立)、AWS SNS 或 GraphQL 订阅。这些服务非常可靠，但这种方法仅在应用程序位于前台时才有效。
但是，似乎还有另一种选择似乎不像前两种那么受欢迎。此选项涉及在移动设备上运行 native 后台服务/进程，该服务/进程参与应用程序内消息交换，类似于正常的应用程序内消息传递。后台服务将订阅 SignalR 或 SNS 或 GraphQL，并在收到消息时在设备上显示本地通知。
最后一种方法有什么问题？为什么不喜欢它而不是似乎更常用的混合方法(当应用程序在后台时推送通知，而当应用程序在前台时推送应用程序内消息)？
谢谢!
最佳答案
主要限制是移动设备不允许应用程序在后台保持长期连接打开。此限制在 Android 8 (Oreo) 中得到了更严格的执行(记录在 https://developer.android.com/about/versions/oreo/background#services )，并且在 iOS 上一直如此。某些 VoIP 应用程序存在异常(exception)情况，但一般来说，此规则适用于所有应用程序。
关键原因之一是电池生命周期。保持连接打开需要少量的能量，如果用户有数十个这样的应用程序，那么这将是一个值得注意的问题。因此，Google 和 Apple 都已标准化，向设备开放一个连接，所有通知都通过该连接传递。
就其值(value)而言，iOS 通知实际上非常可靠且一致。 Android由于各OEM厂商的修改，问题较多。 (记录在此处:https://dontkillmyapp.com/)
一种解决方法是，您可以在 Google Play 商店之外分发一个应用程序，通过请求特殊权限来绕过此限制，但是，它仍然会受到 OEM 问题的影响，就像 FCM 一样，而且可能更糟。
关于firebase - react native : in-app messages when app is in background，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/62527014/