iOS 推送通知与杀死的应用程序 - swift

Question

我正在开发带有推送通知的 iOS 聊天，并使用 Firebase Cloud Messaging，但遇到以下问题:

当应用程序被终止(不在后台)时，有没有办法从通知中获取回调以获取内容(聊天消息)？

获取消息并将其保存在内部数据库中的唯一方法是在启动应用程序时检查我的服务器是否有未读消息？

Firebase 的文档似乎对此论点不是很清楚。仅当我发送静默通知(没有“通知”字段)时，当我打开应用程序时，才会调用应用程序 didReceiveRemoteNotification 回调，但我只能收到最后一个通知。此回调不会在后台调用

2016 年 2 月 12 日更新:

经过多次测试，我联系了苹果支持人员，他们通过这封电子邮件回复了我:

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.

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.

Notifications sent at low priority (priority 5) are throttled, regardless of payload. Silent push notifications should always be sent at low priority.

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.

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.

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.

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.

To test background push notifications, follow these steps.

1. Attach your device to your Mac.
2. Start your app from Xcode.
3. When it has launched, stop your app from within Xcode by clicking the Stop button (square icon at upper left).
4. In Xcode, do Debug -> Attach to Process -> [Fill in Process Name to wait for] -> Attach
5. Send the push notification with content-available:1 and your app will receive the notification every time.

You can use the process list in Instruments to confirm that your app is running in the background.

You can also test using Wi-Fi and a device that is plugged in to wall power.

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.)

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.

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.

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.

If you close an app that has been configured to receive background notifications, it won't receive them until it has been reopened.

在这封电子邮件之后，我尝试发送一条 Telegram 被杀死的通知。 Telegram 接收推送通知并显示它，但如果我在设置离线模式后打开应用程序，消息不会显示在聊天中(这意味着当我打开它时，Telegram 肯定会联系服务器检查未读消息)!相反，whatsapp 可以在后台添加消息，因为它是 VoIP 应用程序，并且可以调用后台回调。

所以添加消息的唯一方法是联系服务器并获取未读消息。

在android中也有同样的问题，但也许你可以通过后台服务来解决它(并在它被杀死时重新启动它)。

现在我必须选择是使用 Apple 推送通知还是 FCM 推送通知。可靠性是一样的吗？ (因为，例如，Android 中的 Telegram 同时使用专有推送服务和 FCM，因为他们说 FCM 不太可靠)

Answer 1

iOS 上的消息传递应用程序在启动时需要检查服务器，以 catch 本地数据库与服务器的状态。推送通知不是用于保持 iOS 内部数据库与服务器同步的正确机制。