错了
轮询是只是其中一种推送方案，成本低，但效率也低，这种方案容易被人诟病，也容易在宣传上被人说不是真正推送，另外实际使用中，因易发生策略冲突，受访对象往往会采取主动措施限制使用，这种事屡见不鲜了。目前，其实好多年前就开始了，主流推送是常连接保持，平时服务器客户端之间只有为保持连接的最简单指令，当真实信息到达时由服务器端立即发出指令给客户端，接下来就是客户端的事了。
ios还是android本质无区别，系统代管程度不同，但苹果和谷歌自身的都不是轮询。

引用:

原帖由 iceliking 于 2012-6-17 14:52 发表


其实就是程序客户和服务器间的hello包，这也不是什么新鲜东西，只从有网络协议就是这么设计的，但前提是在线，在线的依据就是你是否设置了通知（ios）

网络协议的超时过短，不适合的，推送的可要长得多，你做开发还是值得去了解了解具体内容的。

引用:

原帖由 hudihutian 于 2012-6-18 09:54 发表
除非局端MSC和苹果或者GOOGLE的PUSH服务器之间开了特殊的信令接口，否则我真想不出来除了保持链接和后台轮询以外，还有什么办法能PUSH

而这两种方法都费电

还有一种投机方式，国内有厂商利用短信做媒介，中国移动也买过这个方案，用短信作为推送通知，不过短信本身会有一定问题，而且客户端后台程序开发也不太稳定，加上移动脑子问题，单做了一个接入点配置，限制其他应用，推广一般，我记得在adc平台这块后来是开放了，不限制厂家了，其他还是自己做。其实联通本身做push的那套日本access方案其实不错，整合很好，联通后来还用老美seven的方案专门搞push，电信也有搞push，不过市场开发都不好。一般外国公司要这块业务大多是指明要黑莓的，但象移动旗下卓望代理黑莓很早，但当时市场举动也不大，各家业务都是搞得太乱。

之前移动短信通知的推送终端公开支持包括symbian、win、blackberry，其实还支持一些低端java以及几款不清楚什么系统的之前听都没听说过的定制机，估计还是java，系统升级的话，后者这些估计有兼容问题，有些看是特定定做的，某些企业用可能不会考虑大升级，山东有公司直接整合进oa的，但这种例子真的太少。
bb企业级方案可是常连接保持的，和国内这种全方案靠短信不一样。

想起来，当时在开发iphone的，应该早有了，公没公开不清楚。

139那个就是移动方案，所谓的公众版，不过各省公司邮箱方案不是一个厂家的，我有点想不起来，不太确定，好像上线的时候是轮询吧，当时是集团公司规定时间各地统一起上的，之后有没改不记得了，139本来就有手机短信通知的，多少有点急上的感觉。邮箱方案商有两家是移动这个方案的提供商的子公司，整合理论上应该没问题。

补充说明一下，上面轮询说的是服务器后台的轮询，不是指客户端。

139那个由于定位问题，加上后台方案，双向同步应该不会提供。移动方案的同步倒是早实现了，但应该只在mas才会提供。139直接提供下载的客户端也是老版，几年前看就原始得很，不带高级的功能的。又想起来了，客户端里有palm的，好像新版测试也有过，记不太清，现在可能不搞了，估计都不公开了。