# 偷窥iPhone Push Notification的幕后 - 作者：李楠 - 发布时间：2009-08-14 09:00 - 分类：公司 - 原文：https://www.ifanr.com/3776 [by newkhonsou@twitter](http://twitter.com/newkhonsou) ![](http://www.gizmag.com/pictures/lrg_img/iphone-push-notification.jpg) iPhone Push Notification，一个吹得天花乱坠，却又不断跳票的功能，终于在OS3.0上实现。虽然体验糟糕（Tweetie和IM+之间反复切换，每次都需要等待这两个软件加载数据，这种脑残的使用方式能代替多任务？)，但是我终于可以在使用Tweetie的同时，挂着MSN了。 既然BB，Nokia，Palm都先后支持了Push，那么它们之间的比较不可避免。[Handspring](http://twitter.com/handspring)兄有[一篇文章](http://www.ifanr.com/3371)详尽的分析了现有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服务器。 ![](http://farm3.static.flickr.com/2578/3817633366_6b1f6e63f2.jpg) 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应该加过密。 ![](http://farm3.static.flickr.com/2568/3818610113_a4b9eee3aa.jpg) 手机端的类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://www.lucafiligheddu.com/wp-content/uploads/2009/01/screen-capture-489.png)