用第三方推送平台会好很多，比如百度云推

如果你的消息很大可以考虑用xmpp openfire smack。参考 http://blog.csdn.net/shimiso/article/details/11225873
如果你的要在多终端推送，你就自己实习websocket

既然是消息推送就一定是push的方式，用pull不及时而且很浪费电池

长连接在手机休眠下也还是会保持的哈，因为主CPU休眠了，还有一个基带处理器来处理基本的操作的。

这个主cpu休眠后，BP是在工作也能接收信息，但程序都是运行在AP(主cpu)下的，Socket连接也是运行在cpu下的，当AP休眠时，socket监听也就不工作了。就算BP接收到了信息也没有办法去处理吧。因为测试中，只要手机一休眠服务器发送的消息手机就接收不到了。

没人了回答了啊

等待大神的回答..

刚好路过，的确如楼主所说，Android休眠时移动互联网数据通讯会停止（包括GPRS、WIFI等），BP虽然工作但AP是不工作的，自然无法运行App。所以这时候使用TCP长连接，会不断断开和重连，TCP长连接的意义并不大，建议用UDP。

刚刚发布了开源DDPush任意门推送服务器，csdn的帖子在这里，楼主有兴趣可以看看。

推送 服务 一般都是用推送平台  参考相关 API 就可以 

引用 8 楼 DDPush 的回复:

刚好路过，的确如楼主所说，Android休眠时移动互联网数据通讯会停止（包括GPRS、WIFI等），BP虽然工作但AP是不工作的，自然无法运行App。所以这时候使用TCP长连接，会不断断开和重连，TCP长连接的意义并不大，建议用UDP。

刚刚发布了开源DDPush任意门推送服务器，csdn的帖子在这里，楼主有兴趣可以看看。

谢谢这位的回答，这个做的很不错。虽然和我想要的有些差别，不过还时十分感谢~!! 

 
我想知道推送时，手机端程序如何在手机休眠时，处理接收实时消息及思路?

继续等待大神们的详细回答….

引用 10 楼 feikonl 的回复:

Quote: 引用 8 楼 DDPush 的回复:

刚好路过，的确如楼主所说，Android休眠时移动互联网数据通讯会停止（包括GPRS、WIFI等），BP虽然工作但AP是不工作的，自然无法运行App。所以这时候使用TCP长连接，会不断断开和重连，TCP长连接的意义并不大，建议用UDP。

刚刚发布了开源DDPush任意门推送服务器，csdn的帖子在这里，楼主有兴趣可以看看。

谢谢这位的回答，这个做的很不错。虽然和我想要的有些差别，不过还时十分感谢~!! 

谢谢。不知道你要的有些什么具体差别呢？如你所知，android休眠的时候所有工作都会停止，这个是为了省电。但是我们可以通过AlarmManager来唤醒系统（小米手机最短唤醒间隔是5分钟），这样我们的程序就能工作了。但是过于频繁的唤醒会太耗电，所以三五分钟唤醒一次是合适的。

如果是开发即时聊天app之类，有可能第一次的实时消息有延时（实时上我测试过微信也如此，第一次信息有时候会延时三两分钟），因为手机还没被唤醒。一但被唤醒后，大概可以维持几十秒工作时间，这个时候发现有很新的消息，可以保持WakeLock让手机在接下来的3分钟之内（举例而已，未必是3分钟，应该是动态调整）不释放，这样这3分钟之内手机就不会休眠。

为什么要在有最新消息的3分钟不休眠呢？因为这段时间有第二条信息的机率挺大的，那这三分钟之内有信息就可以实时收到。等过了几分钟发现没有新的信息了，那么接下来几分钟有信息的可能就相对小了，就可以释放wakelock让系统休眠了。

这样下来，不实时的情况最多延时一两分钟，剩下的都很实时了，基本就达到了一直在线的效果。如果追求100%时间实时接收信息，我个人认为是不实际的，一来没必要，二来会导致耗电极快。可以下载WakeLock Detector分析微信的行为，你会发现微信唤醒系统的节奏也是几分钟一次，然后会调整休眠的步长。越久没新消息，就可以休眠越久，当然，最久不用超过5分钟。

谢谢，各位的回答，虽然有些回答对我没有太有用，但也十分感谢各位的参与。
最后非常感谢DDPush  大神的回答对我来说很有用~~!!

请问最后实现了保持长连接吗？我最近也碰到这个问题了，过一段时间客户端自己就掉线了

学习了，微信是这个原理哇