解决方案 »

  1.   

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

  2.   

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

  3.   

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

  4.   

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

  5.   

    刚好路过,的确如楼主所说,Android休眠时移动互联网数据通讯会停止(包括GPRS、WIFI等),BP虽然工作但AP是不工作的,自然无法运行App。所以这时候使用TCP长连接,会不断断开和重连,TCP长连接的意义并不大,建议用UDP。刚刚发布了开源DDPush任意门推送服务器,csdn的帖子在这里,楼主有兴趣可以看看。
      

  6.   

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

  7.   


    谢谢这位的回答,这个做的很不错。虽然和我想要的有些差别,不过还时十分感谢~!! 谢谢。不知道你要的有些什么具体差别呢?如你所知,android休眠的时候所有工作都会停止,这个是为了省电。但是我们可以通过AlarmManager来唤醒系统(小米手机最短唤醒间隔是5分钟),这样我们的程序就能工作了。但是过于频繁的唤醒会太耗电,所以三五分钟唤醒一次是合适的。如果是开发即时聊天app之类,有可能第一次的实时消息有延时(实时上我测试过微信也如此,第一次信息有时候会延时三两分钟),因为手机还没被唤醒。一但被唤醒后,大概可以维持几十秒工作时间,这个时候发现有很新的消息,可以保持WakeLock让手机在接下来的3分钟之内(举例而已,未必是3分钟,应该是动态调整)不释放,这样这3分钟之内手机就不会休眠。为什么要在有最新消息的3分钟不休眠呢?因为这段时间有第二条信息的机率挺大的,那这三分钟之内有信息就可以实时收到。等过了几分钟发现没有新的信息了,那么接下来几分钟有信息的可能就相对小了,就可以释放wakelock让系统休眠了。这样下来,不实时的情况最多延时一两分钟,剩下的都很实时了,基本就达到了一直在线的效果。如果追求100%时间实时接收信息,我个人认为是不实际的,一来没必要,二来会导致耗电极快。可以下载WakeLock Detector分析微信的行为,你会发现微信唤醒系统的节奏也是几分钟一次,然后会调整休眠的步长。越久没新消息,就可以休眠越久,当然,最久不用超过5分钟。
      

  8.   

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