【友盟+】开发者社区

为什么iOS两次推送任务间隔时间较长,发送速度会变慢?

友盟PUSH 发表于 2015-8-18 13:22:21 | |阅读模式

友盟PUSH
友盟PUSH 发表于 2015-8-18 13:22:21 | 显示全部楼层 |阅读模式
需要说明的是,iOS应用的推送大部分情况下都要依赖苹果生态提供的APNs(Apple Push Notification Service)服务, 友盟推送所支持的iOS推送就是走的APNs通道。 如果你亲自使用过APNs做推送的话,那么这个问题想必你肯定能知道其中的缘由,因为APNs有很多个tricky的地方。 只不过你现在用的是第三方推送服务平台-友盟推送,所以出现这个问题你觉得可能是第三方推送平台的问题,其实不然,问题还是出在了APNs,我们来仔细分析一下这个问题。

先来简单说说苹果推送的原理,我们以APNs官网的图例来说明:

APNs生成device-token的过程

APNs生成device-token的过程

这个图要说明的是,设备的标识device-token是由APNs颁发的,App开发者或者第三方推送平台(图例中的Provider)需要收集这个device-token,APNs的推送是要求基于APNs颁发的device-token来推送的,如果是一个错误的、或者无效的device-token(比如App已经卸载了),APNs是不接受的。

服务器端连接APNs

服务器端连接APNs

这个图是重点,描述了真实消息推送的过程,App开发者或者第三方推送平台的服务器(图例中的Provider)向APNs发起推送指令的请求,推送指令包含了要下发设备的device-token和要下发的内容payload两部分,由APNs根据device-token(device-token是APNs生成颁发的)将payload下发到设备上,再由设备路由给具体的App。我们这里只关注第一步Provider到APNs的过程,即Provider的服务器和APNs的服务器通信的过程。APNs要求Provider首先与APNs建立一条长连接,Provider通过长连接可以将单个或者一批device-token发送给APNs,这个过程中,只要有一个device-token是不合法的(错误或者失效),那么APNs就会主动断掉Provider到APNs的长连接,Provider探测到连接断掉之后,需要重新建立连接,跳过上次失败的device-token,从下一个device-token接着发送。这个过程循环往复,直至将本次要发送的所有的device-token都推送到APNs,那么这次推送任务就算完成了。剩下的工作就是APNs将消息下发到具体设备了,APNs将消息下发给设备这个过程,不管是App开发者直接和APNs打交道、亦或是第三方推送服务器和APNs打交道,我们都是无法控制的了,所以推送的重点就是图例中的第一步Provider到APNs之间的通信了。

接下来我们回到问题,就是为什么隔了很久之后再去做推送,发送过程会变得非常慢。其实经过上面的解释,大家就应该能把原因猜的差不多了,就是因为长时间不发送的话,会有很多设备上的device-token已经无效了,比如设备卸载了App,或者系统版本升级过导致device-token变化了,或者是其它导致APNs认为device-token不合法的原因。总之,时间长了,不合法的device-token就会变多,在上面的章节中也提到,Provider和APNs的服务器建立长连接进行消息发送时,如果碰到了不合法的device-token,APNs就会断掉长连接,需要Provider重新建立连接。失效的device-token多了,那么断掉连接-重新连接的次数就会增多,每次重新连接都需要耗费时间,甚至如果频繁的断掉-重连APNs,有时候会被APNs认为是一种DoS攻击(APNs官网这么解释,但是具体判定的算法没有透露),会导致短时间内APNs拒绝Provider的连接,这种情况下,不管是App开发者自己直接和APNs打交道,还是第三方推送平台和APNs打交道,碰到这种情况都是无能为力的。 只能被动的接受“断掉-重连”的工作方式,因此整个发送过程会特别缓慢。 所以总结下来,长时间不发送消息,再次发送的时候,必然会出现推送缓慢的情况,原因就是无效的device-token越来越多,导致不断的“断开-重连”。所以在本文开头的时候,就提到过如果App开发者亲自使用过APNs服务的话,对这种现象必定是非常熟悉了,也会见怪不怪了。 如果是两次发送任务之间隔得时间不是太长,两次发送期间失效device-token不是那么多的时候,速度还是比较快的。

那么既然失效的device-token是导致发送变慢的主要原因,那么开发者朋友们肯定会想,能不能提前判断出失效的device-token,直接从发送列表中剔除掉这些失效的token。其实APNs是提供这样的feedback接口的,调用这个接口会得到一批失效的device-token列表。那么是不是在一次发送之前去调用一下这个接口,获取到无效的device-token,在发送的过程中剔除掉这些无效的device-token就能加快发送速度呢? 其实不然,因为feedback接口是一个后验的接口,即只有一次推送任务结束之后,APNs才会把该次失效的device-token更新到feedback接口的返回结果里面。如果你在一次推送任务前调用feedback接口,那么得到的失效device-token是基于上一次推送任务的结果的,两次推送任务之间发生的失效的device-token,是无法提前获取到的,只能等当次推送任务结束之后,才可以去获取新的失效token列表。

问题到这里就解释清楚了,那么碰到这种情况,我们该如何提升发送速度呢? 这里我们给大家讲讲友盟推送平台针对这种情况做的一些优化,相比App开发者直接连接APNs做推送,还是有一定的优势:) 解决方法很简单,就是友盟有很多台连接APNs的服务器,每个服务器我们又会开很多个线程去和APNs做连接,所以在并发度上会有较大的优势。所以针对一次发送任务,使用友盟平台做推送,速度肯定会比自己直接连接APNs有优势,这个也是不少开发者放弃了直接和APNs打交道,而是选择友盟推送来实现iOS推送的原因之一。

如果有更多关于友盟消息推送的问题,欢迎大家在我们的论坛里面提问: 友盟消息推送论坛,也欢迎大家关注我们的新浪微博账号"友盟推送": Sina Visitor System





上一篇:获取不到token
下一篇:在线求助

您需要登录后才可以发帖 登录 | 立即注册

本版积分规则

发表主题

精彩推荐

【报错必看】程序来源失败/新浪精简版授权失败C8998/
问题描述: 1.分享提示程序来源失败,请下载正确的第三方客户端2.新浪微博授权跳转到授权界面不动提示C8998
友盟5.0以下注册时报错
调用PushAgent的register方法报错[/backcolor] java.lang.NoClassDefFoundError: com.umeng.message.ut
集成推送register抛出异常!!!!!
报错内容就是图片 application中只调用了register

关注我们

新浪微博
微信

欢迎关注友盟官方微博微信!

在线客服
返回顶部 返回列表