iOS 和 android 后台接收推送的后台推送原理各是什么？有什么区别

来源：蜘蛛抓取(WebSpider) 时间：2016-11-29 02:35 标签： android消息推送原理
iOS 的推送iOS 在系统级别有一个推送服务程序使用 5223 端口。使用这个端口的协议源于 Jabber 后来发展为 XMPP ，被用于 Gtalk 等 IM 软件中。所以， iOS 的推送，可以不严谨的理解为：苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。然后，系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事。然后，系统分别通知这些 Apps 。这个消息的内容是这样的：应该说，苹果这种方式在技术上没有什么创新。但是，整个架构是很了不起的。 因为：1&使用久经考验的协议，技术风险小。2&苹果勇于承担责任：他需要维护一个代价不小的服务器集群，而且要为服务器的 down 机负责。选择低风险的技术方案 Bug 更少，减轻了用户的痛苦，这是构架师的功劳。苹果承担责任，尽可能的减少了不可控的意外，保证了用户体验。这，只能说是公司决策者的功劳。（从侧面说明有个懂技术的 VP 是多重要。。。而 Scott 走人了。。）他们带给用户的好处也是实实在在的。1 安全。只有登录过的开发者可以通过苹果的服务器推送。2 快速，稳定，可靠。苹果掌控推送服务器和 OS 。3 更省电。4 让整个系统的体验更统一和简单。不会出现杀后台这种脑残事。（不用大量 Apps / Apps 的服务为了推送挂后台）。也不会出现 Apps 被杀就收不到推送这种脑残事（早一点的新浪微博 Android 版仍然如此）。5 开发容易。当然，开发者还是要做些事情，比如维护个服务器什么的：&。但是复杂度无疑降低很多了。Android 的推送Apps 挂后台一直是 Android 引以为豪的特性（虽然我真的不知道是好处多还是坏处多。。）。。。大家挂后台等待推送就成为技术选择。当然， Google 事后也提供类似苹果的推送方式了。倒也谈不上抄袭，毕竟苹果的整个技术实现也没有什么特别创新之处。用户的电池？&Apps 的开发者不会站在系统层面考虑的。他会假设其他 Apps 没有那么&不自觉&。而 Google 不强制的结果就是：没人真正为用户的电池负责。但是， Google 的方案也并非全是悲剧：也因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。最后的话强制和封闭，有时候并非坏事。他意味着做出这个决定的人，要为此负责。所以，如果说苹果的推送方案有何创新？我以为是超越技术，不惜让公司承担更多风险和责任的解决方案。（类似的还有 BB 的专用网络， Kindle 的全球 3G ）个人相信，担负起这些&额外&的责任，是值得的。。。只要是为了用户。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　清澈Saup&&来自知乎
阅读(...) 评论()上下架应用
只需一步，快速开始
iOS 和 Android 的后台推送原理各是什么？有什么区别？
原作者:来自: 知乎 17:42
iOS 的推送iOS 在系统级别有一个推送服务程序使用 5223 端口。使用这个端口的协议源于 Jabber 后来发展为 XMPP ，被用于 Gtalk 等 IM 软件中。所以， iOS 的推送，可以不严谨的理解为：苹果服务器朝手机后台挂的一个 ...
iOS 的推送iOS 在系统级别有一个推送服务程序使用 5223 端口。使用这个端口的协议源于 Jabber 后来发展为 XMPP ，被用于 Gtalk 等 IM 软件中。所以， iOS 的推送，可以不严谨的理解为：苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。然后，系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事。然后，系统分别通知这些 Apps 。这个消息的内容是这样的：应该说，苹果这种方式在技术上没有什么创新。但是，整个架构是很了不起的。 因为：1&使用久经考验的协议，技术风险小。2&苹果勇于承担责任：他需要维护一个代价不小的服务器集群，而且要为服务器的 down 机负责。选择低风险的技术方案 Bug 更少，减轻了用户的痛苦，这是构架师的功劳。苹果承担责任，尽可能的减少了不可控的意外，保证了用户体验。这，只能说是公司决策者的功劳。（从侧面说明有个懂技术的 VP 是多重要。。。而 Scott 走人了。。）他们带给用户的好处也是实实在在的。1 安全。只有登录过的开发者可以通过苹果的服务器推送。2 快速，稳定，可靠。苹果掌控推送服务器和 OS 。3 更省电。4 让整个系统的体验更统一和简单。不会出现杀后台这种脑残事。（不用大量 Apps / Apps 的服务为了推送挂后台）。也不会出现 Apps 被杀就收不到推送这种脑残事（早一点的新浪微博 Android 版仍然如此）。5 开发容易。当然，开发者还是要做些事情，比如维护个服务器什么的：&http://www./3979。但是复杂度无疑降低很多了。Android 的推送Apps 挂后台一直是 Android 引以为豪的特性（虽然我真的不知道是好处多还是坏处多。。）。。。大家挂后台等待推送就成为技术选择。当然， Google 事后也提供类似苹果的推送方式了。倒也谈不上抄袭，毕竟苹果的整个技术实现也没有什么特别创新之处。用户的电池？&Apps 的开发者不会站在系统层面考虑的。他会假设其他 Apps 没有那么“不自觉”。而 Google 不强制的结果就是：没人真正为用户的电池负责。但是， Google 的方案也并非全是悲剧：也因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。最后的话强制和封闭，有时候并非坏事。他意味着做出这个决定的人，要为此负责。所以，如果说苹果的推送方案有何创新？我以为是超越技术，不惜让公司承担更多风险和责任的解决方案。（类似的还有 BB 的专用网络， Kindle 的全球 3G ）个人相信，担负起这些“额外”的责任，是值得的。。。只要是为了用户。PS勇于承担责任的公司也更像个可靠的成年人，而不是一个随意胡闹的孩子。
Powered by
鸟哥笔记 沪ICP备号-1

我要回帖

更多关于 android消息推送原理 的文章

 

随机推荐