iOS 推送及bundle ID provision生成教程-CSDN博客

人力有时而穷，记忆力终究还是挡不住时间消磨，期间遇到各种奇葩问题，也是只有亲身经历才能理解。所以现在记下来，防止以后走弯路。

事先准备：

1）.首先你得有一个付费的开发者账号

2）.Mac、iPhone设备得准备好

开始进入正题

第一步：先准备好CSR，CSR又叫.certSigningRequest文件，用于请求证书和描述文件，所以这也叫请求文件。生成方法如下：

1.打开钥匙串

点击如图所示的“从证书颁发机构请求证书……”

图1 获取CSR

2.跳出证书助理，用户电子邮件地址可随意填，但最好填你自己邮箱，请求选择“存储到磁盘”

图2 保存CSR到本地磁盘

3.点击继续后得到CertificateSigningRequest.certSigningRequest文件

第二步：登录developer.apple.com登录你的开发者账号

图3 申请bundle ID

1.如上图所示，先生成APPID既bundleID，点击加号然后生成bundleID，这里没什么难点，主要需要注意的是bundleID命名的规范性

图4 申请推送证书

2.现在生成推送证书，如上图，一般需要生成开发证书和APPStore用的证书，development对应开发证书，production对应APPStore证书

图5 开发者证书选择如上图

点击右上角加号，如果是development则选择如上图所示的Apple Push Notification service SSL (Sandbox)，点击继续，选择我们刚刚生成的App ID也就是bundle ID

图6 申请证书需要上传CSR

接着上传我们生成好的CertificateSigningRequest.certSigningRequest文件，然后点击生成证书，最后一步的时候记得下载证书到桌面，后面会用到到这里tui'son推送证书就生成了，接下来我们生成描述文件provision

3.描述文件生成也大同小异，没什么难点development就选择development，AppStore就选Appstore，也是上传CSR得到描述文件provision，然后download到桌面备用。

第三步：我们回到桌面，安装推送证书，这里有一个坑，最好我们别直接双击安装，否则有可能出现没有专用秘钥的情况，如下图中第一个证书，发现了吗？它是没有展开箭头的，意味着它没有专用密钥。这样是不行的。

图7 错误的证书，缺少专用密钥

在这里我弄了进一个上午，反复删除证书和provision然后重新安装，甚至重新生成bundle ID和provision以及推送证书全部重来一遍，都无效，网上搜索来的方法几乎都试过，还是无果。突然我看到某个论坛有人说了句，直接把证书拖到登录里，一试，果然可以了！真是大坑！

图7 我们得把证书拖入登录这个选项内

如上图，已经有下拉箭头了，说明有专用密钥了。你可能会问，为什么我千方百计要把专用密钥弄出来呢？直接安装证书，然后选好对应provision和bundleID不就好了吗？程序也可以正常运行啊。是的，没错，是可以运行，但是推送证书所需要的p12文件你就倒不出来了！推送需要证书和专用密钥的p12文件！p12文件！P12文件！

接下来我们就可以倒出p12文件了，右键证书选择导出

图8 导出证书

图9 导出证书p12

终于看到了我梦寐以求的p12文件，泪奔

好的，把它放到桌面上，同理，也别忘记了把对应的专用密钥导出来，如下图

图10 导出密钥p12文件

现在我们就得到了development的推送证书和专用密钥的.p12文件，接下来我们需要把它们合成为一个.pem文件，这个才是服务器做APNs推送需要用到的文件。

第四步：生成.pem文件

准备材料：1.生成推送证书的sh脚本，2.推送证书和provision的.p12文件，然后很重要一点我们需要把我们的推送证书和专用密钥改成如下图一样的名字，因为脚本里的证书和密钥名字得和你的文件对应，脚本才能找到文件并执行命令

apns-dev-cert.p12和apns-dev-key.p12

图10 生成pem需要的文件

第一个是推送证书的p12第二个是专用密钥的p12第三个是生成pem的脚本，新建一个文件夹，把这三个文件放在这个文件夹里，然后用终端cd到这个文件夹，再然后执行命令行sh create_pem.sh

如果你不想给自己的pem加密，就直接enter就好了，直到终端提示你需要输入至少4字符的密码以及确认密码，最后我们回到这个新建的文件夹就能看到我们需要的.pem文件了，如下图

图11 pem文件已经生成

这就是我们最终需要的.pem文件，把这文件给服务器就好了，剩下的是服务器端的事情。

等服务器安装好证书及调试后，我们需要测试下推送到底能不能用，所以，我们提供pem文件的同时得提供bundleID和devicetoken。等等，devicetoken？这是什么东东？好的，接下来我们再讲讲这个坑。

通过神奇的百度，我找到了如下资料：

先简单介绍下push的机制

客户端通过

(void)registerForRemoteNotificationTypes:(UIRemoteNotificationType)types

这个函数向APNs（Apple Push Service）注册push，types可标明接收的push的类型，声音，数字等。

(void)application:(UIApplication

*)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData

*)deviceToken;

当app成功注册通知后，会调用这个函数，并把deviceToken返回给应用。

然后我们的程序就会把返回的这个deviceToken以及设备的udid及软件版本（淘宝for iPhone还是淘宝for iPad）及系统版本，用户名等发送到我们的服务器（下图中的provider）上，然后存储在数据库里。整个获取device token的过程可参见下图所示：

在需要发送push时，我们的服务端就会取出要发送的设备的device token，然后以下图所示的结构，组成符合特定结构的字符串，然后将其发送到的APNs

APNs可以根据与APNs建立连接的Provider所使用的证书判断是要哪个app请求发送的notification，继而把这个notification发送到的设备上。

下图为一个简单的从Provider到Device发送push的过程：

device

token到底是什么呢？不同的app的device

token相同么？一个设备会产生多个device token么？一个的device token可能对应多个UDID么？

结论：device token是对APNs来说，设备的标识符，与app无关，所以同一台设备上，不同的app获得的device token是一样的;一个设备可能会产生多个device token,一个device

token也可能对应多个UDID，下面进行解释。

device

token是什么？

文档中如下描述的：

对于APS来说，token是设备的标识符。device token不同于UIDevice的uniqueIdentifier（即UDID），因为出于安全和隐私原因，当设备被擦除后，token必须变化。

所以也就是说，一般情况下，token是不变的，但是在设备被擦除后，token会变的。

今天无心说在我们的服务器上的数据库里，存在同一个UDID对应有多个token的情况，之前是没有考虑到设备擦除的情况，所以就怀疑是不是同一个设备上同时装了taobao4iphone和taobao4ipad，而token是与app关联的，所以产生的这种情况，于是就找了杨匡的ipad来做测试，结果发现taobao4iphone和taobao4ipad收到的token是相同的，所以token应该是与app无关的，而是针对设备的（文档上也是如此描述的），是设备的标识，那除了设备被擦除的情况外，设备的device token应该是相同的，可是杨匡说之前崇厚给他查出来的他的iPad的token和我log出来的device token是不同的，后来就想到了，push是有两套的，development和product，即调试和release，在这两种情况下，服务端使用的push证书是不一样的，而程序使用的证书也不一样，那同一个设备在development和distribution情况下收到的device token是否一样呢，于是就做了实验，实际结果如下

实验设备：iPad 1

可以看出，同一个设备在development和distribution情况下，收到的device token是不同的，而token是与app无关的。

综合文档及上述实验结果可以得到以下结果：

同一个udid对应有不同的device token的情况暂时有如下两种：

设备擦除过，token变化过，老的新的都存储在数据库里

设备同时装过development和distribution的程序

不知道还有没有其它原因造成的同一个设备有不同的device token的情况，大家如果有什么相关的经验，可以补充一下。

Ok，balabala一堆讲完了，我们总结了下，devicetoken类似于令牌，但是又不同于UUID唯一标识符，devicetoken会变化，但是我们只要知道它也是Apple设备的标识符就好了，配合bundleID这样才能给设备准确地推送，OK科普完毕，开始获取devicetoken

//获取DeviceToken成功

- (void)application:(UIApplication*)application

didRegisterForRemoteNotificationsWithDeviceToken:(NSData*)deviceToken

{

NSLog(@"DeviceToken: {%@}",deviceToken);

//这里进行的操作，是将Device Token发送到服务端

UIAlertView* alert = [[UIAlertViewalloc]initWithTitle:nilmessage:[NSStringstringWithFormat:@"DeviceToken:%@",deviceToken]delegate:selfcancelButtonTitle:nilotherButtonTitles:@"确定",nil];

[alertshow];

}

从上面这个方法里，我们就能得到devicetoken，打印出来就OK了，但我们还有一个问题，APPStore版本和development用的是同样的bundleID所以devicetoken是一致的，但是如果是inhouse版本怎么办？其实也很简单，那就是，我们把上面那个方法里得到的devicetoken传递到某个页面，然后用label或者alertview，或者其他可视的控件展示出来就好了，然后抄下来就OK啦！

OK，推送搞定！

接着我们选择对应的证书provision 和 bundleID就可以愉快地开发啦！