From 2db897729b95fe2b38db817cc6951ed8093a431c Mon Sep 17 00:00:00 2001 From: chenyilong Date: Fri, 18 Nov 2016 10:44:15 +0800 Subject: [PATCH] update APNs article --- ...\345\205\250\346\226\260APNs\345\215\217\350\256\256.md" | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git "a/\345\237\272\344\272\216HTTP2\347\232\204\345\205\250\346\226\260APNs\345\215\217\350\256\256/\345\237\272\344\272\216HTTP2\347\232\204\345\205\250\346\226\260APNs\345\215\217\350\256\256.md" "b/\345\237\272\344\272\216HTTP2\347\232\204\345\205\250\346\226\260APNs\345\215\217\350\256\256/\345\237\272\344\272\216HTTP2\347\232\204\345\205\250\346\226\260APNs\345\215\217\350\256\256.md" index ad1a913..5c45670 100644 --- "a/\345\237\272\344\272\216HTTP2\347\232\204\345\205\250\346\226\260APNs\345\215\217\350\256\256/\345\237\272\344\272\216HTTP2\347\232\204\345\205\250\346\226\260APNs\345\215\217\350\256\256.md" +++ "b/\345\237\272\344\272\216HTTP2\347\232\204\345\205\250\346\226\260APNs\345\215\217\350\256\256/\345\237\272\344\272\216HTTP2\347\232\204\345\205\250\346\226\260APNs\345\215\217\350\256\256.md" @@ -21,7 +21,7 @@ -- | 被吐槽的内容 | 吐槽 -------------|-------------|------------- 1 | 使用第三方SDK接入推送服务，SDK提供商却告诉我，他们无法获知哪条消息成功发送给了APNs，哪些失败了，而且即使APNs接收了，APNs是否能保证投递成功，他们也无能为力。| 我把消息交给你了，你告诉什么都保证不了？推送成功与否”基本靠猜“？ - 2 | ![](http://ww1.sinaimg.cn/large/006tNbRwjw1f9w23sj9gsj30yg07jq3v.jpg)![](http://ww1.sinaimg.cn/large/006tNbRwjw1f9w23sltkhj30yi07naay.jpg) | 为什么我推了四条消息，APNs就只给我最后一条？！ + 2 | ![](http://ww1.sinaimg.cn/large/006tNbRwjw1f9w23sj9gsj30yg07jq3v.jpg)![](http://ww1.sinaimg.cn/large/006tNbRwjw1f9w23sltkhj30yi07naay.jpg) | 为什么我推了多条消息，APNs就只给我最后一条？！ 3 | 推送内容只能是 256 字节 | 这也太小了，根本不够用啊！ 4 | 生产环境推送证书、测试环境推送证书、tvOS推送证书、watchOS推送证书、VOIP推送证书。。 | 证书太多了，制作、切换证书太麻烦！ @@ -136,9 +136,9 @@ APNs的确改进来不少，但仍有需要改进对地方。还是有坑： 这中间发生了什么？ -当 APNs 向你发送了4条推送，但是你的设备网络状况不好，在 APNs 那里下线了，这时 APNs 到你的手机的链路上有4条任务堆积，APNs 的处理方式是，只保留最后一条消息推送给你，然后告知你推送数。那么其他三条消息呢？会被APNs丢弃。 +当 APNs 向你发送了多条推送，但是你的设备网络状况不好，在 APNs 那里下线了，这时 APNs 到你的手机的链路上有多条任务堆积，APNs 的处理方式是，只保留最后一条消息推送给你，然后告知你推送数。那么其他三条消息呢？会被APNs丢弃。 -有一些 App 的 IM 功能没有维持长连接，是完全通过推送来实现到，通常情况下，这些 App 也已经考虑到了这种丢推送的情况，这些 App 的做法都是，每次收到推送之后，然后向自己的服务器查询当前用户的未读消息。但是APNs也同样无法保证这四条推送能至少有一条到达你的 App。很遗憾的告诉这些App，这次的更新对你们所遭受对这些坑，没有改善。 +有一些 App 的 IM 功能没有维持长连接，是完全通过推送来实现到，通常情况下，这些 App 也已经考虑到了这种丢推送的情况，这些 App 的做法都是，每次收到推送之后，然后向自己的服务器查询当前用户的未读消息。但是APNs也同样无法保证这多条推送能至少有一条到达你的 App。很遗憾的告诉这些App，这次的更新对你们所遭受对这些坑，没有改善。 为什么这么设计？APNs的存储-转发能力太弱，大量的消息存储和转发将消耗Apple服务器的资源，可能是出于存储成本考虑，也可能是因为 Apple 转发能力太弱。总之结果就是 APNs 从来不保证消息的达到率。并且设备上线之后也不会向服务器上传信息。