我们的代码大致是这样子的：
如果推送多条，在表面套一个for循环即可。
代码写完，一实行，嘿，收到推送了。以为ios推送功能就这么完成了。
我们大概有几万用户须要推送，上线一运行，创造推送完成一小部分之后就无法推送了，缘故原由是被苹果给封了ip。后来官网一查，原来频繁的连接会被苹果认为是攻击性的访问，因此被封了ip，过一段韶光才能解封。
网上查不了不少资料，创造网友们写的干系的博客教程，都是和我们一样，推送一条就连接一次apns，然后write，然后关闭连接。推送下一条时再连接，write。很少有人提到频繁连接被封的事情。
经由一段韶光研究，创造可以一次连接进行多次推送。改进方法是将外层的for循环放到里面，这样就避免了频繁连接。改进后的代码大致如下
以为问题就这么完美的办理了，然而新的问题又涌现了。。
假设我们现在推送500条，但是有一部分token是失落效了的，失落效的缘故原由可能是用户卸载了app等。当循环wirte这500条数据的过程中，如果中间有一条token是无效的，会导致后续的正常的token无法推送。见下图：
在碰着失落效的token后，apns会忽略后面的token，然后在间隔一小段韶光后断开连接。韶光可能是一两秒。
为理解决这个可能，我们只须要在apns断开的时候，进行重连即可。
改进后的代码如下：
到了这一步，问题已经办理了大半。有心的朋友该当也创造了一个问题，一旦涌现失落效的token，紧随其后的token就受到了无妄之灾，明明是正常的token，却无法推送。
办理的办法只能一个：失落效的token不要进行推送就好了。那么问题来了，我们如何判断一个token是否失落效？在进行wirte的时候，苹果并没有返回给我们推送的结果，我们并不知道这个token是否正常，是否推送成功。
但是苹果给我们供应了一个feedback的接口，我们可以查到失落效的token。备注：要考试测验推送失落败了之后，苹果才知道token失落效。
代码大致如下：
将失落效的token存起来，下次推送的时候不要推送就可以了。
