This walkthrough shows the basic usage and workflow for the Allocation Tracker tool in Android
+ Studio. Allocation Tracker records an app's memory allocations and lists all
+ allocated objects for the profiling cycle with their call stack, size, and allocating code.
+
+ Allocation Tracker records each memory allocation that your app performs during the profiling
+ cycle. You tell Allocation Tracker to start recording and it logs allocations
+ until you tell it to stop.
+
+
+ The Battery Historian chart graphs power-relevant events over time.
+
+ Each row shows a colored bar segment when a system component is active
+ and thus drawing current from the battery. The chart does not show how much battery was used by the
+ component, only that the app was active. Charts are organized by category.
+
+ This walkthrough shows the basic usage and workflow for the Batterystats tool and the Battery
+ Historian script.
+
+ Batterystats collects battery data from your device, and Battery Historian converts that data
+ into an HTML visualization that you can view in your Browser. Batterystats is part of the Android
+ framework, and Battery Historian is open-sourced and available on GitHub at https://github.com/google/battery-historian.
+
+ Heap Viewer, Memory Monitor, and Allocation Tracker are complementary tools that visualize the
+ memory your app uses.
+
+
+
+
+
+ - Shows available and used memory as they both change over time for your app in a
+ graph, with dips indicating Garbage Collection (GC) events.
+
+ - Provides a quick way to test whether app slowness might be related
+ to excessive GC events.
+
+ - Provides a quick way to see whether app crashes might be related
+ to running out of memory.
+
+ - Runs live on your application and updates about once a second.
+
+ - Helps quickly identify the potential of memory leaks.
+
+ - Helps identify GC patterns for your application and determine whether
+ they are healthy and what you expect.
+
+ - Is easy to use, and it is easy to interpret what you see.
+
+ - However, Memory Monitor does not tell you which objects are the cause
+ of your problems, or where in your code it might be.
+
+
+
Heap Viewer
+
+
+
+
+ - Shows snapshots of a number of objects allocated by type.
+
+ - Samples data every time a garbage collection event occurs
+ naturally or triggered by you.
+
+ - Helps identify which object types might be involved in memory leaks.
+
+ - However, you have to look for changes over time yourself by tracking what's
+ happening in the graph.
+
+
+
+
Allocation Tracker
+
+
+
+
+ - Shows when and where your code allocates object types, their size, allocating thread, and
+ stack traces.
+
+ - Helps recognize memory churn through recurring allocation/deallocation patterns.
+
+ - Can be used in combination with Heap Viewer to track down memory leaks. For example, if you
+ see a bitmap object resident on the heap, you can find its allocation location with Allocation
+ Tracker.
+
+ - However, it takes time and experience to learn to interpret the output from this tool.
+
+
diff --git a/docs/html/tools/performance/debug-gpu-overdraw/index.jd b/docs/html/tools/performance/debug-gpu-overdraw/index.jd
new file mode 100644
index 0000000000000..e6b85fd1983c4
--- /dev/null
+++ b/docs/html/tools/performance/debug-gpu-overdraw/index.jd
@@ -0,0 +1,156 @@
+page.title=Debug GPU Overdraw Walkthrough
+meta.tags="android, performance, profiling, tools, rendering, overdraw"
+page.tags="android", "performance", "profiling", "tools", "rendering", "overdraw"
+page.metaDescription=Use color-coding to show how many times each pixel is redrawn on the screen to reduce rendering overhead.
+page.image=tools/performance/thumbnails/tools_debug_gpu_overdraw.png
+page.article=true
+
+
+@jd:body
+
+
+
+
+
+
In this document
+
+
+
You should also read
+
+
+
+
+
This walkthrough shows how to visualize overdraw on your mobile device by color-coding
+ interface elements based on how often they are drawn underneath.
+
+
What it's good for:
+
+
+ - Showing where an app might be doing more rendering work than necessary.
+
+ - Helping you see where you might be able to reduce rendering overhead.
+
+
+
Prerequisites
+
+
+
+
+
Visualizing Overdraw on your Mobile Device
+
+
+
+
+
+
+
+
+ - On your mobile device, go to Settings and tap Developer Options.
+
+ - In the Hardware accelerated rendering section,
+ select Debug GPU Overdraw.
+
+ - In the Debug GPU overdraw popup, select Show overdraw areas.
+
+
+
+
+
+
+
+ - Don't panic as your screen turns into a delirium of colors.
+ The coloring is provided to help you diagnose your app's display behavior.
+
+
+
+
+
+
+
+
+
+ - The colors are hinting at the amount of overdraw on your screen for each pixel, as
+ follows:
+
+
+ - True color: No overdraw
+ - Blue: Overdrawn once
+ - Green: Overdrawn twice
+ - Pink: Overdrawn three times
+ - Red: Overdrawn four or more times
+
+
+
+
+
+
+
+
+
+
+
+ - Some overdraw is unavoidable. As you are tuning your app's
+ user interface, the goal is to arrive at a visualization that shows mostly true
+ colors and 1X overdraw in blue.
+
+
+
diff --git a/docs/html/tools/performance/heap-viewer/index.jd b/docs/html/tools/performance/heap-viewer/index.jd
new file mode 100644
index 0000000000000..9ca0c47c003c4
--- /dev/null
+++ b/docs/html/tools/performance/heap-viewer/index.jd
@@ -0,0 +1,177 @@
+page.title=Heap Viewer Walkthrough
+meta.tags="android, performance, profiling, tools, memory, memoryleaks, memoryheap"
+page.tags="android", "performance", "profiling", "tools", "memory", "memoryleaks", "memoryheap"
+page.metaDescription=Report in real-time how many objects of what types and sizes your application is allocating and find memory leaks.
+page.image=tools/performance/thumbnails/tools_heap_viewer.png
+page.article=true
+
+@jd:body
+
+
+
+
+
+
In this document
+
+
+
You should also read
+
+
+
+
+
+
This walkthrough shows the basic usage and workflow for the Heap Viewer tool. Heap Viewer
+ reports in real-time what types of objects your application has allocated, how many, and
+ their sizes on the heap.
+
+
What it's good for:
+
+
+ - Getting a sense of how your app allocates and frees memory.
+
+ - Identifying memory leaks.
+
+
+
Prerequisites
+
+
+
+
Working with Heap Viewer
+
+
+
+
+
+
+
+
+ - Connect your mobile device to your computer.
+
+ - Open your application in Android Studio, build the source, and run it on your device.
+
+ - Start the Android Device Monitor from Android Studio: Tools -> Android -> Android
+ Device Monitor.
+
+
+
+
+
+
+
+
+ - Make sure your device and application are showing in the Devices tab.
+
+ - Click the DDMS button, because the Heap Viewer is one of the DDMS tools.
+
+ - Click the Heap tab, which is where your data will appear.
+
+ - In the Devices tab, select the app you want to monitor.
+
+
+
+
+
+
+
+
+ - To start monitoring, click the Update Heap button, which looks like a green can.
+
+
+
+
+
+
+
+
+ - Note the Heap updates will happen
+ after every GC for this client. message.
+
+ - Press the Cause CG button to
+ trigger a garbage collection event.
+
+
+
+
+
+
+
+
+ - Click a data type to see detailed information on its current allocations on the
+ heap.
+
+
+
Note: To visualize allocation changes over time, combine
+ several snapshots of the bar graph into an animated gif or video.
+
diff --git a/docs/html/tools/performance/hierarchy-viewer/index.jd b/docs/html/tools/performance/hierarchy-viewer/index.jd
new file mode 100644
index 0000000000000..ebf23e5bcdf08
--- /dev/null
+++ b/docs/html/tools/performance/hierarchy-viewer/index.jd
@@ -0,0 +1,330 @@
+page.title=Hierarchy Viewer Walkthrough
+meta.tags="android, performance, profiling, tools, rendering, hierarchyviewer"
+page.tags="android", "performance", "profiling", "tools", "rendering", "hierarchyviewer"
+page.metaDescription=Visualize your app's view hierarchy to help you simplify your layouts.
+page.image=tools/performance/thumbnails/tools_hierarchy_viewer.png
+page.article=true
+
+@jd:body
+
+
+
+
+
+
In this document
+
+
+
You should also read
+
+
+
+
+
This walkthrough shows the basic usage and workflow for the Hierarchy Viewer tool.
+
+
The Hierarchy Viewer tool visualizes your app's view hierarchy and
+ profiles the relative rendering speed for each view.
+
+
What it's good for:
+
+
+ - Simplifying your view hierarchy to reduce overdraw, and make it easier to manage.
+
+ - Finding potential rendering performance bottlenecks related to the structure and shape of your
+ view hierarchy.
+
+
+
Prerequisites
+
+
+ - A mobile device set up to work with Hierarchy Viewer:
+
+ -
+
+ - You must have Developer
+ Options enabled on your mobile device. You must use a physical device to get
+ accurate measurements.
+
+ - Set an {@code ANDROID_HVPROTO} environment variable on the desktop machine
+ that is connected to your device. For more information, see
+ Device Setup for Hierarchy Viewer.
+
+
+
+ - Debuggable app code with a view hierarchy. Use your own code, or the code for the Sunshine sample app from the Android Fundamentals Udacity course.
+
+
+
Working with Hierarchy Viewer
+
+
+
+
+
+
+
+
+ - Connect your mobile device to your computer.
+
+ - Open your application in Android Studio, build the source, and run it on your device.
+
+ - From Android Studio, start the Android Device Monitor: Tools > Android >
+ Android Device Monitor.
+
+ - Allow USB Debugging on your phone (if asked).
+
+
+
+
+
+
+
+
+ - Figure 2 illustrates what is initially shown in the Device Monitor tool. This varies
+ depending on your setup.
+
Make sure your device
+ and the package for your application are showing in the Devices (DDMS mode) or Windows
+ (Hierarchy Viewer mode) tab. You can choose Window > Reset Perspective to get
+ back to the default arrangement.
+ If the app does not appear, make sure you
+ followed the device
+ setup instructions, then start over at step 1.
+
+
+
+
+
+
+
+
+ - In Android Device Monitor (ADM), in the menu bar, choose Window > Open
+ Perspective, and in the popup click Hierarchy View.
+
+ OR
+ Click the Hierarchy View button if it's already visible.
+ 
+
+
+
+
+
+
+
+
+
+ - If not already open, the Hierarchy View panes open.
+ The example screen in Figure 4 shows an example of these panes.
+
+
+
+
+
+
+
+
+ - If you see a different window arrangement, in Android Device Manager, use
+ Window > Reset Perspective to return to the default layout for this tutorial.
+
+
+
+
+
+
+
+
+ - Double-click your application in the Windows tab. This populates the panes with the
+ view hierarchy of your application.
+ This display is a static representation of the complete view hierarchy defined for the
+ app.
+
+ - You can adjust the sizes of the panes and ADM will preserve your
+ arrangement in future sessions.
+
+
+
+
+
+
+
+
+ - If necessary, click the Layout View tab to hide the Console and show a wireframe of
+ your layout. The outline of the currently selected view is red. Click an outline to select
+ it.
+
+ - The rest of the panes:
+
+
+ - The Tree Overview in the upper right gives you a bird's-eye view of your
+ app's complete View Hierarchy.
+
+ - In the Tree Overview, move the gray viewport rectangle to change what section of
+ your hierarchy shows in the Tree View pane (in the center).
+
+ - In the Tree View, you can drag and zoom the tree using your mouse.
+
+
+
+
+
+
+
+
+ - Click on a View node to display details. Here is an annotated close-up of a node
+ and its details.
+
+
+
+
+
+
+
+
+
+ - Click the View Properties tab at the top right (next to the Windows tab) to see
+ properties of the selected View node.
+
+
+
+
+
+
+
+
+ - Double-click a View node in the Tree View to render it in a popup window.
+
+
+
+
+
+
+
+
+ - Nodes in the Tree View show a Type, which indicates the View class,
+ and an id, which is the view identifier in your code.
+
+
+
diff --git a/docs/html/tools/performance/hierarchy-viewer/profiling.jd b/docs/html/tools/performance/hierarchy-viewer/profiling.jd
new file mode 100644
index 0000000000000..b505228e8ab82
--- /dev/null
+++ b/docs/html/tools/performance/hierarchy-viewer/profiling.jd
@@ -0,0 +1,169 @@
+page.title=Profiling with Hierarchy Viewer
+meta.tags="android, performance, profiling, tools, rendering, hierarchyviewer
+page.tags="android", "performance", "profiling", "tools", "rendering", "hierarchyviewer"
+page.metaDescription=Profile the relative rendering speed for each view.
+page.image=tools/performance/thumbnails/tools_hierarchy_viewer_profiling.png
+page.article=true
+
+@jd:body
+
+
+
+
+
+
This walkthrough shows you how to profile your app's view hiearchy with
+ Hierarchy Viewer, and how to interpret the results.
+
+
Prerequisites
+
+
+
+
Profiling Steps
+
+
+
+
+
+
+
+
+
+ - Start Hierarchy Viewer for your app.
+
+ - In the Tree View or the Layout View, click on the View node whose
+ children you want to profile.
+
+ - To start profiling, click the small button with three circles
+
+ at the top of the Tree View.
+
+
+
+ - For large view hierarchies, profiling may take a few seconds.
+
+ - Each view in your subtree gets three dots, which can be green, yellow, or red.
+
+
+ - The left dot represents the Draw Process of the rendering pipeline.
+ - The middle dot represents the Layout Phase.
+ - The right dot represents the Execute Phase.
+
+
+
+
+
+
+
+
+
+ - These dots roughly correspond to the Measure,
+ Layout, and Draw
+ phases of the processing pipeline.
+
+ - The color of the dots indicates the relative performance
+ of this node in respect to all other profiled nodes.
+
+
+ - Green means the view renders faster than at least
+ half of the other views.
+
+ - Yellow means the view renders faster than the bottom
+ half of the other views.
+
+ - Red means the view is among the slowest
+ half of views.
+
+
+
+
+
+
+
Interpreting Hierarchy Viewer Profiling Results
+
+
Hierarchy Viewer measures the relative performance of a
+ node, so there are always red nodes in a profile, and it
+ doesn't necessarily mean that view is too slow for the users of
+ your app.
+
+
Hierarchy Viewer software rasterizes your Activity to acquire the timing
+ information. Rasterization is the process of taking a high-level primitive, such as a
+ circle or a vector font, and turning it into pixels on the screen. Typically,
+ rasterization is done by the GPU on your device, but in the case of
+ software rasterization, rendering is done on the CPU with
+ ordinary software. This means that the absolute
+ reported timings are correct relative to each other, but are bloated and vary
+ depending on the overall and changing CPU workload on your device and PC. Profile
+ several times to get a feel for the average measurements.
+
+
The following are guidelines for interpreting Hierarchy Viewer profiling output.
+
+
A red node is a potential problem in any situation where your app has
+ unexpectedly slow performance. In a relative setting, there is always a
+ slowest node; make sure it is the node you expect.
+ The following examples illustrate how to interpret red dots.
+
+
+ - Look for red dots in leaf nodes or view groups with only a few children. This
+ might point to a problem. Your app may not be slow, or it may not be slow on your
+ device, but you need to be aware of why that dot is red.
+ Systrace or
+ Traceview
+ can give you additional information.
+
+ - If you have a view group with many children and a red measure phase, take a
+ look at the children to see how they are performing.
+
+ - A view with yellow or even red dots might not be performing slowly on the
+ device. That's where the actual numbers are helpful.
+ Systrace or
+ Traceview
+ can give you additional information.
+
+ - If the root view of a hierarchy has a red measure phase, red layout phase, and
+ yellow draw phase, this is somewhat typical, because it's the
+ parent of all the other views.
+
+ - If a leaf node in a tree with 20+ views has a red draw phase, this is a
+ problem. Check your OnDraw method for code that shouldn't be
+ there.
+
diff --git a/docs/html/tools/performance/hierarchy-viewer/setup.jd b/docs/html/tools/performance/hierarchy-viewer/setup.jd
new file mode 100644
index 0000000000000..aaac1ca48ffac
--- /dev/null
+++ b/docs/html/tools/performance/hierarchy-viewer/setup.jd
@@ -0,0 +1,89 @@
+page.title=Device Setup for Hierarchy Viewer
+meta.tags="android, performance, profiling, tools, rendering, hierarchyviewer"
+page.tags="android", "performance", "profiling", "tools", "rendering", "hierarchyviewer"
+page.metaDescription=Set up your mobile device to work with Hierarchy Viewer.
+page.image=tools/performance/thumbnails/tools_hierarchy_viewer.png
+page.article=true
+
+@jd:body
+
+
+
+
You should also read
+
+
+
+
+
To run Hierarchy Viewer, you must enable Developer Options on your mobile device and perform
+ some setup on your computer.
+
+
Configuring Devices
+
+
+ Enable Developer Options
+ on your mobile device.
- Depending on the type of device you have, do one of the following:
+
+ - If you have a locked device running Android 4.0 or lower, follow the instructions
+ for installing and configuring ViewServer.
+
+ - If you have an unlocked device running Android 4.0 or lower,
+ no further configuration is needed.
+ - If you have a device running Android 4.1 or higher, you must set an environment
+ variable on your development machine. For more information,
+ see Setting the ANDROID_HVPROTO variable
+
+
+
+
+
+
Setting the ANDROID_HVPROTO variable
+
+
Windows
+
+
+ - Click My Computer > Property > Advanced > Environment Variables.
+
+ - Click New.
+
+ - In variables name put:
ANDROID_HVPROTO
+
+ - In variable value put:
ddm
+
+ - Click OK<./li>
+
+
+
Mac
+
+
+ - Edit
~/.bash_profile
+
+ - Add:
+
#Hierarchy Viewer Variable
+
export ANDROID_HVPROTO=ddm
+
+
+ source ~/.bash_profile
+
+
Linux
+
+
+ - Edit
~/.bash_profile
+
+ - Add:
+
+
#Hierarchy Viewer Variable
+
export ANDROID_HVPROTO=ddm
+
+
+ source ~/.bash_profile
diff --git a/docs/html/tools/performance/importing-legacy-apps.jd b/docs/html/tools/performance/importing-legacy-apps.jd
new file mode 100644
index 0000000000000..cee351961976d
--- /dev/null
+++ b/docs/html/tools/performance/importing-legacy-apps.jd
@@ -0,0 +1,149 @@
+page.title=Importing Legacy Apps into Android Studio
+meta.tags="android, performance, profiling, tools"
+page.tags="android", "performance", "profiling", "tools"
+page.metaDescription=Required changes when importing legacy apps into Android Studio.
+page.article=true
+
+@jd:body
+
+
+
+
In this document
+
+
+
You should also read
+
+
+
+
+
+
Importing some pre-Android-1.0 projects into Android 1.0 or newer can trigger a series of
+ errors. This document shows you how to resolve them, using a version of the Sunshine app used in
+ the Android Fundamentals Udacity Course as an
+ example.
+
+
CAVEAT: As with all documentation of this kind, the details are likely to vary for each
+ application and each update of Android Studio.
+
+
Prerequisites
+
+
+
+
Steps for Importing Sunshine into Android Studio 1.1.0
+
+
+ - Download Sunshine ZIP from GitHub: https://github.com/udacity/sunshine/tree/6.10-update-map-intent.
+ (If you are having any problems with Android Studio or the app, use the following version, or
+ your own app, to follow along with the example.https://github.com/udacity/sunshine/tree/3.13-add-share-action-provider)
+
+
- Unzip the application to extract the code folder.
+
+ - Start Android Studio. (This works best if you close all projects, then restart.)
+
+ - Click Import project (Eclipse ADT, Gradle, etc.).
+
+
+
+ - In the popup, find and select the Sunshine-6-10-updated-map-intent folder and click
+ OK.
+
+
+
+ - If prompted, choose a destination folder for your project. If prompted to choose a build
+ system, choose Gradle. (These prompts vary, depending on your project and Android Studio
+ version.) If you need more guidance, see this Lynda tutorial.
+
+ - Wait for the import to complete. If you see no errors, you are now ready to work with your
+ app.
+
+
If you get a Gradle error:
+
+ - If you get a Gradle error, you have some extra work to do.(Because the Import
+ didn(t finish, at this point, you may only see the Gradle
+ Scripts directory in your Project view.)
+
+ - You may see the link Install missing platform(s) and sync
+ project, or a link to install missing build tools.
+ Click whatever link and
+ proceed.
+
+ - The next time through, your build will fail with:
+
+
+
+ - Click the Fix plugin version and re-import project link
+ in the error message. This will rebuild the app and present you with new of errors.
+
+
+
+ - Click the Gradle Settings link in the error message.
+
+ - Check the Use auto-import and click OK.
+
+
+
+ - Expand the project hierarchy and find the build.gradle file.The file you are looking
+ for is not the one showing at the top level, but the one inside Sunshine >
+ app > build.gradle, as shown below.
+
+
+
+ - Double-click the
build.gradle file.
+
+ - Make the following changes to the file:
+
+ - Set
compileSdkVersion 21
+
+ - Set
targetSdkVersion 21
+
+ - Replace
runProguard with minifyEnabled
+
+
+ Your file should look like this:
+ 
+
+
+ - Save (Ctrl-S).
+
+ For the following two messages (Steps 18/19), what you see might vary. You might see either
+ message or both messages in sequence. Click the appropriate links to continue until the Language
+ Level Changed dialog opens.
+
+ - In the code view bar, click the Try again link.
+
+
+
+ - If you see these warnings, click the Sync now link.
+
+
+
+ - In the Language Level Changed dialog, click Yes. And if you get the Gradle Running
+ dialog, Yes again.
+
+
+
+ - After the project reloads, run the app on your device. (If it crashes the first time, try
+ again, and it will run.)
+
+
+
+
diff --git a/docs/html/tools/performance/index.jd b/docs/html/tools/performance/index.jd
new file mode 100644
index 0000000000000..fa5af86bd04e9
--- /dev/null
+++ b/docs/html/tools/performance/index.jd
@@ -0,0 +1,73 @@
+page.title=Performance Profiling Tools
+meta.tags="android, develop, performance, profiling, tools, gather"
+page.tags="android", "develop", "performance", "profiling", "tools" "gather"
+page.metaDescription=Android Studio profiling tools for evaluating your app's performance.
+page.article=true
+
+@jd:body
+
+
Putting pixels on the screen involves four primary pieces of hardware.
+ To greatly simplify, the CPU computes display lists, the GPU renders images to
+ the display, the memory stores images and data, and the battery provides
+ electrical power. Each of these pieces of hardware has constraints; pushing
+ or exceeding those constraints causes your app to be slow, have
+ bad display performance, or exhaust the battery.
+
+
To discover what causes your specific performance problems, you need to
+ take a look under the hood, use tools to collect data about your app's
+ execution behavior, surface that data as lists and
+ graphics, understand and analyze what you see, and improve your code.
+
+
Android Studio and your device provide profiling tools to record and
+ visualize the rendering, compute, memory, and battery performance of your
+ app.
+
+
+
+
Visualize the rendering behavior and performance of your app.
+
+
+
+
+
+
Visualize the memory behavior and performance of your app.
+
+
+
+
+
+
Visualize the CPU behavior and performance of your app.
+
+
+
+
+
+
Visualize the battery behavior and performance of your app.
+
+
+
+
diff --git a/docs/html/tools/performance/memory-monitor/index.jd b/docs/html/tools/performance/memory-monitor/index.jd
new file mode 100644
index 0000000000000..756ca14007257
--- /dev/null
+++ b/docs/html/tools/performance/memory-monitor/index.jd
@@ -0,0 +1,172 @@
+page.title=Memory Monitor Walkthrough
+meta.tags="android, performance, profiling, tools, memory, memoryleaks, garbagecollection, memorymonitor"
+page.tags="android", "performance", "profiling", "tools", "memory", "memoryleaks", "garbagecollection", "memorymonitor"
+page.metaDescription=Graph memory usage and garbage collection events for your app in real-time.
+page.image=tools/performance/thumbnails/tools_memory_monitor.png
+page.article=true
+
+@jd:body
+
+
+
+
+
+
In this document
+
+
+
You should also read
+
+
+
+
+
+
This walkthrough shows the basic usage and workflow for the Memory Monitor tool in Android
+ Studio. Memory Monitor reports in real-time how your app allocates memory.
+
+
What it's good for:
+
+
+ - Showing available and used memory in a graph, and garbage collection events over time.
+
+ - Quickly testing whether app slowness might be related
+ to excessive garbage collection events.
+
+ - Quickly testing whether app crashes may be related to running out of
+ memory.
+
+
+
Prerequisites
+
+
+
+
Working with Memory Monitor
+
+
+
+
+
+
+
+
+ - Connect your mobile device to your computer.
+
+ - Open your application in Android Studio, build the source,
+ and run it on your device.
+
+ - In Android Studio, choose Tools > Android > Memory Monitor.
+
+
+
+
+
+
+
+
+ - This opens the Memory Monitor pane.
+
+ - Choose your device from the drop-down menu at the top left of the pane.
+
+ - Choose your Activity from the drop-down menu at the top right of the pane.
+
+
+
+
+
+
+
+
+ - Once Memory Monitor starts tracking your device, a stacked graph appears,
+ tracking memory usage over time.
+
+
Dark blue: Amount of memory that your app
+ is currently using.
+
+ Light blue: Available, unallocated memory.
+
+
+ - Over time, this graph updates, showing changes in memory usage.
+
+ - As your app allocates and frees memory, the allocated amount shown in the
+ graph changes.
+
+ - When you see the allocated memory drop by a large amount, a garbage
+ collection (GC) event has occurred.
+
+
+
+
+
+
+
+
+ - You can force a garbage collection event by clicking on the garbage truck
+ icon
+
.
+
+
+
+
+
+
diff --git a/docs/html/tools/performance/profile-gpu-rendering/index.jd b/docs/html/tools/performance/profile-gpu-rendering/index.jd
new file mode 100644
index 0000000000000..74862b59acc16
--- /dev/null
+++ b/docs/html/tools/performance/profile-gpu-rendering/index.jd
@@ -0,0 +1,181 @@
+page.title=Profiling GPU Rendering Walkthrough
+meta.tags="android, performance, profiling, tools, rendering, gpu"
+page.tags="android", "performance", "profiling", "tools", "rendering", "gpu"
+page.metaDescription=Overlay a graph on your device, showing how long it takes to render UI elements relative to the 16-ms-per-frame benchmark.
+page.image=tools/performance/thumbnails/tools_profile_gpu_rendering.png
+page.article=true
+
+@jd:body
+
+
+
+
+
+
In this document
+
+
+
You should also read
+
+
+
+
+
This walkthrough shows how to use Profile GPU Rendering on your mobile device.
+
+
Profile GPU Rendering gives you a quick visual representation of how much time it takes to
+ render the frames of a UI window relative to the 16-ms-per-frame benchmark.
+
+
What it's good for:
+
+
+ - Quickly seeing how a UI window performs against the 16-ms-per-frame target.
+
+ - Identifying whether any part of the rendering pipeline stands out in using processing
+ time.
+
+ - Looking for spikes in frame rendering time associated with user or program actions.
+
+
+
Prerequisites
+
+
+
+
Working with Profile GPU Rendering
+
+
+
+
+
+
+
+
+ - On your mobile device, go to Settings > Developer Options.
+
+ - In the Monitoring section, select Profile GPU Rendering.
+
+ - In the Profile GPU Rendering popup, choose On screen as bars to overlay the graphs
+ on the screen of your mobile device.
+
+ - Go to the app that you want to profile.
+
+
+
+
+
+
+
+
What you see:
+
+
+ - For each visible application, the tool displays a graph.
+
+ - The horizontal axis shows time elapsing, and the vertical axis time per frame in
+ milliseconds.
+
+ - As you interact with your application, vertical bars show up on your screen, appearing
+ from left to right, graphing frame performance over time.
+
+ - Each vertical bar represents one frame of rendering.
+ The taller the bar, the longer it took to render.
+
+ - The green line marks the 16 millisecond target. Every time a frame crosses the green line,
+ your app is missing a frame, and your users may see this as stuttering images.
+
+
+
-
+
+
+ The Profile GPU Rendering Graph
+
+ ![]()
+
+ Figure 3. Enlarged Annotated Profile GPU Rendering graph.
+
+
+ In this enlarged image of the Profile GPU Rending graph you can see the colored sections
+ of the graph, and what phase of the rendering pipeline each color represents.
+
+
+ - The green line represents 16 milliseconds. To achieve 60 frames per second,
+ the vertical bar for each frame needs
+ to stay below this 16 ms mark. Any time a bar pushes above this line, there may be pauses in
+ the animations.
+
+ - Each bar has a blue, purple (only for Android version 4.0 and higher),
+ red, and orange component.
+
+
- The blue section of the bar represents the time used to create and update the
+ View's display lists. If this part of the bar is tall, there may be a
+ lot of custom view drawing, or a lot of work in onDraw methods.
+
+ - Android 4.0 and higher: The purple section of the bar represents the time spent
+ transferring resources to the render thread.
+
+ - The red section 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 this bar is directly proportional to the sum of the time it takes each
+ display list to execute—more display lists equals a taller red bar.
+
+ - The orange section of the bar represents the time the CPU is waiting for the GPU to
+ finish its work. If this bar gets tall, it means the app is doing too much work on the GPU.
+
+
+
+ Note:
+ While this tool is named Profile GPU Rendering, all monitored processes actually
+ occur in the CPU. Rendering happens by submitting commands to the GPU, and the GPU renders the
+ screen asynchronously. In certain situations, the GPU can have too much work to do,
+ and your CPU will have to wait before it can submit new commands.
+ When this happens, you'll see spikes in the Process (orange bar) and Execute (red bar)
+ stages, and the sommand submission will block until more room is made on the
+ GPU command queue.
+
+
+
This walkthrough shows the basic usage and workflow for the Systrace tool in the Android
+ Device Monitor.
+
+ Systrace collects system and application process execution data and generates detailed,
+ interactive reports from devices running Android 4.1 and higher.
+
+ This walkthrough shows the basic usage and workflow for the Traceview tool. Traceview logs
+ method execution over time and shows execution data, per-thread timelines, and call stacks.
+
+ 
+ (Start Allocation Tracking tooltip).
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
.
+ 
+ 
+ 
+ 
+ 
+ button.
+ 
+ 
+ 
+ button.
+ 
+ 
+ 
+