我一直在为Android设备使用持久套接字的自定义推送通知解决方案进行测试。我想分享我的发现并验证结果。
简单说明
该应用程序运行前台服务，与服务器建立连接，并通过积极的ping（每10秒间隔）维护该连接。如果检测到连接已死，应用程序将无限期地尝试重新连接。服务器通过双工通道发送通知。 测试1：
假设：一个传入的网络数据包会自动唤醒CPU，因此无需使用唤醒锁。使用AlarmManager进行ping操作（而不是计时器）意味着我们不需要唤醒锁。
去掉唤醒锁似乎真的有助于电池寿命。令人惊讶的是，两种解决方案中的激进ping并没有像我预期的那样影响电池寿命。（我们进行了许多其他测试，包括一个应用程序只保持wifilock并且不执行任何操作，在同一时间段内导致约4%到5%的电池损失）
由于该应用程序能够成功发送所有ping请求并接收所有传入消息，我相信我的假设是正确的。但我很想从任何专家那里得到确认。
还有一个问题： 如果该应用程序改为监听传入连接，则在这种情况下我需要保持唤醒锁，对吗？传入连接不会唤醒CPU吗？我们不会采用这种方法，只是想确认一下。
另外，请不要推荐GCM，公司政策已将其排除在外。
谢谢。
该应用程序运行前台服务，与服务器建立连接，并通过积极的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，公司政策已将其排除在外。
谢谢。