ios-app杀死状态下响应推送

今天填了一个坑，我们app很久之前就有推送功能代码，但是没有太多的实际的推送功能，然后突然发现一个bug，app在杀死状态下接收到推送进入app无法响应跳转。不好填是因为需要杀死app测试，很不好调试，最后用Hud屏幕打印各种东西才找到原因。

首先摘取一篇优秀的博客内容，梳理一下app在各种情况接收到推送响应过程。

设备接到apns发来的通知，应用处理通知有以下几种情况：

1.应用还没有加载

这时如果点击通知的显示按钮，会调用didFinishLaunchingWithOptions，不会调用didReceiveRemoteNotification方法。
如果点击通知的关闭按钮，再点击应用，只会调用didFinishLaunchingWithOptions方法。

2. 应用在前台（foreground)

这时如果收到通知，会触发didReceiveRemoteNotification方法。

3.应用在后台

1.此时如果收到通知，点击显示按钮，会调用didReceiveRemoteNotification方法。
2.点击关闭再点击应用，则上面两个方法都不会被调用这时，只能在applicationWillEnterForeground或者applicationDidBecomeActive,根据发过来通知中的badge进行判断是否有通知，然后发请求获取数据

如第一种所说，didFinishLaunchingWithOptions会被调用但是didReceiveRemoteNotification不会被调用，这个需要特殊解决，但是之前的人写了相关解决代码，但是不是不执行跳转的原因，但是还是先贴一下代码

if (launchOptions != nil) {        //app关闭时，收到推送        [self application:application didReceiveRemoteNotification:launchOptions[@"UIApplicationLaunchOptionsRemoteNotificationKey"]];    }

虽然不执行didReceiveRemoteNotification，但是可以从launchOptions中拿到推送，自己手动执行一下即可。

然后最后找到原因是因为我们在处理跳转的时候没有考虑到当app被杀死执行到推送跳转页面的时候app还没执行到主界面，但是这里却加了判断

if ([[DataManager sharedDataManager].mainWindow.rootViewController isKindOfClass:[RootTabController class]]){    // 判断跳转操作}

执行到这里的时候，rootViewController并不是RootTabController，这个时候的window上应该是广告页。
然后最后采取的方法是上的的判断加else，如果不是的话加一个监听，当进入到app首页后发出通知，然后再此处接收到通知重新执行一次判断跳转操作的代码，不知道还有没有更科学的处理方式