ios 推送是建立在 苹果推送服务器吗

方法/步骤

在developerapplecom的member center设置AppId属性，

enable push

在developerapplecom的member center创建APN证书，

Development -> Apple Push Notification service SSL (Sandbox) 用于沙盒app

Production -> Apple Push Notification service SSL 用于AppStore app

创建完毕后，可以第一步AppId的属性列表中查看到证书名称

基于第1步修改的AppID重新生成provision file，

在iOS Project中加载此provision file,

这样编译出的app才可以获取到device token(推送唯一标识符)

以下为针对服务端的推送设置步骤－－－－－－－－

在keychain中找到第1步创建的APN证书，

展开此证书，分别导出证书和密钥，

名称设为cerp12和keyp12

打开控制台程序，

使用openssl 将cerp12及keyp12转成cerpem和keypem

命令如下：

$ openssl pkcs12 -clcerts -nokeys -out cerpem -in cerp12

$ openssl pkcs12 -nocerts -out keypem -in keyp12

测试生成的cerpem及keypem是否可用

$ openssl s_client -connect gatewaypushapplecom:2195 -cert cerpem -key keypem

注：gatewaypushapplecom:2195用于appStore app;

gatewaysandboxpushapplecom:2195用于沙盒app;

以上命令执行后会打印一大罗信息，最后处于可输入状态，打几个字符回车后自动断开连接即为正常。

合并cerpem及keypem

$ cat cerpem keypem > ckpem

上传ckpem到推送服务器的推送程序的目录。

Tip:－－－－－－－－－－－－－－－－－－－－－－－

find / -name "php"

查询推送服务器php文件目录用。

scp ~/Desktop/ckpem root@xxxxxxxx:/var/www/html

用于上传本地文件到Linux服务器用。

9

服务器php代码加载ckpem向苹果服务器推送消息：略

客户端oc代码获取token,接收推送消息：略

iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器

所以， iOS 的推送，可以不严谨的理解为：苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。

然后，系统根据该 IM 消息识别告诉哪个 App 具体发生了什么事。

然后，系统分别通知这些 App

而 Android每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。

其实 Android 也有类似 APNS 的 GCM（Google Cloud Message）的服务，如果一个应用的推送采用这种模式的话，就和iOS推送一个样了。

GCM相关的程序应该是集成在所谓的Gapps中，但国内的 Android 手机上 GCM 处于基本不可用的状态，而且Android 因为后台可以长驻，所以，App们各显神通。

聊天类应用的话，大多数直接借用 XMPP 规范里的一些成果。少量如微信有IM底子的，自己开发协议。这些在实现原理上与 APNs / GCM 没有本质的区别，但有一定的技术门槛。

而大多数普遍应用，要使用推送的话，则使用轮询的方式简单实现，就是定时去服务器上查询数据，也叫Polling，还有一种手机跟服务器之间维护一个 TCP 长连接，当服务器有数据时，实时推送到客户端，也就是我们说的 Push。

轮询的方式不论怎么优化都比较费电费流量，长连接的方式在网络不稳定的情况下，Socket比较容易断开推送数据失败，

安卓推送可以考虑使用第三方推送工具，比如极光推送

iOS客户端及MDM监管涉及到的token汇总

由于iOS客户端APNS功能及PushKit功能 和MDM的APNS有相同逻辑,为避免混淆,现将iOS端涉及到的所有token做一个区分及解释:

现将推送类型分为如下两种:

1 APNS(ApplePush Notification Services),苹果推送服务通知

客户端用到的地方:

MDM监管,执行指令时使用:

(ps:里面还有一个键为PushMagic的值,这个值是唤醒设备的时候,包含在APNS的推送消息里面的,简单来说是为了区别描述文件用的,还有一个UnlockToken是解锁设备用的,请注意区分)

这个推送是没有声音,没有任何显示的,作用就是唤醒设备主动去连接mdm服务器

总结如下:

在App和MDM整个生命周期中,一共会产生三种token(类似推送效果的,像解锁token等不计入在内),分为

客户端的2种,客户端推送显示推送消息文本的token, 服务器唤醒app执行指令的token

MDM服务器的1种,用来唤醒设备来执行服务器新指令的token

远程推送：苹果公司把不同公司五花八门的推送内容放到自家的Apple push服务器上，用户一联网就通过Apple push service推送内容发到他的设备上。类似于QQ、微博微信都是这样推送的

本地：利用UILocalNotification服务

有三种情况

scheduled time, 时间周期，用来指定iOS系统发送通知的日期和时间；

notification type,通知类型，包括警告信息、动作按钮的标题、应用图标上的badge（数字标记）和播放的声音；

自定义数据，本地通知可以包含一个dictionary类型的本地数据

日历、提醒事项、闹铃都是这样推送消息的。

可以实现相同，以下是实现相同的步骤：

1由App向iOS设备发送一个注册通知，用户需要同意系统发送推送。

2iOS向APNs远程推送服务器发送App的Bundle Id和设备的UDID。

3APNs根据设备的UDID和App的Bundle Id生成deviceToken再发回给App。4App再将deviceToken发送给远程推送服务器(自己的服务器), 由服务器保存在数据库中。

5当自己的服务器想发送推送时, 在远程推送服务器中输入要发送的消息并选择发给哪些用户的deviceToken，由远程推送服务器发送给APNs。

6APNs根据deviceToken发送给对应的用户。

消息推送也可以试一试极光。深耕移动开发领域十余年来，极光始终秉承“以开发者为中心”的战略导向。高度聚焦移动开发者的运营、增长、变现等需求。极光业务已经全面转型纯SaaS业务。极光荣膺“年度最佳SaaS服务”及“年度用户推荐SaaS产品“两大奖项，充分彰显了极光SaaS产品及服务在行业内的强大领先地位。

iOS 是没有第三方推送的，从苹果服务器到 iOS 设备的推送路径是唯一的，需要在 iOS 端用 SDK 提供的 API 实现一些逻辑，同时在自己的服务器端按苹果的规格实现与苹果服务器通信的通信。不过，自己的服务器到苹果的服务器之间的通信，倒是有不少第三方服务可以代劳。

iOS的系统结构分为以下四个层次核心操作系统the Core OS layer、核心服务层the Core Services layer、媒体层the Media layerCocoa触摸框架层the Cocoa Touch layer。

关于第三方的推送服务，可以到极光了解一下。极光灵活的目标筛选，提供用户自定义的标签和别名系统，以及极光自己根据数据分析出的分类目标。

当你的iPhone收到推送信息后到底会发生什么呢？总共有三种可能性： app在前台运行 接收到推送信息时屏幕上不会有任何显示，也不会有提示音，但你的appdelegate会收到这个推送信息。你可以在这里加入代码来处理接收到的信息。 app不在前台运行。