偷窥iPhone Push Notification的幕后

iPhone Push Notification，一个吹得天花乱坠，却又不断跳票的功能，终于在OS3.0上实现。虽然体验糟糕（Tweetie和IM+之间反复切换，每次都需要等待这两个软件加载数据，这种脑残的使用方式能代替多任务？)，但是我终于可以在使用Tweetie的同时，挂着MSN了。

既然BB，Nokia，Palm都先后支持了Push，那么它们之间的比较不可避免。Handspring兄有一篇文章详尽的分析了现有Push方式和他们的优缺点。

不清楚苹果的Push方式，就让我们很难把iPhone Push Notification，与其他几个厂家作横向比较。

苹果的Push到底是怎么实现的？

是哪种Push方式？

有何优缺点？

本文，将带你到iPhone Push Notification的幕后，去偷窥一下Push剧中，登场演员的香艳大腿。

—-

苹果的Push Notification是哪一种？

目前流行的Push方式有三种。

短信触发

2G时代长时间的数据连接会影响电话接入的可靠性，所以Pushmail用短信的方式触发。推过来一个你看不到的短信，让系统去连接邮件服务器。

长连接心跳查询

3G时代，语音和数据分离，手机长时间的保持网络连接成为可能。于是可以建立一个连接，设定一定时间间隔，让手机不断的检查服务器的邮件。

长连接IMAP IDLE

网络进步的同时，邮件推送的协议也在不断改进。IMAP开始支持IDLE特性。让手机不需要总去访问服务器。手机的请求过来，邮件服务器可以把回复挂起，有新邮件近来时再发出。

苹果的呢？吝啬的苹果从来不解释这些技术选择的问题，万能的Google也没个所以然。但我手里的iPhone上，一定有Push实现方式的蛛丝马迹。

最终，我定位到了苹果的Push Notification服务器。

 

IP是17.149.xxx.xxx。 如果你想知道为什么Push Notification有20到30秒的延迟，这个IP就是答案：一台位于美国的主机。没错，日本3G网络下的手机，Push一下，需要横穿整个太平洋！（中美之间的网络通讯恐怕不会快过日美。）

Push方式？答案就在这个TCP连接使用的端口上:5223

使用这个端口的协议源于Jabber后来发展为XMPP。如果这两个词你不知所谓，那么Google Talk你一定知道。

没错，是个IM协议使用的端口！

—-

幕后

5223这个数字就是通向iPhone Push Notification 幕后的大门。他指向一个用XML格式传递消息的开放IM协议。由此，我们可以猜测苹果Push Notification的构架。

服务器和手机上跑着的都是基于Jabber/XMPP协议的类IM程序。手机加服务器为好友，而服务器加所有使用Push的手机为好友(数量一定非常惊人，所以稳定性是问题。这应该也是Push Notification反复跳票的原因。)。

一次Push，就是那个位于美国的服务器中的IM软件，在长长的好友列表中找到你的手机，然后和他说句话。

当然，手机和服务器之间的对话和我们不同。他们不传递牢骚和色情笑话，传XML文件。

用XMPP和Push Notification为关键字Google一下，很容易就找到这个XML文件的例子。这是可读的明码，我们可以从项目名称和值来猜测苹果大概都传了些什么。实际传输中，这个XML应该加过密。

 

手机端的类IM程序应是名为notifyd的后台进程（拥有root权限），他根据收到的XML文件的内容动作。显示一个Popup出来的消息框，或者，清空你手机的所有数据。

—-

回到前台

洞悉苹果Push Notification的幕后可以回答很多现实的疑问。 比如。。。

是否费电？

看苹果的优化程度，个人的主观体验是耗电增加明显。可类比的是Android后台跑一个Gtalk。两者增加的耗电应该差不多。(用同样协议实现的IM客户端)

为什么有延迟？

因为你在日本的邮件服务器要联络在美国的Push服务器，然后，他再给你发一个跨洋消息。

WIFI和3G下皆可Push？

没错。完全没区别。WIFI下没准还快点。参考Gtalk或者MSN的使用经历。

IMAP IDLE呢？

mail.app支持IDLE，但似乎意义不大。mail.app可能因为内存不足给释放掉。(至少在OS 3.0以前) 而iPhone上的那个IM客户端，似乎总是跑在后台的。

Nokia，BB，还有苹果的，哪个最好？

3G下，似乎还是Nokia的方式理想些。

短信触发也不错。短信的接收非常省电。3G下的数据连接，一旦建立，不会轻易断开。你也不会每封信都去连接邮件服务器。所以这仍然是可靠有效的，久经考验的Push方式。

苹果的也不错。后台多跑个Gtalk而已。只不过Push程序一直保持在后台，TCP连接一旦建立，也不会改变状态。（从来不会出现IMAP连接的close and wait状态。）所有这些应该导致更多耗电。相信这就是苹果在宣传Push耗电时，很保守的使用Preserves（维持，保存）这个词的原因吧。微言大义。：）

Pushmail之外的可能性？

iPhone和Push服务器之间传递的是一个XML文件。这个是一种跨平台，并且可以自定义格式的数据文件。

灵活的Push方式带来无限的可能性。看苹果想赋予iPhone后台的那个IM客户端什么功能了。强制升级，删除程序都是小菜一碟。

越狱之后如果有高人感兴趣，给这个IM进程加个UI，iPhone手机之间能互相加好友也有可能。

安全性？

iPhone和Push服务器之间是通过Internet传输XML文件的。那么威胁来自于两方面：

1 劫持XML并修改。

个人不太担心这个。信息应该是加过密的。破解起来似乎得不偿失。（这意味着别人想要检查Push的内容也比较困难。实时的解密加关键字过滤应该是不可能的任务。除非。。。苹果把密钥交出来。）

2 修改iPhone指向的Push服务器。

越狱的iPhone可能在任何地方装软件，而iPhone的root密码是固定的。让iPhone指向一个非苹果的Push服务器，似乎是更现实的威胁。

—-

偷窥了半天，似乎也没有什么特别的快感？

的确，苹果的大腿，没有想象中香艳。不过，技术上的事情往往如此，少有天才的解法，更多是一层层的现有方案的封装和整合。用户体验的好与不好，其实不关他的事。

既然苹果利用IM协议，查看历史纪录肯定不是问题，早日给我们Palm Pre那种Push内容一览吧！

 

转自：http://blog.csdn.net/ydfok/archive/2010/07/13/5732137.aspx

 

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 再论iPhone Push Notification -------------------------------------------------------------------

技术：表情痛苦算站稳

首先，推送的本质是一个服务。所以如果不考虑手机厂商和运营商之间的利益争夺，由运营商实现Push最为理想。这个世界上最好的推送服务，由黑莓和运营商合作提供，不是偶然。

而苹果和Nokia等厂商则决心走另外一条路：绕过运营商。

一个“绕”字，表现出这种方案的尴尬之处。不过，技术的发展和移动网络的普及，让这个目标越来越现实。Push Notification的幕后一文，分析了苹果的Push方案。但那个解释并不完整。他只叙述了从苹果到用户这一段。@RobinLu作为开发者，为我们补完了Push拼图中的另外一块：从开发者到苹果。

原来，除了苹果的Push Server以外，开发者必须自己维护另外一个Web Server，用来收集自己程序产生的推送，并且把他发给苹果的Push Server。

简要的说明如下图。点击放大

 

 

假设，BuddyFeed要支持Push的话。。。

一个BuddyFeed用户发送一个评论，首先在FriendFeed.com提交更新。之后，开发者维护的WebServer会从iPhone的BuddyFeed客户端（或者从FriendFeed.com），得到这个更新的通知。

开发者接收这个通知的服务器，上图中称作App Push Web Server。处理这个通知，变为苹果 Push Server可接受的标准形式，发送给苹果。苹果的Push Server再用Push Notification的幕后一文叙述的方式，把这个消息推送给用户。

———————————–

商业：腰身柔软易推倒

技术上还算完整？但是结合商业考量，就不是那么妙了。

这套方案需要开发者维护一个Web Server。这是个持续的开支。而看看App Store上Push程序的售价，绝大多数都是一次性付款。

IM+:$4.99，Boxcar:$2.99，GPush:$0.99！

考虑一下软件的销售额和他产生流量的关系吧。销售额升升降降都属正常，而Web Server所服务的用户，永远都是增长的！！！更多用户，等于更多流量，等于更多带宽，等于持续增长的昂贵的服务器租金。随着时间推移，当用户已经非常庞大的时候，软件的销售又趋于饱和，开发者会做出什么选择？

向已经购买该软件的用户再次收费，或者，干脆关掉他维护的Web Server!!!

苹果的Push的实现潦草的令人发指。新通知覆盖了旧的，你面对好几个程序上的红色数字，都不知道去哪里找。但是，这种设计上的问题更加致命。当销售下降到不能维持Web Server的月租金，那些廉价Push软件，以何为继？

———————————–

出路？

苹果Push Notification的出路至少有三条：

一是苹果提供为开发者提供App Push Server。

二是In App Purchases，按月收费。

三是Push广告。

目前，App Store中，已经有Push软件选择了方式二，比如Tweet Push。虽然，他更可能提供可靠而长久服务，但无论评价还是人气，都远远没有一次付费的Push软件好。

———————————–

甚至机会？个人SaaS？

ERP等企业级别的应用发展出一个概念：SaaS。Software as a Service（软件即服务）。不再销售软件，而是销售一套基于Web和软件的有弹性的解决方案，并提供支持。为此，收取月/年租。SaaS应用的这种收费方式，已经被企业广泛接受。

本文开头说过，Push即服务。iPhone上Push的实现，其实就是这种企业级概念向个人下放的结果。其实今天的个人用户中，也有大量在付费购买服务。传统网络上，有Flickr Pro的账户。移动网络上，日本大量的用户缴350日元/月得到MMS的同时享受Push Mail。黑莓BIS的用户也不少。

为iPhone用户提供高质量的Push服务，并且按月收费，也许会成为将来市场的常态。

但是苹果Push技术说明上的语焉不详，让普通用户不容易接受月租方式。Push实现的潦草，让Push本来应该体现的价值打了折扣。App Store中廉价风和价格战，更让坚持月租方式的开发者难以出头。

以上种种，都在损害这个机会。

智能手机和其上的应用市场是全新的，高速成长的领域。从iPhone到App Store，苹果难得的在设计创新的同时，实现也保持了非常高的水准。但是不得不说，Push的设计和实现，不配这个评价。

但是，相信无论苹果还是开发者，都在寻找更好的办法。苹果对Push的改进不会停止。而App Store的模式，最终应能让提供完善方案的，负责任的开发者，脱颖而出。

时间将检验一切。

 

转自：http://blog.csdn.net/ydfok/archive/2010/07/13/5732153.aspx