推送通知基础（2之2）
我完成了上一篇文章，总结了如何配置您的应用程序以接收推送通知，但是我没有讨论一旦这些通知到达时您可以怎么做。
所以我们开始。
除非您可以响应这些推送通知，否则向您的设备发送推送通知并没有真正的帮助。 这就是我今天将向您介绍的内容。 具体来说，以下内容：
- 响应用户对推送通知的操作
- 在前台处理推送通知
- 在后台处理推送通知
1和2均由UNUserNotificationCenter处理，其中3由UIApplicationDelegate严格处理。
响应用户对推送通知的操作
UNUserNotificationCenter是一个非常强大的API，它使您可以计划本地通知，配置推送通知动作以及与用户对推送通知的动作进行交互。 iOS在通知方面已经走了很长一段路，而这仅仅是帮助开发人员构建美好体验的另一层。
我们将只专注于响应用户操作。
当推送通知发送到设备时，会显示类似的内容
用户可以选择向右滑动并打开推送通知，或向左滑动并查看一些选项。
无论用户做什么，应用程序都将完全相同地处理它。 UNUserNotificationCenter具有使用方法userNotificationCenter(didReceive: withCompletionHandler:)的协议UNUserNotificationCenterDelegate 。 这是进入应用程序的入口点 。
启用此功能后，我们现在可以在后台响应远程通知。
将通知有效内容中的content-available标志设置为1可使您的应用程序知道有信息要处理，它将触发必要的应用程序委托回调方法。
func application（_ application：UIApplication，didReceiveRemoteNotification userInfo：[AnyHashable：Any]，fetchCompletionHandlercompleteHandler：@转义（UIBackgroundFetchResult）->无效）
与我们通过UNUserNotificationCenterDelegate获得的UNNotificationResponse对象不同，我们在UNUserNotificationCenterDelegate获得准系统有效负载[AnyHashable: Any] 。 用户尚未与推送通知进行交互，因此动作标识符将是无关紧要的。
但是，我们得到了completionHandler 。 再次使用此完成处理程序来让系统知道任何处理已完成。 这对系统很重要，因此可以
- 再次终止应用程序
- 将应用程序保留在后台，但减少分配给该应用程序的资源量
yada yada yada有助于延长电池寿命，保持系统效率。
此完成处理程序和用户通知完成处理程序之间的区别在于其签名。 这里的完成处理程序采用UIBackgroundFetchResult ，它可以是noData ， newData或failed 。 这很清楚，该处理应该是进行任何更新的快速网络调用 ，因为该应用程序没有太多的活动时间（实际上，我相信这是30秒左右）。
后台远程通知的主要动机是，当用户进入“多任务”模式时，他们可以查看每个应用程序的最新状态。 老实说，这提供了相当不错的用户体验;）。
后台远程通知处理不应与后台获取混淆，后台获取是后台工作的一个完全不同的方面。 我将在以后的文章中专门介绍后台获取。
希望您能读一读！ 更多款待即将推出！