1.如果设备offline，APNs的策略是什么？
根据苹果的官方文档，如果设备离线，APNs会启动QoS机制，实现原理：针对该device token和该app，APNs只会保留来自provider的最后一个消息，即新的消息会覆盖旧的消息。所以如果你的朋友手机关机或者飞行模式，你给他发10条微信，如果微信Provider不做特殊处理的话，你朋友再次启动手机的时候只会收到最后一条消息提醒。
2. device token什么时候会变？
Device和App的四种组合，这里我们讨论的是同一Device的同一App，其他三种组合device token肯定都不一样的。
一般情况下，App每次启动从APNs获取的device token是不会变的。但是有以下几种特殊情况：
（1）iOS系统升级，这个可能会导致拿到不同的device token。
（2）App卸载重装，这种情况在iOS 7/8下是没问题的，但是在iOS9/10系统下，拿到的device token就是不同的。
（3）APNs禁用你的device token，因为某些原因，比如安全问题，之前获取的device token失效，这时候再次获取的时候也是不同的。
面对这些不确定的因素，可以采取的策略是每次都重新获取device token，跟本地缓存的比较，如果相同，则不用更新。如果不同，则向自己的服务器去更新，同时更新本地缓存的token。
3. 如何提高推送消息的送达率
APNs跟device的长链接由iOS操作系统建立和管理，我们无法控制，我们能控制的是Provider跟APNs的通信，如何减少消息丢失以及避免重复消息可以在这里做一点研究。
先来看下无效token的情况，上面说的devicetoken可能会改变或者失效，这时候provider再给这个token发推送就会导致APNs返回失败。因为provider与APNs之间也是通过TCP长链接，这个失败报错不会立刻返回，而是要我们的服务器主动去监听。而且一旦有一个失败，后续的推送将会全部失败，连接也会被延时断开。所以如何准确的定位哪个消息推送失败，是解决所有问题的关键。
苹果定义了推送消息体的结构，其中有个字段identifier是消息的唯一标志符。推送失败的情况下，会返回给provider这个identifier，可以通过获取这个值来定位失败的消息，从而可以构造下一批重新推送的消息集合。
还有一个feedback service也是APNs的配套，苹果会把失败的device token维护在这个服务器上的一个列表，provider可以定期去获取这个列表，来更新本地服务器的token列表，从而可以减少无效的token，也就减少了失败的推送以及重连的次数。
4. iOS10的推送新特性
iOS10的推送更加丰富了，增加了声音，图片视频的推送，需要extention的支持，这可能是需要客户端最大改动的部分。交互方式也大大增加，支持多个category和action，用户可以自定义行为。
