1.应用程序注册APNs推送消息。
说明：
a.只有注册过的应用才有可能接收到消息，程序中通常通过UIApplication的registerUserNotificationSettings:方法注册，iOS8中通知注册的方法发生了改变，如果是iOS7及之前版本的iOS请参考其他代码。
b.注册之前有两个前提条件必须准备好：开发配置文件（provisioning profile，也就是.mobileprovision后缀的文件）的App ID不能使用通配ID必须使用指定APP ID并且生成配置文件中选择Push Notifications服务，一般的开发配置文件无法完成注册；应用程序的Bundle Identifier必须和生成配置文件使用的APP ID完全一致。
2.iOS从APNs接收device token，在应用程序获取device token。
说明：
a.在UIApplication的-(void)application:(UIApplication )application didRegisterForRemoteNotificationsWithDeviceToken:(NSData )deviceToken代理方法中获取令牌，此方法发生在注册之后。
b.如果无法正确获得device token可以在UIApplication的-(void)application:(UIApplication )application didFailToRegisterForRemoteNotificationsWithError:(NSError )error代理方法中查看详细错误信息，此方法发生在获取device token失败之后。
c.必须真机调试，模拟器无法获取device token。
3.iOS应用将device token发送给应用程序提供商，告诉服务器端当前设备允许接收消息。
说明：
a.device token的生成算法只有Apple掌握，为了确保算法发生变化后仍然能够正常接收服务器端发送的通知，每次应用程序启动都重新获得device token（注意：device token的获取不会造成性能问题，苹果官方已经做过优化）。
b.通常可以创建一个网络连接发送给应用程序提供商的服务器端， 在这个过程中最好将上一次获得的device token存储起来，避免重复发送，一旦发现device token发生了变化最好将原有的device token一块发送给服务器端，服务器端删除原有令牌存储新令牌避免服务器端发送无效消息。
4.应用程序提供商在服务器端根据前面发送过来的device token组织信息发送给APNs。
说明：
a.发送时指定device token和消息内容，并且完全按照苹果官方的消息格式组织消息内容，通常情况下可以借助其他第三方消息推送框架来完成。
5.APNs根据消息中的device token查找已注册的设备推送消息。
说明：
a.正常情况下可以根据device token将消息成功推送到客户端设备中，但是也不排除用户卸载程序的情况，此时推送消息失败，APNs会将这个错误消息通知服务器端以避免资源浪费（服务器端此时可以根据错误删除已经存储的device token，下次不再发送）。](http://upload-images.jianshu.io/upload_images/689381-69585b5eb236bce6.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
1.应用程序注册APNs推送消息。
说明：
a.只有注册过的应用才有可能接收到消息，程序中通常通过UIApplication的registerUserNotificationSettings:方法注册，iOS8中通知注册的方法发生了改变，如果是iOS7及之前版本的iOS请参考其他代码。
b.注册之前有两个前提条件必须准备好：开发配置文件（provisioning profile，也就是.mobileprovision后缀的文件）的App ID不能使用通配ID必须使用指定APP ID并且生成配置文件中选择Push Notifications服务，一般的开发配置文件无法完成注册；应用程序的Bundle Identifier必须和生成配置文件使用的APP ID完全一致。
2.iOS从APNs接收device token，在应用程序获取device token。
说明：
a.在UIApplication的-(void)application:(UIApplication )application didRegisterForRemoteNotificationsWithDeviceToken:(NSData )deviceToken代理方法中获取令牌，此方法发生在注册之后。
b.如果无法正确获得device token可以在UIApplication的-(void)application:(UIApplication )application didFailToRegisterForRemoteNotificationsWithError:(NSError )error代理方法中查看详细错误信息，此方法发生在获取device token失败之后。
c.必须真机调试，模拟器无法获取device token。
3.iOS应用将device token发送给应用程序提供商，告诉服务器端当前设备允许接收消息。
说明：
a.device token的生成算法只有Apple掌握，为了确保算法发生变化后仍然能够正常接收服务器端发送的通知，每次应用程序启动都重新获得device token（注意：device token的获取不会造成性能问题，苹果官方已经做过优化）。
b.通常可以创建一个网络连接发送给应用程序提供商的服务器端， 在这个过程中最好将上一次获得的device token存储起来，避免重复发送，一旦发现device token发生了变化最好将原有的device token一块发送给服务器端，服务器端删除原有令牌存储新令牌避免服务器端发送无效消息。
4.应用程序提供商在服务器端根据前面发送过来的device token组织信息发送给APNs。
说明：
a.发送时指定device token和消息内容，并且完全按照苹果官方的消息格式组织消息内容，通常情况下可以借助其他第三方消息推送框架来完成。
5.APNs根据消息中的device token查找已注册的设备推送消息。
说明：
a.正常情况下可以根据device token将消息成功推送到客户端设备中，但是也不排除用户卸载程序的情况，此时推送消息失败，APNs会将这个错误消息通知服务器端以避免资源浪费（服务器端此时可以根据错误删除已经存储的device token，下次不再发送）。
