ios 推送丢失问题

以下要讨论的推送丢失问题,前提是ios已经成功推送,但到达率不高的现象。

推送的整体实现环境:APP推送 架设 | ios 推送 PHP具体实现

在采用app推送后,一度为了追求最大的推送消息量,而将ios推送的一次推送值设为500条,在使用一段时间,发现ios测试机接受到的推送消息时断时续。

例如:
服务端每天08:00 至 13:00 推送给每台装了app的ios设备 一条关于今天的资讯。
按照一切流程正常(排除ios设备网络问题),ios设备接收到的推送信息间隔很大。
ios设备上有时候一连3天都有接收到推送的消息,有时候隔了3天也没见到一条推送消息。很不稳定。

分析
由于在 APP推送 架设 一文中,我们的服务器推送架设,对推送的过程和结果都进行了记录:
1、每成功推送一批消息给apns,都会将这些推送消息和推送动作记录在数据库里(mongoDb)。
2、每建立一次ssl链接,如果中途断掉,将会在日志里面记录断掉的点。

首先翻了一下,每次建立ssl链接后断掉的断点日志:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[ 2013-05-16 09:00:02 ]  [48]  [ 25 - 67214 ] [ <73bcbf1a ...... b400aba6> ]
[ 2013-05-16 09:01:02 ]  [49]  [ 25 - 66858 ] [ <b297d83a ...... 138dde7a> ]
[ 2013-05-16 09:01:02 ]  [49]  [ 25 - 68162 ] [ <5ae010a0 ...... 3c246137> ]
[ 2013-05-16 09:01:03 ]  [48]  [ 25 - 67128 ] [ <f0a03104 ...... 1d4f4b02> ]
[ 2013-05-16 09:01:03 ]  [106]  [ 25 - 65020 ] [ <cfd51575 ...... 4a155252> ]
[ 2013-05-16 09:02:02 ]  [105]  [ 25 - 67846 ] [ <e0e702e2 ...... b1a43c0a> ]
[ 2013-05-16 09:02:02 ]  [138]  [ 25 - 70190 ] [ <403f9325 ...... ef77f6ce> ]
[ 2013-05-16 09:02:04 ]  [106]  [ 25 - 69698 ] [ <7f39be75 ...... db8aafb1> ]
[ 2013-05-16 09:04:02 ]  [106]  [ 25 - 71787 ] [ <03ed937a ...... ed8d23ff> ]
[ 2013-05-16 09:05:02 ]  [48]  [ 25 - 69847 ] [ <ebf76430 ...... 8a6b874d> ]
[ 2013-05-16 09:06:03 ]  [49]  [ 25 - 72995 ] [ <d01b5016 ...... 4d3e3b51> ]
[ 2013-05-16 09:06:03 ]  [146]  [ 25 - 74817 ] [ <7f9ee669 ...... 7ad56199> ]
[ 2013-05-16 09:07:02 ]  [107]  [ 25 - 73025 ] [ <b9768292 ...... 75bf334d> ]
[ 2013-05-16 09:08:03 ]  [168]  [ 25 - 76533 ] [ <bcbb8ccd ...... e49cfdac> ]
[ 2013-05-16 09:08:03 ]  [48]  [ 25 - 75925 ] [ <8724982a ...... 6268d937> ]
[ 2013-05-16 09:08:03 ]  [48]  [ 25 - 75246 ] [ <5164e2a0 ...... 1ead0d83> ]
[ 2013-05-16 09:09:02 ]  [48]  [ 25 - 74579 ] [ <5a3ee344 ...... 579e3b52> ]
[ 2013-05-16 09:09:03 ]  [48]  [ 25 - 72005 ] [ <fd5b29c2 ...... 6150c7a1> ]
[ 2013-05-16 09:11:03 ]  [108]  [ 25 - 79394 ] [ <8a3865c4 ...... 1791ee20> ]
[ 2013-05-16 09:11:04 ]  [49]  [ 25 - 79431 ] [ <a8d1b8fe ...... 530ccc84> ]
......

---日志参数----:
第一个参数:推送的时间
第二个参数:每次运行推送的消息条数
第三个参数:推送对象在内部的标识
第四个参数:推送对象设备在apns的唯一标识

又翻了好几天的断点日志,发现一个很有趣的现象, 即第二个参数出现48的概率远远超过其他,而且是出现的数值里面最低的。结合发生的ios推送丢失现象,因此大胆推测程序每次和apns建立ssl传输数据,apns最多接受48条,超过48条的数据,即使apns接收了,也不会进行推送。如果这个推测成立就可以很好的解释,为啥ios设备接收到的消息时断时续。

解决
那么就行动吧,在推送服务端将ios每次推送的条数为48条,但是提高推送的频率,让总体的推送量没有因此而减少。
又观察了几天的推送情况:
1、建立的推送断点日志没有再产生
2、好几台ios测试设备每天均收到推送的消息,没有再出现断断续续的现象

至此,ios推送丢失问题基本解决了。可以更大规模的应用了。

你可能感兴趣的:(ios 推送丢失问题)