一、APNS介绍（原生推送实现原理）
在iOS平台上，大部分应用是不容许在后台运行并链接网络的。在应用没有被运行的时候，只能经过 Apple Push Notification Service (APNs) 把数据发送到终端用户。对于互联网应用，正确高效的使用APNs 显然很是重要。html
Apple为应用开发者提供了一个APNS推送接口，称为binary interface。ios
（1）Binary Interface V1
最第一版本的binary interface 协议以下图，这里咱们称之为v1。 缓存
v1 协议有几个问题：服务器
一、消息是否发送成功没有明确的反馈；网络
二、若是一个消息发送失败，好比由于deviceToken 不合法，APNs 会在大约500ms 后断掉连接，在断链前发送的消息也会发送失败；并发
三、经验证，feedback service 只有报告应用被卸载后，形成deviceToken 失效的错误。而不会报告deviceToken 不合法这种类型的推送错误。app
也就是说若是咱们给一批用户发消息，只要有一个deviceToken 不合法，将会有可能形成若干个用户收不到消息。而且没办法确认哪些deviceToken不合法，哪些deviceToken 须要被重发。这应该是APNs 丢消息的一个重要的缘由。ide
（2）Binary Interface V2
通过开发者不断的向Apple 反馈这个问题，Apple 终于推出了一个新版本的binary interface，称为enhanced binary interface，咱们称这为v2。测试
咱们发现，在v1 的基础上增长了两个字段：优化
Identifier一个任意的值，用于一条消息的识别。若是发送出现问题，错误应答里会把Identifier 带回来。
Expiry离线消息超时的时间，若是为0或者小于0，APNs 不会保存这条消息。
和v1 同样，若是消息发送没有问题，APNs 不会有任何返回。和v1 不一样，而且很重要的改进是，若是发送出现错误，v2 会在断链以前返回一个错误应答，带上发消息时的Identifier 和一个错误码。
根据这个错误应答，咱们有机会找到是哪条消息发送出错，并肯定哪些消息须要被重发。
二、应用内消息和推送的区别
应用内消息（如下简称消息）和推送通知的区别，消息：不须要Apple 推送证书。由第三方的服务器下发，而不是APNs。相比通知，更快速，几乎没有延迟，可用于IM 消息的即时送达。可以长时间保留离线消息，可获取全部历史消息内容。
经过长链接技术下发消息，所以：手机必须启动并与第三方服务器创建链接。
若是手机启动马上切至后台，极可能链接没有创建。手机必须处于前台才能收到消息。手机从后台切回前台，会自动从新创建链接，并收到离线消息。
没有任何展现（横幅、通知中心、角标、声音），所以能够：自定义字段实现UI 效果。彻底在静默状况下处理App 内部逻辑。
应用内消息在App离线下，接收到应用内消息，把消息缓存到服务器，当App在线时和服务器创建长链接，服务器再把全部缓存的离线消息一块儿推给App，这是目前iOS聊天类App实现的方案。第三方服务提供的免费资源通常里面缓存条目是有限制的（极光缓存5条）。
三、App推送方案汇总
（1）本身搭建推送服务器
根据以上介绍要搭建本身的推送服务器，要根据APNs提供的推送协议，证书配置，搭建本身的推送服务，经过APNs推送在App杀死、后台、前台状态均可以收到通知，以下图咱们搭建的就相似于Provider的做用，经过APNs推送会受到网络、APNs服务器并发量等限制会出现延时（可忽略不计）。
本身搭建推送服务优势：不受限于第三方服务，拥有本身的推送服务，独享消息推送通道，对本身业务的扩展扩大颇有必要。缺点是：一直须要人员维护推送服务和APNs服务的对接，增长开发和运营成本，显然在发展公司从起点去作是很是艰难的。
如上图是推送流程图，服务器根据APNs提供的协议格式，把消息传递到APNs服务器，而后APNs服务根据deviceToken推送到指定设备，设备根据App包名找到对应的App。
上图是上面的一个内容补充，更详细的说明APNs的推送流程。设备向APNs服务注册deviceToken，设备把deviceToken发送给第三方服务，服务器根据APNs的协议格式组合成消息转发给APNs服务，APNs服务通知设备。
（2）极光推送
极光推送（JPush）是国内首个为移动应用开发者提供专业、高效的消息推送服务的产品。从上图能够看出，JPush包括2个部分，APNs推送（代理），与JPush应用内消息。
红色部分是APNs 推送，JPush 代理开发者的应用（须要基于开发者提供的应用证书），向苹果APNs服务器推送。由APNs Server推送到iOS设备上。
蓝色部分是JPush应用内推送部分，即App启动时，内嵌的JPush SDK会开启长链接到JPush Server，从而JPush Server能够推送消息到App里。
JPush iOS 推送相比直接向APNs 推送有什么好处？
减小开发及维护成本：
一、应用开发者不须要去开发维护本身的推送服务器与APNs 对接。
二、集成了JPush iOS SDK 后没必要本身维护更新device token。
三、经过JPush 的Web Portal 直接推送，也能够调用JPush的HTTP 协议API 来完成，开发工做量大大减小。
减小运营成本：
一、极光推送支持一次推送，同时向Android, iOS, WinPhone 三个平台。支持统一的API 与推送界面。
二、极光推送提供标签、别名绑定机制，以及提供了很是细分的用户分群方式，运营起来很是简单、直观。
提供应用内推送：
一、除了使得APNs 推送更简单，也另外提供应用内消息推送。这在相似于聊天的场景里颇有必要。
我的集成使用体验：集成相对简单，SDK集成度高，推送体验效果优异，不多出现延时状况，惟一的缺点是免费版本没有作离线点击通知作统计，能够为用户设置标签进行组推送、别名实现用户的单一推送，支持定时推送，能实现康加App推送须要的全部功能。
收费状况：
提供VIP服务，免费和VIP差异在最大并发数、专享高速推送通道、离线保存消息时间、消息送达统计等，详情见https://www.jiguang.cn/push-price
（3）信鸽推送
信鸽是深圳市腾讯计算机系统有限公司推出的一款专业的免费移动消息推送营销平台。针对iOS设备的消息推送，信鸽平台目前只借助APNs通道，暂不支持应用内自有通道的消息下发。
一、设备Token的自动化获取和注册，下降接入门槛。
二、帐号、标签与设备的绑定接口，以便开发者实现特定群组的消息推送，丰富推送方式。
三、点击量上报，统计消息被用户点击的次数。
我的集成使用体验：官网目前主要版本是2.5.0，我的体验较差，SDK代码集成度不是过高，大部分实现仍是用iOS原生API，官网已提供3.1.0版本SDK，集成度和极光类似度很高，3.1.0版本使用体验很好，能为用户设置标签进行组推送、帐号绑定实现用户的单一推送，能实现康加App的推送需求。
收费状况：
暂时没有提供付费服务，提供无限量推送条数
（4）个推
个推iOS SDK为应用提供推送服务，当应用在前台时，维持与推送服务器的长链接，实时接收推送消息；当应用在后台时，经过苹果APNs推送通知。集成简单快速。
一、能够根据用户属性创建不一样标签，进行定向推送，也能够进行A/B分组测试，从而进行精细化运营。
二、提供别名接口、静默时间设置接口、推送控制接口，知足APP的各类需求。
三、个推SDK不只能提供云端到客户端的推送服务，也能够提供从客户端上传至云端的服务，即推送消息链路支持上下行双向通道，开发者与客户端之间互动更便利。
四、支持APNs 多媒体推送和通知的展现、点击统计功能。
五、最新SDK还支持独有的APNs 展现和点击统计，有助于开发者掌握更精准的推送数据，优化运营效果。
我的集成使用体验：SDK集成度介于极光和信鸽之间，略差于极光，实现了APNS推送和消息内通道，在方法回调处理上相比极光不是很优异，个推和极光、信鸽最大的区别是（App在前台，推送会走应用内消息通道）。能为用户设置标签进行组推送、别名实现用户的单一推送，技术支持较好，反馈问题能获得及时的解决。免费下暂不支持定时推送。
收费状况：
个推提供VIP服务，和免费的主要区别在于用户数限制、推送通道、定时推送、独立推送通道等，详情参考：http://www.getui.com/cn/getui.html
（5）云巴推送
一、集成APNs
云巴SDK 集成了APNs，开发者无需开发与APNs 对接的模块，也没必要本身负责Device Token 的更新，一切交给云巴。
二、确保消息的送达
众所周知，APNs 并不保证消息的送达。 而云巴SDK 支持 离线消息的功能，可保证消息送达客户端。
在推送消息时，若是客户端当前不在线，消息将暂存在云巴服务器上（多达50 条，长达15 天）。 当客户端上线并成功链接到云巴的服务器后，服务器会把离线消息推送给该客户端。客户端成功接收后，服务器才会删除保存的离线消息。
我的集成使用体验：SDK只能代码集成，不能用cocoapods，下载的官方demo比较老旧，远程通知收不到， 远程通知只能作一个保存等进入前台时再显示出来。目前已反馈给云巴技术，技术支持较差，在群里发送一天没人回应。技术文档比较老旧，写的较乱，找东西比较费劲。我的综合体验是这几个推送体验最差的一个。并且免费消息量有限制，对于用户量趋于增大渐渐的会打到推送瓶颈。能设置频道和别名进行指定推送。
收费状况：
云巴提供付费服务，与免费的差异主要是推送消息量、离线消息保存时间、传输速度，免费20次每秒，付费5000次每秒，详情参考https://yunba.io/pricing/
四、各个方案优缺点分析
搭建推送服务：本身搭建推送服务，须要人力、技术、工做量、运营成本等，对我公司目前情况不适合考虑此方案。
极光推送：也是国内最先的移动推送平台，一直是免费状态，因为其出色的推送体验被大多开发者依赖。极光推送免费状态下支持无限推送条数。
信鸽推送：是腾讯移动推送，2.5.0版本我的使用体验不是很好，但新版本3.1.0版本体验出色，能实现推送的需求。目前信鸽推送的条数也不受限制，免费权限很高。
个推：免费服务不支持定时推送。内部集成双通道服务，App前台使用个推服务消息，App后台使用APNs推送，这样在前台收到消息无延时。
云巴推送：体验最糟糕的一个，官网技术文档乱，技术支持差，推送条目有限制。
五、App推送建议
（1）公司App推送需求
从当前App需求功能角度分析，用户打开App会以手机号或者惟一ID做为推送别名，当用户测量报告完成康加服务器调第三方API，向指定用户推送报告信息，推送过程用户可能在当前App（在前台），或在桌面和其余App等，在前台时最佳推送是不经过APNs，优势见消息内消息，在App后台必须使用APNs推送。App推送还有一个需求是多少天没有测量须要提醒用户测量，既须要具有定时推送功能。
（2）几种推送免费下作到程度
极光：无限推送条目、APNs推送通道、定时推送、（免费）不支持统计
信鸽：无限推送条目、APNs推送通道、定时推送、支持统计
个推：无限推送条目、两种推送通道、（免费服务）不支持定时推送
云巴：有限推送条目、两种推送通道、不支持定时推送、注册用户数限制
综合公司App推送需求：无限推送条目、定时推送是当前的基本需求，而实现这一点的有极光推送和信鸽。极光和信鸽都使用APNs推送通道。我的感受两种均可以使用，都有很出色的体验。信鸽支持免费统计功能，若是运营对统计要求的话信鸽更好些，极光是国内最先作第三方推送平台的，通过这么多版本的优化，不管是推送技术程度和使用体验都是很优异的。
六、离线推送
（1）APNs离线推送
若是推送的时候deviceToken对应的机器在APNS服务器上是离线状态，苹果会保存推送信息“一段时间”。当机器恢复在线状态时，推送信息到该机器。若是机器长时间不在线，苹果会抛弃掉这条消息。这个“一段时间”没有明文说多久，并且不知道苹果在不一样状况下对这个时间有没有动态调整，因此没法推测这个时间对于信息丢失状况的影响。
对于连续推送的状况，针对离线设备，苹果永远只存储最新的一条，上一条信息会被抛弃。
（1）极光非APNs离线推送（信鸽暂不支持非APNs离线推送）
对于Apple通知来讲，断网（断开了与Apple服务器的链接），即为离线。该状态下，Apple服务器只会保存1 条消息，在联网后发给手机。
对于应用内消息，有网，且处于前台时才是在线状态（与极光服务器有链接），其余均为离线。该离线状态下，极光服务器免费保存5 条离线消息，在线后发给手机。
参考资料：
https://docs.jiguang.cn/jpush/client/iOS/ios_sdk/#jpush-apns_1
https://redth.codes/the-problem-with-apples-push-notification-ser/
http://docs.developer.qq.com/xg/ios_access/ios-tui-song-fu-wu-jie-shao.html
https://www.jianshu.com/p/e9c313df746f