Android持久套接字连接规则

我一直在为使用持久套接字的Android设备定制推送通知解决方案做一些测试。我想分享我的发现并验证结果

简单描述
应用程序运行前台服务并与服务器建立连接，并通过主动ping（间隔@10秒）保持连接。如果检测到连接已断开，应用程序将继续尝试无限期重新连接。服务器通过双工通道发送通知

测试1:

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%

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%

测试2:

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%

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%

假设：传入的网络数据包自动唤醒CPU，因此不需要唤醒锁。使用AlarmManager ping（而不是计时器）意味着我们不需要唤醒锁

移除唤醒锁似乎真的有助于电池。令人惊讶的是，这两种解决方案上的攻击性ping并没有像我预期的那样影响电池寿命。（我们进行了许多其他测试，包括一个应用程序只持有一个wifilock，而没有做任何事情，在同一时期内造成了大约4%到5%的电池损耗）

由于应用程序能够成功发送所有ping请求并接收所有传入消息，我相信我的假设是正确的。但我很想得到任何专家的确认

还有一个问题： 如果应用程序要侦听传入的连接。在这种情况下，我需要保持唤醒锁，对吗？传入连接不会唤醒CPU？我们不走这条路，只是想确认一下

此外，请不要推荐GCM，公司政策已将其排除在外

---

谢谢。

由于大家对这个问题感兴趣，没有得到证实，我现在就回答。测试完成已经有一段时间了，生产级解决方案已经创建并经过严格测试。移除唤醒锁仍然有助于电池，并且没有发现任何其他问题，例如丢失ping请求或传入通知，因此这是我根据上述假设收到的唯一验证

需要注意的其他事项：

• 在ping报警的BroadcastReceive的OnReceive方法中，如果您没有直接调用套接字（生成新线程或意图），则需要保持唤醒锁，直到ping请求完成。Android只在OnReceive返回之前保持唤醒锁，之后CPU可能（但很少）在ping完成之前休眠

• 如果通知是敏感的，请使用

• 还有一个特定于设备的问题影响了解决方案，本文对此进行了讨论

更新

Android 5.1遇到以下问题：

更新2

---

需要为安卓6.0编码打盹模式：

如果你有套接字连接，为什么让手机ping？为什么不让服务器在有话要说的时候发送信息，有时甚至是心跳来保持信息的活跃呢？在我们的例子中，连接可以在几个交换机之间。我们需要尽快确定无效连接。因此，对于移动客户端的每次ping，服务器都必须做出响应。它保护我们免受沉默的隔绝。我确信这里有一个很重要的问题，但是我找不到它的当前形式。如果你还在寻找答案，你可能会考虑编辑一个更有针对性的问题。JMHO:-）“我们需要尽快确定无效连接。因此，对于移动客户端的每一次ping，服务器都必须做出响应。”我认为底层传输协议，我认为TCP，通过周期性心跳来实现这一点。Android客户端不是这样吗？如果有TCP心跳，我想知道它们对电池有多大的影响…？很好的发现…，老兄。。。。！！尽管如此，我知道这是一个老问题：您是否在传入数据包上获得了WakeLock来处理这些数据包？或者换句话说，从网络中唤醒设备后，设备处于活动状态的时间有多长？是的，虽然您将在不必持有wakelock的情况下接收传入数据包，但在接收传入数据时仍应创建wakelock。否则，您可能无法在设备进入睡眠前完成数据处理。至于长度部分，则根据设备的不同而有所不同。我很喜欢这种碎片。这是一个很老的问题，但是你的更新2中有关于打盹模式的注释吗？我发现套接字连接没有到达我正在测试我的应用程序的6.0+设备，我猜这是因为打瞌睡模式。尽管设置了高性能Wifi锁，但它不会响应套接字请求。避免或忽略打盹模式容易吗？白名单？谷歌正试图走苹果的路，真的希望你使用他们的推送通知系统（Firebase）。幸运的是，正如您所说，您可以请求用户将您的应用程序列入白名单，以避免其受到睡眠模式的影响（工作方式类似于权限）。请注意，除非你有充分的理由进入白名单，否则谷歌可能会拒绝你向Play Store提交的应用程序。此外，当针对较新的API级别时，AlarmManager确实存在一些限制，即使是白名单也没有帮助。