APNs的工作机制简单来说可以分为两步：
第一步是注册推送服务从APNs获取device token来告知应用提供商服务端。
第二步是应用提供商服务端通过APNs给设备推送消息，device token是作为设备的唯一标示。
device token特性
相信很多人都有这样一个疑问，作为一个设备推送的唯一标示，device token是否会变化或者过期呢？苹果在这点上有些含糊其辞，只是在官方文档上建议开发者在每次启动应用时应该都向APNs获取device token并上传给服务器。从这句话来看，device token是会变化的，不然不用每次启动都去获取。
因为苹果官方没有给出明确的device token变化的情况，所以以下列举的都是一些前人总结的经验，主要援引了stackoverflow上关于这个问题一个回答，回答者称是和苹果的一个工程师交流及自己实验得出的结果。
1.升级系统device token有可能变化，确认的是升级到iOS5会变化，猜测是升级大的系统版本后device token会变化。
2.抹掉所有内容和设置，reset设备后，device token会变化。3.恢复一个非本机的备份后，device token会变化。
4.device token会过期，这个众说纷纭，有说是半年的，有说一年，有说两年的，不过会过期应该是确凿的。
5.备份或者恢复本机的备份，device token不会变化。
所以保险起见，按照苹果的每次启动应用时检查device token并发送到服务器是比较稳妥的做法。
1.每个device token都是唯一的，只会对应一台设备。
2.device token与设备系统相关（注意不是和设备绑定的！详解见后文），同一设备系统上不同应用获取的token是同一个。
3.应用卸载重新安装，获取到的device token不会变化，而且不会再弹出推送权限申请的弹窗，会自动继承前一次安装的设置信息。这个特性容易引发一些安全问题，用户卸载重新安装一个应用后，还没有登录应用，就可能接到上次登录帐号的推送消息了。我使用iPhone QQ和Skype都碰到过这种情况。客户端没有办法处理这个问题，因为被卸载时客户端是没法做出反应来通知服务器的。苹果有一个feedback的机制可以解决这个问题，苹果为每个应用程序维护了一个不断更新的推送失败的设备列表。服务端可以去定期检查并更新推送设备列表，这样能解决大部分问题，也能减少不必要的报文开销。
4.第三点客户端不能处理，但退出登录通知服务器就是客户端的工作了。用户退出登录客户端时，客户端应该告知服务器，停止对这个设备继续推送用户退出登录帐号的消息了。这点应该不算device token的特性了，是一个标准处理方法。
APP状态
根据application.applicationState的状态，判断执行哪种动作。
UIApplicationStateActive, // 激活状态，用户正在使用App
UIApplicationStateInactive, // 不激活状态，用户切换到其他App、按Home键回到桌面、拉下通知中心
UIApplicationStateBackground // 在后台运行
服务器相关：
1、node-apn
第三方服务：
1.腾讯信鸽推送 http://xg.qq.com/
2.极光推送 https://www.jpush.cn/
3.友盟推送
3.个推 http://www.getui.com/
4.云巴
3.Amazon SNS 移动推送通知 https://docs.aws.amazon.com/zh_cn/sns/latest/dg/SNSMobilePush.html
