|
应该说，苹果这种方式在技术上没有什么创新。但是，整个架构是很了不起的。因为： 1.使用久经考验的协议，技术风险小。 2.苹果勇于承担责任：他需要维护一个代价不小的服务器集群，而且要为服务器的down机负责。 选择低风险的技术方案Bug更少，减轻了用户的痛苦，这是构架师的功劳。苹果承担责任，尽可能的减少了不可控的意外，保证了用户体验。这只能说是公司决策者的功劳。（从侧面说明有个懂技术的VP是多重要......而Scott走人了......） 他们带给用户的好处也是实实在在的。 1.安全。只有登录过的开发者可以通过苹果的服务器推送。 2.快速，稳定，可靠。苹果掌控推送服务器和OS。 3.更省电。 4.让整个系统的体验更统一和简单。 不会出现杀后台这种脑残事（不用大量Apps/Apps的服务为了推送挂后台），也不会出现Apps被杀就收不到推送这种脑残事（早一点的新浪微博Android版仍然如此）。 5.开发容易。当然，开发者还是要做些事情，比如维护个服务器什么的：http://www.ifanr.com/3979。但是复杂度无疑降低很多了。 Android的推送 Apps挂后台一直是Android引以为豪的特性（虽然我真的不知道是好处多还是坏处多），大家挂后台等待推送就成为技术选择。当然，Google事后也提供类似苹果的推送方式了，倒也谈不上抄袭，毕竟苹果的整个技术实现也没有什么特别创新之处。 用户的电池？ Apps的开发者不会站在系统层面考虑的。他会假设其他Apps没有那么"不自觉"。而Google不强制的结果就是：没人真正为用户的电池负责。 但是，Google的方案也并非全是悲剧：也因为整个技术方案非强制，Android的Apps在接收到推送后的表现更为灵活。 像Line的Android版本可以在推送通知的Popup上直接回复，iOS就需要越狱才能做到了。 最后的话 强制和封闭，有时候并非坏事。他意味着做出这个决定的人，要为此负责。所以，如果说苹果的推送方案有何创新？ 我以为是超越技术，不惜让公司承担更多风险和责任的解决方案（类似的还有BB的专用网络，Kindle的全球3G）。个人相信，担负起这些"额外"的责任，是值得的......只要是为了用户。 PS：勇于承担责任的公司也更像个可靠的成年人，而不是一个随意胡闹的孩子。 郑紫阳，表演时不知应该望向边。 51票，来自周文杰、闲云野鹤、谢浩然更多 iOS系统的推送（APNS，即ApplePushNotificationService）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。 你的例子里面，腾讯QQ的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。 而Android就不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实Android也有类似APNS的GCM（GoogleCloudMessage），属于开发者可选，非强制。（更多请看本回答评论区里面@BillCheng的补充） 所以你大概看出来区别，iOS的消息推送机制面世之时是一种全新的解决方案（堪称平台中的平台），应用本身不能有常驻的后台进程，系统的开销少，内存使用更少，电量也更少（把更多的运算和资源开销放在云端，非设备端）。而Android的特点，虽然开销大，优点是更稳定快速，但不明显。 更多请阅开发文档：ApplePushNotificationService(APNs)|http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html...2012-12-24? 方家文，Oldcodingman 3票，来自任雪涛、雁渡、王仲禹 我感觉以上的回答，并没有正点地谈到"原理"，并且我对其评判断观点也不认同，所以尝试来回答下这个问题。 我的观点是：APNs是iOS成功的一个非常重要的设计！ 先说原理 iOS的推送：就是Apple官方的APNs（ApplePushNotificationservice）。Android的推送：Google官方的是GCM(GoogleCloudMessaging）。 本质上，APNs与GCM是类似的技术实现原理：即系统层有一个常驻的TCP长连接，一直保持的长连接，即使手机休眠的时候也在保持的长连接。这里对于大部分人来说，最不理解的就是，休眠时候都保持在那里的TCP长连接，不会耗电很厉害么？ 答案是：不会。这是手机的设计来做到的。TCP长连接有个心跳的时间，在国外可以很长比如30分钟，在国内则因为网络环境复杂一般10分钟。客户端发起的心跳，会短暂地消耗手机电能，但在这个心跳间隔期间，则消耗电能是很少的。当在心跳期间服务器端有推送信息过来时，客户端可以收到并做处理。 这里有篇文章以Android为例做原理解释：http://blog./index.php/jpush_wireless_push_principle/... 再说APNs的设计成功处 iOS为了真正地为用户体验负责，不允许应用在后台活动。有了这个限制，但是对于终端设备，应用又是有必要"通知"到达用户的，随时与用户主动沟通起来的（典型的如聊天应用）。 这就是APNs的逻辑所在：iOS自己做个长驻后台保持连接。所有应用，有必要（申请）并且被允许（用户可以改设置）的话，可以通过APNs中转到达用户。这样就完善了！ 有可能很多人没有真正地体会到iOS不允许后台应用的好处。我是Android开发人员，Android手机上一般只保留几个常用的应用，不常用就卸载。但是我的iPhone/iPad上则是，除非空间不足，一般不会删除应用。 Android就像Windows，你要真的很费心去维护：有软件在干背后干坏事么？设备又给拖慢了，要清理。要考虑杀毒了...... Android因为后台可以长驻，尤其是国内的Android的手机上Google自家的推送服务GCM处于基本不可用的状态。所以，各App各显神通。聊天类应用的话，大多数直接借用XMPP规范里的一些成果。少量如微信有IM底子的，自己开发协议。这些在实现原理上与APNs/GCM没有本质的区别，但有一定的技术门槛。而大多数普遍应用，要使用推送的话，则使用轮询的方式简单实现。 其实，国外如UrbanAirship自己实现了Android上的第三方提供的推送平台。近期国内如极光推送也实现了第三方的推送平台（技术与微信、GCM、APNs类似）。理论上，如果一个Android设备上多款应用都使用极光推送这种第三方推送平台的话，也可以如APNs一样达到节省电量、流量消耗的效果。 |
|
|
