Android持久套接字连接规则
我一直在使用持久套接字对Android设备进行自定义推送通知解决scheme的testing。 我想分享我的发现并validation结果。
简单的描述
应用程序运行前台服务，并build立与服务器的连接，并通过主动ping（10秒间隔）来维护连接。 如果连接被检测为死亡，应用程序会一直试图无限期地重新连接。 服务器通过双工通道发送通知。
testing1：
Pinging is done using a timer at 10 second intervals. Server sends notification every minute. Applications acquires wifi and wake locks. Duration : 8 hours Battery loss : ~14% testing2：
Pinging is done using AlarmManager at 10 second intervals. Server sends notification every minute. Application acquires only a wifilock Duration : 8 hours Battery loss : ~7%
假设：传入的networking数据包会自动唤醒CPU，因此不需要唤醒locking。 使用AlarmManager来ping（而不是定时器）意味着我们不需要唤醒锁。
去除那个唤醒锁真的好像帮助电池。 令人惊讶的是，任何一种解决scheme的攻击性testing都不会像我所预期的那样影响电池寿命。 （我们有很多其他的testing，包括一个应用程序只是一个wifilock，没有做任何事情导致约4％至5％的同期电池损失）
由于应用程序能够成功发送所有的ping请求并接收所有传入的消息，我相信我的假设是正确的。 但我很想得到任何专家的确认。
还有一个问题：如果应用程序是要监听传入的连接。 在这种情况下，我需要保持一个唤醒锁，对吗？ 传入的连接不会唤醒CPU？ 我们不走这条路，只是想确认一下。
另外，请不要推荐GCM，它已经被公司政策排除了。
谢谢。
既然这个问题有一些兴趣，没有确认，我现在就回应。 testing完成已经有一段时间了，生产水平的解决scheme已经创build并经过了严格的testing。 删除唤醒锁仍然帮助电池，并没有发现其他问题，如缺lessping请求或传入的通知，所以这是唯一的validation，我收到了上述假设。
其他注意事项：
-
在用于Pinging警报的BroadcastReceiver的OnReceive方法中，如果您不是直接调用套接字（产生新的线程或意图），则需要持有唤醒锁，直到ping请求完成。 Android只保留一个唤醒锁，直到OnReceive返回，之后才有可能（但很less）CPU在睡眠完成前hibernate。
-
如果通知是敏感的，请使用高性能Wifilocking 。
-
还有一个其他设备特定的问题影响了解决scheme， 这里介绍 。
更新
使用Android 5.1进入以下问题： Android问题
更新2
需要针对Android 6.0打盹模式进行编码： 打盹模式
