批处理传输和连接

每次启动一个连接---跟传输的数据大小无关---在使用典型的3G无线信号时，就会潜在的导致无线信号消耗近20秒的电量。

如果一个应用程序每隔20秒ping一次服务器，只是告知该应用程序正在运行，且对用户是可见的，那么无线信号的保持将无法限制，这会导致在几乎没有实际数据传输的情况下，明显的消耗电池电量。

基于以上考虑，重要的是要把传输的数据打包，并创建一个传输队列。这样由于发生在类似的时间窗内，就可以提高传输效率，从而尽可能的确保缩短无线信号消耗电量所持续的时间。

这种方法的基本原理是在限制必要的会话数量的同时，尽可能的每次会话期间传输更多的数据。

这就意味着你要容忍通过队列批量传输数据所带来的延迟，并且它会抢占计划内的更新和数据预获取处理，以便这些传输在所需的敏感的传输时间内都能够被执行。同样，计划好的更新和定期的预获取数据也应该启动该传输队列的执行。

现在，我们选取上文中介绍的预获取数据的一个示例详细说明。

新闻阅读器需要收集一些用于分析的信息，来弄清楚用户的阅读模式，以及最流行的故事的排行。为了保持新闻的新鲜度，它每小时都要检查更新。为了节省带宽，它不会下载每篇文章的全部图片，它只会预先下载一些缩略图，并且在这些缩略图被选中时才下载全部图片。

在这个示例中，在应用程序中收集到所有分析信息应该被打包到一起，并放到用于下载的队列中，而不是在收集的时候就传输。这个结果数据包应该在下载全尺寸图片或执行更新处理时被传输。

任何时间敏感或按需传输的数据---如下载全尺寸图片，都应该由于定期更新处理。计划好的更新应该在按需传输的同时被执行，并在设置的间隔之后发生下次更新计划。这种方法在需要下载图片时，捎带执行了定期更新，从而有效的降低了定期更新的执行成本。

减少连接

通常，重用既存的网络连接比启动一个新的连接更加高效。重用连接还让网络更加智能的应对网络拥堵和相关网络数据的问题。

不要创建多个并发连接来下载数据，也不要连续发多个GET请求，而是要尽可能的把多个请求打包的一个GET请求中。

例如，在一个单一的请求/响应处理中来获取每篇新闻文章，比为了几篇文章而使用多次查询的策略要更加高效。为了传输跟服务器和客户端相匹配的超时的终止/终止确认包，无线信号需要转换为活跃状态，因此好的做法是在不使用连接时主动把它关闭，而不是等待连接超时。

但是，连接关闭太早会阻碍连接的复用，从而导致在建立新的连接时又会产生额外的开销。一个折中的方案是不立即关闭连接，但在其超时之前依然主动关闭它。