我有一个项目，其中一个客户端应用程序，可能在Android设备上，将从服务器请求一些文件。一种实现是从服务器到设备的突发传输，其中X文件与链接/指针一起被发送到下一个块。另一个实现是发送文件ID列表，然后为每个ID发出一个http请求并单独获取文件。我听说这真的会伤害电池寿命。这是真的吗？
另一个问题是带宽，客户端可能不希望/需要在一个突发中发送所有文件，因此服务器有点迫使客户端一起接受它们。在个人提交中，客户可以在他想要的时候获取文件。
对电池寿命的影响是否如此之大以至于超出带宽是一个有效的选择？还是有其他选择吗？
答案 0 :(得分：4)
我听说这真的会伤害电池寿命。这是真的吗？
不一定。在大多数Android设备上，HttpClient和HttpUrlConnection都可以支持Keep-Alive，因此如果您的HTTP服务器设置正确，并且您相当快速地发出请求，我就不会指望主要区别。
在个人提交中，客户可以根据需要获取文件。
如果您的意思是他们可能会在相当长的一段时间内请求他们，则无法使用Keep-Alive。但是，您可能会要求整体文件较少，并且占用的带宽要少得多。从抽象的角度来看，不可能告诉你哪种方式更适合电池消耗。
对电池寿命的影响是否如此之大以至于超出带宽是一个有效的选择？
这取决于您下载的数量，频率等等。
然而，恕我直言，你关注的是错误的问题。
如果您正在消耗所以大量的带宽而您担心电池寿命，那么您的用户将使用干草叉和镐来攻击您，因为他们在计量数据计划上花了这么多钱。
因此，我会使用TrafficStats并尝试各种方案来查看您真正使用了多少带宽，因此是否需要找到一般消耗更少带宽的方法（例如，轮询频率较低），所以用户不会被您的应用破坏。我怀疑你的电池问题会将自己视为一种副作用。
但是，如果在您的测试中，您发现您的应用程序出现在“设置”中的“电池责任屏幕”中，则然后开始担心电池消耗，无论是来自带宽还是其他来源（例如，过多）使用WakeLocks）。
答案 1 :(得分：4)
查看Google IO会话中有关电池续航时间的这些幻灯片：
http://dl.google.com/io/2009/pres/W_0300_CodingforLife-BatteryLifeThatIs.pdf
具体而言，AlarmManager具有方法setInexactRepeating(...)。系统可以将您的更新与其他设备结合使用，这样可以提高功效，并避免将设备从睡眠状态唤醒。