我今天把洞填好了。 我们的APP很久以前就有推送功能代码，但实际的推送功能并不多。 然后突然发现了漏洞。 APP在杀死的状态下受到推送，进入APP，无法响应跳跃。 之所以难以填写，是因为需要杀死APP进行测试，很难调试。 最后在Hud画面上打印了各种各样的东西，找到了原因。
首先提取优秀的博客内容，整理APP在各种情况下接受推送响应的过程。
设备收到来自apns的通知，APP应用程序处理通知可能存在以下情况：
1 .如果在APP应用程序尚未加载时单击查看通知按钮，则会调用didFinishLaunchingWithOptions，而不会调用didReceiveRemoteNotification方法。
单击“关闭通知”按钮，然后单击“APP应用程序”，仅调用didFinishLaunchingWithOptions方法。
2 .应用于前台(foreground )时，收到通知时将触发didReceiveRemoteNotification方法。
3 .应用于后台1 .此时收到通知并单击查看按钮，将调用didReceiveRemoteNotification方法。
2 .单击“关闭”，然后单击“APP”，在上述两种方法都没有被调用时，只能通过applicationWillEnterForeground或applicationDidBecomeActive判断是否有通知，然后发送
如第一个所述，调用didFinishLaunchingWithOptions，但不调用didReceiveRemoteNotification。 这需要特别的解决，但是前面的人写了相关的解决方案代码，不是不执行跳转的理由，但是贴上了代码
launch选项！=nil(//app关闭时，推送[ self application : applicationdidreceiveremotenotification 3360 launch options [ @ ' uiappplications ] 请尝试自己手动运行。
最后，我找到了原因，因为在处理跳转时，我没有考虑到在APP被杀并推送跳转页面之前，APP还没有在主界面上运行，但我在这里做了一个判断
if ([ datamanagershareddatamanager ].main window.rootviewcontrolleriskindofclass 3360 [ roottabcontrollerclass ] ) /
最后一种方法是对上面的判断加else，否则加拦截，进入APP首页后发出通知，在这里接到通知后再次运行判断跳转操作的代码。 我不知道有没有更科学的处理方法