使用 http 时的 Android 电池

Question

最近 google 推出了推送到设备服务，但它仅适用于 2.2 及更高版本。

我的应用程序中需要一个类似的系统，并且我正在尝试绕过限制。

问题是电池生命周期。由于必须立即通知用户有关服务器上的更改，我想实现一个在后台运行的服务(标准 Android 服务)并查询服务器以获取更新。

当然，查询服务器，即使是每秒，都会消耗大量带宽和电池，所以我的问题是:如果服务器在一段时间内保持响应，会有什么不同吗？ (Comet类型ajax请求背后的思想)

像这样工作:

• 设备发送数据更新请求
• 服务器获取请求并循环一分钟，检查每次迭代是否有更新
  • 如果有更新，服务器会发回响应并更新
  • 如果没有，服务将继续下一次迭代。
• 一分钟后，它终于发送了没有数据可用的响应
• 响应后(无论是空的还是有数据的)Android 会触发另一个这样的请求。

它肯定会消耗更少的带宽，但它会消耗更少(甚至更多)的电池吗？

Answer 1

按照您的建议持有 TCP 套接字(并因此等待 HTTP 响应)可能是您的最佳选择。您所描述的内容实际上已经通过 HTTP 继续请求实现。看看 Bayeux protocol用于 HTTP 推送通知。另外，查看 Android 实现 here.对于它的值(value)，这绝对是我会使用的。我没有对它进行任何类型的分析，但这允许您通过允许连接挂起尽可能长的时间来最大程度地减少通过线路传输的数据量(与功耗成正比)。

简而言之，Bayeux 的工作方式与您所建议的非常相似。客户端打开一个请求，服务器等待它。如果它有东西要发送，它就发送它，否则它只是等待。最终，请求将超时。此时，客户端发出另一个请求。您获得的是近乎即时的从服务器推送到客户端，而无需持续轮询和复制 HTTP header 等信息。