IOS消息推送相关介绍

63 阅读 0 评论 42 点赞

我是靠谱客的博主积极长颈鹿，最近开发中收集的这篇文章主要介绍IOS消息推送相关介绍，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

有段时间没写博客了，在走上“黑暗的道路上”...

万恶的分割线

最近这段时间一直在做手机APP服务端相关开发工作，其中对于推送这块是我单独负责的一个模块，在此有些相关细节的说明，相信会对一些开发有些帮助

一.基本介绍

苹果推送官网相关介绍：
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//app
le_ref/doc/uid/TP40008194-CH100-SW9
相关推送的原理，建议最好查看官网文档，看完后，对其推送会有深入的理解。
IOS推送协议经历过协议的修订，现在是V2版本
相关推送的实现，java中主要有javapns与apns两个开源项目，我们项目中使用了jar包javapns2.2版本，并在此基础上修订了一些小地方。
javapns开源地址https://code.google.com/p/javapns/
对于IOS推送的证书生成及相关细节，有需要的可自行查找。(本人只做服务器端开发)

二.推送方式

IOS推送主要有两种主式，一种是sandbox方法，一种是production方式，前者是测试所用，后者是线上产品推送所用。

两种不同的方式，会推送到苹果不同的服务器上。
每个设备每个应用会有一个叫token的唯一标识，在线上与测试过程中，也会生成不同的token,测试所用token一定要发送到sandbox服务器，还在线上需要发送到

production服务器中去。在此需要注意，javapns在实现时，SSLsocket会重用，如果当使用一个sandbox的token发送到production上的服务器上时，会引起此socket连接不可用，但是此状态是无法检测的，这会引起后续使用此socket连接推送的消息都会推送失败，因此一定需要注意。

另位SSLsocket一段时间未使用，会出现推送失败的问题，现在我们的修订是，对于SSLSocket空闲时间过长，在发送消息时会进行检测，出现此情况，会重建此连接后再继续推送消息，从而保证推送的成功。

三.推送内容
消息推送时，主要有对应三个字段
alert 推送的消息内容（会组装成Json格式）
badge 用户未读消息的条数（需要我们自己的服务器保证用户的未读消息自增）
sound 用户接收消息时所听到的声音提示（不填，或者使用默认的"default"字符，即是默认声音，如果需要自定义声音，需要在自己的应用下指定声音文件，并在推送

时写上此声音文件的名字，如果无对应的文件，会以默认声音提示）对于以上字段值得说明的有时我们需要达到一种无声的状态，即在应用中可配制，对用户只显示提示的未读消息条数，还不显示推送内容，也无推送声音，此实现只要把推送内容填成空字符即可~

对于定制的声音格式，IOS是有限制的：

Custom alert sounds are played by the iOS system-sound facility, so they must be in one of the following audio data formats:

Linear PCM
MA4 (IMA/ADPCM)
µLaw
aLaw

You can package the audio data in an aiff, wav, or caf file.

需要注意
四.推送优化
使用javapns推送时，存在多线程的方式，可用于推送，但是其多线程的实现对于实际使用时会存在问题。
对于相同的用户，消息推送提醒比较频繁时，由于多线程，会出现晚发送的消息会比早推送的消息早提示，并且会引起未读消息条数乱序的错误提示现象，此问题还是比较严重的。对于此，可基于相同的token设置做映射到相同的线程进行推送，因为其基于队列的方式，基于此实现，只要入队列保证了唯一性，即可保证推送顺序的准确性。

五.token失效问题
说到token问题，苹果为了更好的用户体验，这个推送带来了多少推送的用户量，应该很多服务器啊！！！
对于token失效，是指苹果在推送应用的消息给此设备时，发现此设备对应的应用已经删除，苹果会保证此token失效在feedback队列中。
我们可以通过其feedback服务定时去查询失效token，并检测到哪些token已经失效，可做特殊处理。
但实现存在的问题：
当一个用户在卸装后，收到一条推送后，此token就会被标识为已经失效，但是用户在马上又重装了此应用后，并登录，使用，此前feedback服务如果一直未去检测，还会把此token保存在失效的队列中。虽然此不影响到用户的推送与使用。如果feedback服务在处理时，对于失效的token进行了清除等严重的操作，会小悲剧下下。当然苹果的实现还是比较合理的，feedback返回时，同时也会带上此token失效的时间，通过此时间应用可进行相应的判断做处理。值得说明的是feedback在调用后，苹果对于此失效的token将不会再保存。

以上是IOS推送在实现过程中比较明显的问题，希望对各位有所有帮助。