×

深圳网站建设—APP开发—网站制作—小程序开发_博纳网络公司

0755 -
82538016
82560826
网站制作资讯

iOS推送功能详细流程以及解决方案

文章编辑:网站建设 文章来源:APP开发 浏览量:

iOS推送功能详细解决方案
  iOS推送必必须用到APNS。ApNS是Apple Push Notification Service (Apple PushH服务)由于iOS系统的限制,应用是不允许在后台运行并连接网络的。如果App在iOS上没有运行,但是我们APP开发者却想推送消息给使用该App的iOS用户,只能通过APNS推送消息。深圳APP开发公司现在就这个问题结合我们多年实际开发经验整理归纳出如下几种方法供您参考:
1.APNS原理
  APINS推送有一个重要概念:Device t oken。Device token是iOS设备上某个App在APNS上的唯一标识符,通过Device tokeu,APNS就知道把消息推送到哪台iOS设备上由哪个App接收。
APNS的推送原理如图9-40所示
  根据图9-40“APNS的推送原理”,APNS推送流程如下。
(1) iOS设备在网络接通的情况下连接APNS服务器,连接成功后和APNS服务器保持一个长连接。在图9-40中,iOS设备l对应的是长连接l。
(2) App后台服务器按照定格式推送消息(消息己包含Device token)到APNS服务器。在图9-40中,推送的消息包含了Device tokenl。
(3) APNS服务器根据Device token查找其对应的长链接。在图9-40,Device tokenl对应的是长链接l,APNS服务器把消息推送到长链接l对应的是iOS设备l。
(4) iOS没各l收到推送消息后,如果该推送消息对应的App正在运行,则通知App处理,如果该App没有运行,则在屏幕上弹出消息。
2.APNS推送协议分析
  APNS上的推送接口称为Binary Interface,App后台连接APNS服务器后必须按照Biuary Interface格式推送消息。
如图9-41所示是最初版本的Binuy Interface,称之为vl版。
这个版本的接口有如下两个问题。
  ·没法确定消息是否发送成功。
  ·当发送了一个无效Device token后,APNS和iOS设备的连接会在短时间内断开,在连接断开之前发送的Device t oken也会失效。这就是说,当连续推送批消息(里面可能包含无效的Device token)后如果链接断开,没法确定推送给哪些Device token的消息是已经发送成功,推送给哪些Device t oken的消息需要重发,这就造成了用户经常收不到推送的情况。
  接下来苹果推出了改进版本的Binary Interface,称之为V2版,如图9-42所示。
我们可看到V2版的协议增加了如下两个字段。
  ·Identifier:用于识别条消息,可以是任意值。如果发送出现问题,在APNS返回的错误应答中会包含出问题的Identifier。
  ·Expiry:离线消息超时的时间。如果为0或者小于0,APNS服务器不会保存这条消息。在V2版中,如果发送过程中发生了错误,会返回个错误的Error-response.包含status和Identifier。错误码的格式如图9-43所示。
  根据错误应答的Identifier,开发者就知道推送给哪些Device token的消息需要重发。
  Binary Interface V2有个不便的地方:每个推送只能给一个Device token推送消息,如果要给上百万台设备推送消息那效率非常低,于是苹果推出了Binary Interface V3版,如图9-44所示。
  从图9-44中可看到,在Binarv Interface V3版中次给多个Device token发送消息。
3.iOS推送服务器架构
服务端推送APNS过程中需要注意推送了无效Device token的问题。为什么会有无效的Device token呢?因为当用户卸载了App后,用户的Device t oken就失效,但是这个失效的Device token可能被开发者保存在数据库,下次推送时还会把这个失效的Device token推送到APNS服务器。
  如果推送返回Error-response,iOS推送服务器获取Error-response中错误消息的Identifier.该identifier后的推送都需要重发。因为服务器发送的消息包含了无效Device token后隔段时间,服务器和APNS连接会断开,从发送无效的Device t oken那个刻起直到APNS连接断开,这段时间所发送的Device token都会失效。所以考虑重发解决Device token的问题时可以把发送消息保存到历史消息发送队列,从历史消息发送玑列中找到Error-response中返回的Identifier.就可以知道哪个消息开始出错,这样就能知道哪些消息需要重发了。
APNS历史消息玑列如图9-45所示
  假设当Error-response中返回的Identifier为4,那么后面Identifier的5和6都需要重发。
  另外APNS的feedback s ervice会返回那些已经卸载的设备的Device t oken,定期在数据库中删除这些无效的Device token以提高推送的成功率。
  因此针对重发Device token的问题.iOS推送服务器工作的流程如下。
(1)应用服务器把推送的消息写入到iOS推送服务器的APNS消息队列。
(2) APNS发送模块从APNS消息队列取出一个消息,根据APNS推送协议封装这个消息(包括给这个消息加上一个全局唯一的Identifier),然后发送到苹果APNS服务器,同时把发送的消息保存在APNS历史消息队列。
(3) iOS推送服务器中有一个模块不断检测苹果APNS服务器是否有返回Error-response,一旦发现Error-response就获取其中的Identifier,遍历APNS历史消息队列.把队列中这个Identifier后面的所有消息重新放入到PNS消息队列,让APNS发送模块重新发送这些消息。
APP开发公司工程师上面所描述的iOS推送服务器的工作流程如图9-46所示。
好了,本文关于ios系统推送功能的解决流程就分享到这里,喜欢本站的朋友请持续关注本站,我们会定期更新相关类型经验分享文章。博纳网络编辑整理。


当前文章链接:/construction/appkaifa/1842.html
如果您觉得案例还不错请帮忙分享:

[声明]本网转载网络媒体稿件是为了传播更多的信息,此类稿件不代表本网观点,本网不承担此类稿件侵权行为的连带责任。故此,如果您发现本网站的内容侵犯了您的版权,请您的相关内容发至此邮箱【qin@198bona.com 】,我们在确认后,会立即删除,保证您的版权。