Question

我一直在测试使用持久套接字的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%

测试2：

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，它已被公司政策排除。

感谢。

Answer 1

由于对这个问题有兴趣并且没有确认，我现在就回复。自测试完成以来已经有一段时间了，并且已经创建并严格测试了生产级解决方案。删除唤醒锁仍然有助于电池，没有发现其他问题，例如缺少ping请求或传入通知，因此这是我在上述假设中收到的唯一验证。

需要注意的其他事项：

在用于ping警报的BroadcastReceiver的OnReceive方法中，如果您没有直接调用套接字（产生新线程或意图），则需要保持唤醒锁定，直到ping请求完成。 Android只在OnReceive返回之前保持唤醒锁定，之后可能（但很少见）CPU可能在ping完成之前休眠。
如果通知是敏感的，请使用High Performance Wifi Lock。
还有另一个特定于设备的问题影响了该解决方案，涵盖了here。

<强>更新

使用Android 5.1进入以下问题：Android Issue

更新2

需要围绕Android 6.0的Doze模式进行编码：Doze Mode

Android持久套接字连接规则

1 个答案: