本文讲解iOS的远程通知的基本使用，主要包括远程通知的类型，处理远程通知的场景，以及远程通知相关证书的配置等等。
一、APNs简介
APNs是苹果公司提供的远程通知的服务器，当App处于后台或者没有运行时，如果后台需要发送通知，那么就需要借助APNs服务器。在App接收通知的过程中，通知的发送路径是：
Provider -> APNs服务器 -> iPhone -> App
其中，Provider和APNs之间有一个TLS连接，Provider通过该连接将远程通知发送到APNs服务器；iPhone与APNs之间也有一个TLS连接，APNs将远程通知通过该连接发送给iPhone，进而通知用户某App有新通知。
iPhone与APNs连接图如下：
图片1
注意：
- 此连接由系统建立并维持，无需开发人员管理；
- 上图中的证书是苹果设备本身的证书，与开发者账号中申请的证书无关；
- 每个设备与
APNs服务器只需维持一条连接。
Provider与APNs连接图如下：
图片2
注意：
- 此连接由
App的bundle ID唯一确定 - 上图中
Provider certificate需要通过开发者账号申请生成，其中包含App的bundle ID
APNs工作流程
图片3
注意：
- 首先客户端需要向
APNs服务器注册当前App，APNs会返回一个Token(注意这个过程要求App有合法的证书，需要包含推送功能的证书)；注意不同应用在同一设备上获取的Token不同，同一应用在不同设备上获取的Token也不同，所以Token是跟设备与App唯一绑定的 -
App拿到Token后需要将其发送给Provider -
Provider发送推送通知时，指定Token和通知内容，并发送给APNs服务器 -
APNs服务器会将通知发送给Token对应的设备上 - 设备收到通知后，根据
APNs发过来的通知中带有的bundle ID信息区分是哪个App的远程通知(这里应该是根据Token来获取bundle ID)
APNs的Feedback 机制
Feedback 是 APNs 服务器提供的用于减少服务器压力以及优化网络的服务，工作流程图如下：
图片4
注意：
-
Provider发送一个远程通知给APNs服务器，APNs服务器会检测目的设备是否在线，如果不在线，那么APNs服务器会暂存该消息 - 当目的设备上线后，
APNs会发送暂存的消息给目的设备(按照苹果官方说法暂存消息只会暂存最后一条消息，之前的消息会被丢弃)； - 如果目的设备很久都没有上线，那么
APNs消息会把该设备加入feedback名单。Provider可以定期去APNs拉新feedback名单； - 当
Provider再次给之前的设备发送远程通知时，需要检查一下feedback名单，如果设备在这个名单，则不再发送给APNs了； - 当设备重新上线后，
Provider可以再将此设备移除feedback名单，当Provider更新feedback list后，就可以重新给该设备发送远程通知了。当然，feedback list的更新可能会有周期，如果需要及时有效的更新feedback list，那么需要App打开后，及时通知Provider； - 这种机制的好处就是防止发送多余无用的远程通知消息，一方面可以减缓
APNs服务器的压力，另一方面也可以减少网络流量
二、证书配置
假定已经有开发证书的情况，下面只介绍配置推送证书的步骤
- 创建新的
App ID - 创建推送证书和发布证书
- 创建新的
Provisioning Profiles
三、通知类型
远程通知具体可分为普通远程通知和静默远程通知
普通远程通知
收到通知后，有文字和声音，点击通知会进入App，然后执行如下方法
-(void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler
静默远程通知
收到通知后，没有文字和声音，不用点开通知，也不用打开App，就能执行如下方法
-(void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler
静默通知注意点：
-
aps数据中一定要加"content-available" : 1 - 一定不能加
alert，如果加入了alert就不是静默推送了 -
sound和badge也不能加
四、通知处理场景
1.申请通知权限
if (DEF_IOS10) {
// iOS 10
UNUserNotificationCenter *center = [UNUserNotificationCenter currentNotificationCenter];
[center requestAuthorizationWithOptions:UNAuthorizationOptionSound | UNAuthorizationOptionAlert | UNAuthorizationOptionBadge completionHandler:^(BOOL granted, NSError * _Nullable error) {
if (granted) {
NSLog(@"greet");
} else {
NSLog(@"reject");
}
}];
} else if (DEF_IOS8) {
// iOS 8 和 iOS 9
UIUserNotificationSettings *settings = [UIUserNotificationSettings settingsForTypes:UIUserNotificationTypeBadge | UIUserNotificationTypeAlert | UIUserNotificationTypeSound categories:nil];
[[UIApplication sharedApplication] registerUserNotificationSettings:settings];
} else {
// iOS 7
[[UIApplication sharedApplication] registerForRemoteNotificationTypes:UIUserNotificationTypeBadge | UIUserNotificationTypeAlert | UIUserNotificationTypeSound];
}
iOS9以后，每次重新安装应用后得到的 Token 是不一样的，而且每次重装系统也会改变，所以 每次应用启动时都需要按上面的步骤注册一次
2.发送DeviceToken
application:didRegisterForRemoteNotificationsWithDeviceToken:
在这个方法里把deviceToken发送给服务器Provider
3.接收通知
应用在前台
- iOS6
-(void) application: didReceiveRemoteNotification:
- iOS7 ~ iOS9
-(void) application: didReceiveRemoteNotification: fetchCompletionHandler:
- iOS10
-(void)userNotificationCenter:(UNUserNotificationCenter *)center willPresentNotification:(UNNotification *)notification withCompletionHandler:(void (^)(UNNotificationPresentationOptions))completionHandler
应用在后台，但是还活着
iOS6 ~ iOS9 调用方法和应用在前台相同
iOS10
-(void)userNotificationCenter:(UNUserNotificationCenter *)center didReceiveNotificationResponse:(UNNotificationResponse *)response withCompletionHandler:(void (^)())completionHandler
应用被杀死状态
这种情况和应用重新启动类似，应用会调用下面的方法重新启动
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
其中，通知的信息在launchOptions里，
id userInfo = [launchOptions objectForKey:UIApplicationLaunchOptionsRemoteNotificationKey]
参考资料
http://www.jianshu.com/p/ad43bc1a970a
http://www.tuicool.com/articles/AFRvemV
http://blog.csdn.net/hherima/article/details/47133171