在说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
- 触发时机：程序被杀死时调用。
- 适宜操作：这个阶段应该进行释放一些资源和保存用户数据。
- application:didFinishLaunchingWithOptions:
-
状态切换
- 启动程序
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
| APP状态 | 消息推送 | 用户操作 | 是否触发 |
|---|---|---|---|
| Not Running | 收到推送消息提示 | 点击消息 | YES |
| Not Running | 收到推送消息提示 | 点击APP | NO |
| Background | 收到推送消息提示 | 点击消息 | YES |
| Background | 收到推送消息提示 | 点击APP | NO |
| Active | 无推送消息提示 | 无 | YES |
那么什么情况下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更新。但不需要做对应页面的跳转。不希望打断用户当前的行为。
