一、引言
应用开发到一定阶段的时候，运行为了吸引用户提高应用的使用频率，消息推送这个简单的功能是比不可少的。对于 iOS 应用的推送分为本地推送和远程推送，常用的应该是远程推送。在 iOS 10 发布之后，对远程推送进行了一次比较大的升级，之前也没有仔细研究过，今天突然发现了之前存在很多误区，特此记录。我的推送服务用的是极光推送。
二、远程推送的分类状态
远程推送一般情况下根据 App 的运行状态分成 前台、后台、未启动 三种状态。
-
在 iOS 10 之前 我们要对这三种状态分别处理：
1.1 应用在前台运行时，这时候收到远程推送，系统默认不会有任何响应，但是我们可以通过下面这个方法捕获到推送的消息内容进行处理，常见的处理操作（比如打开应用的某个指定页面），但是如果这时候就直接打开页面，对用户来说就比较不友好了，我正在使用你突然直接给我跳转一个新页面，WC，这是神马逻辑。所以这种处理逻辑很不好。比较友好的处理方式可以是模仿系统推送一样，在顶部弹出一个 view 显示消息的内容，几秒后消失，用户可以点击也可以不点击（github 上也有封装好开源库，使用起来非常方便）。还有一种处理方式就是在应用内对应的 tab 或 item 上设置角标来提示用户有新内容。也可以将远程消息转换为本地推送来处理。
1.2 应用在后台挂起时，就比较好处理了，点击消息进入应用也会执行下面的方法。
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler {
// Required, iOS 7 Support
[UIApplication sharedApplication].applicationIconBadgeNumber = 0;
[JPUSHService setBadge:0];
[JPUSHService handleRemoteNotification:userInfo];
if (application.applicationState == UIApplicationStateActive) {
//如果是在前台运行，可以将推送消息转换为本地推送消息，实现类似远程推送的效果
UILocalNotification *localNotification = [[UILocalNotification alloc] init];
localNotification.userInfo = userInfo;
localNotification.soundName = UILocalNotificationDefaultSoundName;
localNotification.alertBody = [[userInfo objectForKey:@"aps"] objectForKey:@"alert"];
localNotification.fireDate = [NSDate date];
[[UIApplication sharedApplication] scheduleLocalNotification:localNotification];
} else if (application.applicationState == UIApplicationStateInactive){
//如果是在后台挂起，用户点击进入是UIApplicationStateInactive这个状态
// TODO...
}
// 这个方法必须调用
completionHandler(UIBackgroundFetchResultNewData);
}
1.3 应用未启动收到远程推送消息是，会调用:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
与点击应用图标进入应用的流程是一样的，区别在于 launchOptions 这个参数，如果是点击推送消息进入，launchOptions 会包含推送消息的内容，所以可以根据 launchOptions 来判断。
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// app关闭时，收到推送， 程序未启动，退出状态(如果是点击推送消息进入应用，launchOptions 会包含推送消息的内容。如果是点击图标进入则 launchOptions 不包含)
if (launchOptions) {
NSDictionary *userInfo = [launchOptions objectForKey:@"UIApplicationLaunchOptionsRemoteNotificationKey"];
if (userInfo) {
//TODO...
}
}
return YES;
}
获取到消息后，就可以对消息进行处理了。
- 在 iOS 10 之后，接受推送消息的方法变为：
- (void)userNotificationCenter:(UNUserNotificationCenter *)center didReceiveNotificationResponse:(UNNotificationResponse *)response withCompletionHandler:(void (^)())completionHandler
// 极光用的是下面这个方法
- (void)jpushNotificationCenter:(UNUserNotificationCenter *)center didReceiveNotificationResponse:(UNNotificationResponse *)response withCompletionHandler:(void (^)())completionHandler API_AVAILABLE(ios(10.0))
这个方法了。
, iOS 10 的远程推送消息不在区分应用的状态了。无论当应用是在前台运行还是后台挂起状态，当接收到推送消息时，都会以横幅的形式提示用户（挂起时屏幕未锁定是横幅提示，屏幕锁定就会在通知中心里面），所以用户点击消息的处理可以放在一起不用再区分状态。
最大的坑来了。 一开始处理消息的时候，分作两种状态处理的， 应用未启动和前台后台。应用未启动用的上面提到的方式。但是测试的时候发现，推界面推了两次，由于未启动状态还不能连着真机测试，log 也没有异常，只能是加 toast 和 alert 来一步一步调试。发现原来是处理消息的方法调用了两次。那么问题来了，为什么会调用两次？一次是在 didFinishLaunchingWithOptions 调用的，那么另一次呢，在 didReceiveNotificationResponse 中。这就是 iOS 跟之前的不同之处。之前跟本不会调用。找到问题根源就好处理了，可以把 didFinishLaunchingWithOptions 中的处理删除，只用 didReceiveNotificationResponse 里面的一套处理逻辑就好，这样做事最简单方便的，也比较好维护。但是如果你的应用兼容 iOS 9 一下的系统就要分情况对待了。
- 在 iOS 6 之前，接收消息的方法是：
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo
不过现在应该没有老系统的机器了吧？ 所以可以忽略这种情况。
三、总结
以上就是这次新应用推送消息遇到的问题，对于 iOS 10 之后的这种处理方法，在 iOS 11.4.1 系统和 12.0.1 系统上的效果都是一样的，目前手边没有 10 的系统没法测试，但是个人认为应该不会有什么区别。
如果看文章的小伙伴有跟我不一样的结论，欢迎指正。
