Merge "docs: Fixing onRequestPermissionResults() code sample" into mnc-docs
diff --git a/docs/html/images/training/app/madscientist.png b/docs/html/images/training/app/madscientist.png
new file mode 100644
index 0000000..5e67056
--- /dev/null
+++ b/docs/html/images/training/app/madscientist.png
Binary files differ
diff --git a/docs/html/jd_collections.js b/docs/html/jd_collections.js
index 9f39602..59b4efa 100644
--- a/docs/html/jd_collections.js
+++ b/docs/html/jd_collections.js
@@ -1670,4 +1670,12 @@
"training/testing/performance.html"
]
},
+ "app/landing/videos": {
+ "title": "",
+ "resources": [
+ "https://www.youtube.com/watch?v=CaMTIgxCSqU",
+ "https://www.youtube.com/watch?v=OrLEoIsMIAc",
+ "https://www.youtube.com/watch?v=bSOREVMEFnM"
+ ]
+ },
}
diff --git a/docs/html/training/app/approach.jd b/docs/html/training/app/approach.jd
new file mode 100644
index 0000000..3177fb3
--- /dev/null
+++ b/docs/html/training/app/approach.jd
@@ -0,0 +1,175 @@
+page.title=Gather, Insight, Action
+meta.tags="android, performance", "app"
+page.tags="app"
+page.article=true
+@jd:body
+
+<style>
+ .app-icon {
+ height: 64px;
+ }
+ .app-icon-small {
+ height: 32px;
+ }
+ .app-icon-inline {
+ height: 16px;
+ }
+</style>
+
+
+
+<p>Your app has a performance problem if it does not instantly respond
+to a user action, stutters, or makes the user wait at any point.
+This lesson introduces the most basic performance test for your app,
+and a process for iteratively finding and fixing performance problems. </p>
+
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_gather.png">
+ Litmus test your app</h2>
+
+ <p>To find out whether your app has performance issues, you don't need fancy
+ tools. </p>
+
+ <p>Do the following:</p>
+
+ <ol>
+ <li>Install your app on the lowest-end device that your target audience might have.</li>
+
+ <li>Use your app as a user would, and keep detailed notes on even the smallest wait, stutter,
+ or unresponsiveness. Watch out for increasing slowness over time.</li>
+
+ <li>Hand the device to a friend and take notes while they are using it.</li>
+
+ <li>If you would like feedback from a larger audience, consider running a mini-usability test,
+ such as described in
+ <a href="https://www.youtube.com/watch?v=0YL0xoSmyZI">
+ Guerilla Testing with Usability Cafe</a>.</li>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/0YL0xoSmyZI?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float:none; margin: 0 0 20px 20px;"></iframe>
+
+ </ol>
+
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_insight.png">
+ Approach performance problems methodically</h2>
+
+ <p><b>If these hands-on tests didn't reveal any performance problems,</b></p>
+
+ <ul>
+ <li>you could do nothing further, or</li>
+
+ <li>you can dive deeper and make your app perform even better. This could benefit users with
+ slower connections or on simpler devices, and increase your potential audience.</li>
+ </ul>
+
+ <p><b>If you gathered any notes related to performance, then performance is a problem for your
+ app.</b></p>
+
+ <p>Once you have subjectively established that your app could benefit from performance tuning, we
+ have two recommendations for an objective and systematic approach to finding and fixing
+ performance problems faster.</p>
+
+
+
+ <h3>1. Use performance profiling tools</h3>
+
+ <p>Android and Android Studio come with many
+ <a href="http://developer.android.com/tools/performance/index.html">
+ performance profiling tools</a>
+ to help you
+ identify performance problems and track down where they are in your code. And after you have
+ changed your code, run the tools again to measure the impact of your change. Compare results to
+ make sure you've fixed the right problem, and find out whether you need to
+ make additional performance improvements.</p>
+
+ <p>To learn more about why you should use tools, see
+ <a href="https://www.youtube.com/watch?v=SA4j6KKjMRk">Tools Not Rules</a>.</p>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/SA4j6KKjMRk?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float:none; margin: 0 0 20px 20px;"></iframe>
+
+ <h3>2. Follow the Performance Tuning Lifecycle</h3>
+
+ <p>When optimizing your application, you must be able to measure its state, make changes, and
+ then evaluate the performance differences of these changes. Thus, the Performance Tuning
+ Lifecycle is built around the concept of "What you can measure, you can
+ optimize".</p>
+
+ <p>The Performance Tuning Lifecycle (Figure 1), consists of three phases:
+ gather information, gain insight, and take action.</p>
+
+ <div class="figure" style="">
+ <img src="{@docRoot}images/training/app/gather_insight_action.png"
+ alt=""
+ height=""/>
+ <p class="img-caption">
+ <strong>Figure 1. </strong>The Performance Tuning Lifecycle.
+ </p>
+ </div>
+
+ <p><b>
+ <img class="app-icon-small" src="{@docRoot}images/training/app/app_icon_gather.png">
+ Gather Information.</b> <br>
+ Use the
+ <a href="http://developer.android.com/tools/performance/index.html">
+ performance profiling tools</a>
+ to capture data
+ about your app. Since most tools are specialized, you may need to run several tools.</p>
+
+ <p><b>
+ <img class="app-icon-small" src="{@docRoot}images/training/app/app_icon_insight.png">
+ Gain Insight.</b><br>
+ Take the time to understand what your gathered data means for your app.
+ You may need to go through several iterations of gathering information and gaining insight to
+ pinpoint what the problem (or problems!) is.</p>
+
+ <p><b>
+ <img class="app-icon-small" src="{@docRoot}images/training/app/app_icon_action.png">
+ Take Action.</b><br>
+ Take all the information and all the insights, and determine and evaluate
+ different ways to solve your problem. Taking action can take different forms, and what you decide
+ to do depends on your situation and context, which may also include coding resources, budgets,
+ and deadlines.</p>
+
+ <p>And once you've taken action, verify that your changes had the desired
+ outcome:</p>
+
+ <p>
+ <img class="app-icon-inline" src="{@docRoot}images/training/app/app_icon_gather.png">
+ Gather a second set of data.
+ <img class="app-icon-inline" src="{@docRoot}images/training/app/app_icon_insight.png">
+ Compare it to your original data.
+ <img class="app-icon-inline" src="{@docRoot}images/training/app/app_icon_action.png">
+ Make more changes...
+ and repeat this process until your app consistently responds smoothly to all user actions, never
+ stutters, and never makes the user wait. On all target devices.</p>
+
+ <p>To learn more, see
+ <a href="https://youtu.be/_kKTGK-Cb_4">The Performance Tuning Lifecycle</a>.</p>
+
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/_kKTGK-Cb_4?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float:none; margin: 0 0 20px 20px;"></iframe>
+
+
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_action.png">
+ Start improving performance</h2>
+
+ <ul>
+ <li>If your notes include problems with the speed or smoothness of animations, or the app does
+ not consistently respond to user input, start with
+ <a href="{@docRoot}training/app/rendering/index.html">
+ Optimizing Rendering Performance</a>.</li>
+
+ <li>If your app uses the GPS or mobile radio, or makes a lot of networking calls, check
+ out: <a href="{@docRoot}training/app/battery/index.html">
+ Optimizing Battery Performance</a>.</li>
+ </ul>
diff --git a/docs/html/training/app/battery/index.jd b/docs/html/training/app/battery/index.jd
index c8445d7..20341c5 100644
--- a/docs/html/training/app/battery/index.jd
+++ b/docs/html/training/app/battery/index.jd
@@ -1,4 +1,48 @@
-page.title=Optimizing Battery Life
+page.title=Battery Performance
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>
diff --git a/docs/html/training/app/battery/network/action-any-traffic.jd b/docs/html/training/app/battery/network/action-any-traffic.jd
new file mode 100644
index 0000000..20ce36c
--- /dev/null
+++ b/docs/html/training/app/battery/network/action-any-traffic.jd
@@ -0,0 +1,103 @@
+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
diff --git a/docs/html/training/app/battery/network/action-app-traffic.jd b/docs/html/training/app/battery/network/action-app-traffic.jd
new file mode 100644
index 0000000..09746e9
--- /dev/null
+++ b/docs/html/training/app/battery/network/action-app-traffic.jd
@@ -0,0 +1,135 @@
+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>
diff --git a/docs/html/training/app/battery/network/action-server-traffic.jd b/docs/html/training/app/battery/network/action-server-traffic.jd
new file mode 100644
index 0000000..e5ac971
--- /dev/null
+++ b/docs/html/training/app/battery/network/action-server-traffic.jd
@@ -0,0 +1,81 @@
+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>
diff --git a/docs/html/training/app/battery/network/action-user-traffic.jd b/docs/html/training/app/battery/network/action-user-traffic.jd
new file mode 100644
index 0000000..4d73ff3
--- /dev/null
+++ b/docs/html/training/app/battery/network/action-user-traffic.jd
@@ -0,0 +1,122 @@
+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>
diff --git a/docs/html/training/app/battery/network/analyze-data.jd b/docs/html/training/app/battery/network/analyze-data.jd
new file mode 100644
index 0000000..03efa05
--- /dev/null
+++ b/docs/html/training/app/battery/network/analyze-data.jd
@@ -0,0 +1,225 @@
+page.title=Analyzing Network Traffic Data
+trainingnavtop=true
+
+@jd:body
+
+<div id="tb-wrapper">
+<div id="tb">
+
+<h2>This lesson teaches you to</h2>
+<ol>
+ <li><a href="#general-traffic">Analyze App Network Traffic</a></li>
+ <li><a href="#traffic-types">Analyze Network Traffic Types</a></li>
+</ol>
+
+</div>
+</div>
+
+
+<img src="{@docRoot}images/training/app/app_icon_insight.png" align="left"
+ height="64px" style="margin: 0 10px 5px 0;">
+
+<p>
+ Gathering data about the network access behavior of your app is the first step toward optimizing
+ your app's use of network hardware, and making your app more power efficient. After you have
+ tagged your app code with traffic identifiers, run tests, and collected data, it is time to
+ analyze that data.
+</p>
+
+<p>
+ This lesson teaches you how to look at the network traffic data you have collected from your app
+ and directs you to actions for improving your app's networking performance and reducing power
+ consumption.
+</p>
+
+
+<h2 id="general-traffic">Analyze App Network Traffic</h2>
+
+<p>
+ Efficient use of network resources by an app is characterized by significant periods where
+ the network hardware is not in use.
+
+ On mobile devices, there is a significant cost associated with starting up the radio
+ to send or receive data, and with keeping the mobile radio active for long periods. If your app
+ is accessing the network efficiently, you should see that its communications over the network are
+ tightly grouped together, well spaced with periods where the app is making no connection requests.
+</p>
+
+<p>
+ Figure 1 shows suboptimal network traffic from app, as measured by the Network Traffic tool. The
+ app is making frequent network requests. This traffic has few periods of
+ rest where the radio could switch to a standby, low-power mode. The network access behavior of
+ this app is likely to keep the radio on for extended periods of time, which is
+ battery-inefficient.
+</p>
+
+<img src="{@docRoot}images/training/app/suboptimal_network_traffic_pattern.png"
+ alt="" id="figure1" />
+<p class="img-caption">
+ <strong>Figure 1.</strong> Battery-inefficient network activity measured from an app.
+</p>
+
+<p>
+ Figure 2 shows an optimal network traffic pattern. The app sends network requests in bursts,
+ separated by long periods of no traffic where the radio can switch to standby. This chart shows
+ the same amount of work being done as Figure 1, but the requests have been shifted and grouped to
+ allow the radio to be in standby most of the time.
+</p>
+
+<img src="{@docRoot}images/training/app/optimal_network_traffic_pattern.png"
+ alt="" id="figure2" />
+<p class="img-caption">
+ <strong>Figure 2.</strong> Battery-efficient network activity measured from an app.
+</p>
+
+<p>
+ If the network traffic for your app looks similar to the graph in Figure 2, you are in good
+ shape! Congratulations! You may want to pursue further networking efficiency by checking out the
+ techniques described in <a href=
+ "{@docRoot}training/app/battery/network/action-any-traffic.html">Optimizing General Network
+ Use</a>
+</p>
+
+<p>
+ If the network traffic for your app looks more like the graph in Figure 1, it's time to take a
+ harder look at how your app accesses the network. You should start by analyzing what types of
+ network traffic your app is generating.
+</p>
+
+
+<h2 id="traffic-types">Analyze Network Traffic Types</h2>
+
+<p>
+ When you look at the network traffic generated by your app, you need to understand the source of
+ the traffic, so you can optimize it appropriately. Frequent network activity generated by your
+ app may be entirely appropriate if it is responding to user actions, but completely inappropriate
+ if you app is not in the foreground or if the device in a pocket or purse. This section discusses
+ how to analyze the types of network traffic being generated by your app and directs you to
+ actions you can take to improve performance.
+</p>
+
+<p>
+ In the previous lesson, you tagged your app code for different traffic types and used the Network
+ Traffic tool to collect data on your app and produce a graph of activity, as shown in Figure 3.
+</p>
+<img src="{@docRoot}images/training/app/network_traffic_colors.png" />
+<p class="img-caption">
+ <strong>Figure 3.</strong> Network traffic tagged for the three categories: user, app, and
+ server.
+</p>
+
+<p>
+ The Network Traffic tool colors traffic based on the tags you created in the previous lesson. The
+ colors are based on the traffic type <a href=
+ "{@docRoot}training/app/battery/network/gather-data.html#constants">constants you defined</a> in
+ your app code. Refer back to your app code to confirm which constants represent user, app, or
+ server-initiated traffic.
+</p>
+
+<p>
+ The following sections discuss how to look at network traffic types and provides recommendations
+ on how to optimize traffic.
+</p>
+
+
+<h3 id="user">Analyzing user-initiated network traffic</h3>
+
+<p>
+ Network activity initiated by the user may be efficiently grouped together while a user is
+ performing a specific activity with your app, or spread out unevenly as users request additional
+ information your app does not have. Your goal in analyzing user-initiated network traffic is to
+ look for patterns of frequent network use over time and attempt to create, or increase the size
+ of, periods where the network is not accessed.
+</p>
+
+<p>
+ The unpredictability of user requests makes it challenging to optimize this type of network use
+ in your app. In addition, users expect fast responses when they are actively using an app, so
+ delaying requests for efficiency can lead to poor user experiences. In general, you should
+ prioritize a quick response to the user over efficient use of the network while a user is
+ directly interacting with your app.
+</p>
+
+<p>
+ Here are some approaches for optimizing user-initiated network traffic:
+</p>
+
+<ul>
+ <li>
+ <a href="{@docRoot}training/app/battery/network/action-user-traffic.html#pre-fetch-data">
+ Pre-fetch Network Data</a> - When the user performs an action in your app, the app
+ anticipates which data may be needed for the next user actions, fetches it in bulk
+ in a single connection, and holds it until the user requests it.
+ </li>
+
+ <li>
+ <a href="{@docRoot}training/app/battery/network/action-user-traffic.html#check-or-listen">
+ Check for Connectivity or Listen for Changes</a> - Check for network connectivity or listen
+ for connectivity changes before performing an update.
+ </li>
+
+ <li>
+ <a href="{@docRoot}training/app/battery/network/action-user-traffic.html#reduce-connections">
+ Reduce the Number of Connections</a> - Use server APIs that allow data to be downloaded in sets.
+ </li>
+</ul>
+
+<p class="caution">
+ <strong>Caution:</strong> Beware of network activity grouping bias in your user activity test
+ data! If you ran a set of user scenarios with your network testing plan, the graph of
+ user-initiated network access may be unrealistically grouped together, potentially causing you to
+ optimize for user behavior that does not actually occur. Make sure your user network test
+ scenarios reflect realistic use of your app.
+</p>
+
+
+<h3 id="app">Analyzing app-initiated network traffic</h3>
+
+<p>
+ Network activity initiated by your app code is typically an area where you can have a significant
+ impact on the efficient use of network bandwidth. In analyzing the network activity of your app,
+ look for periods of inactivity and determine if they can be increased. If you see patterns of
+ consistent network access from your app, look for ways to space out these accesses to allow the
+ device radio to switch into low power mode.
+</p>
+
+<p>
+ Here are some approaches for optimizing app-initiated network traffic:
+</p>
+
+<ul>
+ <li>
+ <a href="{@docRoot}training/app/battery/network/action-app-traffic.html#batch-schedule">
+ Batch and Schedule Network Requests</a> - Defer your app's network requests so they can be
+ processed together and at a time which is advantageous for battery life.
+ </li>
+
+ <li>
+ <a href="{@docRoot}training/app/battery/network/action-app-traffic.html#check-connect">
+ Allow System to Check for Connectivity</a> - Avoid the battery cost of running your app just
+ to check for a network connection when you can let the system run the check while your app
+ sleeps.
+ </li>
+</ul>
+
+
+<h3 id="server">Analyzing server-initiated network traffic</h3>
+
+<p>
+ Network activity initiated by servers communicating with your app is also typically an area where
+ you can have a significant impact on the efficient use of network bandwidth. In analyzing the
+ network activity from server connections, look for periods of inactivity and determine if they
+ can be increased. If you see patterns of consistent network activity from servers, look for ways
+ to space out this activity to allow the device radio to switch into low power mode.
+</p>
+
+<p>
+ Here is an approach for optimizing app-initiated network traffic:
+</p>
+
+<ul>
+ <li>
+ <a href="action-server-traffic.html#gcm">Use GCM for Server Updates</a> - Consider using
+ the Google Cloud Messaging service for server side updates instead of polling.
+ </li>
+</ul>
diff --git a/docs/html/training/app/battery/network/gather-data.jd b/docs/html/training/app/battery/network/gather-data.jd
new file mode 100644
index 0000000..fd6557e
--- /dev/null
+++ b/docs/html/training/app/battery/network/gather-data.jd
@@ -0,0 +1,271 @@
+page.title=Collecting Network Traffic Data
+trainingnavtop=true
+
+@jd:body
+
+<div id="tb-wrapper">
+<div id="tb">
+
+<h2>This lesson teaches you to</h2>
+<ol>
+ <li><a href="#tag-requests">Tag Network Requests</a></li>
+ <li><a href="#build-type">Configure a Network Test Build Type</a></li>
+ <li><a href="#deploy-apk">Deploy the Network Test APK</a></li>
+ <li><a href="#network-tool">Run Network Traffic Tool</a></li>
+</ol>
+
+</div>
+</div>
+
+<img src="{@docRoot}images/training/app/app_icon_gather.png" align="left"
+ width="64px" style="margin: 0 10px 5px 0;">
+
+<p>
+ The network traffic generated by an app can have a significant impact on the battery life of the
+ device where it is running. In order to optimize that traffic, you need to both measure it and
+ identify its source. Network requests can come directly from a user action, requests from your own
+ app code, or from a server communicating with your app.
+</p>
+
+<p>
+ The <a href="{@docRoot}tools/debugging/ddms.html#network">Network Traffic tool</a> (part of the
+ DDMS tools) enables you to view how and when your app transfers data over a network.
+</p>
+
+<p>
+ This lesson shows you how to measure and categorize network requests by tagging your source code,
+ then shows you how to deploy, test and visualize your apps's network traffic.
+</p>
+
+
+<h2 id="tag-requests">Tag Network Requests</h2>
+
+<p>
+ Apps use the networking hardware on a device for various reasons. In order to properly optimize
+ your app's use of networking resources, you must understand how frequently your app is using the
+ network and for what reasons. For performance analysis purposes, you should break down use of
+ network hardware into these categories:
+</p>
+
+<ul>
+ <li>
+ <strong>User-initiated network requests</strong> - Requests initiated by the user, such as a
+ user request for an updated articles list in a news app.
+ </li>
+
+ <li>
+ <strong>App-initiated network requests</strong> - Requests initiated within Android app code
+ that are not used to immediately satisfy a user action, such as an app request to cache the
+ text of unread articles in a news app.
+ </li>
+
+ <li>
+ <strong>Server-initiated network requests</strong> - Requests initiated by a server to your app
+ that are not used to immediately satisfy a user action, such as notification of a newly
+ available article in a news app.
+ </li>
+</ul>
+
+<p>
+ This procedure shows you how to tag your app's source code with constants to categorize traffic
+ as one of these three request types. The Network Traffic tool represents each type of traffic
+ with a different color, so you can visualize and optimize each traffic stream separately.
+ The technique described here reports network traffic based on the execution of threads in your
+ app which you identify as a user, app or server source.
+</p>
+
+<ol>
+ <li>In your app's development project, define three constants to represent the different types
+ of network use:
+
+<pre id="constants">
+public static final int USER_INITIATED = 0x1000;
+public static final int APP_INITIATED = 0x2000;
+public static final int SERVER_INITIATED =0x3000;
+</pre>
+ </li>
+
+ <li>Find networking code in your app by searching for the most common classes used for
+ this purpose:
+ <ol type="a">
+ <li>In Android Studio, choose <strong>Edit > Find > Find in Path</strong>.</li>
+ <li>Paste the following string into the <strong>Text to find</strong> field:<br>
+ <code>extends GcmTaskService|extends JobService|extends
+ AbstractThreadedSyncAdapter|HttpUrlConnection|Volley|Glide|HttpClient</code>
+ </li>
+ <li>Check <strong>Regular expression</strong>.</li>
+ <li>Check <strong>File mask(s)</strong> and type <code>*.java</code>.</li>
+ <li>Click the <strong>Find</strong> button.</li>
+ </ol>
+ </li>
+
+<li>
+ Based on your findings in the previous step, tag your app's use of network traffic by adding the
+ {@link android.net.TrafficStats#setThreadStatsTag} method to each execution thread in your app
+ that uses network resources, as shown in the following code example.
+
+<pre>
+if (BuildConfig.NETWORK-TEST && Build.VERSION.SDK_INT >= 14) {
+ try {
+ TrafficStats.setThreadStatsTag(USER_INITIATED);
+ // make network request using HttpClient.execute()
+ } finally {
+ TrafficStats.clearThreadStatsTag();
+ }
+}
+</pre>
+
+ <p class="note">
+ <strong>Note:</strong> Ensure the tagging does not get into your production code by making
+ inclusion of this conditional, based on the build type used to generate the APK.
+ In the example above, the <code>BuildConfig.NETWORK-TEST</code> field identifies this
+ APK as a test version.
+ </p>
+
+ </li>
+</ol>
+
+<p class="note">
+ <strong>Note:</strong> This technique for tagging network traffic from your app depends on
+ how the APIs you are using access and manage network sockets. Some networking libraries may
+ not allow the {@link android.net.TrafficStats} utilities to tag traffic from your app.
+</p>
+
+<p>
+ For more information about tagging and tracking network traffic with the Network Traffic tool,
+ see <a href="http://tools.android.com/recent/detailednetworkusageinddms">Detailed Network Usage
+ in DDMS</a>.
+</p>
+
+
+<h2 id="build-type">Configure a Network Test Build Type</h3>
+
+<p>
+ When you run performance tests, your APK should be as close as possible to the production
+ build. In order to achieve this for your network testing, create a <code>network-test</code>
+ build type, rather than using <code>debug</code> build type.
+</p>
+
+<ol>
+ <li>Open your app in Android Studio.</li>
+ <li>Create a debuggable build type for your network test by modifying your project's
+ <code>build.gradle</code> file as shown in the following code example:
+
+<pre>
+android {
+ ...
+ buildTypes {
+ debug {
+ // debuggable true is default for the debug buildType
+ }
+ <strong>network-test {
+ debuggable true
+ }</strong>
+ }
+ ...
+}
+</pre>
+ </li>
+</ol>
+
+
+<h2 id="deploy-apk">Deploy the Network Test APK</h2>
+
+<p>
+ To deploy the APK generated by the {@code network-test} build type configured in the previous
+ proceedure:
+</p>
+
+<ol>
+ <li>Check that <strong>Developer Options</strong> are enabled on your test device. For
+ information about how to check and enable this option, see <a href=
+ "{@docRoot}tools/device.html#developer-device-options">Using Hardware Devices</a>.
+ </li>
+
+ <li>Using a USB cable, connect your test device to your development computer.
+ </li>
+
+ <li>In Android Studio, select <strong>Build Variants</strong> on the left edge of the window.
+ </li>
+
+ <li>Click the <strong>Sync Project with Gradle Files</strong> button to populate the
+ Build Variants list with <code>network-test</code> for the app module.
+ </li>
+
+ <li>Choose <code>network-test</code> from the list.
+ </li>
+
+ <li>Deploy the debuggable version of your app to your device by choosing
+ <strong>Run</strong> > <strong>Debug</strong>.
+ </li>
+</ol>
+
+
+<h2 id="network-tool">Run Network Traffic Tool</h2>
+
+<p>
+ The Network Traffic tool in Android Studio helps you see how your app uses network resources
+ while it is running. When running the tool with your app to test performance, you should have a
+ testing plan that exercises the primary functionality of the app, simulating a user interacting
+ with your app. You should also include idle time in your test plan, simulating periods when
+ users are not directly interacting with your app.
+</p>
+
+<p>
+ To improve the repeatability of your testing, you should start with a known initial state for
+ your app by clearing app data. The following procedure shows you how to stop your app and clear
+ <em>all</em> app data including previously cached data and networking data. This step puts your
+ app back to a state where it must re-cache all previously cached data. Do not skip this step.
+</p>
+
+<p>
+ To start the Network Traffic tool and visualize the network requests:
+</p>
+
+<ol>
+ <li>Start the Network Traffic tool by launching Android Studio and choosing <strong>Tools >
+ Android > Android Device Monitor</strong>. When asked, allow incoming network connections.
+ </li>
+
+ <li>In the Android Device Monitor window, click the <strong>DDMS</strong> button along the top
+ and choose the <strong>Network Statistics</strong> tab. If you don't see this tab, widen the
+ window and then try <strong>Window > Reset Perspective</strong>.
+ </li>
+
+ <li>Select your app to debug from the list of debuggable apps on your device in the
+ <strong>Devices</strong> tab, then click the <strong>Start</strong> button in the
+ <strong>Network Statistics</strong> tab.
+
+ <p class="note">
+ <strong>Note:</strong> You may be prompted to <strong>Allow USB Debugging</strong> on your
+ device. Select <strong>OK</strong> to allow debugging to proceed.
+ </p>
+ </li>
+
+ <li>Clear your app data using the following adb command:
+<pre class="no-pretty-print">
+adb shell pm clear <em>package.name.of.app</em>
+</pre>
+ </li>
+
+ <li>Start your app and run a testing plan that exercises your apps primary use cases. Your plan
+ should also allow for app idle time, where the user is not interacting with the app, to allow
+ app-initiated and server-initiated network access to occur.
+ </li>
+
+ <li>Repeat the test by clearing the app data and running your test plan again. You should repeat
+ the test a few times to verify the repeatability of your performance data.
+ </li>
+</ul>
+</ol>
+
+<p>
+ Use of tagging for network traffic helps you visually distinguish each request category by
+ producing a different color for each network traffic in the Network Traffic tool, as shown in
+ Figure 1.
+</p>
+
+<img src="{@docRoot}images/training/app/network_traffic_colors.png" />
+<p class="img-caption">
+ <strong>Figure 1.</strong> Network traffic tagged for the three categories.
+</p>
diff --git a/docs/html/training/app/battery/network/index.jd b/docs/html/training/app/battery/network/index.jd
new file mode 100644
index 0000000..e022065
--- /dev/null
+++ b/docs/html/training/app/battery/network/index.jd
@@ -0,0 +1,87 @@
+page.title=Reducing Network Battery Drain
+page.article=true
+
+page.tags=battery
+page.metaDescription=Learn how to optimize your app to reduce battery drain and use network resources efficiently.
+
+@jd:body
+
+
+<iframe width="448" height="252"
+ src="//www.youtube.com/embed/fEEulSk1kNY?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float: right; margin: 0 0 20px 20px;"></iframe>
+
+<p>
+ Requests that your app makes to the network are a major cause of battery drain because they turn
+ on the power-hungry mobile or Wi-Fi radios. Beyond the energy needed to send and receive packets,
+ these radios expend extra power just turning on and keeping awake. Something as simple as a
+ network request every 15 seconds can keep the mobile radio on continuously and quickly use up
+ battery power.
+</p>
+
+<p>
+ This lesson shows you how to visualize network traffic and you how to tag and categorize your
+ app's source code to color-code your network requests according to how they are initiated, then
+ profile the network traffic. From there, each category identifies areas of your app that you can
+ make more battery-efficient.
+</p>
+
+
+<h2>Performance Actions</h2>
+
+<dl>
+ <dt>
+ <strong><a href="gather-data.html">
+ Collecting Network Traffic Data</a></strong>
+ </dt>
+ <dd>
+ Learn how to instrument your app's code and gather data on its use of network resources.
+ </dd>
+
+ <dt>
+ <strong><a href="analyze-data.html">
+ Anaylzing Network Traffic Data</a></strong>
+ </dt>
+ <dd>
+ Learn how to analyze your app's use of network resources in response to user actions
+ and optimize it to reduce power consumption.
+ </dd>
+
+ <dt>
+ <strong><a href="action-user-traffic.html">
+ Optimizing User-Initiated Network Use</a></strong>
+ </dt>
+ <dd>
+ Learn how to optimize your app's use of network resources in response to user actions
+ to reduce power consumption.
+ </dd>
+
+ <dt>
+ <strong><a href="action-app-traffic.html">
+ Optimizing App-Initiated Network Use</a></strong>
+ </dt>
+ <dd>
+ Learn how to optimize your app's requests for network resources to reduce
+ power consumption.
+ </dd>
+
+ <dt>
+ <strong><a href="action-server-traffic.html">
+ Optimizing Server-Initiated Network Use</a></strong>
+ </dt>
+ <dd>
+ Learn how to optimize your app's requests for network resources and to reduce
+ power consumption.
+ </dd>
+
+ <dt>
+ <strong><a href="action-any-traffic.html">
+ Optimizing General Network Use</a></strong>
+ </dt>
+ <dd>
+ Learn how to optimize your app's requests for network resources and to reduce
+ power consumption.
+ </dd>
+
+</dl>
\ No newline at end of file
diff --git a/docs/html/training/app/index.jd b/docs/html/training/app/index.jd
index 2675a78..d9feb57 100644
--- a/docs/html/training/app/index.jd
+++ b/docs/html/training/app/index.jd
@@ -1,4 +1,110 @@
+fullpage=true
page.title=Android Performance Patterns
-page.tags=app
-
+page.viewport_width=970
+meta.tags="android, performance", "app",
+page.tags="app"
+section.landing=true
+header.hide=1
+carousel=1
+tabbedList=1
+excludeFromSuggestions=true
@jd:body
+
+
+<section class="dac-expand dac-hero dac-section-light">
+ <div class="wrap">
+ <div class="cols dac-hero-content">
+ <div class="col-1of2 col-push-1of2 dac-hero-figure">
+ <img class="dac-hero-image" src="{@docRoot}images/training/app/madscientist.png" />
+ </div>
+ <div class="col-1of2 col-pull-1of2">
+ <h1 class="dac-hero-title">Android Performance Patterns</h1>
+ <p class="dac-hero-description">
+ Everything you need to know about improving your app’s performance. </p>
+ </p>
+ <a class="dac-hero-cta" href="{@docRoot}training/app/approach.html">
+ <span class="dac-sprite dac-auto-chevron"></span>
+ Test you app's performance
+ </a><br>
+ <a class="dac-hero-cta" href="{@docRoot}training/app/rendering/index.html">
+ <span class="dac-sprite dac-auto-chevron"></span>
+ Improve rendering performance
+ </a><br>
+ <a class="dac-hero-cta" href="{@docRoot}training/app/battery/index.html">
+ <span class="dac-sprite dac-auto-chevron"></span>
+ Improve battery utilization
+ </a><br>
+ </div>
+ </div>
+</section>
+
+
+<section class="dac-section dac-section-light">
+ <div class="wrap">
+
+
+ <p>This series of lessons teaches you how to improve the performance of your
+ Android applications using a workflow of gathering data, analyzing the data, and
+ taking action based on your insights.</p><br>
+
+
+ <h2>Performance actions</h2>
+
+ <dl>
+ <dt>
+ <strong><a href="{@docRoot}training/app/approach.html">
+ Test Your App's Performance</a></strong>
+ </dt>
+ <dd>
+ Learn how to test your app for performance problems. No tools required.<br>
+ Then find out how you can methodically address performance issues
+ following the Performance Improvement Lifecycle.
+ </dd>
+
+ <dt>
+ <strong><a href="{@docRoot}training/app/rendering/index.html">
+ Optimizing Rendering Performance</a></strong>
+ </dt>
+ <dd>
+ Learn how to improve the performance of everything related to drawing
+ and animating the screen. </a></strong>
+ </dd>
+ <dt>
+ <strong><a href="{@docRoot}training/app/battery/index.html">
+ Optimizing Battery Utilization</a></strong>
+ </dt>
+ <dd>
+ Learn how to efficiently use limited battery resources for
+ networking requests. </a></strong>
+ </dd>
+ </dl><br>
+
+ <h2>Resources</h2>
+
+ <dl>
+ <dt>
+ <strong><a href="https://plus.sandbox.google.com/communities/116342551728637785407">
+ Android Performance G+ Community</a></strong>
+ </dt>
+ <dd>
+ Join our G+ community for more information, tips and support. It's all about
+ Performance!
+ <br><b>#perfmatters</b>.
+ </dd>
+ <dt>
+ <strong><a href="https://www.udacity.com/course/android-performance--ud825">
+ Android Performance Course on Udacity</a></strong>
+ </dt>
+ <dd>
+ Dive deeply into Android Performance with this from-the-ground-up course.
+ </dd>
+ <dt>
+ <strong><a href="https://www.youtube.com/playlist?list=PLOU2XLYxmsIKEOXh5TwZEv89aofHzNCiu">Android
+ Performance Patterns on YouTube</a></strong>
+ </dt>
+ <dd>
+ Watch the whole series of Android Performance Patterns videos.
+ </dd>
+ </dl>
+ <br>
+ </div></section>
diff --git a/docs/html/training/app/rendering/hierarchies.jd b/docs/html/training/app/rendering/hierarchies.jd
new file mode 100644
index 0000000..2513425
--- /dev/null
+++ b/docs/html/training/app/rendering/hierarchies.jd
@@ -0,0 +1,296 @@
+page.title=Simplify Complex View Hierarchies
+meta.tags="android, performance", "app",
+page.tags="app"
+page.article=true
+@jd:body
+
+<style>
+ .app-icon {
+ height: 64px;
+ }
+</style>
+
+
+<p>At the heart of your app is the hierarchy of views that makes up the user interface and the
+ visual experience of users. With feature-rich apps, this hierarchy grows large and complex and
+ can become a source of performance problems. The most likely symptom you will see is a generic
+ general slowness of the app, especially when rendering complex views to the screen.</p>
+
+ <p>Simplifying or rearranging the view hierarchy of your app can improve performance, especially
+ on lower-end devices and earlier versions of Android. As an added benefit, your app will become
+ easier to maintain overall.</p>
+
+ <p>Analyzing the view hierarchy is an example of using several tools together to pinpoint and fix
+ performance problems. It is also an example of eliminating another inefficiency first, so that
+ your data becomes more precise.</p>
+
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_gather.png">
+ Analyze the view hierarchy</h2>
+
+ <p>If you have not done so already, reduce overdraw by removing unnecessary backgrounds. This
+ will remove a common source of overdraw that is not related to your view hierarchy. See
+ <a href="{@docRoot}training/app/rendering/overdraw.html">
+ Visualizing and Reducing Overdraw</a>.</p>
+
+ <ol>
+ <li><b>Run the Show GPU View Updates tool</b> on your mobile device. In <b>Developer
+ Options</b>, scroll to <b>Hardware accelerated rendering</b> and turn on <b>Show GPU view
+ updates</b>.</li>
+
+ <li>Interact with your app.</li>
+
+ <li>Views on the screen that are updated will flash red. If you
+ notice that parts of your screen are flashing, and they have nothing to do with the area that's
+ being updated, there may be a connection in the view hierarchy that's causing them to be
+ invalidated improperly. As such, you can focus your efforts on these areas to find problems
+ faster.</li>
+
+ <li><b>Run the
+ <a href="{@docRoot}tools/performance/profile-gpu-rendering/index.html">
+ Profile GPU Rendering tool</a>
+ and look at the blue segments of
+ the bars.</b> If the blue segments are tall and causing the bars to cross the 16
+ milliseconds-per-frame line,
+ your app spends a lot of time updating display lists. The M release of Android adds additional
+ color segments, and the Measure/Layout segment may also be larger than expected. One reason for
+ this can be view hierarchies that are unnecessarily complex. See also
+ <a href="{@docRoot}training/app/rendering/profile-gpu.html">
+ Improving GPU Rendering Performance</a>.</li>
+
+ <li><b>Start the
+ <a href="{@docRoot}tools/performance/hierarchy-viewer/index.html">
+ Hierarchy Viewer tool</a>.</b></li>
+
+ <li>Find the areas of the view hierarchy where you still see a lot of overdraw in your app.
+ Consider whether restructuring your views could reduce overdraw.</li>
+
+ <li>Identify areas where your view hierarchy is complex, and consider how you could simplify
+ it.</li>
+
+ <li>Profile the view hierarchy from Hierarchy Viewer to confirm or identify additional
+ potential problem spots. See
+ <a href="{@docRoot}tools/performance/hierarchy-viewer/profiling.html">
+ Profiling with Hierarchy Viewer</a>.</li>
+ </ul>
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_insight.png">
+ Possible optimizations</h2>
+
+ <p>Hierarchy Viewer can help identify these specific issues that are directly related to the
+ structure of the view hierarchy.</p>
+
+ <ul>
+ <li>Views that do not contribute to the final image. See
+ <a href="#remove">Remove extraneous views</a>
+ .</li>
+
+ <li>Deep view hierarchies of nested views. Jump to
+ <a href="#nested">Simplify nested layouts</a>
+ .</li>
+
+ <li>Large number of simple views. Check out
+ <a href="#reduce">Reduce the number of views</a>
+ .</li>
+
+ <li>Nested layouts that trigger multiple layout passes. Got to
+ <a href="#flatten"> Flatten the view hierarchy</a>
+ .</li>
+ </ul>
+
+ <p>Minimizing these issues can improve performance, especially on older devices. For your own
+ benefit, these simplifications will make your code easier to maintain and profile in the
+ future.</p>
+
+<h2 id="remove"><img class="app-icon" src="{@docRoot}images/training/app/app_icon_action.png">
+ Remove extraneous views</h2>
+
+ <p>Remove views that do not contribute to the final image.<p>
+
+ <p>To identify views that do not contribute to the final image on the screen:</p>
+
+ <ol>
+ <li>In Hierarchy Viewer, walk through the hierarchy starting from the leaves towards the
+ root.</li>
+
+ <li>Click each node to see how the screen looks at that node. Alternatively, look at the Layout
+ View window to see how views are layering themselves.</li>
+
+ <li>If a view that was previously visible becomes fully hidden, then you may not need that view
+ at all, as shown in Figure 1.</li>
+ </ol>
+
+ <div>
+ <img src="{@docRoot}images/training/app/remove_hidden_views.png"
+ alt=""
+ height="" />
+ <p class="img-caption">
+ <strong>Figure 1. </strong>Views 2 and 3 are fully obscured and can be safely removed.
+ </p>
+ </div>
+
+ <p>Eliminate from your code the views that are completely covered, never displayed, or outside
+ the screen.</p>
+
+<h2 id="nested"><img class="app-icon" src="{@docRoot}images/training/app/app_icon_action.png">
+ Simplify nested layouts</h2>
+
+ <p>Simplify nested layouts that trigger multiple layout passes.</p>
+
+ <p>Some layout containers, such a RelativeLayout, require two layout passes in order to finalize
+ the positions of their child views. As a result, their children also require two layout passes.
+ When you nest these types of layout containers, the number of layout passes increases
+ exponentially with each level of the hierarchy.</p>
+
+ <p>For example, a view inside a grid view inside a list view inside a relative layout could get
+ laid out 8 times(!) as shown in Figure 2.</p>
+
+ <div>
+ <img src="{@docRoot}images/training/app/layout_pass_multiplication.png"
+ alt=""
+ height="" />
+ <p class="img-caption">
+ <strong>Figure 2. </strong>Example of layout pass multiplication.
+ </p>
+ </div>
+
+ <p><b>Watch out for the following containers and conditions:</b></p>
+
+ <ul>
+ <li><a href="http://developer.android.com/reference/android/widget/RelativeLayout.html">
+ RelativeLayout</a></li>
+
+ <li><a href="http://developer.android.com/reference/android/widget/LinearLayout.html">
+ LinearLayouts</a>
+ that also use the <code>measureWithLargestChild</code> layout weight</li>
+
+ <li><a href="http://developer.android.com/reference/android/widget/GridView.html">
+ GridViews</a> that also use gravity.</li>
+
+ <li>Custom containers that are subclasses of the above.</li>
+
+ <li>Some uses of weights in layouts can also trigger multiple layout passes.</li>
+ </ul>
+
+ <p><b>Using any of these containers as</b></p>
+
+ <ul>
+ <li>the root of a complex view hierarchy,</li>
+
+ <li>the parent of a deep subtree,</li>
+
+ <li>or using many of them in your layout,</li>
+ </ul>
+
+ <p>can result in noticeable performance penalties.</p>
+
+ <p>For more information, see
+ <a href="https://www.youtube.com/watch?v=dB3_vgS-Uqo">Double Layout Taxation</a>.</p>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/dB3_vgS-Uqo?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float:none; margin: 0 0 20px 20px;"></iframe>
+
+
+ <p>Consider whether you can achieve the same layout using a container configuration that does not
+ result in these exponential numbers of layout passes. For example:</p>
+
+ <ul>
+ <li>Replace a RelativeLayout with a GridView (without gravity) as your root view.</li>
+ </ul>
+
+ <p>In addition, you can apply all the techniques mentioned in this document to simplify the view
+ hierarchy.</p>
+
+ <ul>
+ <li>Reduce the number of layouts by eliminating or combining views. See
+ <a href="#remove">
+ Remove Views that do not Contribute to the Final Image</a>
+ and
+ <a href="#reduce">
+ Reduce the Number of Views</a>.
+ </li>
+
+ <li>Eliminate overlapping views where possible.</li>
+
+ <li>Flatten the view hierarchy by choosing different layouts. See
+ <a href="#flatten">Flatten the View Hierarchy</a>
+ </li>
+
+ <li>Redesign your app's user interface to use fewer views.</li>
+ </ul>
+
+
+ <p>For more tips, see
+ <a href="http://developer.android.com/training/improving-layouts/optimizing-layout.html">
+ Optimizing Layout Hierarchies</a>.</p>
+
+
+
+<h2 id="reduce"><img class="app-icon" src="{@docRoot}images/training/app/app_icon_action.png">
+ Reduce the number of views</h2>
+
+ <p>If your user interface has many simple views, you may be able to combine some of them without
+ diminishing the user experience, as shown in Figure 3.</p>
+
+
+<div>
+ <img src="{@docRoot}images/training/app/combine_views.png"
+ alt=""
+ height="" />
+ <p class="img-caption">
+ <strong>Figure 3. </strong>Example of combining views.
+ </p>
+ </div>
+
+ <p>Both the changes below may affect how you present information to the user and will include
+ design trade-offs. Remember that performance is more important than anything else for your
+ app's success, and opt for simplicity wherever you can.</p>
+
+ <ul>
+ <li>Reduce the number of views by combining them into fewer views. For example, you can combine
+ text views if you reduce the number of fonts and styles.</li>
+
+ <li>Redesign your app's user interface to use fewer views.</li>
+ </ul>
+
+
+
+<h2 id="flatten"><img class="app-icon" src="{@docRoot}images/training/app/app_icon_action.png">
+ Flatten the view hierarchy</h2>
+
+ <p>Does your view hierarchy have parts that look like the nested arrangement on the left of
+ Figure 4?</p>
+
+<div>
+ <img src="{@docRoot}images/training/app/flatten_view_hierarchy.png"
+ alt=""
+ height="" />
+ <p class="img-caption">
+ <strong>Figure 4. </strong>This deep view hierarchy can be flattened to improve performance.
+ </p>
+ </div>
+
+ <p>Flatten the view hierarchy by replacing nested linear layouts with relative layouts wherever
+ possible. See
+ <a href="http://developer.android.com/training/improving-layouts/optimizing-layout.html">
+ Optimizing Layout Hierarchies</a>.</p>
+
+
+
+<h2>Example of simplifying a view hierarchy</h2>
+
+ <p>Watch a screencast which shows how to apply all these techniques to simplify a view
+ hierarchy. See
+ <a href="https://www.youtube.com/watch?v=-FUw8HMbmBQ&">
+ Optimizing Layouts with Hierarchy Viewer</a>.</p>
+
+<h2>Advanced analysis</h2>
+
+ <p>Use the
+ <a href="http://developer.android.com/tools/debugging/improving-w-lint.html">Lint tool</a>
+ on your layout files to search for possible view hierarchy optimizations. See
+ <a href="http://developer.android.com/training/improving-layouts/optimizing-layout.html#Lint">
+ Optimizing Layout Hierarchies: Use Lint</a>.</p>
+
diff --git a/docs/html/training/app/rendering/index.jd b/docs/html/training/app/rendering/index.jd
index 733131e..19d274b 100644
--- a/docs/html/training/app/rendering/index.jd
+++ b/docs/html/training/app/rendering/index.jd
@@ -1,4 +1,92 @@
-page.title=Optimizing Rendering Performance
+page.title=Rendering Performance
page.tags=render
-
+page.article=true
@jd:body
+
+<p>The most common performance problems are related to how your app draws, and how that
+ eventually appears on the user's screen.</p>
+
+ <p><b>Finding rendering problems</b> is an iterative process of using hands-on testing to
+ identify problem spots, harness tools to discover the underlying cause, and improve your code.
+ See also <a href="{@docRoot}/training/app/approach.html">
+ Test Your App's Performance</a>.</p>
+
+ <p><b>Optimizing rendering performance</b> means to remove unnecessary work, simplify structures
+ and processes, manage bitmaps properly, and be mindful of the natural constraints imposed by the
+ hardware and the Android system.</p>
+
+ <p><b>The result of great rendering performance</b> is instantly INVISIBLE to your users. That
+ is, your app runs so fast and smoothly, that users fully focus on their task, not on your
+ app's UI and performance.</p>
+
+ <p>You can test for and improve common rendering problems by using the tools and strategies
+ recommended in this course.</p>
+
+ <h2>Lessons</h2>
+
+ <dl>
+ <dt>
+ <strong><a href="{@docRoot}training/app/rendering/overdraw.html">
+ Visualizing and Reducing Overdraw</a></strong>
+ </dt>
+ <dd>
+ Every time your app draws a pixel on the screen, it takes time. Learn how to
+ find and fix performance problems related to drawing the same pixel more than once
+ per screen.
+ </dd>
+ <dt>
+ <strong><a href="{@docRoot}training/app/rendering/profile-gpu.html">
+ Improving GPU Rendering Performance</a></strong>
+ </dt>
+ <dd>
+ The most common issues that can make your app slow are related to the process of
+ drawing on the screen. Learn how to find and fix issues that keep your app from
+ rendering smoothly.
+ </dd>
+ <dt>
+ <strong><a href="{@docRoot}training/app/rendering/hierarchies.html">
+ Simplifying Complex View Hierarchies</a></strong>
+ </dt>
+ <dd>
+ With feature-rich apps, the view hierarchy can grow large and complex and become a
+ source of performance problems. Learn how to examine and simplify you app's view
+ hierarchy.
+ </dd>
+ <dt>
+ <strong><a href="{@docRoot}training/app/rendering/rendering-checklist.html">
+ Rendering Problems Checklist</a></strong>
+ </dt>
+ <dd>
+ There are many issues that can affect the rendering performance of your app. Learn
+ how to diagnose and fix the most common ones.
+ </dd>
+ </dl>
+
+
+ <h2>Resources</h2>
+
+ <dl>
+ <dt>
+ <strong><a href="https://plus.sandbox.google.com/communities/116342551728637785407">
+ Android Performance G+ Community</a></strong>
+ </dt>
+ <dd>
+ Join our G+ community for more information, tips, and support. It's all about
+ Performance!
+ <br>#perfmatters.
+ </dd>
+ <dt>
+ <strong><a href="https://www.udacity.com/course/android-performance--ud825">
+ Android Performance Course on Udacity</a></li></strong>
+ </dt>
+ <dd>
+ Dive deeply into Android Performance with this from-the-ground-up course.
+ </dd>
+ <dt>
+ <strong><a href="https://www.youtube.com/playlist?list=PLOU2XLYxmsIKEOXh5TwZEv89aofHzNCiu">Android
+ Performance Patterns on YouTube</a></strong>
+ </dt>
+ <dd>
+ Watch the whole series of Android Performance Patterns videos.
+ </dd>
+ </dl>
\ No newline at end of file
diff --git a/docs/html/training/app/rendering/overdraw.jd b/docs/html/training/app/rendering/overdraw.jd
new file mode 100644
index 0000000..cdc237f
--- /dev/null
+++ b/docs/html/training/app/rendering/overdraw.jd
@@ -0,0 +1,159 @@
+page.title=Visualize and Reduce Overdraw
+page.tags=render
+page.article=true
+@jd:body
+
+<style>
+ .app-icon {
+ height: 64px;
+ }
+</style>
+
+ <p>Every time your app draws a pixel on the screen, it takes time. Every time your app draws a
+ pixel that has already been drawn, it wastes time. Drawing a pixel more than once per screen
+ refresh is called <i>o</i><i>verdraw</i>, and it's a common problem affecting
+ the performance of modern applications. To be efficient, every time your app refreshes the
+ screen, it should draw every changed pixel only once.</p>
+
+ <p>For example, an app might draw a stack of 52 overlapping cards, with only the last card fully
+ visible. Completely drawing the 51 cards that are underneath and partially covered, is an example
+ of overdraw.</p>
+
+<div class="figure" style="float:none">
+ <img src="{@docRoot}images/training/app/stacked_cards.png"
+ alt=""
+ height="" />
+ <p class="img-caption">
+ <strong>Figure 1. </strong>Example of card stack with potential overdraw.
+ </p>
+ </div>
+
+ <p>Watch the
+ <a href="https://www.youtube.com/watch?v=T52v50r-JfE">Understanding Overdraw</a>
+ video
+ for a detailed introduction, and see the rest of this page for more on finding and fixing
+ overdraw.</p>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/T52v50r-JfE?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float:none; margin: 0 0 20px 20px;"></iframe>
+
+ <p class="note"><b>Note:</b> Reducing overdraw can save significant GPU resources and greatly
+ decrease the time it takes to draw a frame. Reducing overdraw may have a significant impact, if it
+ is the biggest performance issue your app has; or it may have no noticeable impact, if you are on
+ a fast device, or if your app has other, much bigger performance issues.</p>
+
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_gather.png">
+ Test for overdraw</h2>
+
+ <p>You can visualize overdraw using color tinting on your device with the
+ <a href="{@docRoot}tools/performance/debug-gpu-overdraw/index.html">Debug GPU Overdraw tool</a>.
+ </p>
+
+ <p>To turn on Debug GPU Overdraw on your mobile device:</p>
+
+ <ol>
+ <li>Open <b>Settings.</b></li>
+
+ <li>Tap <b>Developer Options</b>.</li>
+
+ <li>In the <i>Hardware accelerated rendering</i> section, select <b>Debug GPU
+ Overdraw</b>.</li>
+
+ <li>In the Debug GPU overdraw popup, select <b>Show overdraw areas</b>.</li>
+ </ol>
+
+ <p>See
+ <a href="{@docRoot}tools/performance/debug-gpu-overdraw/index.html">Debug GPU Overdraw</a>
+ for a full tutorial, or try the <a href=
+ "https://io2015codelabs.appspot.com/codelabs/android-performance-debug-gpu-overdraw#1">Debug
+ GPU Overdraw Codelab</a>.</p>
+
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_insight.png">
+ Interpret the Debug GPU Overdraw output</h2>
+
+ <p>As a general rule, if at any given point your app is drawing something that the user does not
+ see, don't draw it. More specifically, Debug GPU Overdraw highlights can guide
+ you to the following issues:</p>
+
+ <ul>
+ <li><b>Unnecessary backgrounds.</b> See
+ <a href="#backgrounds">Eliminate unnecessary backgrounds</a>.</li>
+
+ <li><b>Areas of the screen that have not changed are drawn.</b> See
+ <a href="#clip">Clip generously</a>.</li>
+
+ <li><b>Complex or poorly organized view hierarchy.</b> See
+ <a href="{@docRoot}training/app/rendering/hierarchies.html">
+ Simplifying Complex View Hierarchies</a>.</li>
+ </ul>
+
+
+<h2 id="backgrounds"><img class="app-icon" src="{@docRoot}images/training/app/app_icon_action.png">
+ Eliminate unnecessary backgrounds</h2>
+
+ <p>Search your code for <code>android:background</code>, and for each
+ background, determine whether it's needed and visible on the screen.</p>
+
+ <p>Removing unnecessary backgrounds is a quick way of improving rendering performance. An
+ unnecessary background may never visible, because it's completely covered by
+ everything else the app is drawing in that view. For example, a parent's default
+ background that is overdrawn by the children's custom backgrounds.</p>
+
+ <p>You can remove backgrounds by removing the <code>android:background</code>? line of code in an view.</p>
+
+ <p><b>Before:</b></p>
+
+<pre>
+ <FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
+ xmlns:tools="http://schemas.android.com/tools"
+ android:id="@+id/activity_chatum_latinum_container"
+ android:layout_width="match_parent"
+ android:layout_height="match_parent"
+ android:background="@android:color/white" <===== Background
+ tools:context=".MainActivity"
+ tools:ignore="MergeRootFrame" />
+</pre>
+
+ <p><b>After:</b></p>
+
+ <pre>
+ <FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
+ xmlns:tools="http://schemas.android.com/tools"
+ android:id="@+id/activity_chatum_latinum_container"
+ android:layout_width="match_parent"
+ android:layout_height="match_parent"
+ tools:context=".MainActivity"
+ tools:ignore="MergeRootFrame" />
+</pre>
+
+
+<h2 id="clip"><img class="app-icon" src="{@docRoot}images/training/app/app_icon_action.png">
+ Clip generously</h2>
+
+ <p>Find areas that are drawn unnecessarily and clip generously.</p>
+
+ <p>When you are using custom views, you may be redrawing areas of the screen that have not
+ changed.</p>
+
+ <p>For each update, even if only a portion of a custom view has changed, the entire view must be
+ rebuilt. This is most common for views that use Canvas for drawing. For example, if you draw a
+ small circle in a corner of the view, the whole view gets rebuilt.</p>
+
+ <p>The Android system does to a good job at culling views that are 100% invisible or overlapped
+ by another view, but cannot eliminate more complex views, for example those that include
+ text transparency or rounded corners.</p>
+
+ <p>Before you draw a custom view, test whether it's visible at all. If it is
+ visible, only draw the portions that the user sees.</p>
+
+ <p>See <a href="https://www.youtube.com/watch?v=vkTn3Ule4Ps">
+ Overdraw, ClipRect, QuickReject</a>.</p>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/vkTn3Ule4Ps?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float:none; margin: 0 0 20px 20px;"></iframe>
diff --git a/docs/html/training/app/rendering/profile-gpu.jd b/docs/html/training/app/rendering/profile-gpu.jd
new file mode 100644
index 0000000..56a65fb
--- /dev/null
+++ b/docs/html/training/app/rendering/profile-gpu.jd
@@ -0,0 +1,356 @@
+page.title=Improve GPU Rendering Performance
+meta.tags="android, performance", "app"
+page.tags="app"
+page.article=true
+@jd:body
+
+<style>
+ .app-icon {
+ height: 64px;
+ }
+</style>
+
+
+<p>The most common issues that can make your app slow are related to the process of drawing on
+ the screen. Android provides the
+ <a href="{@docRoot}tools/performance/profile-gpu-rendering/index.html">Profile GPU Rendering</a>
+ tool on your
+ device to analyze the rendering performance of your app. The Profile GPU Rendering tool draws a
+ graph on the screen to show the rendering performance of each window.</p>
+
+ <p>This page introduces how to use the Profile GPU Rendering tool and interpret its graphs, and,
+ depending on your findings, suggests what to try next to optimize your app's
+ performance.</p>
+
+ <p>For a quick overview of the tool and how to use it, watch the embedded
+ <a href="https://www.youtube.com/watch?v=VzYkVL1n4M8">Profile GPU Rendering</a> video.
+ Then profile your app and analyze the results following the steps
+ below.</p>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/VzYkVL1n4M8?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float: none; margin: 0 0 20px 20px;"></iframe>
+
+
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_gather.png">
+ Graph the rendering performance of your app</h2>
+
+ <p>Turn on Profile GPU Rendering:</p>
+
+ <ol>
+ <li>On your mobile device, go to <b>Settings ></b> <b>Developer Options</b>.</li>
+
+ <li>In the <i>Monitoring</i> section, select <b>Profile GPU Rendering</b>.</li>
+
+ <li>In the Profile GPU Rendering popup, choose <b>On screen as bars</b> to overlay the graphs
+ on the screen of your mobile device.</li>
+
+ <li>Run your app and interact with it to see the graph grow and change.</li>
+ </ol>
+
+ <p>You are going to see a chart of multi-colored bars on your screen, similar to Figure 1. Each
+ vertical bar represents one frame of rendering for that activity, that is, one redrawing of the
+ window on the screen.</p>
+
+ <div>
+ <img src="{@docRoot}images/training/app/profile_gpu_rendering_annotated_graph.png"
+ alt=""
+ height="" />
+ <p class="img-caption">
+ <strong>Figure 1. </strong>Profile GPU Rendering graph.
+ </p>
+ </div>
+
+ <p>The height and coloring of a bar, as shown in Figure 1, indicate how fast each frame was
+ created, and how much time different phases of the rendering process required.</p>
+
+ <p>The green line marks 16 milliseconds. If a bar crosses that line, it took more than 16
+ milliseconds to create and draw that window on the screen. If this happens often, or if any bars
+ cross the line by a lot, users can probably notice a delay or stutter while using the app.</p>
+
+
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_insight.png">
+ Interpret the Profile GPU Rendering graph</h2>
+
+ <p>Look at the colored segments of the bars that cross the green 16 millisecond line, in
+ particular any segments that are much taller than their neighbors.</p>
+
+ <p>If you see that</p>
+
+ <ul>
+ <li><b>blue Update</b> segments are tall, updating views in the CPU takes too long. Jump to
+ <a href="#blue">Speed up view updating</a>.</li>
+
+ <li><b>purple Transfer</b> segments are tall, transferring resources from the CPU to the GPU is
+ too slow. See <a href="#purple">
+ Transfer less data</a>.</li>
+
+ <li><b>red Execute</b> segments are tall, submitting commands to the GPU takes too long. Go to
+ <a href="#red">Reduce the number of commands</a>.</li>
+
+ <li><b>orange Process</b> segments are tall, the CPU is waiting for the GPU. Read
+ <a href="#orange">Give less work to the GPU</a>.</li>
+ </ul>
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_insight.png">
+ Advanced Analysis</h2>
+
+ <p>To improve the performance of your app, you may need to take one, some, or all of the actions
+ on this page. You may need to use more additional tools or investigate other sources of performance
+ issues.</p>
+
+ <p>For example:</p>
+
+ <ul>
+ <li>Run the
+ <a href="{@docRoot}tools/performance/systrace/index.html">Systrace</a> tool
+ to log specific app execution data over time and find
+ performance bottlenecks.</li>
+
+ <li>Gather more granular data about how your app draws on a frame-by-frame basis, with the
+ <a href="https://source.android.com/devices/tech/debug/dumpsys.html">dympsys tool</a>.
+ Run
+ <a href="https://developer.android.com/preview/testing/performance.html">
+ adb shell dumpsys gfxinfo framestats</a> (version M or later).</li>
+
+ <li>Your app may be stuttering because it is doing too much work in the UI thread (version L or
+ later). Use
+ <a href="{@docRoot}tools/performance/traceview/index.html">Traceview</a>
+ to log method execution over time, and examine thread
+ timelines and call stacks.</li>
+ </ul>
+
+
+<h2 id="blue"><img class="app-icon" src="{@docRoot}images/training/app/app_icon_insight.png">
+ Blue: Updating views takes too long</h2>
+
+ <p>The blue Update segment of the bar represents the time used by the CPU to create and update
+ all the views for this rendering of the screen. This is part of a processing sequence called the
+ invalidation pipeline. To learn more about the invalidation pipeline, see
+ <a href="https://www.youtube.com/watch?v=we6poP0kw6E">Views, Invalidations, and Performance</a>
+ and <a href="https://www.youtube.com/watch?v=dB3_vgS-Uqo">Double Layout Taxation</a>.</p>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/we6poP0kw6E?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float: none; margin: 0 0 20px 20px;"></iframe>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/dB3_vgS-Uqo?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float: none; margin: 0 0 20px 20px;"></iframe>
+
+ <p>If this blue bar segment is tall, it can indicate that your app does too much work creating
+ and updating views, or is updating too many views or views that are too complex.</p>
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_action.png">
+ Blue: Speed up view updating</h2>
+
+ <p><b>Reduce overdraw.</b></p>
+
+ <ul>
+ <li>Use the
+ <a href="{@docRoot}tools/performance/debug-gpu-overdraw/index.html">Debug GPU Overdraw tool</a>
+ and optimize areas that appear red in the tool.
+ See <a href="{@docRoot}training/app/rendering/overdraw.html">
+ Visualizing and Reducing Overdraw</a>.</li>
+ </ul>
+
+ <p><b>Simplify complex view hierarchies.</b></p>
+
+ <ul>
+ <li>Use the
+ <a href="{@docRoot}tools/performance/hierarchy-viewer/index.html">Hierarchy Viewer tool</a>
+ to analyze and profile your app's
+ view hierarchy, and simplify complex views.
+ See <a href="{@docRoot}training/app/rendering/hierarchies.html">
+ Simplifying Complex View Hierarchies</a>.</li>
+ </ul>
+
+ <p><b>Optimize onDraw() for custom views.</b></p>
+
+ <ul>
+ <li>If you are using custom views, investigate your onDraw() methods. Doing large amounts of
+ work in onDraw() can slow down the Update phase of the rendering process. Move anything not
+ directly related to drawing outside of the onDraw() method, perhaps even into a separate
+ thread.</li>
+
+ <li>Don't paint large bitmaps in your onDraw() method. See
+ <a href="https://developer.android.com/training/displaying-bitmaps/index.html">
+ Displaying Bitmaps Efficiently</a>.</li>
+
+ <li>Calculate anything that you can ahead of time (not in onDraw()). See
+ <a href="http://developer.android.com/training/custom-views/optimizing-view.html">Optimizing the View</a>.</li>
+ </ul>
+
+
+
+<h2 id="purple"><img class="app-icon" src="{@docRoot}images/training/app/app_icon_insight.png">
+ Purple: Transferring resources is too slow</h2>
+
+ <p>The purple segment of the bar represents the time the GPU Driver spent transferring resources
+ from the CPU to the GPU. Moving a significant amount of data between processors takes time, and
+ the larger the data to be moved, the longer the delay in execution.
+ See <a href="https://www.youtube.com/watch?v=zVK6TKSx1lU">CPU, GPU, and your Android</a>.</p>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/zVK6TKSx1lU?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float: none; margin: 0 0 20px 20px;"></iframe>
+
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_action.png">
+ Purple: Reduce bitmap sizes</h2>
+
+ <ul>
+ <li>Use the smallest bitmap dimensions possible by resizing and pre-scaling bitmaps. See
+ <a href="https://www.youtube.com/watch?v=HY9aaXHx8yA">Reusing Bitmaps</a>
+ and this <a href="https://www.youtube.com/watch?v=12cB7gnL6po">Bitmap Scaling code example</a>.</li>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/HY9aaXHx8yA?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float: none; margin: 0 0 20px 20px;"></iframe>
+
+ <li>Use a different, smaller pixel format.
+ See <a href="https://www.youtube.com/watch?v=1WqcEHXRWpM">Smaller Pixel Formats</a>.</li>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/1WqcEHXRWpM?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float: none; margin: 0 0 20px 20px;"></iframe>
+
+ <li>Optimize your app's UI objects. Reduce overdraw, reuse UI
+ elements, prefer standard over custom resources, be frugal with fonts, and control alpha
+ rendering.
+ See also <a href="https://www.youtube.com/watch?v=wIy8g8yNhNk">
+ The Hidden Cost of Transparency</a>.</li>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/wIy8g8yNhNk?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float: none; margin: 0 0 20px 20px;"></iframe>
+
+ </ul>
+
+
+
+
+<h2 id="red"><img class="app-icon" src="{@docRoot}images/training/app/app_icon_insight.png">
+ Red: Submitting commands to the GPU is too slow</h2>
+
+ <p>The red segment of the bar represents the time spent by Android's 2D renderer issuing commands
+ to OpenGL to draw and redraw display lists. The height of the red bar is proportional to how much
+ time was spent submitting commands to the GPU for the total of all views that need to be redrawn.
+ Display lists that do more complex operations contribute more time to the overall size of the red
+ bar. The size of the red bar is an indicator of the <i>complexity</i> of the display
+ lists' operations. The <i>number</i> of display lists does not directly
+ correlate to the size of the red bar.</p>
+
+ <ul>
+ <li>Learn more about how the CPU creates and submits commands to the GPU, and how the GPU
+ Driver can become a bottleneck in your app's rendering pipeline. Watch <a href=
+ "https://www.youtube.com/watch?v=zVK6TKSx1lU">CPU, GPU, and your Android</a>.</li>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/zVK6TKSx1lU?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float:none; margin: 0 0 20px 20px;"></iframe>
+
+
+ <li>Find out when Views get invalidated, how that affects performance, and how to reduce this
+ performance problem. Check out <a href=
+ "https://www.youtube.com/watch?v=we6poP0kw6E">Views, Invalidations, and Performance</a>.</li>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/we6poP0kw6E?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float:none; margin: 0 0 20px 20px;"></iframe>
+
+
+ <li>Under some conditions, views get laid out multiple times, which can be a significant
+ performance hit for large view hierarchies. Learn more by watching <a href=
+ "https://www.youtube.com/watch?v=dB3_vgS-Uqo">Double Layout
+ Taxation</a>.</li>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/dB3_vgS-Uqo=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float:none; margin: 0 0 20px 20px;"></iframe>
+
+</ul>
+
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_action.png">
+ Red: Reduce the number of commands</h2>
+ <p><b>Reduce overdraw.</b></p>
+
+ <ul>
+ <li>Run the
+ <a href="{@docRoot}tools/performance/debug-gpu-overdraw/index.html">Debug GPU Overdraw tool</a>
+ to show which view objects are doing
+ unnecessary redrawing. See also
+ <a href="{@docRoot}training/app/rendering/overdraw.html">
+ Visualizing and Reducing Overdraw</a>.</li>
+ </ul>
+
+ <p><b>Limit alpha blending.</b></p>
+
+ <ul>
+ <li>Look for transparent views doing alpha blending. See <a href=
+ "https://www.youtube.com/watch?v=wIy8g8yNhNk">The Hidden Cost of Transparency</a>.</li>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/wIy8g8yNhNk?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float: none; margin: 0 0 20px 20px;"></iframe>
+ </ul>
+
+
+<h2 id="orange"><img class="app-icon" src="{@docRoot}images/training/app/app_icon_insight.png">
+ Orange: The CPU is waiting for the GPU</h2>
+
+ <p>The orange segment of the bar represents the length of time that the CPU is waiting for the
+ GPU to finish its work. After transferring data to the GPU, the CPU waits for the GPU to
+ acknowledge receipt. If this bar segment gets tall, it means the app is doing too much complex
+ work on the GPU, and the GPU is unable to keep up with the data flow from the CPU.</p>
+
+<h2><img class="app-icon" src="{@docRoot}images/training/app/app_icon_action.png">
+ Give less work to the GPU</h2>
+
+ <p><b>Simplify complex view hierarchies.</b></p>
+
+ <ul>
+ <li>Use the
+ <a href="{@docRoot}tools/performance/hierarchy-viewer/index.html">Hierarchy Viewer tool</a>
+ to see whether you can reduce the number
+ of views. See
+ <a href="{@docRoot}training/app/rendering/hierarchies.html">
+ Simplifying Complex View Hierarchies</a>.</li>
+ </ul>
+
+ <p><b>Optimize drawing.</b></p>
+
+ <ul>
+ <li>Reduce the number of calls to Canvas drawing methods by batching operations. Learn more
+ about <a href="https://www.youtube.com/watch?v=PEgkXFPcDTE">Batching</a>.</li>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/PEgkXFPcDTE?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float: none; margin: 0 0 20px 20px;"></iframe>
+
+ <li>Look at draw calls that include bitmap uploads (for pre-L versions), paths, or shadow work,
+ and simplify them. See
+ <a href="https://www.youtube.com/watch?v=wIy8g8yNhNk">The Hidden Cost of Transparency</a>.</li>
+
+ <iframe width="448" height="252"
+ src="//www.youtube.com/embed/wIy8g8yNhNk?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float: none; margin: 0 0 20px 20px;"></iframe>
+
+ </ul>
+
diff --git a/docs/html/training/app/rendering/rendering-checklist.jd b/docs/html/training/app/rendering/rendering-checklist.jd
new file mode 100644
index 0000000..6dc0eae
--- /dev/null
+++ b/docs/html/training/app/rendering/rendering-checklist.jd
@@ -0,0 +1,277 @@
+page.title=Rendering Problems Checklist
+page.tags=render
+page.article=true
+@jd:body
+
+<p>The following checklist summarizes common rendering problems and solutions.
+For each problem, learn how users are affected, how to diagnose, and how to
+approach fixing it. Use the linked resources for details on the suggested solutions.</p>
+
+<!----------------------------->
+
+ <h2>Excessive Overdraw</h2>
+
+ <p><b>What the user sees:</b><br>
+ The most likely symptom is a generic general slowness of screen
+ rendering, as well as stuttering animations.</p>
+
+ <p><b>Use this tool:</b><br>
+ <a href="{@docRoot}tools/performance/debug-gpu-overdraw/index.html">
+ Debug GPU Overdraw</a></p>
+
+ <p><b>What you see:</b><br>
+ Red-colored views indicate multiple layers of unnecessary drawing.</p>
+
+ <p><b>Problem:</b><br>
+ Your app redraws the same pixels multiple times, resulting in
+ overdraw.</p>
+
+ <p><b>Solution:</b><br>
+ If you are drawing pixels on the screen that the user never sees, you might
+ be able to improve drawing performance by removing unnecessary backgrounds, reorganizing views,
+ and applying clipping techniques to custom views.</p>
+
+ <p><b>Optimize your app:</b><br>
+ <a href="{@docRoot}training/app/rendering/overdraw.html">Reduce Overdraw</a>,
+ <a href="{@docRoot}training/app/rendering/hierarchies.html">Simplifying View Hierarchies</a>,
+ and
+ <a href="https://www.youtube.com/watch?v=vkTn3Ule4Ps">Apply Clipping</a>.</p>
+
+<!----------------------------->
+
+ <h2>View Hierarchies that are too complex</h2>
+
+ <p><b>What the user sees:</b><br>
+ The most likely symptom is a generic general slowness of the app,
+ especially when rendering complex views to the screen.</p>
+
+ <p><b>Use this tool:</b><br>
+ <a href="{@docRoot}tools/performance/hierarchy-viewer/index.html">Hierarchy Viewer</a></p>
+
+ <p><b>What you see:</b><br>
+ A view hierarchy that is deeper than wide, with a lot of nesting. When
+ you profile your view hierarchy, there are red dots in leaf nodes.
+ See <a href="{@docRoot}tools/performance/hierarchy-viewer/profiling.html">
+ Profiling with Hierarchy Viewer</a>.</p>
+
+ <p><b>Problem:</b><br>
+ The more complex and deep your view hierarchy, the more likely it is that a
+ simple change to a view can trigger multiple passes through large parts of this hierarchy to
+ recalculate the sizes, positions, and layout of affected views.</p>
+
+ <p><b>Solution:</b><br>
+ Flatten and simplify your view hierarchies. Try different layouts. Combine
+ views.</p>
+
+ <p><b>Optimize your app:</b><br>
+ <a href="{@docRoot}training/app/rendering/hierarchies.html">
+ Simplify Complex View Hierarchies</a>.</p>
+
+
+<!----------------------------->
+
+ <h2>Too many Invalidations</h2
+
+ <p><b>What the user sees:</b><br>
+ Slow response to user-initiated actions. Sluggish scrolling.</p>
+
+ <p><b>Use these tools:</b><br>
+ On your mobile device, in Developer Options, turn on
+ <a href="{@docRoot}tools/performance/profile-gpu-rendering/index.html">Profile GPU Rendering</a>
+ and GPU View Updates.</p>
+
+ <p><b>What you see:</b><br>
+ In Profile GPU Rendering, for bars that cross the 16 millisecond threshold, the
+ blue updated segment in particular may be large. The M release of Android adds additional color
+ segments, and the Measure/Layout segment may also be larger than expected.</p>
+
+ <p>In GPU View Updates, portions of the screen will flicker wildly in response to user
+ actions:</p>
+
+ <ul>
+ <li>One portion of the screen continues to flicker long after it has stopped changing visually
+ for the user.</li>
+
+ <li>Large portions of the screen flicker, even though only a small part is changing
+ visually.</li>
+ </ul>
+
+ <b>Problem:</b><br>
+ <p>Every time a view changes, the display lists are invalidated and have to be
+ recreated and executed.</p>
+
+ <b>Solution:</b><br>
+ <p>While it is impossible to avoid invalidations, minimizing how often they
+ happen, and how many views are affected, can improve your app's
+ performance.</p>
+
+ <b>Optimize your app:</b><br>
+ <p>Minimize view invalidations. See
+ <a href="https://www.youtube.com/watch?v=we6poP0kw6E">Views, Invalidations, and
+ Performance</a>
+ and <a href="https://www.youtube.com/watch?v=dB3_vgS-Uqo">Double Layout Taxation</a>.</p>
+
+
+<!----------------------------->
+
+ <h2>Multiple Layout Passes</h2>
+
+ <p><b>What the user sees:</b><br>
+ Slow response to user-initiated actions. Sluggish scrolling.</p>
+
+ <p><b>Use these tools:</b><br>
+ <a href="{@docRoot}tools/performance/hierarchy-viewer/index.html">Hierarchy Viewer</a>.
+ On your mobile device, in Developer
+ Options, turn on
+ <a href="{@docRoot}tools/performance/profile-gpu-rendering/index.html">Profile GPU Rendering</a>
+ and GPU View Updates.</p>
+
+ <p><b>What you see:</b><br>
+ In Profile GPU Rendering, for bars that cross the 16 millisecond threshold, the
+ blue segment in particular may be large. In GPU View Updates, large portions of the whole screen
+ will flicker wildly in response to user actions. In Hierarchy Viewer, look for red dots in the
+ measure and layout phases, especially on leaf nodes.</p>
+
+ <p><b>Problem:</b><br>
+ Changing the position or size of a view can trigger a cascade of calculations
+ throughout your view hierarchy to adjust neighboring and parent views.</p>
+
+ <p><b>Solution</b><br>
+ You might be able to improve rendering performance by rearranging or
+ simplifying your view hierarchy, or by using different layout containers.</p>
+
+ <p><b>Optimize your app:</b><br>
+ <href="{@docRoot}training/app/rendering/hierarchies.html">
+ Simplify Complex View Hierarchies</a>
+ and minimize view invalidations.
+ See <a href=
+ "https://www.youtube.com/watch?v=we6poP0kw6E">Views, Invalidations, and Performance</a>
+ and <a href="https://www.youtube.com/watch?v=dB3_vgS-Uqo">Double Layout Taxation</a>.</p>
+
+
+<!----------------------------->
+
+ <h2>Alpha Blending</h2>
+
+ <p><b>What the user sees:</b><br>
+ App slows down whenever views and animations use alpha
+ rendering.</p>
+
+ <p><b>Use this tool:</b><br>
+ <a href="{@docRoot}tools/performance/profile-gpu-rendering/index.html">Profile GPU Rendering</a>.
+ Also, in Developer options, turn on
+ Show Hardware Layers Updates. The screen will flash green for every hardware layer update. Note
+ that for pre-M (API level 22 and below), you have to use hardware layers explicitly (e.g.
+ mView.animate().alpha(0).withLayer().start()), while for API levels 23 and above, the system does
+ this for you automatically.</p>
+
+ <p><b>What you see:</b><br>
+ In the Profile GPU Rendering graph, orange bar segments may be tall,
+ because the CPU is waiting for the GPU to finish all this work. On our device, the screen will
+ flash green while your app slows down. See
+ <a href="http://www.curious-creature.com/2013/09/13/optimizing-hardware-layers/">
+ Optimizing Hardware Layers</a> for an example.</p>
+
+ <p><b>Problem:</b><br>
+ From a performance perspective, fade and transparency effects are expensive,
+ because you have to draw every pixel and possibly whole parts of your view hierarchy multiple
+ times.</p>
+
+ <p><b>Solution:</b><br>
+ You might be able to improve drawing performance by controlling how the
+ renderer uses hardware layers and by using alpha rendering sparingly.</p>
+
+ <p><b>Optimize your app:</b><br>
+ Eliminate non-critical alpha rendering and use hardware layers
+ effectively. Learn more on <a href=
+ "https://www.youtube.com/watch?v=wIy8g8yNhNk">The Hidden Cost of Transparency</a>
+ and <a href="http://developer.android.com/guide/topics/graphics/hardware-accel.html">
+ Hardware Acceleration</a></p>
+
+<!----------------------------->
+
+ <h2>Large Uncompressed Bitmaps</h2>
+
+ <p><b>What the user sees:</b><br>
+ Intermittent drops in frame rate, and crashes in the worst
+ case.</p>
+
+ <p><b>Use these tools:</b><br>
+ <a href="{@docRoot}tools/performance/memory-monitor/index.html">Memory Monitor</a>
+ and <a href="{@docRoot}tools/performance/heap-viewer/index.html">Heap Viewer</a>.</p>
+
+ <p><b>What you see:</b><br>
+ In Heap Viewer, look for large bitmap
+ objects. In Memory Monitor, you'll see an unhealthy number of garbage
+ collection events.</p>
+
+ <p><b>Problem:</b><br>
+ Once loaded, your app's bitmaps are uncompressed, which
+ not only uses up memory but also affects garbage collection.</p>
+
+ <p><b>Solution:</b><br>
+ You might be able to increase available memory, reduce garbage collection
+ overhead, and increase rendering performance by using smaller bitmap pixel formats.</p>
+
+ <p><b>Optimize your app:</b><br>
+ Consider Smaller Pixel Formats. See <a href=
+ "https://www.youtube.com/watch?v=1WqcEHXRWpM">Smaller Pixel Formats</a>.</p>
+
+ <!----------------------------->
+
+<h2>Dimension Bitmaps</h2>
+
+ <p><b>What the user sees:</b><br>
+ Intermittent drops in frame rate, and crashes in the worst
+ case.</p>
+
+ <p><b>Use these tools:</b><br>
+ <a href="{@docRoot}tools/performance/memory-monitor/index.html">Memory Monitor</a>
+ and <a href="{@docRoot}tools/performance/heap-viewer/index.html">Heap Viewer</a>.</p>
+
+ <p><b>What you see:</b><br>
+ In Heap Viewer, look for large bitmap objects. In Memory Monitor,
+ you'll see and unhealthy number of garbage collection events.</p>
+
+ <p><b>Problem:</b><br>
+ If the bitmaps your app is loading are larger than what is being displayed on
+ the screen, they unnecessarily use memory space.</p>
+
+ <p><b>Solution:</b><br>
+ You might be able to increase available memory and rendering performance be
+ pre-scaling your bitmaps.</p>
+
+ <p><b>Optimize your app:</b><br>
+ Use <a href="https://www.youtube.com/watch?v=HY9aaXHx8yA">Pre-scaled Bitmaps.</a></p>
+
+<!----------------------------->
+
+ <h2>Large Number of Bitmap Objects</h2>
+
+ <p><b>What the user sees:</b><br>
+ Intermittent drops in frame rate, and crashes in the worst
+ case.</p>
+
+ <p><b>Use these tools:</b><br>
+ <a href="{@docRoot}tools/performance/memory-monitor/index.html">Memory Monitor</a>
+ and
+ <a href="{@docRoot}tools/performance/allocation-tracker/index.html">Allocation Tracker</a>.</p>
+
+ <p><b>What you see:</b><br>
+ In Allocation Tracker, look for bitmap objects. In Memory Monitor, you
+ may see an unhealthy number of garbage collection events.</p>
+
+ <p><b>Problem:</b><br>
+ Your app is loading a stream of bitmaps that are each only used for a short
+ time.</p>
+
+ <p><b>Solution:</b><br>
+ You might be able to improve memory usage and rendering performance by using
+ object pools to reuse existing bitmap objects, and be reusing and caching bitmaps and
+ textures.</p>
+
+ <p><b>Optimize your app:</b><br>
+ <a href="https://www.youtube.com/watch?v=_ioFW3cyRV0>">Reuse Bitmaps</a>
+ and consider using <a href="https://www.youtube.com/watch?v=bSOREVMEFnM">Object Pools</a>.
+ Consider using the <a href="https://github.com/bumptech/glide">Glide Library</a>.
+
diff --git a/docs/html/training/training_toc.cs b/docs/html/training/training_toc.cs
index 85733bf..36a400e 100644
--- a/docs/html/training/training_toc.cs
+++ b/docs/html/training/training_toc.cs
@@ -1840,6 +1840,100 @@
</ul>
</li> <!-- end of Background Jobs -->
+
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>training/app/index.html">
+ <span class="small">Android Performance Patterns</span><br/>
+ </a>
+ </div>
+ <ul>
+
+ <li>
+ <a href="<?cs var:toroot ?>training/app/approach.html"
+ description=
+ "How to approach performance testing, analysis and making improvements to you app."
+ >Gather, Insight, Action</a>
+ </li>
+
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>training/app/rendering/index.html"
+ description=
+ "How to analyze app rendering performance and improve the speed and smoothness
+ of your user interface.">
+ Optimizing Rendering Performance</a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>training/app/rendering/overdraw.html">
+ Reducing Overdraw
+ </a>
+ </li>
+ <li><a href="<?cs var:toroot ?>training/app/rendering/profile-gpu.html">
+ Improving GPU Rendering Performance
+ </a>
+ </li>
+ <li><a href="<?cs var:toroot ?>training/app/rendering/hierarchies.html">
+ Simplifying Complex View Hierarchies
+ </a>
+ </li>
+ <li><a href="<?cs var:toroot ?>training/app/rendering/rendering-checklist.html">
+ Rendering Issues and Solutions Checklist
+ </a>
+ </li>
+ </ul>
+ </li><!-- end of Rendering Performance-->
+
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>training/app/battery/index.html"
+ description=
+ "How to analyze app battery use and reduce the power consumed by your app."
+ >Battery Performance</a>
+ </div>
+ <ul>
+
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>training/app/battery/network/index.html">
+ Reducing Network Battery Drain
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>training/app/battery/network/gather-data.html">
+ Collecting Network Traffic Data
+ </a>
+ </li>
+ <li><a href="<?cs var:toroot ?>training/app/battery/network/analyze-data.html">
+ Analyzing Network Traffic Data
+ </a>
+ </li>
+ <li><a href="<?cs var:toroot ?>training/app/battery/network/action-user-traffic.html">
+ Optimizing User-Initiated Network Use
+ </a>
+ </li>
+ <li><a href="<?cs var:toroot ?>training/app/battery/network/action-app-traffic.html">
+ Optimizing App-Initiated Network Use
+ </a>
+ </li>
+ <li><a href="<?cs var:toroot ?>training/app/battery/network/action-server-traffic.html">
+ Optimizing Server-Initiated Network Use
+ </a>
+ </li>
+ <li><a href="<?cs var:toroot ?>training/app/battery/network/action-any-traffic.html">
+ Optimizing General Network Use
+ </a>
+ </li>
+ </ul>
+ </li>
+
+ </ul>
+ </li> <!-- end of Battery Performance-->
+
+ </ul>
+ </li> <!-- end of APP -->
+
+
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>training/best-performance.html">
