关于iOS的Push Notification的响应

在说Push Notification的响应之前，先来讨论下iOS应用程序的状态，回调方法以及状态切换

应用程序的状态

状态	说明	描述
Not Running	未运行	程序没启动
Inactive	未激活	程序在前台运行，不过没有接收到事件。在没有事件处理情况下程序通常停留在这个状态
Active	激活	程序在前台运行而且接收到了事件。这也是前台的一个正常的模式
Backgroud	后台	程序在后台而且能执行代码，大多数程序进入这个状态后会在在这个状态上停留一会。时间到之后会进入挂起状态(Suspended)。有的程序经过特殊的请求后可以长期处于Backgroud状态
Suspended	挂起	程序在后台不能执行代码。系统会自动把程序变成这个状态而且不会发出通知。当挂起时，程序还是停留在内存中的，当系统内存低时，系统就把挂起的程序清除掉，为前台程序提供更多的内存。

回调方法

application:didFinishLaunchingWithOptions:

-  本地通知：UIApplicationDidFinishLaunchingNotification
-  触发时机：程序启动并进行初始化的时候后。
-  适宜操作：这个阶段应该进行根视图的创建。

applicationDidBecomeActive：

-  本地通知：UIApplicationDidBecomeActiveNotification
-  触发时机：程序进入前台并处于活动状态时调用。
-  适宜操作：这个阶段应该恢复UI状态（例如游戏状态）。

applicationWillResignActive:

-  本地通知：UIApplicationWillResignActiveNotification
-  触发时机：从活动状态进入非活动状态。
-  适宜操作：这个阶段应该保存UI状态（例如游戏状态）。

applicationDidEnterBackground:

-  本地通知：UIApplicationDidEnterBackgroundNotification
-  触发时机：程序进入后台时调用。
-  适宜操作：这个阶段应该保存用户数据，释放一些资源（例如释放数据库资源）。

applicationWillEnterForeground：

-  本地通知：UIApplicationWillEnterForegroundNotification
-  触发时机：程序进入前台，但是还没有处于活动状态时调用。
-  适宜操作：这个阶段应该恢复用户数据。

applicationWillTerminate:

-  本地通知：UIApplicationWillTerminateNotification
-  触发时机：程序被杀死时调用。
-  适宜操作：这个阶段应该进行释放一些资源和保存用户数据。

状态切换
- 启动程序
  Not running =》Inactive =》Active
  - willFinishLaunchingWithOptions
  - didFinishLaunchingWithOptions
  - applicationDidBecomeActive
- 按下home键
  Active =》Inactive =》Background =》(Suspended =》Not Running)
  - applicationWillResignActive
  - applicationDidEnterBackground
  - applicationWillTerminate:
- 双击home键，再打开程序
  - applicationWillEnterForeground
  - applicationDidBecomeActive

言归正传，来说说Push Notification的响应。首先说iOS 10 之前。回调函数有两个，分别是

application:didReceiveRemoteNotification:
application:didReceiveRemoteNotification:fetchCompletionHandler:

这两个函数有什么区别呢？
简单来说，iOS7以上，你只需要实现第二个函数即可。因为如果你两个函数都实现的化，程序只会调用第二个。（相信现在也没有什么iOS不支持iOS7了吧。）
具体的请参考苹果文档
https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623117-application
https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623013-application

那么什么情况下application: didReceiveRemoteNotification: fetchCompletionHandler: 会被触发？

APP状态	消息推送	用户操作	是否触发
Not Running	收到推送消息提示	点击消息	YES
Not Running	收到推送消息提示	点击APP	NO
Background	收到推送消息提示	点击消息	YES
Background	收到推送消息提示	点击APP	NO
Active	无推送消息提示	无	YES

结论：如果应用不在激活状态，点击APP激活应用是不会触发application:didReceiveRemoteNotification:fetchCompletionHandler函数的，只有点击推送过来的消息，才会触发函数调用。

此外，在iOS7之后，不需要再考虑在应用未启动状态下，接到推送消息，在application: didFinishLaunchingWithOptions:中获取推送信息了。因为application:didReceiveRemoteNotification:fetchCompletionHandler在这种情况下会被调用。如果还继续在application: didFinishLaunchingWithOptions:中做推送处理，那么就会出现重复。

再看iOS10的情况，iOS10提供了两个delegate函数，分别对应应用处于激活状态和非激活状态

userNotificationCenter:willPresentNotification:withCompletionHandler:
userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:

APP状态	消息推送	用户操作	是否触发
Not Running	收到推送消息提示	点击消息	触发 didReceiveNotificationResponse
Not Running	收到推送消息提示	点击APP	NO
Background	收到推送消息提示	点击消息	触发 didReceiveNotificationResponse
Background	收到推送消息提示	点击APP	NO
Active	可自定义	无	触发willPresentNotification

触发willPresentNotification可自定义是否弹出消息提示，此时，若点击消息提示，则会调用didReceiveNotificationResponse。

综上，正确处理badge更新的好时机

程序不在前台
- 我们可以在applicationDidBecomeActive函数中从服务器获取各个badge的信息，并进行UI更新。
- application:didReceiveRemoteNotification:fetchCompletionHandler 和application:didReceiveRemoteNotification:fetchCompletionHandler函数内仅处理对应页面的跳转。
程序在前台
application:didReceiveRemoteNotification:fetchCompletionHandler 和userNotificationCenter:willPresentNotification:withCompletionHandler函数内从服务器获取各个badge的信息，并进行UI更新。但不需要做对应页面的跳转。不希望打断用户当前的行为。

参考： iOS应用程序生命周期(前后台切换,应用的各种状态)详解