主要还是翻译了,官方的,Android studio 使用,对比着Androidstudio,让你马上成为内存分析高手
Android Monitorprovides 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:
Android Monitor提供了一个内存监视器，以便您可以更轻松地监视应用程序性能和内存使用情况，以查找释放的对象，找到内存泄漏，并跟踪连接的设备使用的内存量。内存监视器报告应用程序如何分配内存，并帮助您可视化应用程序使用的内存。它允许您：
Show a graph of available and allocated Java memory
over time.
Show garbage collection (GC) events over time.
Initiate garbage collection events.
Quickly test whether app slowness might be related to
excessive garbage collection events.
Quickly test whether app crashes may be related to
running out of memory.
显示可用和分配的Java内存随时间的图表。
随着时间的推移显示垃圾收集（GC）事件。
启动垃圾回收事件。
快速测试应用程序慢度是否可能与过多的垃圾回收事件相关。
快速测试应用程式当机是否与内存用完相关。
Memory Monitor Workflow内存监视器工作流
To profile and optimize memory use, the typical
workflow is to run your app and do the following:
Profile the app using the Memory
Monitor to find out whether undesirable garbage collection event patterns
might be causing performance problems.
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.
Start allocation tracking to determine where any
problems are happening in your code.
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:
Get a sense of how your app allocates and frees memory.
Identify memory leaks.
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:
Identify where many similar object types, from roughly
the same call stack, are allocated and deallocated over a very short
period of time.
Find the places in your code that may contribute to
inefficient memory use
要配置和优化内存使用，典型的工作流程是运行您的应用程序，并执行以下操作：
使用内存监视器配置应用程序，以确定不受欢迎的垃圾收集事件模式是否可能导致性能问题。
如果在很短的时间内看到很多垃圾收集事件，请转储Java堆以标识获取或保持意外或不必要分配的候选对象类型。
开始分配跟踪，以确定您的代码中发生了什么问题。
Java堆数据实时显示应用程序分配的对象类型，数量以及它们在堆上的大小。查看堆有助于：
了解你的应用程序如何分配和释放内存。
识别内存泄漏。
分配跟踪记录应用程序内存分配，并列出分析周期的所有分配，包括调用堆栈，大小和分配代码。它可以帮助您：
识别来自大致相同的调用栈的许多类似的对象类型在很短的时间内被分配和释放。
找到代码中可能会导致低效内存使用的地方
Garbage collection roots and dominator trees
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
icon (and a depth of zero) and a dominator with
the
icon.
There are several kinds of garbage collection roots
in Java:
references on the stack
Java Native Interface (JNI) native objects and memory
static variables and functions
threads and objects that can be referenced
classes loaded by the bootstrap loader
finalizers and unfinalized objects
busy monitor objects
垃圾收集根和支配者树
当转储Java堆时，内存监视器创建一个Android特定的堆/ CPU分析（HPROF）文件，您可以在HPROF查看器中查看。HPROF查看器指示具有GC根图标图标（深度为零）的垃圾回收根以及具有Dominator图标图标的控制器。
Java中有几种垃圾回收根：
堆栈上的引用
Java本机接口（JNI）本机对象和内存
静态变量和函数
线程和对象
由引导加载程序加载的类
终结者和未定义的对象
繁忙的监视器对象
The HPROF file provides the list of roots to the
HPROF Viewer.
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.
HPROF文件向HPROF查看器提供根的列表。
控制树跟踪由应用程序创建的对象的路径。
如果到达另一对象的唯一方式是直接或间接地通过控制器对象，则对象支配另一对象。 当您检查应用程序创建的对象和路径以优化内存使用时，请尝试删除不再需要的对象。
您可以释放控制对象以释放所有下级对象。 例如，在下图中，如果您要删除对象B，那么也将释放它所支配的对象（即对象C，D，E和F）使用的内存。实际上，如果对象C，D，E和F标记为移除，但对象B仍然指向它们，这可能是它们未释放的原因。
Memory leak and use analysis
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.
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?
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.
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.
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.
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.
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.
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
内存泄漏和使用分析
如果应用程序有效地使用内存，应用程序的性能会更好，并且在不再需要内存时释放内存。大的或随时间增长的内存泄漏是最重要的纠正。
优化内存使用的一种方法是分析大型数组。例如，你可以减少数组中单个元素的大小以节省内存吗？
另一个值得关注的领域是应用程序不再需要但继续参考的对象。您可以在不同时间段收集堆转储，并比较它们以确定是否有不断增长的内存泄漏，例如您的代码多次创建但不会销毁的对象类型。例如，这些对象可以是增长数组或对象树的一部分。要跟踪这个问题，比较堆转储，看看你是否有一个特定的对象类型继续随着时间的推移有越来越多的实例。
包含根或控制器对象的持续增长的对象树可以防止从属对象被垃圾回收。此问题是内存泄漏，内存不足错误和崩溃的常见原因。您的应用程序可能具有少量对象，这会阻止大量的下级对象被破坏，因此会快速耗尽内存。要找到这些问题，请获取堆转储并检查由根和控制器对象持有的内存量。如果内存很大，你可能会找到一个好的地方开始优化你的内存使用。
当您开始缩小内存问题时，您还应该使用分配跟踪器来更好地了解分配内存分配对象的位置。分配跟踪器可以是有价值的，不仅用于查看内存的特定用途，而且用于分析关键代码路径，例如加载和滚动。例如，在应用程序中显示列表时跟踪分配，您可以查看需要为该行为完成的所有分配，它们所在的线程以及它们来自哪里。这些信息对于收紧这些路径以减少他们需要的工作和改善UI的整体平滑性是非常有价值的。
对于不必要的分配或者多次创建相同对象而不是重用它们的分配来检查算法非常有用。例如，你是否在递归循环中创建临时对象和变量？如果是这样，请尝试在循环之前创建一个对象或变量，以便在循环中使用。否则，您的应用程序可能会不必要地分配许多对象和变量，具体取决于递归的数量。
对于创建最大和最大对象的代码部分执行分配测试很重要，因为这些区域提供了最多的优化机会。除了单元测试，你应该测试你的应用程序与生产现实的数据加载，特别是那些算法是数据驱动。此外，确保考虑应用程序缓存和启动阶段，有时可能很慢;分配分析最好在该阶段后完成，以产生准确的结果。
优化代码后，请确保测试它的工作。您需要在不同的负载条件下测试，而且不需要运行内存监视器工具。比较优化前后的结果，以确保性能实际上有所提高
Memory management for different virtual machines
Android Monitor uses the Virtual Machine (VM) that
the device or emulator uses:
Android 4.3 (API level 18) and lower uses the Dalvik
VM.
In Android 4.4 (API level 19), the Android RunTime
(ART) VM is an option, while the Dalvik VM is the default.
Android 5.0 (API level 21) and higher uses the ART VM.
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.
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.
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.
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, seeAddressing Garbage Collection (GC) IssuesandInvestigating Your RAM Usage.
The ART VM adds a number of performance, development,
and debugging improvements over the Dalvik VM. For more information, seeART and Dalvik.
Memory management for different virtual machines
Android Monitor uses the Virtual Machine (VM) that
the device or emulator uses:
Android 4.3 (API level 18) and lower uses the Dalvik
VM.
In Android 4.4 (API level 19), the Android RunTime
(ART) VM is an option, while the Dalvik VM is the default.
Android 5.0 (API level 21) and higher uses the ART VM.
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.
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.
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.
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, seeAddressing Garbage Collection (GC) IssuesandInvestigating Your RAM Usage.
The ART VM adds a number of performance, development,
and debugging improvements over the Dalvik VM. For more information, seeART and Dalvik.
内存泄漏和使用分析
如果应用程序有效地使用内存，应用程序的性能会更好，并且在不再需要内存时释放内存。大的或随时间增长的内存泄漏是最重要的纠正。
优化内存使用的一种方法是分析大型数组。例如，你可以减少数组中单个元素的大小以节省内存吗？
另一个值得关注的领域是应用程序不再需要但继续参考的对象。您可以在不同时间段收集堆转储，并比较它们以确定是否有不断增长的内存泄漏，例如您的代码多次创建但不会销毁的对象类型。例如，这些对象可以是增长数组或对象树的一部分。要跟踪这个问题，比较堆转储，看看你是否有一个特定的对象类型继续随着时间的推移有越来越多的实例。
包含根或控制器对象的持续增长的对象树可以防止从属对象被垃圾回收。此问题是内存泄漏，内存不足错误和崩溃的常见原因。您的应用程序可能具有少量对象，这会阻止大量的下级对象被破坏，因此会快速耗尽内存。要找到这些问题，请获取堆转储并检查由根和控制器对象持有的内存量。如果内存很大，你可能会找到一个好的地方开始优化你的内存使用。
当您开始缩小内存问题时，您还应该使用分配跟踪器来更好地了解分配内存分配对象的位置。分配跟踪器可以是有价值的，不仅用于查看内存的特定用途，而且用于分析关键代码路径，例如加载和滚动。例如，在应用程序中显示列表时跟踪分配，您可以查看需要为该行为完成的所有分配，它们所在的线程以及它们来自哪里。这些信息对于收紧这些路径以减少他们需要的工作和改善UI的整体平滑性是非常有价值的。
对于不必要的分配或者多次创建相同对象而不是重用它们的分配来检查算法非常有用。例如，你是否在递归循环中创建临时对象和变量？如果是这样，请尝试在循环之前创建一个对象或变量，以便在循环中使用。否则，您的应用程序可能会不必要地分配许多对象和变量，具体取决于递归的数量。
对于创建最大和最大对象的代码部分执行分配测试很重要，因为这些区域提供了最多的优化机会。除了单元测试，你应该测试你的应用程序与生产现实的数据加载，特别是那些算法是数据驱动。此外，确保考虑应用程序缓存和启动阶段，有时可能很慢;分配分析最好在该阶段后完成，以产生准确的结果。
优化代码后，请确保测试它的工作。您需要在不同的负载条件下测试，而且不需要运行内存监视器工具。比较优化前后的结果，以确保性能实际上有所提高
Displaying a Running App in the Memory Monitor
To display an app running on a particular device or
emulator in the Memory Monitor:
Meet theprerequisites and dependencies.
Open an app project.
Run the appon a hardware
device or emulator.
Display
Android Monitor.
Click theMonitorstab anddisplay the Memory Monitor.
Enable the Memory Monitor by clicking Pause
to deselect it.
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.
To force a garbage collection event, click Initiate
GC
.
In the following figure, the VM initiated the first
garbage collection event, while the developer forced the second.
在内存监视器中显示正在运行的应用程序
要在内存监视器中显示在特定设备或模拟器上运行的应用程序：
满足先决条件和依赖关系。
打开应用程序项目。
在硬件设备或模拟器上运行应用程序。
显示Android监视器。
单击监视器选项卡并显示内存监视器。
通过单击暂停暂停图标来取消选择内存监视器。
在图中，y轴以兆字节显示空闲和分配的RAM。x轴表示经过的时间;它以秒，然后是分钟和秒开始，以此类推。
可用内存量（以兆字节为单位）以浅色显示，分配的内存为较暗的颜色。 当分配的内存急剧下降时，这表示垃圾回收事件。
要强制垃圾回收事件，请单击启动GC启动GC图标。
在下图中，VM启动了第一次垃圾收集事件，而开发人员强制第二次。
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're healthy
and what you expect.
The graph can show you potential issues:
Excessive garbage collection events slow down the app.
The app runs out of memory, which causes it to crash.
Potential memory leaks.
For example, you might see the following signs of
problems:
Your app is static, but you see memory being allocated
in the monitor.
You see spikes of memory allocations in the monitor,
but you don’t think there’s any app logic to cause this behavior.
To stop the Memory Monitor, click
Pause
again to select it.
Forcing a Garbage Collection Event
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.
To force a garbage collection event:
While theMemory
Monitor is running, click Initiate GC
与您的应用程序交互，并观察它如何影响内存监视器中的内存使用情况。您可以识别应用程序的垃圾回收模式，并确定它们是否健康，以及您期望的内容。
该图表可以显示潜在问题：
过多的垃圾收集事件会减缓应用程序。
应用程序内存不足，导致它崩溃。
潜在内存泄漏。
例如，您可能会看到以下问题的迹象：
您的应用程序是静态的，但您会看到在显示器中分配的内存。
您会看到显示器中的内存分配峰值，但您不认为有任何应用程序逻辑导致此行为。
要停止内存监视器，请再次单击暂停暂停图标以将其选中。
强制垃圾收集事件
通常，VM仅在绝对需要时执行垃圾收集，因为它很昂贵。然而，在某些情况下强制垃圾收集是有用的。例如，当定位内存泄漏时，如果要确定是否已成功释放大对象，则可以比通常更积极地启动垃圾回收。
强制垃圾收集事件：
当内存监视器运行时，单击启动GC启动GC图标
Taking a Snapshot of the Java Heap and Memory
Allocation
You can take snapshots while the Memory Monitor is
running or paused:
To take and display a snapshot of the Java heap,
seeHPROF Viewer
and Analyzer.
To take and display a snapshot of memory allocation,
seeAllocation
Tracker.
获取Java堆和内存分配的快照
您可以在内存监视器运行或暂停时拍摄快照：
要获取和显示Java堆的快照，请参阅HPROF Viewer和Analyzer。
要获取和显示内存分配的快照，请参阅分配跟踪器。