使用 http 时 Android 电池

发布于 2024-10-10 15:29:44 字数 514 浏览 0 评论 0原文

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

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

问题是电池寿命。由于必须立即通知用户服务器上的更改,因此我想实现一个驻留在后台的服务(标准 Android 服务)并查询服务器以获取更新。

当然,查询服务器,即使是每秒,都会消耗大量的带宽和电池,所以我的问题是:如果服务器将响应保留一段时间,会有什么影响吗? (Comet类型ajax请求背后的想法)

工作原理如下:

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

它肯定会花费更少的带宽,但它会消耗更少(甚至更多)的电池吗?

Recently google introduced push-to-device service, but it's only available 2.2 and up.

I need a similar system in my app, and I'm trying to get around limitations.

The issue is battery life. Since the user must be notified immediately about the changes on the server, I thought to implement a service that would live in the background (standard Android service) and query the server for updates.

Of course, querying the server, even each second, will cost a lot of bandwidth, as well as battery, so my question is this: does it make a difference if the server is holding the response for some period of time? (the idea behind Comet type ajax request)

Works like this:

  • Device sends request for data update
  • Server gets the request and goes in the loop for one minute, checking if there are updates on each iteration
    • If there are updates, server sends response back with updates
    • If not, service goes on to the next iteration.
  • After a minute, it finally sends the response that no data is yet available
  • After response (no matter whether empty or with data) Android fires another such request.

It will definitely cost less bandwidth, but will it consume less (or even more) battery?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

清晰传感 2024-10-17 15:29:44

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

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

Holding a TCP socket (and consequently waiting for an HTTP response) as you suggest is probably going to be your best option. What you've described is actually already implemented via HTTP continuation requests. Have a look at the Bayeux protocol for HTTP push notifications. Also, check out the Android implementation here. For what it's worth, that's definitely what I would use. I haven't done any sort of analysis of it, but this allows you to minimize the amount of data transmitted over the line (which is directly proportional to the power consumption) by allowing the connection to hang for as long as possible.

In short, the way Bayeux works is very similar to what you've suggested. The client opens a request and the server waits on it. If it has something to send, it sends it otherwise it simply waits. Eventually, the request will timeout. At that point, the client makes another request. What you attain is near instantaneous push to the client from the server without constant polling and duplication of information like HTTP headers, etc.

甩你一脸翔 2024-10-17 15:29:44

当手机频繁使用网络时,电池的消耗会更多。也就是说,什么时候发送请求,什么时候收到响应。它还仅通过监听响应来消耗电池。但是,手机会下载数据并检查是否有响应吗?或者手机是否会开放接收它并且服务器会将响应推送到手机?主要取决于这个。如果手机只是愿意接收响应,但在整个等待过程中尝试下载某些响应时实际上并未使用网络,则它应该使用较少的电池。

此外,就使用网络而言,手机每分钟而不是每秒发送一次查询肯定会消耗更少的电池。然而,这取决于你如何让手机保持不动,如果你用非常复杂的逻辑来让它等待,可能不会延长电池寿命。然而,情况可能并非如此,我想说这很可能适合您。

最后,它应该对电池有帮助,但有一些方法可以做到这一点,但它不会。编写程序然后只需更改某种类型的变量(例如将 WAIT_TIME 更改为 1 秒而不是 1 分钟)并测试电池使用情况不会有什么坏处,不是吗?

When the phone is actively using the networks, it's battery is used more. That is to say when it sends the request and when it receives the response. It will also be using battery just by listening for a response. However, will the phone download data, checking to see if there's a response? Or will the phone just be open to receiving it and the server will push the response out to the phone? That is mainly what it depends on. If the phone is just open to receiving the response but does not actually use the network while trying to download some response the whole time it's waiting, it should use less battery.

Additionally, the phone sending a query every minute instead of every second definitely uses less battery, as far as using the networks goes. However it depends on how you make the phone hold, if you tie it up with very complex logic to make it wait it may not help battery life. That's probably not the case, however, and I would say that in all likelihood this would work out for you.

In closing, it should help the battery but there are ways you could make it in which it would not. It wouldn't hurt to write the program and then just change some type of variable (for example WAIT_TIME to 1 second instead of 1 minute) and test battery usage though, would it?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文