Ale*_*lex 37 sockets android tcp wakelock batterylevel
我一直在使用持久套接字对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%
Run Code Online (Sandbox Code Playgroud)
测试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%
Run Code Online (Sandbox Code Playgroud)
假设:传入的网络数据包会自动唤醒CPU,因此无需唤醒锁定.使用AlarmManager ping(而不是计时器)意味着我们不需要唤醒锁.
取下那个唤醒锁似乎真的有助于电池.令人惊讶的是,对任何一种解决方案的激烈攻击并没有像我预期的那样影响电池寿命.(我们进行了许多其他测试,包括一个应用程序只是持有一个wifilock并且没有做任何导致同期电池损失约4%到5%的测试)
由于应用程序能够成功发送所有ping请求并接收所有传入消息,我相信我的假设是正确的.但我很乐意得到任何专家的确认.
还有一个问题: 如果应用程序要监听传入的连接.在这种情况下我需要拿一个唤醒锁,对吗?传入连接不会唤醒CPU?我们不是沿着这条路走下去,而是想确认一下.
此外,请不要推荐GCM,它已被公司政策排除.
谢谢.
Ale*_*lex 13
由于对这个问题有兴趣而没有确认,我现在就回答.自测试完成以来已经有一段时间了,并且已经创建并严格测试了生产级解决方案.删除唤醒锁仍然有助于电池并没有发现其他问题,例如缺少ping请求或传入通知,因此这是我在上述假设中收到的唯一验证.
其他注意事项:
在用于ping警报的BroadcastReceiver的OnReceive方法中,如果您没有直接调用套接字(产生新线程或意图),则需要保持唤醒锁定,直到ping请求完成.Android仅在OnReceive返回之前保持唤醒锁定,之后可能(但很少见)CPU可能在ping完成之前休眠.
如果通知敏感,请使用高性能Wifi锁.
更新
使用Android 5.1进入以下问题:Android问题
更新2
需要围绕Android 6.0的Doze模式进行编码:打盹模式
归档时间: |
|
查看次数: |
8198 次 |
最近记录: |