android_frameworks_base/docs/html/tools/help/am-memory.jd

page.title=Memory Monitor
parent.title=Android Monitor
parent.link=android-monitor.html
page.tags=monitor
@jd:body

<div id="qv-wrapper">
<div id="qv">
  <h2>In this document</h2>
<ol>
  <li><a href="#workflow">Memory Monitor Workflow</a>
  <ol>
  <li><a href="#treeroot">Garbage collection roots and dominator trees</a></li>
  <li><a href="#analysis">Memory leak and use analysis</a></li>
  <li><a href="#vm">Memory management for different virtual machines</a></li>
  </ol>
  </li>
  <li><a href="#displaying">Displaying a Running App in the Memory Monitor</a></li>
  <li><a href="#forcing">Forcing a Garbage Collection Event</a></li>
  <li><a href="#dumping">Dumping and Analyzing the Java Heap</a>
    <ol>
      <li><a href="#hprof-snapshot">Taking and displaying a snapshot of the Java heap</a></li>
      <li><a href="#hprof-diving">Diving into heap dump data in the HPROF Viewer</a></li>
      <li><a href="#hprof-analyzing">Analyzing heap dump data in the HPROF Analyzer</a></li>
      <li><a href="#hprof-sorting">Sorting heap dump data</a></li>
      <li><a href="#hprof-source">Displaying Java source</a></li>
      <li><a href="#hprof-viewing">Viewing a saved HPROF file</a></li>
      <li><a href="#hprof-renaming">Renaming an HPROF file</a></li>
      <li><a href="#hprof-locating">Locating a heap dump file on disk</a></li>
      <li><a href="#hprof-deleting">Deleting a heap dump file</a></li>
      <li><a href="#hprof-converting">Converting a heap dump file to standard HPROF format</a></li>
    </ol>
    </li>
  <li><a href="#tracking">Tracking and Analyzing Memory Allocation</a>
      <ol>
      <li><a href="#alloc-snapshot">Taking and displaying a snapshot of allocation data</a></li>
      <li><a href="#alloc-sorting">Sorting allocation data</a></li>
      <li><a href="#alloc-source">Displaying Java source</a></li>
      <li><a href="#alloc-viewing">Viewing a saved allocation tracking file</a></li>
      <li><a href="#alloc-renaming">Renaming an allocation tracking file</a></li>
      <li><a href="#alloc-locating">Locating an allocation tracking file</a></li>
      <li><a href="#alloc-deleting">Deleting an allocation tracking file</a></li>
    </ol>
    </li>
</ol>

 <h2>See also</h2>
  <ol>
    <li><a href="{@docRoot}training/articles/memory.html">Managing Your App's Memory</a></li>
    <li><a href="{@docRoot}guide/practices/verifying-apps-art.html#GC_Migration">Addressing Garbage Collection Issues</a></li>
    <li><a href="{@docRoot}tools/debugging/debugging-memory.html">Investigating Your RAM Usage</a></li>

    <li>
        <a href="{@docRoot}tools/help/android-monitor.html">Android Monitor</a>
      </li>
    <li><a href="{@docRoot}tools/help/am-logcat.html">logcat Monitor</a>
      </li>

      <li><a href="{@docRoot}tools/help/am-cpu.html">CPU Monitor</a>
      </li>

      <li><a href="{@docRoot}tools/help/am-gpu.html">GPU Monitor</a>
      </li>

      <li>
        <a href="{@docRoot}tools/help/am-network.html">Network Monitor</a>
      </li>
  </ol>


<h2>
  Dependencies and Prerequisites
</h2>

<ul>
  <li>
    Make sure your development computer detects your hardware device, which often happens
  automatically when you connect it to a USB port.
  </li>
<li>
    <a href="{@docRoot}tools/device.html#device-developer-options">Enable</a> <strong><a href=
    "{@docRoot}tools/device.html#device-developer-options">USB debugging</a></strong> in
    <strong>Developer Options</strong> on the device or emulator.
  </li>

  <li>In your app, set the <code>debuggable</code> property to <code>true</code> in the manifest or
  <code>build.gradle</code> file (it’s initially set by default).
  </li>

  <li>Enable ADB integration through <strong>Tools</strong> &gt; <strong>Android</strong> &gt;
  <strong>Enable ADB Integration</strong>.
  </li>

   <li>
    <a href="{@docRoot}tools/help/monitor.html">Android Device Monitor</a> can’t be running.
  </li>
</ul>

</div>
</div>

<p>
  Android Studio provides a Memory Monitor so you can more easily monitor app performance and
  memory usage to find deallocated objects, locate memory leaks, and track the amount of memory the
  connected device is using. The Memory Monitor reports how your app allocates memory and helps you
  to visualize the memory your app uses. It lets you:
</p>

<ul>
  <li>Show a graph of available and allocated memory over time.
  </li>
<li>Show garbage collection (GC) events
  over time.
  </li>
  <li>Initiate garbage collection events.
  </li>

  <li>Quickly test whether app slowness might be related to excessive garbage collection events.
  </li>

  <li>Quickly test whether app crashes may be related to running out of memory.
  </li>
</ul>

<h2 id="workflow">
  Memory Monitor Workflow
</h2>

<p>
  To profile and optimize memory use, the typical workflow is to run your app and do the following:
</p>

<ol>
  <li>Profile the app using the Memory Monitor to find out whether undesirable garbage collection
  event patterns might be causing performance problems.
  </li>

  <li>If you see many garbage collection events in a short amount of time, dump the Java heap to
  identify candidate object types that get or stay allocated unexpectedly or unnecessarily.
  </li>

  <li>Start allocation tracking to determine where any problems are happening in your code.
  </li>
</ol>

<p>
  The Java heap data shows in real-time what types of objects your application has allocated, how
  many, and their sizes on the heap. Viewing the heap helps you to:
</p>

<ul>
  <li>Get a sense of how your app allocates and frees memory.
  </li>

  <li>Identify memory leaks.
  </li>
</ul>

<p>
  Allocation tracking records app memory allocations and lists all allocations for the
  profiling cycle, including the call stack, size, and allocating code. It helps you to:
</p>

<ul>
  <li>Identify where many similar object types, from roughly the same call stack, are allocated and
  deallocated over a very short period of time.
  </li>

  <li>Find the places in your code that may contribute to inefficient memory use.
  </li>
</ul>

<h3 id="treeroot">
  Garbage collection roots and dominator trees
</h3>

<p>
  When you dump the Java heap, the Memory Monitor creates an Android-specific Heap/CPU Profiling
  (HPROF) file that you can view in the HPROF Viewer. The HPROF Viewer indicates a garbage
  collection root with the <img src="{@docRoot}images/tools/am-igcroot.png"
  style="vertical-align:sub;margin:0;height:17px" alt="GC Root icon" /> icon (and a depth of zero)
  and a
  dominator with the <img src="{@docRoot}images/tools/am-idom.png"
  style="vertical-align:sub;margin:0;height:17px" alt="Dominator icon" /> icon.
</p>

<p>
  There are several kinds of garbage collection roots in Java:
</p>

<ul>
<li>references on the stack</li>
<li>Java Native Interface (JNI) native objects and memory</li>
<li>static variables and functions</li>
<li>threads and objects that can be referenced </li>
<li>classes loaded by the bootstrap loader</li>
<li>finalizers and unfinalized objects</li>
<li>busy monitor objects</li>
</ul>

<p>
  The HPROF file provides the list of roots to the HPROF Viewer.
</p>

<p>
  A dominator tree traces paths to objects created by the app. An object dominates another object
  if the only way to reach the other object is, directly or indirectly, through the dominator
  object. When you examine objects and paths created by an app in an effort to optimize memory use,
  try to remove objects that are no longer needed. You can release a dominator object to
  release all subordinate objects. For example, in the following figure, if you were to
  remove object B, that would also release the memory used by the objects it dominates, which are
  objects C, D, E, and F. In fact, if objects C, D, E, and F were marked for removal, but object B
  was still referring to them, that could be the reason that they weren’t released.
</p>

  <img src="{@docRoot}images/tools/am-domtree.png" height="200" />

<h3 id="analysis">
  Memory leak and use analysis
</h3>

<p>
  An app performs better if it uses memory efficiently and releases the memory when it’s no longer
  needed.
  Memory leaks that are large or that grow over time are the most important to correct.
</p>

<p>
  One way to optimize memory usage is to analyze large arrays. For example, can you reduce the size
  of individual elements in the array to save memory? Does a dominator object point to
  an element in the array, preventing it from being garbage-collected? If the dominator object
  directly points to an element in the array, the dominator is either the contiguous memory
  representing the underlying data of the array, some part of the array, or the array itself.
</p>

<p>
  Another area that deserves attention is objects that the app no longer needs but continues to
  reference. You can gather heap dumps over different periods of time and compare them to determine
  if you have a growing memory leak, such as an object type that your code creates multiple times
  but doesn’t destroy. These objects could be part of a growing array or an object tree, for
  example. To track down this problem, compare the heap dumps and see if you have a particular
  object type that continues to have more and more instances over time.
</p>

<p>
  Continually growing object trees that contain root or dominator objects can prevent subordinate
  objects from being garbage-collected. This issue is a common cause of memory leaks, out-of-memory
  errors,
  and crashes. Your app could have a small number of objects that are preventing a large number of
  subordinate objects from being destroyed, so it runs out of memory quickly. To find these issues,
  get a heap dump and examine the amount of memory held by root and dominator objects. If the
  memory is substantial, you’ve likely found a good place to start optimizing your memory use.
</p>

<p>
  As you start narrowing down memory issues, you should also use the Allocation Tracker to get a
  better understanding of where your memory-hogging objects are allocated. The Allocation Tracker
  can be valuable not only for looking at specific uses of memory, but also for analyzing critical
  code paths, such as loading and scrolling. For example, tracking allocations when flinging a list
  in your app
  allows you to see all of the allocations that need to be done for that behavior, what thread they
  are on, and where they came from. This information is extremely valuable for tightening up these
  paths to reduce the work they need and improve the overall smoothness of the UI.
</p>

<p>
  It’s useful to examine your algorithms for allocations that are unnecessary or that create the
  same object many times instead of reusing them. For example, do you create temporary objects and
  variables within recursive loops? If so, try creating an object or variable before
  the loop for use within the loop. Otherwise, your app might needlessly allocate many objects and
  variables, depending on the number of recursions.
</p>

<p>
  It’s important to perform allocation tests on portions of your code that create the most and
  largest objects, as those areas offer the most optimization opportunities. In addition to unit
  tests, you should test your app with production-realistic data loads, especially those algorithms
  that are data-driven. Also, make sure to account for the app caching and startup phase, which can
  sometimes be slow; allocation analysis is best done after that phase to produce accurate results.
</p>

<p>
  After you optimize code, be sure to test that it worked. You need to test under different load
  conditions and also without running the Memory Monitor tools. Compare results before and after
  optimization to make sure that performance has actually improved.
</p>

<h3 id="vm">
  Memory management for different virtual machines
</h3>

<p>
  Android Monitor uses the Virtual Machine (VM) that the device or emulator uses:
</p>

<ul>
  <li>Android 4.3 (API level 18) and lower uses the Dalvik VM.
  </li>

  <li>In Android 4.4 (API level 19), the Android RunTime (ART) VM is an option, while the Dalvik VM
  is the default.
  </li>

  <li>Android 5.0 (API level 21) and higher uses the ART VM.
  </li>
</ul>

<p>
  The VM handles garbage collection. The Dalvik VM uses a mark-and-sweep scheme for garbage
  collection. The ART VM uses a generational scheme, combined with mark-and-sweep when memory needs
  a more thorough garbage collection, such as when memory becomes excessively fragmented. The
  logcat Monitor displays some messages that indicate the type of garbage collection that occurred
  and why.
</p>

<p>
  Memory Monitor results can vary between the different VMs. As a result, if you’re supporting both
  VMs, you might want to test with both. In addition, the VMs available for different API levels
  can have different behavior. For example, the Dalvik VM in Android 2.3 (API level 10) and lower
  uses externally allocated memory while higher versions allocate in the Dalvik heap only.
</p>

<p>
  You can’t reconfigure the Dalvik and ART VMs to tune performance. Instead, you should examine
  your app code to determine how to improve its operation, for example, reducing the size of very
  large arrays.
</p>

<p>
  There are programmatic ways to manipulate when the VM performs garbage collection, although it’s
  not a best practice. These techniques can be specific to the VM. For more information, see
  <a href=
  "{@docRoot}guide/practices/verifying-apps-art.html#GC_Migration">Addressing
  Garbage Collection (GC) Issues</a> and <a href=
  "{@docRoot}tools/debugging/debugging-memory.html">Investigating Your RAM
  Usage</a>.
</p>

<p>
  The ART VM adds a number of performance, development, and debugging improvements over the Dalvik
  VM. For more information, see <a href=
  "https://source.android.com/devices/tech/dalvik/index.html">ART and Dalvik</a>.
</p>

<h2 id="displaying">
  Displaying a Running App in the Memory Monitor
</h2>

<p>
  Follow these steps:
</p>

<ol>
  <li>Optionally connect a hardware device.
  </li>

  <li>
    <a href=
    "{@docRoot}tools/help/android-monitor.html#displaying">Display Android Monitor</a>.
  </li>

  <li>Click the <strong>Memory</strong> tab.
  </li>

  <li>Open an app project and <a href=
  "{@docRoot}tools/building/building-studio.html#RunningApp">run it</a> on a
  hardware device or emulator.
  </li>

  <li>Enable the Memory Monitor by clicking Pause <img src="{@docRoot}images/tools/am-ipause.png"
    style="vertical-align:sub;margin:0;height:17px" alt="Pause icon" /> to deselect it.
  </li>


<p>
  In the graph, the y-axis displays the free and allocated RAM in megabytes. The x-axis shows the
  time elapsed; it starts with seconds, and then minutes and seconds, and so on. The amount of free
  memory, measured in megabytes,
  is shown in a light color, and allocated memory is a darker color. When there’s a sharp drop in
  allocated memory, that indicates a garbage collection event. </p>



<p>
  To force a garbage collection event, click Initiate GC <img src="{@docRoot}images/tools/am-igc.png"
  style="vertical-align:sub;margin:0;height:17px" alt="Initiate GC icon" />.
</p>

  <p>In the following figure, the VM initiated the first garbage collection event, while the
    developer forced the second.
</p>
<img src="{@docRoot}images/tools/am-gc.png" />

  <li>Interact with your app and watch how it affects memory usage in the Memory Monitor. You can
  identify garbage collection patterns for your app and determine whether they are healthy and what
  you expect.
  </li>


<p>
  The graph can show you potential issues:
</p>

<ul>
  <li>Excessive garbage collection events slow down the app.
  </li>

  <li>The app runs out of memory, which causes it to crash.
  </li>

  <li>Potential memory leaks.
  </li>
</ul>

<p>
  For example, you might see the following signs of problems:
</p>

<ul>
  <li>Your app is static, but you see memory being allocated in the monitor.
  </li>

  <li>You see spikes of memory allocations in the monitor, but you don’t think there’s any app
  logic to cause this behavior.
  </li>
</ul>
  <li>To stop the Memory Monitor, click Pause <img src="{@docRoot}images/tools/am-ipause.png"
    style="vertical-align:sub;margin:0;height:17px" alt="Pause icon" /> again to select it.
  </li>

</ol>

<h2 id="forcing">
  Forcing a Garbage Collection Event
</h2>

<p>
  Normally, VMs perform garbage collection only when absolutely needed, since it’s expensive.
  However, it can be useful to force garbage collection in certain circumstances. For example, when
  locating memory leaks, if you want to determine whether a large object was successfully released
  already, you can initiate garbage collection much more aggressively than usual.
</p>

<p>
  To force a garbage collection event:
</p>

<ul>
  <li>While the <a href="#displaying">Memory Monitor is running</a>, click Initiate GC
  <img src="{@docRoot}images/tools/am-igc.png" style="vertical-align:sub;margin:0;height:17px"
  alt="Initiate GC icon" />.
  </li>
</ul>

<h2 id="dumping">
  Dumping and Analyzing the Java Heap
</h2>

<p>
  When you're monitoring memory usage in Android Studio you can, at the same time, dump the Java
  heap to a heap snapshot in an Android-specific HPROF binary format file. The HPROF Viewer
  displays classes, instances of each class, and a reference tree to help you track memory usage
  and find memory leaks. HPROF is a heap dump format originally supported by J2SE.
</p>
<p>The Java heap display does the following:</p>

<ul>
  <li>Shows snapshots of a number of objects allocated by type.
  </li>

  <li>Samples data every time a garbage collection event occurs naturally or is triggered by you.
  </li>

  <li>Helps identify which object types might be involved in memory leaks.
  </li>
</ul>

<p>
  However, you have to look for changes over time yourself by tracking what's happening in the
  graph.
</p>

<p>
  The HPROF Analyzer finds the following potential issues:
</p>

<ul>
  <li>All destroyed activity instances that are reachable from garbage collection roots.
  </li>

  <li>Where the target program has strings that repeat values.
  </li>
</ul>

<p>
  A dominator is at the top of a tree. If you remove it, you also remove the branches of the tree
  it dominates, so it’s a potential way to free memory.
</p>

<h3 id="hprof-snapshot">
  Taking and displaying a snapshot of the Java heap
</h3>

<p>
  To see a snapshot of the Java heap, follow these steps:
</p>

<ol>
  <li>While the Memory Monitor is running, click Dump Java Heap
    <img src="{@docRoot}images/tools/am-idump.png"
    style="vertical-align:sub;margin:0;height:17px" alt="Dump Java Heap icon" />.
  </li>


<p>
  When the icon on the Memory Monitor display changes from
  <img src="{@docRoot}images/tools/am-idumpstart.png"
  style="vertical-align:sub;margin:0;height:17px" alt="Dump Java Heap Start icon" /> to
  <img src="{@docRoot}images/tools/am-idumpend.png" style="vertical-align:sub;margin:0;height:17px"
  alt="Dump Java Heap End icon" />, the file is ready. Android Studio creates the heap snapshot
  file with the
  filename <code>Snapshot_<em>yyyy.mm.dd_hh.mm.ss</em>.hprof</code> using
  the year, month, day, hour, minute, and second of the capture, for example,
  <code>Snapshot_2015.11.17_14.58.48.hprof</code>.
</p>

  <li>Click <strong>Captures</strong> in the main window.
  </li>

<p>
  The <em>Captures</em> window appears.
</p>

  <li>Double-click the file to view it in the HPROF Viewer.
  </li>

<p>
  The HPROF Viewer appears:
</p>
<img src="{@docRoot}images/tools/am-hprofviewer.png" />
<p>
  The tool displays the following information:
</p>

<table>
  <tr>
    <th scope="col">Column</th>
    <th scope="col">Description</th>
  </tr>

  <tr>
    <td><strong>Class Name</strong></td>
    <td>The Java class responsible for the memory.</td>
  </tr>

  <tr>
    <td><strong>Total Count</strong></td>
    <td>Total number of instances outstanding.</td>
  </tr>
  <tr>
    <td><strong>Heap Count</strong></td>
    <td>Number of instances in the selected heap.</td>
  </tr>
  <tr>
    <td><strong>Sizeof</strong></td>
    <td>Size of the instances (currently, 0 if the size is variable).</td>
  </tr>
  <tr>
    <td><strong>Shallow Size</strong></td>
    <td>Total size of all instances in this heap.</td>
  </tr>
  <tr>
    <td><strong>Retained Size</strong></td>
    <td>Size of memory that all instances of this class is dominating.</td>
  </tr>
  <tr>
    <td><strong>Instance</strong></td>
    <td>A specific instance of the class.</td>
  </tr>
  <tr>
    <td><strong>Reference Tree</strong></td>
    <td>References that point to the selected instance, as well as references pointing to the
      references.</td>
  </tr>
  <tr>
    <td><strong>Depth</strong></td>
    <td>The shortest number of hops from any GC root to the selected instance.</td>
  </tr>
  <tr>
    <td><strong>Shallow Size</strong></td>
    <td>Size of this instance.</td>
  </tr>
  <tr>
    <td><strong>Dominating Size</strong></td>
    <td>Size of memory that this instance is dominating.</td>
  </tr>
</table>

  <li>Select the Heap menu option you want to display:
    <ul>
      <li>
        <strong>App heap</strong> - The heap used by the current app.
      </li>

      <li><strong>Image heap</strong> - The memory mapped copy of the
      current app on disk.
      </li>


  <li>
    <strong>Zygote heap</strong> - The common set of libraries and runtime classes and data that
    all apps are forked
    from. The zygote space is created during device startup and is never allocated into.
  </li>

    </ul>

      <li>Select the View menu option you want to display:
        <ul>
          <li>
            <strong>Class List View</strong>
          </li>

              <li>
                <strong>Package Tree View</strong>
              </li>
            </ul>
    </ol>


<h3 id="hprof-diving">
  Diving into heap dump data in the HPROF Viewer
</h3>
<p>The following steps outline the typical workflow:</p>
<ol>
<li>In the HPROF viewer, select a class name. </li>
<li>Select an instance of that class.</li>
<li>Examine the reference tree.</li>
<li>Right-click an item to <strong>Jump to source</strong> or <strong>Go to instance</strong>,
  as needed.</li>
</ol>



<h3 id="hprof-analyzing">Analyzing heap dump data in the HPROF Analyzer</h3>
<p>You can detect leaked activities and find duplicate strings with the HPROF Analyzer.
  Follow these steps: </p>
<ol>
<li>In the <em>Captures</em> window, double-click an <code>.hprof</code> file to display it in the
  HPROF Viewer. </li>
<li>Click <strong>Capture Analysis</strong> on the right side of the main Android Studio window.</li>


<p>The HPROF Analyzer appears to the right of the HPROF Analyzer, by default: </p>

<img src="{@docRoot}images/tools/am-hprofanalyzer.png" />

<li>In the <strong>Analyzer Tasks</strong> list, select the items you want to find.</li>
<li>Click Perform Analysis <img src="{@docRoot}images/tools/am-iperformanalysis.png"
  style="vertical-align:sub;margin:0;height:17px" alt="Perform Analysis icon" />.</li>
<li>Examine the items in <strong>Analysis Results</strong>. Click an item to display it in the
  HPROF Viewer.</li>
</ol>



<h3 id="hprof-sorting">Sorting heap dump data</h3>
<p>Follow this step:</p>
<ul>
<li>In the HPROF Viewer, click a column heading to sort the table by ascending or descending
  order. </li>
</ul>


<h3 id="hprof-source">Displaying Java source</h3>
<p>For some items displayed in the HPROF Viewer, you can go straight to its source code.
  Follow this step:</p>
<ul>
<li>In the HPROF Viewer, right-click a class, instance, or item in the reference tree, and then
  select <strong>Jump to Source</strong>. </li>


<p>The source code appears in the Code Editor.</p>
</ul>

<h3 id="hprof-viewing">Viewing a saved HPROF file</h3>
<p>After you do a heap dump, Android Studio automatically stores it so you can view it again.
  Follow these steps:</p>

<ol>
<li>Click <strong>Captures</strong> in the main window.</li>

<p>The <em>Captures</em> window appears.</p>
<li>Open the <strong>Heap Snapshot</strong> folder.</li>
<li>Double-click the file to view it.</li>
</ol>


<h3 id="hprof-renaming">Renaming an HPROF file</h3>

<p>If you rename a file from within Android Studio, it continues to appear in <em>Captures</em>
  window. Follow these steps:</p>
<ol>
<li>In the <em>Captures</em> window, right-click the file and select <strong>Rename</strong>. </li>
<li>In the dialog, specify the name of the file and click <strong>OK</strong>.</li>
</ol>


<h3 id="hprof-locating">Locating a heap dump file on disk</h3>
<p>You can quickly discover where Android Studio stored HPROF files on disk.</p>


<p>Follow this step in Android Studio: </p>
<ul>
<li>In the <em>Captures</em> window, right-click a heap snapshot file and select
  <strong>Show in files</strong>.</li>

<p>Android Studio opens an operating system file browser displaying the location where the file
  resides.</p>
</ul>
<p class="note"><strong>Note:</strong> If you move an HPROF file, Android Studio no longer
  displays it in the <em>Captures</em> window. To display it, use
  <strong>File</strong> &gt; <strong>Open</strong>. Also, if you want to rename the file, do it
  from the <em>Captures</em> window and not in the operating system file browser. </p>

<h3 id="hprof-deleting">Deleting a heap dump file</h3>

<p>To delete a heap dump file, follow this step: </p>
<ul>
<li>In the <em>Captures</em> window, right-click a heap snapshot file and select
  <strong>Delete</strong>.</li>

<p>Android Studio deletes the file from the <em>Captures</em> dialog and from disk. </p>
</ul>

<h3 id="hprof-converting">Converting a heap dump file to standard HPROF format</h3>
<p>You can convert an HPROF file to standard format so you can use it outside of Android Studio with
  other analysis tools. Follow these steps: </p>
<ol>
<li>In the <em>Captures</em> window, right-click a heap snapshot file and select <strong>Export to
  standard .hprof</strong>.</li>
<li>In the <em>Convert Android Java Heap Dump</em> dialog, specify a filename and click
  <strong>OK</strong>.</li>


<p>Android Studio creates a binary HPROF file in the location you specified.</p>
</ol>

<h2 id="tracking">
  Tracking and Analyzing Memory Allocation
</h2>

<p>Android Studio allows you to track memory allocation as it monitors memory use. Tracking memory
  allocation allows you to monitor where objects are being allocated when you perform certain
  actions. Knowing these allocations enables you to adjust the method calls related to those actions
  to optimize app performance and memory use.</p>

<p>The Allocation Tracker does the following:</p>
<ul>
<li>Shows when and where your code allocates object types, their size, allocating thread, and stack
  traces.</li>
<li>Helps recognize memory churn through recurring allocation/deallocation patterns.</li>
<li>Help you track down memory leaks when used in combination with the HPROF Viewer. For example,
  if you see a bitmap object resident on the heap, you can find its allocation location with
  Allocation Tracker.</li>
</ul>


<p>However, it takes time and experience to learn to interpret the output from this tool.</p>

<h3 id="alloc-snapshot">Taking and displaying a snapshot of allocation data</h3>

<p>Follow these steps:</p>
<ol>
<li>While the Memory Monitor is running, click Start Allocation Tracking
  <img src="{@docRoot}images/tools/am-ialloctracking.png"
  style="vertical-align:sub;margin:0;height:17px" alt="Start Allocation Tracking icon" />. </li>
<li>Click Start Allocation Tracking
  <img src="{@docRoot}images/tools/am-ialloctracking.png"
  style="vertical-align:sub;margin:0;height:17px" alt="Start Allocation Tracking icon" /> again to
  deselect it and end the snapshot. </li>

  <p>The Memory Monitor displays the period when it took the snapshot. In the following
    figure, you can see the snapshot period, as shown on the left. By comparison, when you dump the
    Java heap, the Memory Monitor displays just the point where the heap snapshot was taken, as
    shown on the right.</p>
    <img src="{@docRoot}images/tools/am-dumpalloc.png" />

<p>Android Studio creates the heap snapshot file with the
  filename <code>Allocations_<em>yyyy.mm.dd_hh.mm.ss</em>.alloc</code> using the year, month, day,
  hour, minute, and second of the capture, for example,
  <code>Allocations_2015.11.17_14.58.48.alloc</code>.</p>
<li>Click <strong>Captures</strong> in the main window.</li>


<p>The <em>Captures</em> window appears.</p>
<li>Double-click the file to view it in the Allocation Tracker. </li>
<li>Optionally click the graphic icon to display a visual representation of the data.
  </li>
<p>
  The Allocation Tracker appears:
</p>
<img src="{@docRoot}images/tools/am-alloctracker.png" />
<p>


<p>The tool displays the following information: </p>

<table>
  <tr>
    <th scope="col">Column</th>
    <th scope="col">Description</th>
  </tr>

  <tr>
    <td><strong>Method</strong></td>
    <td>The Java method responsible for the allocation.</td>
  </tr>
  <tr>
    <td><strong>Count</strong></td>
    <td>Total number of instances allocated.</td>
  </tr>
  <tr>
    <td><strong>Size</strong></td>
    <td>The total amount of allocated memory in bytes.</td>
  </tr>

</table>


<li>Select the Group By menu option you want to display: </li>
<ul>
<li><strong>Group by Allocator</strong> </li>
<li><strong>Group by Method</strong></li>
</ul>

</ol>



<h3 id="alloc-sorting">Sorting allocation data</h3>

<p>Follow this step:</p>
<ul>
<li>In the Allocation Tracker, click a column heading to sort the table by ascending or
  descending order. </li>
</ul>


<h3 id="alloc-source">Displaying Java source</h3>
<p>For some items displayed in the Allocation Tracker, you can view the Java source. Follow one of
  these steps:</p>
<ul>
<li>In the Allocation Tracker, right-click a method and then select <strong>Jump to Source</strong>.
</li>
<li>In the Allocation Tracker, select a method and then click Jump to Source
  <img src="{@docRoot}images/tools/am-ijumptosource.png"
  style="vertical-align:sub;margin:0;height:17px" alt="Jump to Source icon" />. </li>
</ul>

<p>The source code appears in the Code Editor.</p>

<h3 id="alloc-viewing">Viewing a saved allocation tracking file</h3>
<p>After you monitor allocation tracking, Android Studio automatically stores it so you can view it
  again. Follow these steps:</p>


<ol>
<li>Click <strong>Captures</strong> in the main window.</li>


<p>The <em>Captures</em> window appears.</p>
<li>Open the <strong>Allocation Tracking</strong> folder.</li>
<li>Double-click the file to view it.</li>
</ol>


<h3 id="alloc-renaming">Renaming an allocation tracking file</h3>

<p>If you rename a file from within Android Studio, it continues to appear in the <em>Captures</em>
  window. Follow these steps:</p>
<ol>
<li>In the <em>Captures</em> window, right-click the file and select <strong>Rename</strong>.</li>
<li>In the <em>Rename</em> dialog, specify the name of the file and click <strong>OK</strong>.</li>
</ol>


<h3 id="alloc-locating">Locating an allocation tracking file</h3>
<p>You can quickly discover where Android Studio stored allocation tracking files on disk.</p>


<p>Follow this step in Android Studio: </p>
<ul>
<li>In the <em>Captures</em> window, right-click allocation file and select
  <strong>Show in Files</strong>.</li>

<p>Android Studio opens an operating system file browser displaying the location where the file
  resides.</p>
</ul>

<p class="note"><strong>Note:</strong> If you move an allocation tracking file, Android Studio
  no longer displays it in the <em>Captures</em> window. To display the file, use
  <strong>File</strong>
  &gt; <strong>Open</strong>. Also, rename the file from the <em>Captures</em>
  window and not in the operating system file browser. </p>

<h3 id="alloc-deleting">Deleting an allocation tracking file</h3>


<p>Follow this step: </p>
<ul>
<li>In the <em>Captures</em> window, right-click an allocation tracking file and select
  <strong>Delete</strong>.</li>

<p>Android Studio deletes the file from the <em>Captures</em> dialog and from disk. </p>
</ul>