Android的持续套接字连接规则 [英] Android persistent socket connection rules

问题描述

我已经做了一些测试，使用持久套接字Android设备定制的推送通知解决方案。我想和大家分享我的发现和验证的结果。

I have been doing some testing for a custom push notification solution for Android devices using persistent sockets. I would like to share my findings and validate the results.

简单说明
该应用程序运行的前台服务，并建立与服务器的连接，并认为通过积极的ping命令连接（@ 10秒的时间间隔）。如果连接被检测过死，应用程序一直尝试重新连接下去。服务器通过双工信道发送通知。

Simple Description
The applications runs a foreground service and establishes a connection with the server and maintains that connection via aggressive pinging (@ 10 secs interval). If the connection is ever detected as dead, the app keeps trying to reconnect indefinitely. The server sends notifications via duplex channel.

测试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（而不是定时器）意味着我们不需要wakelock。

Assumptions: An incoming network packet automatically wakes up the CPU, thus no need for a wake lock. Using AlarmManager to ping(instead of timers) means we do not need a wakelock.

去除wakelock似乎真的帮助电池。出人意料的是，无论是解决方案的积极的ping命令并没有影响电池寿命，就像我本来期望。 （我们有许多其他测试，包括了：其中，应用程序只是举行了wifilock并没有采取任何行动，造成较上年同期约4％至5％的电池损耗）

Removing that wakelock really seemed to help the battery. Surprisingly, the aggressive pinging on either solution did not affect the battery life as much as I would have expected. (We had many other tests including one where the application just held a wifilock and did nothing which caused around 4% to 5% battery loss over the same period)

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

Since the application was able to successfully send all the ping requests and receive all the incoming messages, I believe my assumptions are correct. But I would love to get some confirmation from any experts.

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

One more question: If the application was to instead listen for incoming connections. I would need to hold a wakelock in this case, correct? An incoming connection does not wake up the CPU? We are not going down this route, but just wanted to confirm.

另外，请不要推荐GCM，已经排除了公司的政策。

Also, please do not recommend GCM, it has been ruled out by company policy.

感谢。

推荐答案

由于出现了这个问题，也没有确认一定的兴趣，我刚才回应。它已经有一段时间的测试完成后，和生产水平的解决方案已被创建并经过严格测试。拆除之后锁仍帮助了电池，没有其他问题被发现，如丢失ping请求或来电通知，所以这是我收到的上述假设的唯一验证。

Since there has been some interest in this question and no confirmations, I will just respond now. It has been a while since the tests were done, and a production level solution has been created and rigorously tested. Removing the wake lock still helped the battery and no other issues were found such as missing ping requests or incoming notifications, so that is the only validation that I received on the said assumptions.

其他注意事项：

• 在的BroadcastReceiver为ping命令报警的onReceive方法，如果你不是直接调用插座（生成一个新的线程或意图），您将需要持有唤醒锁直到ping请求结束。 Android的持有唤醒锁只有等到的onReceive回报，之后，有可能（但很少），该平结束前，CPU可以睡觉了。

• In the OnReceive method of the BroadcastReceiver for the pinging alarm, if you are not directly calling on the socket (spawning a new thread or intent), you will need to hold a wake lock until the ping request is finished. Android holds a wake lock only until OnReceive returns, after that it is possible(but rare) that the CPU may sleep before the ping is finished.

使用一个<一个href="http://developer.android.com/reference/android/net/wifi/WifiManager.html#WIFI_MODE_FULL_HIGH_PERF"相对=nofollow>高性能无线锁如果通知是敏感的。

Use a High Performance Wifi Lock if the notifications are sensitive.

有受影响的解决方案，一个其他设备的具体问题，它是覆盖<一个href="http://stackoverflow.com/questions/19148765/android-reconnect-to-wi-fi-after-entering-coverage-area-while-screen-turned-of">here.

There was one other device specific issue that affected the solution, it is covered here.

更新

跑进了以下问题与Android 5.1：的Andr​​oid版本

Ran into the following issue with Android 5.1 : Android Issue

这篇关于Android的持续套接字连接规则的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！