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