Android(安卓)Studio之内存分析

主要还是翻译了,官方的,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.

内存泄漏和使用分析

如果应用程序有效地使用内存，应用程序的性能会更好，并且在不再需要内存时释放内存。大的或随时间增长的内存泄漏是最重要的纠正。

优化内存使用的一种方法是分析大型数组。例如，你可以减少数组中单个元素的大小以节省内存吗？

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

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。

要获取和显示内存分配的快照，请参阅分配跟踪器。

更多相关文章

随机推荐