下载客户端
下载客户端
关于我们 寻求报道 加入我们
公司 2009-8-14 09:00

偷窥iPhone Push Notification的幕后

by newkhonsou@twitter

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内容一览吧!

有好的产品或者项目希望我们报道,猛戳这里 寻求报道

文章评论(-)
后参与讨论
正在加载中

Palm Pre屏幕键盘的最新进展

2009-8-14 09:03下一篇

诺基亚微软不神圣的Office联盟

2009-8-13 11:00上一篇