I'm developing an iOS chat with push notifications and I use Firebase Cloud Messaging but I have this problem:
我正在使用推送通知开发iOS聊天，我使用Firebase云消息传递，但我遇到了这个问题：
When the app is killed (not in background) there is a way to get a callback from the notification to get the content (the chat message)?
当应用程序被杀死（不在后台）时，有一种方法可以从通知中获取回调以获取内容（聊天消息）吗？
The only way to get a message and save it in the internal database is check on my server when I start the app if there is a unread message?
获取消息并将其保存在内部数据库中的唯一方法是在我启动应用程序时检查我的服务器是否有未读消息？
The documentantion of Firebase doesn't seem very clear on this argument. Only if I send a silent notification (without "notification" field) the app didReceiveRemoteNotification callback was called when I open the app but I can get only last notification. This callback isn't called in background
Firebase的文档在这个论点上似乎不太明确。只有当我发送静默通知（没有“通知”字段）时，才会在我打开应用程序时调用应用程序didReceiveRemoteNotification回调，但我只能收到最后一次通知。此回调不在后台调用
UPDATE 02/12/2016:
更新02/12/2016：
After a lot of tests, I have contacted apple support and they have responded to me with this email:
经过大量测试后，我联系了苹果支持，他们已经通过这封电子邮件回复了我：
I'm responding to your question about background push notifications.
我正在回答有关后台推送通知的问题。
This topic was first discussed in the WWDC 2013 session 204 WWDC 2013: What’s New with Multitasking. Silent push notifications (those whose payloads contain only the content-available key and no alert, badge, or sound keys) are throttled to be delivered only when iOS determines that it’s energy-efficient to do so.
本主题首次在WWDC 2013会议204 WWDC 2013中进行了讨论：多任务处理的新功能。静默推送通知（那些其有效负载仅包含内容可用密钥且没有警报，标记或声音密钥的通知）仅在iOS确定能够高效执行时才会受到限制。
Push notifications with user-visible keys such as alert, sound, or badge sent at high priority (priority 10) are always displayed. However, if the notification also contains the content-available key, the notification may be throttled and thus not be sent to the app in the background unless the user taps the notification.
始终显示具有用户可见键的推送通知，例如以高优先级（优先级10）发送的警报，声音或徽章。但是，如果通知还包含内容可用密钥，则通知可能会受到限制，因此除非用户点击通知，否则不会在后台发送到应用程序。
Notifications sent at low priority (priority 5) are throttled, regardless of payload. Silent push notifications should always be sent at low priority.
无论有效负载如何，以低优先级（优先级5）发送的通知都会受到限制。应始终以低优先级发送无提示推送通知。
As the WWDC session says, you may expect up to several silent push notifications per hour across all apps on a device. But it is entirely possible and appropriate that you may receive none at all.
正如WWDC会议所说，您可能希望设备上的所有应用每小时最多可以发送几次静音推送通知。但完全可能和恰当的是你根本不会收到任何东西。
The purpose of the throttle is to predict when the user will launch an app and thus allow background activity to update the app’s content in an energy-efficient manner. It also serves to prevent apps from consuming too much of the user’s battery or cellular data with background traffic.
节流的目的是预测用户何时启动应用程序，从而允许后台活动以节能方式更新应用程序的内容。它还可以防止应用程序使用后台流量消耗过多的用户电池或蜂窝数据。
Once the device-wide battery or data budgets have been exhausted, no more background push notifications will be delivered until the budgets are reset. The budgets are reset every 24 hours, and this schedule cannot be changed by user or developer action.
一旦设备范围的电池或数据预算耗尽，在重置预算之前不会再发送后台推送通知。预算每24小时重置一次，用户或开发人员操作无法更改此计划。
Since these budgets apply across all apps on a device, it’s possible that an app other than your own has exhausted the budgets. You can check the overall battery usage of an app in Settings > General > Usage > Battery Usage.
由于这些预算适用于设备上的所有应用，因此您自己以外的应用可能会耗尽预算。您可以在设置>常规>使用情况>电池使用情况中查看应用的总体电池使用情况。
The throttle also tracks when the device has poor network connectivity, because repeated attempts to connect to APNs when network connectivity is spotty can cause significant power drain. This is by far the most common reason why push notifications do not reach a device. To check if poor network connectivity is affecting your push notifications, you can use the steps in Observing Push Status Messages.
节流阀还跟踪设备网络连接不良的情况，因为当网络连接不稳定时连续尝试连接到APN会导致大量功耗。这是推送通知无法到达设备的最常见原因。要检查网络连接是否正在影响推送通知，可以使用“观察推送状态消息”中的步骤。
The throttle is disabled if you run your app with a debugger attached. This allows you to test that your notifications are being received correctly, but should only be considered a best-case scenario.
如果您使用附加的调试器运行应用程序，则禁用限制。这允许您测试正确接收通知，但只应被视为最佳情况。
Additionally, starting with iOS 9, users have the ability to turn the throttle on any time they please by turning on Low Power Mode in Settings > Battery.
此外，从iOS 9开始，用户可以通过打开设置>电池中的低功耗模式随时打开油门。
To test background push notifications, follow these steps.
要测试后台推送通知，请按照下列步骤操作。
- Attach your device to your Mac.
- 将您的设备连接到Mac。
- Start your app from Xcode.
- 从Xcode启动您的应用程序。
- When it has launched, stop your app from within Xcode by clicking the Stop button (square icon at upper left).
- 启动后，单击“停止”按钮（左上角的方形图标），从Xcode中停止应用程序。
- In Xcode, do Debug -> Attach to Process -> [Fill in Process Name to wait for] -> Attach
- 在Xcode中，执行Debug - > Attach to Process - > [Fill in Process Name to waiting] - > Attach
- Send the push notification with content-available:1 and your app will receive the notification every time.
- 发送内容可用的推送通知：1，您的应用每次都会收到通知。
You can use the process list in Instruments to confirm that your app is running in the background.
您可以使用Instruments中的进程列表确认您的应用程序是在后台运行的。
You can also test using Wi-Fi and a device that is plugged in to wall power.
您还可以使用Wi-Fi和插入墙上电源的设备进行测试。
If you’re sending silent push notifications, be sure you’re using the APNs Provider API or the Binary Provider API so you can set the notification priority to 5. (The default priority is 10.)
如果您要发送静默推送通知，请确保使用APNs Provider API或二进制提供程序API，以便将通知优先级设置为5.（默认优先级为10.）
If you believe throttling is not working properly, please file a bug report at https://developer.apple.com/bug-reporting. The details of how throttling works are not public API, but iOS Engineering looks at these bug reports and can determine if notifications are being throttled as expected.
如果您认为限制无法正常工作，请通过https://developer.apple.com/bug-reporting提交错误报告。限制工作的详细信息不是公共API，但iOS工程师会查看这些错误报告，并可以确定通知是否按预期受到限制。
The important point is that apps should never be designed expecting that every push notification will be received. This is not how APNs is intended to work; it is intended to inform the user or app that some event of interest has occurred. Apps are expected to work properly, albeit perhaps with degraded functionality, if push notifications are not received. The user can turn off push notifications or background app updates at any time, and of course push notifications will not be received if the device doesn’t have Internet connectivity.
重要的是，应该永远不要设计应用程序，期望每次推送通知都会被收到。这不是APN的工作方式;它旨在通知用户或应用程序发生了一些感兴趣的事件。如果未收到推送通知，预计应用程序可以正常工作，但可能会降低功能。用户可以随时关闭推送通知或后台应用程序更新，当然，如果设备没有Internet连接，则不会收到推送通知。
Starting with iOS 7, all background categories except location and VoIP (on iOS 9.3 and later) behave consistently when a user force-quits an app from the multitasking display. An app will not be launched again automatically until the user chooses to launch it again. This respects the user's intent not to have the app running, which can be a very important recovery technique if an app is misbehaving and crashing on launch.
从iOS 7开始，当用户从多任务显示器强制退出应用程序时，除位置和VoIP（在iOS 9.3及更高版本上）之外的所有背景类别都表现一致。在用户选择再次启动应用程序之前，不会再自动启动应用程序。这尊重用户不让应用程序运行的意图，如果应用程序在启动时行为不端并崩溃，这可能是一项非常重要的恢复技术。
If you close an app that has been configured to receive background notifications, it won't receive them until it has been reopened.
如果您关闭已配置为接收后台通知的应用，则在重新打开后才会收到它们。
After this email, I have tried to send a notification with Telegram killed. Telegram receive the push notification and show it but if I open the app after setting the offline mode the message isn't shown in the chat (this mean that surely telegram contact server to check unread message when I open it)! Instead whatsapp can add message in background because it is a VoIP app and it can call a background callback.
在这封电子邮件之后，我试图发送电报被杀的通知。电报收到推送通知并显示它，但是如果我在设置离线模式后打开应用程序，则消息不会显示在聊天中（这意味着当我打开它时，确实是电报联系服务器检查未读消息）！相反，whatsapp可以在后台添加消息，因为它是一个VoIP应用程序，它可以调用后台回调。
So the only way to add message is contact the server and get the unread message.
因此，添加消息的唯一方法是联系服务器并获取未读消息。
There is the same problem in android but probably you can solve it with a background service (and restart it when it is killed).
Android中存在同样的问题，但可能你可以使用后台服务来解决它（并在它被杀死时重启它）。
Now I have to choose if use Apple Push notifications or FCM push notifications. The reliability is the same? (Because, for example, Telegram in android uses both a proprietary push service and FCM because they say that FCM isn't very reliable)
现在我必须选择是否使用Apple推送通知或FCM推送通知。可靠性是一样的吗？ （因为，例如，Android中的Telegram使用专有的推送服务和FCM，因为他们说FCM不是很可靠）
1 个解决方案
#1
2
Messaging apps on iOS need to check on the server when they launch to catch up a local database with the state of the server. Push notifications are not the right mechanism to use to keep your iOS internal database synchronized with your server.
iOS上的消息传递应用程序需要在服务器启动时检查服务器，以便使用服务器状态来跟踪本地数据库。推送通知不是用于使iOS内部数据库与服务器保持同步的正确机制。
#1
2
Messaging apps on iOS need to check on the server when they launch to catch up a local database with the state of the server. Push notifications are not the right mechanism to use to keep your iOS internal database synchronized with your server.
iOS上的消息传递应用程序需要在服务器启动时检查服务器，以便使用服务器状态来跟踪本地数据库。推送通知不是用于使iOS内部数据库与服务器保持同步的正确机制。