Merge "Revert "docs: Battery performance, networking analysis and optimization"" into mnc-docs

page.title=Battery Performance

page.title=Optimizing Battery Life

page.tags=battery

page.metaDescription=Learn how to optimize your app to reduce battery drain and use power-hungry resources efficiently.

page.article=true

@jd:body

<iframe width="448" height="252"

    src="//www.youtube.com/embed/9i1_PnPpd3g?autohide=1&showinfo=0"

    frameborder="0" allowfullscreen=""

    style="float: right; margin: 0 0 20px 20px;"></iframe>

<p>

  Users want their devices to run as long as possible on a single charge of battery. As an app

  developer, you should strive to make your app draw the minimum amount of power from the battery

  without sacrificing responsiveness, speed or latency for the user. You can take steps to optimize

  your app for maximum battery life by following the guidelines in this course. In many cases,

  you can minimize battery consumption and still get the same amount of work done by being

  more efficient.

</p>

<p>

  When users notice their battery does not get them through the day, they commonly check their

  device's Settings to find the offending app, where they can easily uninstall it. You should

  analyze your app to see if it is a leading source of battery drain, and take steps to prevent

  excessive battery consumption.

</p>

<p>

  These lessons show you how to analyze your app for common sources of battery drain and fix them

  in your app.

</p>

<h2>Lessons</h2>

<dl>

  <dt>

    <b><a href="{@docRoot}training/app/battery/network/index.html">

        Reducing Network Battery Drain</a></b>

  </dt>

  <dd>

    Learn how to analyze your app's use of network resources and optimize it to reduce

    power consumption.

  </dd>

</dl>

page.title=Optimizing General Network Use

trainingnavtop=true

@jd:body

<div id="tb-wrapper">

<div id="tb">

<h2>This lesson teaches you to</h2>

<ol>

  <li><a href="#compress-data">Compress Data</a>

  <li><a href="#cache-locally">Cache Files Locally</a></li>

  <li><a href="#pre-fetch">Optimize Pre-Fetch Cache Size</a></li>

</ol>

</div>

</div>

<img src="{@docRoot}images/training/app/app_icon_action.png" align="left"

  width="64px" style="margin: 0 10px 5px 0;">

<p>

  Some techniques for reducing the amount of network use can be applied to multiple network

  use scenarios. After you complete your analysis and optimization of the primary network

  access use case for your app, you should also look at these general-purpose techniques

  and see if you can apply them to your app.

</p>

<p>

  This lesson briefly covers techniques that you can use to lower network use and reduce the

  impact your app has on battery life.

</p>

<h2 id="compress-data">Compress Data</h2>

<iframe width="448" height="252"

    src="//www.youtube.com/embed/IwxIIUypnTE?autohide=1&showinfo=0"

    frameborder="0" allowfullscreen=""

    style="float: right; margin: 0 0 20px 20px;"></iframe>

<p>

  If you can reduce the amount of data sent or received over a network connection, this also

  reduces the duration of the connection, which conserves battery. You can:

</p>

<ul>

  <li>Compress data, using a compression technique such as GZIP compression.</li>

  <li>Use succinct data protocols. While JSON and XML offer human-readability, and

    language-flexibility, they are bandwidth-heavy formats, with

    high serialization costs in the Android platform. Binary serialization formats,

    such as <a href="https://developers.google.com/protocol-buffers/">Protocol Buffers</a> or

    <a href="https://google.github.io/flatbuffers/">FlatBuffers</a> offer a smaller on-the-wire

    packet size, as well as faster encoding and decoding time. If your application transfers a lot

    of serialized data on a regular basis, these formats can yield benefits for decoding time and

    transfer size.

  </li>

</ul>

<h2 id="cache-locally">Cache Files Locally</h2>

<iframe width="448" height="252"

    src="//www.youtube.com/embed/7lxVqqWwTb0?autohide=1&showinfo=0"

    frameborder="0" allowfullscreen=""

    style="float: left; margin: 0 20px 20px 0;"></iframe>

<p>

  Your app can avoid downloading duplicate data by caching. Always cache static resources,

  including on-demand downloads such as full size images, and cache them for as long as reasonably

  possible.

</p>

<p>

  For example, you should consider this approach for a networked app that displays data from

  user-initiated network requests as the primary content on the screen. When the user opens this

  screen the first time, the app should display a splash screen. Subsequent loads should initially

  load with the data that was cached from the last network request. The screen reloads with

  new data once the network request is complete.

</p>

<p>

  To learn about caching, watch the video. To implement caching in your app, see <a href=

  "{@docRoot}training/efficient-downloads/redundant_redundant.html#LocalCache">Cache Files

  Locally</a>.

</p>

<h2 id="pre-fetch">Optimize Pre-Fetch Cache Size</h2>

<p>

  Optimize pre-fetch cache size based on local file system size and current network connectivity.

  You can use the connectivity manager to determine what type of networks (Wi-FI, LTE, HSPAP, EDGE,

  GPRS) are active and modify your pre-fetching routines to minimize battery load.

</p>

<p>

  For more information, see

  <a href="{@docRoot}training/efficient-downloads/connectivity_patterns.html#Bandwidth">Use

  Modifying your Download Patterns Based on the Connectivity Type</a>.

</p>

 No newline at end of file

page.title=Optimizing App-Initiated Network Use

trainingnavtop=true

@jd:body

<div id="tb-wrapper">

<div id="tb">

<h2>This lesson teaches you to</h2>

<ol>

  <li><a href="#batch-schedule">Batch and Schedule Network Requests</a>

  <li><a href="#check-connect">Allow System to Check for Connectivity</a></li>

</ol>

</div>

</div>

<img src="{@docRoot}images/training/app/app_icon_action.png" align="left"

  width="64px" style="margin: 0 10px 5px 0;">

<p>

  Network traffic initiated by your app can usually be significantly optimized, since you can plan

  for what network resources it needs and set a schedule for accessing them. By applying careful

  scheduling, you can create significant periods of rest for the device radio and, thereby, save

  power. There are several Android APIs that can help with network access scheduling, and some of

  these functions can coordinate network access for other apps, further optimizing battery

  performance.

</p>

<p>

  This lesson teaches you how to reduce battery consumption by applying techniques for

  optimizing app-initiated network traffic.

</p>

<h2 id="batch-schedule">Batch and Schedule Network Requests</h2>

<iframe width="448" height="252"

    src="//www.youtube.com/embed/Ecz5WDZoJok?autohide=1&showinfo=0"

    frameborder="0" allowfullscreen=""

    style="float: right; margin: 0 0 20px 20px;"></iframe>

<p>

  On a mobile device, the process of turning on the radio, making a connection, and keeping the

  radio awake uses a large amount of power. For this reason, processing individual requests at

  random times can consume significant power and reduce battery life. A more efficient approach is

  to queue a set of network requests and process them together. This allows the system to pay the

  power cost of turning on the radio just once, and still get all the data requested by an app.

</p>

<iframe width="448" height="252"

    src="//www.youtube.com/embed/orlRuEwlDoM?autohide=1&showinfo=0"

    frameborder="0" allowfullscreen=""

    style="float: left; margin: 0 20px 20px 0;"></iframe>

<p>

  Using a network access scheduler API for queuing and processing your app data requests can

  significantly increase the power efficiency of your app. Schedulers conserve battery power by

  grouping requests together for the system to process. They can further improve efficiency by

  delaying some requests until other requests wake up the mobile radio, or waiting until the

  device is charging. Schedulers defer and batch network requests system-wide, across all apps on

  the device, which gives them an optimizing advantage over what any individual app can do.

</p>

<h3 id="choosing-scheduler">Choosing a batch-and-scheduling API</h3>

<p>

  Android provides three different APIs for your app to batch and schedule network requests. For

  most operations, these techniques are functionally equivalent. These APIs are listed in the

  following table with the most highly recommended first.

</p>

<table>

  <tr>

    <th>Scheduler</th>

    <th>Requirements</th>

    <th>Implementation Ease</th>

  </tr>

  <tr>

    <td><a href="https://developers.google.com/cloud-messaging/network-manager">

      GCM Network Manager</a></td>

    <td>GCM Network Manager requires that your app use the Google Play services client library,

      version 6.1.11 or higher.  Use the latest available version.</td>

    <td>Straightforward</td>

  </tr>

  <tr>

    <td><a href="{@docRoot}reference/android/app/job/JobScheduler.html">Job Scheduler</a></td>

    <td>Job Scheduler does not require Google Play services, but is available only when targeting

      Android 5.0 (API level 21) or higher.</td>

    <td>Straightforward</td>

  </tr>

  <tr>

    <td><a href="{@docRoot}training/sync-adapters/index.html">Sync Adapter</a></td>

    <td>Sync Adapter does not require the Google Play services client library and has been

      available since Android 2.0 (API level 5).</td>

    <td>Complex</td>

  </tr>

</table>

<p class="note">

  <strong>Note:</strong> For scheduled data synchronization, you should <em>always</em> prefer GCM

  Network Manager or Job Scheduler over Sync Adapter if your requirements allow it.

</p>

<h2 id="check-connect">Allow System to Check for Connectivity</h2>

<p>

  One of the most serious and unexpected causes of battery drain is when a user travels beyond the

  reach of any cell tower or access point. In this situation, the user is typically not using their

  device, but they notice the device getting warm, and then see that the battery is low or has run

  out.

</p>

<p>

  In this scenario, the problem is that an app is running a background process that keeps

  waking up the mobile radio at regular intervals to search for a cellular signal, but finds none.

  Searching for a cell signal is one of the most power-draining operations there is.

</p>

<p>

  The way to avoid causing this kind of problem for a user with your app is to use a

  battery-efficient method for checking connectivity. For app-initiated network requests, use a

  <a href="#choosing-scheduler">scheduler</a>, which automatically uses <a href=

  "{@docRoot}training/monitoring-device-state/connectivity-monitoring.html">Connectivity

  Manager</a> to check for connectivity before calling into your app. As a result, if there's no

  network, the Connectivity Manager conserves battery because it performs the connectivity check

  itself, without loading the app to run the check. Battery is further conserved because schedulers

  use <a href="http://en.wikipedia.org/wiki/Exponential_backoff" class="external-link">exponential

  backoff</a> to check for connectivity less frequently as time progresses.

</p>

page.title=Optimizing Server-Initiated Network Use

trainingnavtop=true

@jd:body

<div id="tb-wrapper">

<div id="tb">

<h2>This lesson teaches you to</h2>

<ol>

  <li><a href="#gcm">Send Server Updates with GCM</a>

</ol>

</div>

</div>

<img src="{@docRoot}images/training/app/app_icon_action.png" align="left"

  width="64px" style="margin: 0 10px 5px 0;">

<p>

  Network traffic sent by server programs to your app can be challenging to optimize. A

  solution to this problem is to periodically poll the server from your app to check for updates.

  This approach can waste network connection and power by starting up a device radio, only to

  receive an answer that no new data is available. A more efficient approach would be for the

  server to notify your app when it has new data, but figuring out how to send a notification from

  your server to potentially thousands of devices is no easy feat.

</p>

<p>

  The <a href="https://developers.google.com/cloud-messaging/gcm">Google Cloud Messaging</a> (GCM)

  service solves this communication problem by allowing your servers to send notifications to

  instances of your app wherever they are installed, enabling greater network efficiency and

  lowering power usage.

</p>

<p>

  This lesson teaches you how to apply the GCM service to reduce network use for server-initiated

  actions and reduce battery consumption.

</p>

<h2 id="gcm">Send Server Updates with GCM</h2>

<p>

  Google Cloud Messaging (GCM) is a lightweight mechanism used to transmit brief messages from an

  app server to your app. Using GCM, your app server uses a message-passing

  mechanism to notify your app that there is new data available. This approach eliminates network

  traffic that your app would perform, by not contacting a backend server for new data when there

  is none available.

</p>

<p>

  An example use of GCM is an app that lists speaker sessions at a conference. When sessions are

  updated on your server, the server sends a message to your app telling it updates are available.

  Your app can then call the server to update the sessions on the device only when there is new

  data, rather than periodically contacting the server to find out if there are updates.

</p>

<p>

  GCM is more efficient than polling for changes on the server. The service eliminates

  unnecessary connections where polling would return no updates, and it avoids running periodic

  network requests that could cause a device radio to power up. Since GCM can be used by many apps,

  using it in your app reduces the total number of network connections needed on a device and

  allows the device radio to sleep more often.

</p>

<p>

  For more information about GCM and how to implement it for your app, see

  <a href="https://developers.google.com/cloud-messaging/gcm">Google Cloud Messaging</a>.

</p>

<p class="note">

  <strong>Note:</strong> When using GCM, your app can pass messages in normal or high priority.

  Your server should typically use <a href=

  "https://developers.google.com/cloud-messaging/concept-options#setting-the-priority-of-a-message">

  normal priority</a> to deliver messages. Using this priority level prevents devices from being

  woken up if they are inactive and in a low-power <a href=

  "https://developer.android.com/training/monitoring-device-state/doze-standby.html">Doze</a>

  state. Use high priority messages only if absolutely required.

</p>

page.title=Optimizing User-Initiated Network Use

trainingnavtop=true

@jd:body

<div id="tb-wrapper">

<div id="tb">

<h2>This lesson teaches you to</h2>

<ol>

  <li><a href="#pre-fetch-data">Pre-fetch Network Data</a>

  <li><a href="#check-or-listen">Check for Connectivity or Listen for Changes</a></li>

  <li><a href="#reduce-connections">Reduce the Number of Connections</a></li>

</ol>

</div>

</div>

<img src="{@docRoot}images/training/app/app_icon_action.png" align="left"

  width="64px" style="margin: 0 10px 5px 0;">

<p>

  Quick handling of user requests helps ensure a good user experience, especially when it comes to

  user actions that require network access. You should prioritize low latency over power

  conservation to provide the fastest response when optimizing network use that is a direct result

  of user actions. Attaining an optimal network traffic profile for your app, while making sure

  that your users get fast responses, can be a bit challenging.

</p>

<p>

  This lesson teaches you how to optimize network use for user-initiated

  actions and reduce battery consumption.

</p>

<h2 id="pre-fetch-data">Pre-fetch Network Data</h2>

<iframe width="448" height="252"

    src="//www.youtube.com/embed/Rk1u7VVmadE?autohide=1&showinfo=0"

    frameborder="0" allowfullscreen=""

    style="float: right; margin: 0 0 20px 20px;"></iframe>

<p>

  Pre-fetching data is an effective way to reduce the number of independent data transfer sessions

  that your app runs. With pre-fetching, when the user performs an action in your app, the app

  anticipates data that will most likely be needed for the next user actions and fetches that data

  in bulk. Battery power consumption is reduced because the pre-fetched data does not require

  separate requests that each incur the overhead of waking up the mobile radio.

</p>

<p class="note">

  <strong>Tip:</strong> To explore whether your app might benefit from pre-fetching, review your

  app's network traffic and look for situations where a specific series of user actions almost

  always results in multiple network requests over the course of the task. For instance, an app

  that incrementally downloads article content as a user views it might be able to pre-fetch one or

  more articles in categories the user is known to view.

</p>

<p>

  Watch the video on effective pre-fetching below which describes what pre-fetching is, where to

  use it, and how much data to pre-fetch. For more details, see <a href=

  "{@docRoot}training/efficient-downloads/efficient-network-access.html#PrefetchData">Optimizing

  Downloads for Efficient Network Access</a>.

</p>

<h2 id="check-or-listen">Check for Connectivity or Listen for Changes</h2>

<p>

  Searching for a cell signal is one of the most power-draining operations on a mobile

  device. Your app should always check for connectivity before sending a user-initiated network

  request. If you use a scheduling service, the service does this automatically for you. Fo

  (<a href="#heading=h.a114i7ic2bxc">Schedulers</a> do this automatically for you.)

</p>

<ul>

  <li>If only certain buttons in your activity depend on a network connection, use <a href=

  "{@docRoot}reference/android/net/ConnectivityManager.html">Connectivity Manager</a> to check for

  a network connection before sending the network request, as instructed in <a href=

  "{@docRoot}training/monitoring-device-state/connectivity-monitoring.html#MonitorChanges">Monitor

  for Changes in Connectivity</a>. If there's no network, the app can save battery by not forcing

  the mobile radio to search.

  </li>

  <li>If your entire activity's user interface is non-functional without network access, then use

  <a href="{@docRoot}training/monitoring-device-state/manifest-receivers.html">Manipulate Broadcast

  Receivers on Demand</a>. This technique listens for connectivity changes when your activity is in

  the foreground, and prevents network requests from proceeding when no connectivity exists. That

  is, if your app detects that connectivity has been lost, it disables all of its receivers, except

  for the connectivity-change receiver. An example would be a news app that presents an activity

  with a full-screen view of news snippets and does no pre-fetching. Any snippet a user taps would

  require a network connection.

  </li>

</ul>

<p>

  A best practice for user-initiated traffic is to first check for a connection using <a href=

  "{@docRoot}reference/android/net/ConnectivityManager.html">Connectivity Manager</a>, and if there

  is no connection, <a href="#heading=h.a114i7ic2bxc">schedule</a> the network request for when the

  connection is made. Schedulers will use techniques such as exponential backoff to save battery,

  where each time the attempt to connect fails, the scheduler doubles the delay before the next

  retry.

</p>

<p class="note">

  <strong>Note:</strong> To check for connectivity for app-initiated traffic, see <a href=

  "action-app-traffic.html#check-connect">Optimizing App-Initiated Network Use</a>.

</p>

<h2 id="reduce-connections">Reduce the Number of Connections</h2>

<p>

  In general, it's 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. For more information on reducing the number of connections used by your app,

  see <a href="{@docRoot}training/efficient-downloads/efficient-network-access.html#ReduceConnections">

  Optimizing Downloads for Efficient Network Access</a>.

</p>