在说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更新。但不需要做对应页面的跳转。不希望打断用户当前的行为。
网友评论