Optimizing Downloads for Efficient Network Access
1.This lesson teaches you to
- Understand the radio state machine
- Understand how apps can impact the radio state machine
- Efficiently prefetch data
- Batch transfers and connections
- Reduce the number of connections you use
You should also read
Using the wireless radio to transfer data is potentially one of your app's most significant sources of battery drain. To minimize the battery drain associated with network activity, it's critical that you understand how your connectivity model will affect the underlying radio hardware.
This lesson introduces the wireless radio state machine and explains how your app's connectivity model interacts with it. It goes on to propose ways to minimize your data connections, use prefetching, and bundle your transfers in order to minimize the battery drain associated with your data transfers.
2.The Radio State Machine
A fully active wireless radio consumes significant power, so it transitions between different energy states in order to conserve power when not in use, while attempting to minimize latency associated with "powering up" the radio when it's required.
The state machine for a typical 3G network radio consists of three energy states:
- Full power: Used when a connection is active, allowing the device to transfer data at its highest possible rate.
- Low power: An intermediate state that uses around 50% of the battery power at the full state.
- Standby: The minimal energy state during which no network connection is active or required.
While the low and idle states drain significantly less battery, they also introduce significant latency to network requests. Returning to full power from the low state takes around 1.5 seconds, while moving from idle to full can take over 2 seconds.
To minimize latency, the state machine uses a delay to postpone the transition to lower energy states. Figure 1 uses AT&T's timings for a typical 3G radio.
Figure 1. Typical 3G wireless radio state machine.
The radio state machine on each device, particularly the associated transition delay ("tail time") and startup latency, will vary based on the wireless radio technology employed (2G, 3G, LTE, etc.) and is defined and configured by the carrier network over which the device is operating.
This lesson describes a representative state machine for a typical 3G wireless radio, based on data provided by AT&T. However, the general principles and resulting best practices are applicable for all wireless radio implementations.
This approach is particularly effective for typical web browsing as it prevents unwelcome latency while users browse the web. The relatively low tail-time also ensures that once a browsing session has finished, the radio can move to a lower energy state.
Unfortunately, this approach can lead to inefficient apps on modern smartphone OSs like Android, where apps run both in the foreground (where latency is important) and in the background (where battery life should be prioritized).
3.How Apps Impact the Radio State Machine
Every time you create a new network connection, the radio transitions to the full power state. In the case of the typical 3G radio state machine described above, it will remain at full power for the duration of your transfer—plus an additional 5 seconds of tail time—followed by 12 seconds at the low energy state. So for a typical 3G device, every data transfer session will cause the radio to draw energy for almost 20 seconds.
In practice, this means an app that transfers unbundled data for 1 second every 18 seconds will keep the wireless radio perpetually active, moving it back to high power just as it was about to become idle. As a result, every minute it will consume battery at the high power state for 18 seconds, and at the low power state for the remaining 42 seconds.
By comparison, the same app that bundles transfers of 3 seconds of every minute will keep the radio in the high power state for only 8 seconds, and will keep it in the low power state for only an additional 12 seconds.
The second example allows the radio to be idle for an additional 40 second every minute, resulting in a massive reduction in battery consumption.
Figure 2. Relative wireless radio power use for bundled versus unbundled transfers.
4.Prefetch Data
Prefetching data is an effective way to reduce the number of independent data transfer sessions. Prefetching allows you to download all the data you are likely to need for a given time period in a single burst, over a single connection, at full capacity.
By front loading your transfers, you reduce the number of radio activations required to download the data. As a result you not only conserve battery life, but also improve the latency, lower the required bandwidth, and reduce download times.
Prefetching also provides an improved user experience by minimizing in-app latency caused by waiting for downloads to complete before performing an action or viewing data.
However, used too aggressively, prefetching introduces the risk of increasing battery drain and bandwidth use—as well as download quota—by downloading data that isn't used. It's also important to ensure that prefetching doesn't delay application startup while the app waits for the prefetch to complete. In practical terms that might mean processing data progressively, or initiating consecutive transfers prioritized such that the data required for application startup is downloaded and processed first.
How aggressively you prefetch depends on the size of the data being downloaded and the likelihood of it being used. As a rough guide, based on the state machine described above, for data that has a 50% chance of being used within the current user session, you can typically prefetch for around 6 seconds (approximately 1-2 Mb) before the potential cost of downloading unused data matches the potential savings of not downloading that data to begin with.
Generally speaking, it's good practice to prefetch data such that you will only need to initiate another download every 2 to 5 minutes, and in the order of 1 to 5 megabytes.
Following this principle, large downloads—such as video files—should be downloaded in chunks at regular intervals (every 2 to 5 minutes), effectively prefetching only the video data likely to be viewed in the next few minutes.
Note that further downloads should be bundled, as described in the next section, Batch Transfers and Connections, and that these approximations will vary based on the connection type and speed, as discussed inModify your Download Patterns Based on the Connectivity Type.
Let's look at some practical examples:
A music player
You could choose to prefetch an entire album, however should the user stop listening after the first song, you've wasted a significant amount of bandwidth and battery life.
A better approach would be to maintain a buffer of one song in addition to the one being played. For streaming music, rather than maintaining a continuous stream that keeps the radio active at all times, consider using HTTP live streaming to transmit the audio stream in bursts, simulating the prefetching approach described above.
A news reader
Many news apps attempt to reduce bandwidth by downloading headlines only after a category has been selected, full articles only when the user wants to read them, and thumbnails just as they scroll into view.
Using this approach, the radio will be forced to remain active for the majority of users' news-reading session as they scroll headlines, change categories, and read articles. Not only that, but the constant switching between energy states will result in significant latency when switching categories or reading articles.
A better approach would be to prefetch a reasonable amount of data at startup, beginning with the first set of news headlines and thumbnails—ensuring a low latency startup time—and continuing with the remaining headlines and thumbnails, as well as the article text for each article available from at least the primary headline list.
Another alternative is to prefetch every headline, thumbnail, article text, and possibly even full article pictures—typically in the background on a predetermined schedule. This approach risks spending significant bandwidth and battery life downloading content that's never used, so it should be implemented with caution.
One solution is to schedule the full download to occur only when connected to Wi-Fi, and possibly only when the device is charging. This is investigated in more detail in Modify your Download Patterns Based on the Connectivity Type.
3.Batch Transfers and Connections
Every time you initiate a connection—irrespective of the size of the associated data transfer—you potentially cause the radio to draw power for nearly 20 seconds when using a typical 3G wireless radio.
An app that pings the server every 20 seconds, just to acknowledge that the app is running and visible to the user, will keep the radio powered on indefinitely, resulting in a significant battery cost for almost no actual data transfer.
With that in mind it's important to bundle your data transfers and create a pending transfer queue. Done correctly, you can effectively phase-shift transfers that are due to occur within a similar time window, to make them all happen simultaneously—ensuring that the radio draws power for as short a duration as possible.
The underlying philosophy of this approach is to transfer as much data as possible during each transfer session in an effort to limit the number of sessions you require.
That means you should batch your transfers by queuing delay tolerant transfers, and preempting scheduled updates and prefetches, so that they are all executed when time-sensitive transfers are required. Similarly, your scheduled updates and regular prefetching should initiate the execution of your pending transfer queue.
For a practical example, let's return to the earlier examples from Prefetch Data.
Take a news application that uses the prefetching routine described above. The news reader collects analytics information to understand the reading patterns of its users and to rank the most popular stories. To keep the news fresh, it checks for updates every hour. To conserve bandwidth, rather than download full photos for each article, it prefetches only thumbnails and downloads the full photos when they are selected.
In this example, all the analytics information collected within the app should be bundled together and queued for download, rather than being transmitted as it's collected. The resulting bundle should be transferred when either a full-sized photo is being downloaded, or when an hourly update is being performed.
Any time-sensitive or on-demand transfer—such as downloading a full-sized image—should preempt regularly scheduled updates. The planned update should be executed at the same time as the on-demand transfer, with the next update scheduled to occur after the set interval. This approach mitigates the cost of performing a regular update by piggy-backing on the necessary time-sensitive photo download.
4.Reduce Connections
It's generally more efficient to reuse existing network connections than to initiate new ones. Reusing connections also allows the network to more intelligently react to congestion and related network data issues.
Rather than creating multiple simultaneous connections to download data, or chaining multiple consecutive GET requests, where possible you should bundle those requests into a single GET.
For example, it would be more efficient to make a single request for every news article to be returned in a single request / response than to make multiple queries for several news categories. The wireless radio needs to become active in order to transmit the termination / termination acknowledgement packets associated with server and client timeout, so it's also good practice to close your connections when they aren't in use, rather than waiting for these timeouts.
That said, closing a connection too early can prevent it from being reused, which then requires additional overhead for establishing a new connection. A useful compromise is not to close the connection immediately, but to still close it before the inherent timeout expires.
Optimizing Downloads for Efficient Network Access的更多相关文章
- 开源网络准入系统(open source Network Access Control system)
开源网络准入系统(open source Network Access Control system) http://blog.csdn.net/achejq/article/details/5108 ...
- 「2014-5-31」Z-Stack - Modification of Zigbee Device Object for better network access management
写一份赏心悦目的工程文档,是很困难的事情.若想写得完善,不仅得用对工具(use the right tools),注重文笔,还得投入大把时间,真心是一件难度颇高的事情.但,若是真写好了,也是善莫大焉: ...
- Z-Stack - Modification of Zigbee Device Object for better network access management
写一份赏心悦目的工程文档,是很困难的事情.若想写得完善,不仅得用对工具(use the right tools),注重文笔,还得投入大把时间,真心是一件难度颇高的事情.但,若是真写好了,也是善莫大焉: ...
- 记一次 Docker swarm - overlay network access error
背景 之前使用Docker swam 在不同的服务器 (docker host) 上面创建了service,他们之间的container通过overlay的网络通信. 昨天由于公司网络维护,其中一台服 ...
- eclipse启动报错the catalog could not be loaded please ensure that you have network access and if needed have configured your network proxy
搜索关键词不对在网上查了一圈没找到合适的解决办法 去看报错的日志文件 然并卵.不过下面有个config.ini,想着以前能用现在不能用,肯定是配置问题,打开该文件 转载请注明出处http://www. ...
- NAP(Network Access Protection)
- Android 性能优化(7)网络优化( 3) Optimizing User-Initiated Network Use
Optimizing User-Initiated Network Use This lesson teaches you to Pre-fetch Network Data Check for Co ...
- Android推送技术研究
前言 最近研究Android推送的实现, 研究了两天一夜, 有了一点收获, 写下来既为了分享, 也为了吐槽. 需要说明的是有些东西偏底层硬件和通信行业, 我对这些一窍不通, 只能说说自己的理解. 为什 ...
- Android Training
Building Apps with Content Sharing Simple Data --> Intent && ActionProvider 介绍如何让应用程序共享简单 ...
随机推荐
- 学习LaTex
MarkDown+Latex 本来想学习latex编辑公式的,在博客园内置的MarkDown编辑器已经支持Latex公式解析了,如下: $$x=\frac{-b\pm\sqrt{b^2-4ac}}{2 ...
- 题目1011:最大连续子序列 O(n)
题目大意:给出一系列的数字.要求你输出这些数字的最大连续和,并输出构成这个最大连续和的第一个数和最后一个数 解题思路:用一个变量维护最大连续和 假设当前这个变量小于0的话,就表示这个变量仅仅会拉低连续 ...
- 【计算机视觉】SIFT中LoG和DoG比較
在实际计算时,三种方法计算的金字塔组数noctaves,尺度空间坐标σ,以及每组金字塔内的层数S是一样的.同一时候,如果图像为640*480的标准图像. 金字塔层数: 当中o_min = 0,对于分辨 ...
- MongoDB 自己定义函数
定义 db.system.js.insert({ _id : "TestConcat", value : function TestConcat(s1, s2){ return s ...
- android <application> 开发文档翻译
由于本人英文能力实在有限,不足之初敬请谅解 本博客仅仅要没有注明"转",那么均为原创.转贴请注明本博客链接链接 <application>语法: <appl ...
- 数据结构与算法问题 AVL二叉平衡树
AVL树是带有平衡条件的二叉查找树. 这个平衡条件必须保持,并且它必须保证树的深度是O(logN). 一棵AVL树是其每一个节点的左子树和右子树的高度最多差1的二叉查找树. (空树的高度定义为-1). ...
- 为Html.EditorForModel自定义模版
对于MVC视图渲染来说,大家应该不会陌生,但对于模型的渲染,不知道是否听说过,主要是说Model通过它属性的相关特性(DataType,UIHint)来将它们自动渲染到View上,这是一个比较不错的技 ...
- YTU 2441: C++习题 复数类--重载运算符2+
2441: C++习题 复数类--重载运算符2+ 时间限制: 1 Sec 内存限制: 128 MB 提交: 847 解决: 618 题目描述 定义一个复数类Complex,重载运算符"+ ...
- 比特币客户端bitcoind的高级用法
Bitcoin 比特币官方客户端有两个版本:一个是图形界面的版本,通常被称为 Bitcoin(首字母大写),以及一个简洁命令行的版本(称为 bitcoind).它们相互间是兼容的,有着同样的命令行参数 ...
- Database Firewall——mysql也是支持的
Database Firewall The most impressive feature of MySQL security is the Database Firewall. The firewa ...