关于推送通知，iOS推送主要是通过服务端来实现的，相关过程可以参考下面两篇文章：
文章中介绍的jar包列表：
- bcprov-jdk16-145-1.jar
- commons-io-2.0.1.jar
- commons-lang-2.5.jar
- javapns-jdk16-163.jar
- log4j-1.2.16.jar
其中介绍最全面的是这篇blog：http://tanqisen.github.io/blog/2013/02/27/ios-push-apns/
整体流程如下图所示：
其中涉及到的角色有：
- Provider:应用自己的服务器；
- APNS:Apple Push Notification Service的简称，苹果的PUSH服务器；
-
OS设备连接网络后，会自动与APNS保持类似TCP的长链接，等待APNS推送消息的到来；
-
应用启动时注册消息推送，并获取设备的在APNS中注册的唯一设备标示deviceToken上传给应用服务器(即Provider)；
-
在需要给应用推送消息时，Provider把push内容、接收push消息的deviceToken按APNS指定的格式打包好，发送给APNS；
-
APNS收到Provider发送的消息后，查找deviceToken指定的设备，如果该设备已经和APNS建立了连接，则立即将消息推送给该设备，如果设备不在线，则在该设备下次连接到APNS后将消息推送到设备。请注意苹果并不保证推送一定成功；
-
设备收到push消息后，iOS系统会根据SSL证书判断这个push消息是发给那个应用的，进而启动相应客户端。
上述过程中，有两个关键步骤需要自己处理的是：1.客户端获取deviceToken，并上传到Provider；2.Provider发送push消息到APNS。这两个步骤中都需要苹果的push证书授权，下面就来介绍如何生成push证书，以及Provisioning Profile。
pom.xml中额外依赖一下的jar包：
<!-- Apple Push Notification Related Dependencies -->
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk16</artifactId>
<version>1.46</version>
</dependency>
<dependency>
<groupId>com.github.fernandospr</groupId>
<artifactId>javapns-jdk16</artifactId>
<version>2.3.1</version>
</dependency>
发送消息通知的代码如下所示：
String deviceToken = "xxxxxxx";
//被推送的iphone应用程序标示符
PushNotificationPayload payload = new PushNotificationPayload();
payload.addCustomAlertBody("通知!");
payload.addBadge(1);
payload.addSound("default");
PushNotificationManager pushManager = new PushNotificationManager();
Device device = new BasicDevice(deviceToken);
String certificatePassword = "123456";
InputStream keyStoreFileInputStream = this.getClass().getClassLoader().getResourceAsStream("push.p12");
//注意：最后一个参数表明该请求是否为生产环境，如果配置的证书为测试使用的证书，请将该参数修改为false
pushManager.initializeConnection(
new AppleNotificationServerBasicImpl(keyStoreFileInputStream, certificatePassword,
true));
pushManager.sendNotification(device, payload);
pushManager.stopConnection();
发送消息通知涉及到的有deviceToken（每台设备，针对每个app都是不一样的），证书文件(keystore)，验证密码，便可以正常向设置对应的APP发送通知了。
iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。你的例子里面，腾讯 QQ 的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。
而 Android，就不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实 Android 也有类似 APNS 的 GCM（Google Cloud Message），属于开发者可选，非强制，但是Google的服务，你懂得。
自己开发倒不如直接用第三方的系统，不划算啊~费时费力，效果还不一定好。找个靠谱点的第三方，直接上去下载个文档用，方便啊。不知道你怎么看，我们公司比较了几家以后，使用第三方的极光推送来达到此目的，对应的Java SDK地址：http://docs.jpush.io/server/java_sdk/。
先去注册，登录完成后，即可创建一个新的应用，应用创建成功后，可以在应用信息下查看到具体详情：
应用信息
| AppKey | xxxx | |
| Master Secret | xxxx | |
| 创建日期 | 2016-03-17 13:10 | |
| 最后修改时间 | 2016-03-17 13:10 |
极光推送的文档相对来说还是比较全面的，从常见问题开始：http://docs.jpush.io/guideline/faq/
如果我们并不在服务端进行用户设备等数据的存储，那么就会丧失对所有的注册设备的所有权，只能通过极光推送的相关页面来手动发送通知，鉴于此，还是需要我们在后端设置对应的数据表来对所有注册用户进行处理。
推送服务的整体流程如下，以iOS为示例（android比较简单，不需要APNS服务角色）
整体的流程如下：
- 设备APP移动端向极光推送发送注册设备所需要的信息，包括deviceToken，手机号（用于收费版短信通知）等；
- 注册极光推送相关服务后，再向后端服务提供设备信息，注册的极光id，手机号用于后端存储；
- 后端服务需要将相关数据持久化；
- 如果触发了消息通知机制，一种方法是可以通过极光推送提供的网页端来进行，另外一种就是在后端服务中直接根据用户手机号/注册id/设备别名通过JPush API来进行；
- 极光推送服务收到通知后，需要将消息发送到APNS（Apple Push Notification Service）中；
- APNS根据设备deviceToken发送消息至移动端设备，点击后启动应用程序。
服务端的API主要分为以下几部分：
1. Push
向某一个或一类设备发送推送通知；
如果服务端使用Java作为开发语言，可以参考其中的Java SDK部分：http://docs.jpush.io/server/java_sdk/
需要注册极光推送ID相关的appKey，masterSecret等信息。
JPushClient jpushClient = new JPushClient(masterSecret, appKey, 3);
// For push, all you need do is to build PushPayload object.
PushPayload payload = buildPushObject_all_all_alert();
try {
PushResult result = jpushClient.sendPush(payload);
LOG.info("Got result - " + result);
} catch (APIConnectionException e) {
// Connection error, should retry later
LOG.error("Connection error, should retry later", e);
} catch (APIRequestException e) {
// Should review the error, and fix the request
LOG.error("Should review the error, and fix the request", e);
LOG.info("HTTP Status: " + e.getStatus());
LOG.info("Error Code: " + e.getErrorCode());
LOG.info("Error Message: " + e.getErrorMessage());
}
JPush的相关文档以及API还是比较方便的，大量使用了创建者模式（Builder），可以快捷地创建推送对象，推送平台。
2. Report
Report API用于可以用于各类统计查询相关功能，Received API 以 msg_id 作为参数，去获取该 msg_id 的送达统计数据。如果一次 API 调用推送有很多对象（比如广播推送），则此 API 返回的统计数据会因为持续有客户端送达而持续增加。每条推送消息的送达统计数据最多保留一个月。即发起推送请求后从最后一个推送送达记录时间点开始保留一个月，如果保留期间有新的送达，将在这个新送达的时间点起再往后保留一个月。
如果我们想要对信息进行统计，那么需要在发送消息完成后记录该信息的msg_id。
3. Device
Device API可以用于服务器端查询，更新，删除设备的tags, alias信息，如果不想让APP客户端和服务端的tags，别名等信息互相覆盖，那么考虑只在 客户端或服务端来进行更新操作，http://docs.jpush.io/server/rest_api_v3_device/
但是服务端的Device API只能修改设备tags，alias信息，功能相对来说有局限，因此大部分功能的注册只能在客户端进行。
4. Schedule
在API层面，全面支持定时发送功能，这是一个相对独立的任务执行模块，http://docs.jpush.io/server/rest_api_push_schedule/。
可惜的是，JPush 的 Java SDK中并没有涉及到Device，Schedule相关的客户端可供直接使用，如果想要在服务端使用该功能，需要在参考JPush Java SDK的源码自己实现一部分功能。