第四部我们需要将我们的devicetoken上传给服务器，接下来使我们的服务器像苹果设备推送push。演示过程。

我们已经拿到了一个tokenstr并把它应该传给我们的服务器，但这里我们并没有搭建自己的服务器，我们将模拟服务器的方式在本地创建一个服务器推送的环境，也就是说我们会使用一个第三方的工具去推送push，push如果要工作的话有几个事项需要注意，我们之前已经生成了服务器使用的push证书，但是我们的客户端APP的开发证书，也就是provising profile,要生成一个特定的调试证书，这个证书的id要跟bundle identifer保持一致。下面我们取苹果的开发者网站去生成一个带id的开发证书

生成相应的证书和APPid

证书是做什么用的呢，就是后面我们给苹果的APNS发送推送的时候，需要告诉苹果我们到底是谁，这个是作为一个身份认证的作用。生成相应的证书和APPid之后。我会在我的电脑上去模拟一个push的测试环境，那么我们需要将证书导入出来。接下来我们需要在我们的工程中 完成push的注册。完成注册之后，我们才可以在我们的电脑上面搭建的测试环境向我们的手机去推送push，接下来我们回到我们的工程去完成push的注册流程。我们一般将push的注册代码写在APPdelegate，因为他需要在启动的时候就完成注册，因为这个是一个非常优先的过程，因为可能在你执行其他业务模块之前我们就需要启用这个push的功能，所以注册的流程必须要尽快的启动，我们一般把他的调用放在

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 

这样一个回调里面。我们建立一个函数调用，取名为registerAPN,在启动的回调里面，我们就调用这个APP

关于怎么去注册APNS的话在不同的系统版本下面行为表现并不一样，主要是以ios7ios8为分界线，先用ios8的注册的方式作为讲解。后面我们会有专门的课程教大家怎么去设置push这样一个交互的流程。

ios8环境下面如果要注册APN的话，我们先需要生成一个notification的一个setting，也就是说像用户询问push的权限。

UIUserNotificationSettings* setting = 

[UIUserNotificationSettings settingsForTypes:

          (UIUserNotificationTypeSound | UIUserNotificationTypeAlert | UIUserNotificationTypeBadge)

                                           categories:nil]

settingsForTypes就是我们需要申请的一个push的一个权限的类型。接下来是像我们的用户申请权限，我们调用对应的api

[[UIApplication shareApplication]registerUserNotificationSettings:setting]在我们调用这行api之后我们会收到一个registerficationSettings的一个回调，如果用户点了允许我们的push权限我们就会收到这个回调。

- (void)application:(UIApplication *)application didRegisterUserNotificationSettings:(UIUserNotificationSettings *)notificationSettings 

到这里的时候就表示用户已经允许了我们的push权限的申请。那么接下来的话就是获取token，之前我们的流程图当中也讲解到了这一步。我们调用相应的api来获取这样一个token。

- (void)application:(UIApplication *)application didRegisterUserNotificationSettings:(UIUserNotificationSettings *)notificationSettings 

{

[application registerForRemoteNotifications];

}调用这行api之后，我们就会像苹果的APNS服务器去申请一个APP的token，也就是我们的devicetoken，那我们看一下的devicetoken的回调是怎么样的。

- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {

这个回调表示我们拿到了正确的devicetoken,需要转化成服务器识别的string，并把它传递给我们的服务器，进行数据类型的转换。我们需要调试一下来看一下tokenstr到底是一个什么样的格式，因为苹果的push不支持模拟器调试的，所以我们需要启动设备去调试。

48 申请权限 在真机点击好

60像服务器申请token

67拿到tokenstr

打印一下看一下具体的内容。

去掉空格和尖括号，将tokenstr传给我们的服务器。因为我们并没有搭建真正的服务器，我们就不去详细的阐述了。我们的目标是在本地建立一个测试环境，推荐一个APP可以将苹果的设备搭建成一个push服务器去向苹果的APNS服务器去推送push，

pu sh工作原理

iOS的pu sh通道是一个独立的长链接通道，这个通道是由iOS系统独立维护的。也就是说我们每一个手机系统在他开机之后就会有一个后台悄悄的长链接连  向苹果的服务器也就是说我们看到的APNS服务器。APNS当收到新的pu sh通知的时候它就会把通知推给我们的设备。这里一个大致的工作原理是这样一个流程。我们的手机系统在启动之后或者说打开某一个app之后生成一个独立的唯一的token并把这个token上传给我们自己的服务器，我们自己的服务器有了这个token之后就可以向自己的设备推送通知了，但是呢这个token这个通知并不能直接推送给我们的设备而是要推送给苹果的服务器，我们之前提到了pu sh的通道是由苹果去维护的是一个唯一的一个通道，所以我们的服务器需要拿着这个token并告诉苹果服务器我们推送哪一条通知。也就是这样，我们的server会把token加上pu sh的内容一起推给苹果的服务器，苹果的服务器在收到这个服务器的pu sh之后会把这个pu sh再根据这个token定位到我们的设备。也就是把我们的push推给我们的设备。推给我们的设备之后，我们的设备拿到这个token之后，他就能够知道这个token是属于我们设备上的哪一个app，这样就可以把这个通知推送到具体某一个app当中。这样一个流程大概就是pu sh的一个工作原理