Because Android is designed for mobile devices, you should always be careful about how much random-access memory (RAM) your app uses. Although Dalvik and ART perform routine garbage collection (GC), this doesn’t mean you can ignore when and where your app allocates and releases memory. In order to provide a stable user experience that allows the system to quickly switch between apps, it is important that your app does not needlessly consume memory when the user is not interacting with it.

尽管Dalvik 有gc，但是还要注意内存使用，当应用不再与用户交互时，就不应占有内存了。

　　Even if you follow all the best practices for Managing Your App Memory during development (which you should), you still might leak objects or introduce other memory bugs. The only way to be certain your app is using as little memory as possible is to analyze your app’s memory usage with tools. This guide shows you how to do that.

时常用工具分析内存使用情况，可以保证应用使用较少的内存。

2.Interpreting Log Messages 内存分析日志中各消息的含义

　　The simplest place to begin investigating your app’s memory usage is the runtime log messages. Sometimes when a GC occurs, a message is printed to logcat. The logcat output is also available in the Device Monitor or directly in an IDE such as Android Studio.

内存分析日志中各消息可以在LogCat中看到。

2.1 Dalvik Log Messages 内存分析日志之（1）dalvikvm类型日志

In Dalvik (but not ART), every GC prints the following information to logcat:

dalvikvm类型的日志格式如下：主要有4个部分

D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time>

Example:

D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms

其中的含义如下：

GC Reason 如上例中的：  ” GC_CONCURRENT  “

　　What triggered the GC and what kind of collection it is. Reasons that may appear include:

　　触发GC的原因，它有下面几种

当应用堆开始满时，触发gc

当应用堆已经满时，还要分配内存。

创建 HPROF 文件时。

当代码中调用了gc() 时触发， 应避免直接调用。

api 10 以下才有可能出现的情况

Amount freed 上例中的  freed 2049K

　被gc回收的内存总量,

　　The amount of memory reclaimed from this GC.

Heap stats ＊ 上例中的 65% free 3571K/9991K

　释放的比例和对象大小／堆总量，如果这个数持续增加，说明有内存泄漏。

　　Percentage free of the heap and (number of live objects)/(total heap size).

External memory stats 上例中的 external 4703K/5261K

　在外部申请的内存，api10以下才出现。

　　Externally allocated memory on API level 10 and lower (amount of allocated memory) / (limit at which collection will occur).

Pause time 上例中的 paused 2ms+2ms

　释放所用的时间

　　Larger heaps will have larger pause times. Concurrent pause times show two pauses: one at the beginning of the collection and another near the end.

　　As these log messages accumulate, look out for increases in the heap stats (the 3571K/9991K value in the above example). If this value continues to increase, you may have a memory leak.

　注意其中 的  heap stats the 3571K/9991K， 如果该值持续增加，表明有内存泄漏。

2.2 ART Log Messages 内存分析日志之（2）ART型日志

　　Unlike Dalvik, ART doesn't log messages for GCs that were not explicitly requested. GCs are only printed when they are  they are deemed slow. More precisely, if the GC pause exceeds than 5ms or the GC duration exceeds 100ms. If the app is not in a pause perceptible process state, then none of its GCs are deemed slow. Explicit GCs are always logged.

ART只在有必要时才在logcat中打印日志，如：gc停顿5ms以上，或运行超过100ms。如果进程还是在不可见态，gc不会认为运行变慢了。

ART includes the following information in its garbage collection log messages:

art型日志的格式如下：

I/art: <GC_Reason> <GC_Name> <Objects_freed>(<Size_freed>) AllocSpace Objects, <Large_objects_freed>(<Large_object_size_freed>) <Heap_stats> LOS objects, <Pause_time(s)>

Example:

I/art : Explicit concurrent mark sweep GC freed 104710(7MB) AllocSpace objects, 21(416KB) LOS objects, 33% free, 25MB/38MB, paused 1.230ms total 67.216ms

GC Reason 如上例中： I/art : Explicit

　　触发GC的原因，它有下面几种：

　　What triggered the GC and what kind of collection it is. Reasons that may appear include:

另一个在其它后台线程中的gc被触发，它不阻止清理本线程的内存。

当应用的堆已満时，在线程中申请内存时，这个gc被触发。

这个是由直接调用gc()或gc().触发，art建议不要直接调用gc()，

本地语言（如c/c++）写的代码中内存有压力时触发。

运行时gc切换后触发，具体是在内存较低的设备上，一个进程从可见状态到不可见状态切换时。

当系统整理内存碎片时触发。

不是一个真正的gc清理，而是一个通知，当系统正在内存压缩内存，调用GetPrimitiveArrayCritical被阻止时，
通常GetPrimitiveArrayCritical失败是由于移动gc的限制。

不是一个真正的gc清理，裁剪堆过程中gc不可以回收，它被阻止时收到的通知。

GC Name 如上例中：  concurrent mark sweep GC

　　ART has various different GCs which can get run.

ART 里有多个gc，它们如下：

一个较完整的gc，除了镜像空间，都能清理。

除镜像空间和zygote空间，都可清理的gc。

这个gc比前两个常用，它运行更快同时有较少的停顿。

压缩堆时使用的副本gc。

Objects freed 上例中： 104710(7MB) AllocSpace objects  中的104710

　　The number of objects which were reclaimed from this GC from the non large object space.

本次gc回收的AllocSpace objects 的数目

Size freed 上例中： 104710(7MB) AllocSpace objects  中的7MB

　　The number of bytes which were reclaimed from this GC from the non large object space.

本次gc回收的Los objects大小

Large objects freed  上例中的： 21(416KB) LOS objects 中的21

　　The number of object in the large object space which were reclaimed from this garbage collection.

本次gc回收的大对象的数目。

Large object size freed 上例中的： 21(416KB) LOS objects 中的416KB

　　The number of bytes in the large object space which were reclaimed from this garbage collection.

本次gc回收的大对象的字节大小。

Heap stats 上例中的  33% free, 25MB/38MB

　　Percentage free and (number of live objects)/(total heap size).

回收所占比例 ， 活动对象的大小／堆总计大小

Pause times 上例中的 paused 1.230ms total 67.216ms

　　In general pause times are proportional to the number of object references which were modified while the GC was running. Currently, the ART CMS GCs only has one pause, near the end of the GC. The moving GCs have a long pause which lasts for the majority of the GC duration.

检查内存泄漏的一个方法：

　　If you are seeing a large amount of GCs in logcat, look for increases in the heap stats (the 25MB/38MB value in the above example). If this value continues to increase and doesn't ever seem to get smaller, you could have a memory leak. Alternatively, if you are seeing GC which are for the reason "Alloc", then you are already operating near your heap capacity and can expect OOM exceptions in the near future.

在ART类型的日志中，有两条信息说明有内存泄漏：
1，注意上例中的 25MB/38MB  如果这个值持续增加且不减少，说明有内存泄漏。
2，当触发gc的原因是 Alloc 时。

3.Viewing Heap Updates 查看当前内存快照的2种方法

　　To get a little information about what kind of memory your app is using and when, you can view real-time updates to your app's heap in Android Studio's HPROF viewer or in the Device Monitor:

可以在android studio中查看当前app的内存，cpu,gpu,网络使用情况，并进行分析。

3.1 Memory Monitor in Android Studio 查看当前内存快照方法（1）：用AS

　　Use Android Studio to view your app's memory use:

监查内存的步骤如下：

1. Start your app on a connected device or emulator.
2. Open the Android run-time window, and view the free and allocated memory in the Memory Monitor.
3. Click the Dump Java Heap icon () in the Memory Monitor toolbar.

   　Android Studio creates the heap snapshot file with the filename Snapshot-yyyy.mm.dd-hh.mm.ss.hprof in the Captures tab.

   按 Dump Java Heap 图标

4. Double-click the heap snapshot file to open the HPROF viewer.

   Note: To convert a heap dump to standard HPROF format in Android Studio, right-click a heap snapshot in the Captures view and select Export to standard .hprof.

   在HPROF中查看快照，Captures tab页面中可以把as生成的.hprof转成mat可打开的标准 .hprof

5. Interact with your app and click the () icon to cause heap allocation.

   按 Initiate GC 图标。

6. Identify which actions in your app are likely causing too much allocation and determine where in your app you should try to reduce allocations and release resources.

   看哪里用内存多，然后调整。

3.2 Device Monitor 观察内存快照方法（2）：用 device monitor

1. Open the Device Monitor.

   From your <sdk>/tools/ directory, launch the monitor tool.

2. In the Debug Monitor window, select your app's process from the list on the left.
3. Click Update Heap above the process list.
4. In the right-side panel, select the Heap tab.

The Heap view shows some basic stats about your heap memory usage, updated after every GC. To see the first update, click the Cause GC button.

　　　　　　Figure 1. The Device Monitor tool, showing the [1] Update Heap and [2] Cause GC buttons. The Heap tab on the right shows the heap results.

Continue interacting with your app to watch your heap allocation update with each garbage collection. This can help you identify which actions in your app are likely causing too much allocation and where you should try to reduce allocations and release resources.

4.Tracking Allocations 跟踪记录内存分配的2种方法

　　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 useful not only for looking at specific uses of memory, but also to analyze critical code paths in an app such as scrolling.

跟踪记录内存使用记录是个好习惯，它可以知道哪些对象占用了大量内存，也可分析哪些代码有危险。

　　For example, tracking allocations when flinging a list in your app allows you to see all the allocations that need to be done for that behavior, what thread they are on, and where they came from. This is extremely valuable for tightening up these paths to reduce the work they need and improve the overall smoothness of the UI.

　　To use the Allocation Tracker, open the Memory Monitor in Android Studio and click the Allocation Tracker icon. You can also track allocations in the Android Device Monitor:

4.1 Android Studio 跟踪记录内存分配方法（1）：用AS

To use the Allocation Tracker in Android Studio:

　用AS跟踪内存使用情况的步骤：

1. Start your app on a connected device or emulator
2. Open the Android run-tme window, and view the free and allocated memory in the Memory Monitor.
3. Click the Allocation Tracker icon () in the Memory Monitor tool bar to start and stop memory allocations.

   　Android Studio creates the allocation file with the filename Allocations-yyyy.mm.dd-hh.mm.ss.alloc in the Captures tab.

   按 Allocation Tracker 图标

4. Double-click the allocation file to open the Allocation viewer.
5. Identify which actions in your app are likely causing too much allocation and determine where in your app you should try to reduce allocations and release resources.

   看哪里占内存多，然后调整。

4.2 Device Monitor 跟踪记录内存分配方法（2）：用device monitor

　使用device monitor的步骤：

1. Open the Device Monitor.

   From your <sdk>/tools/ directory, launch the monitor tool.

2. In the DDMS window, select your app's process in the left-side panel.
3. In the right-side panel, select the Allocation Tracker tab.
4. Click Start Tracking.

   按 Start Tracking 按钮

5. Interact with your app to execute the code paths you want to analyze.
6. Click Get Allocations every time you want to update the list of allocations.

   按Get Allocations 按钮

　　The list shows all recent allocations, currently limited by a 512-entry ring buffer. Click on a line to see the stack trace that led to the allocation. The trace shows you not only what type of object was allocated, but also in which thread, in which class, in which file and at which line.

　　　　　　　　　　　　　　Figure 2. The Device Monitor tool, showing recent app allocations and stack traces in the Allocation Tracker.

Note: You will always see some allocations from DdmVmInternal and elsewhere that come from the allocation tracker itself.

　注意 device monitor 本身也会有一些内存分配，还要把它们当作你的应用分配的

　　Although it's not necessary (nor possible) to remove all allocations from your performance critical code paths, the allocation tracker can help you identify important issues in your code. For instance, some apps might create a new Paint object on every draw. Moving that object into a global member is a simple fix that helps improve performance.

5.Viewing Overall Memory Allocations 用adb全局查看内存使用情况

5.1 命令

　　For further analysis, you may want to observe how your app's memory is divided between different types of RAM allocation with the following adb command:

adb shell dumpsys meminfo <package_name|pid> [-d]

The -d flag prints more info related to Dalvik and ART memory usage.

The output lists all of your app's current allocations, measured in kilobytes.

When inspecting this information, you should be familiar with the following types of allocation:

用上述命令打印的结果，你应注意下面这两个类型的分配。

Private (Clean and Dirty) RAM

　　This is memory that is being used by only your process. This is the bulk of the RAM that the system can reclaim when your app’s process is destroyed. Generally, the most important portion of this is “private dirty” RAM, which is the most expensive because it is used by only your process and its contents exist only in RAM so can’t be paged to storage (because Android does not use swap). All Dalvik and native heap allocations you make will be private dirty RAM; Dalvik and native allocations you share with the Zygote process are shared dirty RAM.

Private Clean和Private Dirty 是你的应用进程产生的内存，其中private dirty是运行时产生的无用内存。注意：所有的Dalvik与本地的分配都产生private dirty ram.应用进程与Zygote共享的内存是 shared dirty ram.

Proportional Set Size (PSS)

　　This is a measurement of your app’s RAM use that takes into account sharing pages across processes. Any RAM pages that are unique to your process directly contribute to its PSS value, while pages that are shared with other processes contribute to the PSS value only in proportion to the amount of sharing. For example, a page that is shared between two processes will contribute half of its size to the PSS of each process.

　　A nice characteristic of the PSS measurement is that you can add up the PSS across all processes to determine the actual memory being used by all processes. This means PSS is a good measure for the actual RAM weight of a process and for comparison against the RAM use of other processes and the total available RAM.

　　

　　For example, below is the the output for Map’s process on a Nexus 5 device. There is a lot of information here, but key points for discussion are listed below.

下面是一个adb shell dumsys meminfo xxx 示例

adb shell dumpsys meminfo com.google.android.apps.maps -d

Note: The information you see may vary slightly from what is shown here, as some details of the output differ across platform versions.

** MEMINFO in pid 18227 [com.google.android.apps.maps] **

                   Pss  Private  Private  Swapped     Heap     Heap     Heap

                 Total    Dirty    Clean    Dirty     Size    Alloc     Free

                ------   ------   ------   ------   ------   ------   ------

  Native Heap    10468    10408        0        0    20480    14462     6017

  Dalvik Heap    34340    33816        0        0    62436    53883     8553

 Dalvik Other      972      972        0        0

        Stack     1144     1144        0        0

      Gfx dev    35300    35300        0        0

    Other dev        5        0        4        0

     .so mmap     1943      504      188        0

    .apk mmap      598        0      136        0

    .ttf mmap      134        0       68        0

    .dex mmap     3908        0     3904        0

    .oat mmap     1344        0       56        0

    .art mmap     2037     1784       28        0

   Other mmap       30        4        0        0

   EGL mtrack    73072    73072        0        0

    GL mtrack    51044    51044        0        0

      Unknown      185      184        0        0

        TOTAL   216524   208232     4384        0    82916    68345    14570

 Dalvik Details

        .Heap     6568     6568        0        0

         .LOS    24771    24404        0        0

          .GC      500      500        0        0

    .JITCache      428      428        0        0

      .Zygote     1093      936        0        0

   .NonMoving     1908     1908        0        0

 .IndirectRef       44       44        0        0

 Objects

               Views:       90         ViewRootImpl:        1

         AppContexts:        4           Activities:        1

              Assets:        2        AssetManagers:        2

       Local Binders:       21        Proxy Binders:       28

       Parcel memory:       18         Parcel count:       74

    Death Recipients:        2      OpenSSL Sockets:        2

　　Here is an older dumpsys on Dalvik of the gmail app:

** MEMINFO in pid 9953 [com.google.android.gm] **

                 Pss     Pss  Shared Private  Shared Private    Heap    Heap    Heap

               Total   Clean   Dirty   Dirty   Clean   Clean    Size   Alloc    Free

              ------  ------  ------  ------  ------  ------  ------  ------  ------

  Native Heap      0       0       0       0       0       0    7800    7637(6)  126

  Dalvik Heap   5110(3)    0    4136    4988(3)    0       0    9168    8958(6)  210

 Dalvik Other   2850       0    2684    2772       0       0

        Stack     36       0       8      36       0       0

       Cursor    136       0       0     136       0       0

       Ashmem     12       0      28       0       0       0

    Other dev    380       0      24     376       0       4

     .so mmap   5443(5) 1996    2584    2664(5) 5788    1996(5)

    .apk mmap    235      32       0       0    1252      32

    .ttf mmap     36      12       0       0      88      12

    .dex mmap   3019(5) 2148       0       0    8936    2148(5)

   Other mmap    107       0       8       8     324      68

      Unknown   6994(4)    0     252    6992(4)    0       0

        TOTAL  24358(1) 4188    9724   17972(2)16388    4260(2)16968   16595     336

 Objects

               Views:    426         ViewRootImpl:        3(8)

         AppContexts:      6(7)        Activities:        2(7)

              Assets:      2        AssetManagers:        2

       Local Binders:     64        Proxy Binders:       34

    Death Recipients:      0

     OpenSSL Sockets:      1

 SQL

         MEMORY_USED:   1739

  PAGECACHE_OVERFLOW:   1164          MALLOC_SIZE:       62

　　Generally, you should be concerned with only the Pss Total and Private Dirty columns. In some cases, the Private Clean and Heap Alloc columns also offer interesting data. Here is some more information about the different memory allocations (the rows) you should observe:

在看adb shell dumpsys meminfo打印结果时，应注意 Pss Total,Private Dirty, Private Clean,Heap Alloc这几个列。

5.2 meminfo每行的含义

Dalvik 使用的内存大小：其中

Pss Total 列是Zygote分配的内存大小（含共享部分）

Private Dirty 列是应用进程分配的内存和从zygote生成进程时带过来的内存。

注意：在新版本中还有 Dalvik Other这行。

Heap Alloc列是应用进程 Dalvik和本地堆的内存记录。

已经映射的.so和.dex内存大小，其中：
Pass Total包含共享部分，
Private Clean 只是应用进程部分.

多个app之间共享的 预映射的class 代码镜像大小。

多个app之间共享的 预映射的class 堆镜像大小。这个镜像是很多应用共享。

命令中加入 -d 后才能显示。应用的堆大小。包含zygote空间和不静态空间，但是不含镜像和大对象空间。

ART大对象空间，包含zygote大对象，大对象一般大于12kb.

应用内部记录的gc减少的数量。

JIT 数据和代码缓存大小。

这里系统启动时占用的zygote的大小，它是固定的。

ART使用的静态空间大小，里面是静态变量或静态方法。可以在代码中减小它们。

ART间接引用的空间大小，它很重要，可以通过减小本地或全局jni引用。

系统不能归类的RAM页，通常里面包含由于地址布局不规则(Adress Space Layout Randomization)
导致无法回收的本地分配。其中：

 Pss Total 是未知的共享zygote大小

应用进程总内存开销，其中：
Private Dirty 和 Private Clean是进程自己分配的大小。
Dirty在进程结束后被回收。
Clean 是应用进程映射的page 对应的文件大小。 

应用进程中 root views 占的空间大小.每个view可能包含一个窗口。

应用进程中活动的 Context和Activity 占空间大小。可以通过它快速识别没被回收的对象,
它们通常是由于静态引用。

Note: A View or Drawable object also holds a reference to the Activity that it's from, so holding a View or Drawable object can also lead to your app leaking an Activity.

注意：

    View 或 Drawable都产生对Activity的引用，它们可能导致内存泄漏。

6.Capturing a Heap Dump 捕获内存快照的3种方法

　　A heap dump is a snapshot of all the objects in your app's heap, stored in a binary format called HPROF. Your app's heap dump provides information about the overall state of your app's heap so you can track down problems you might have identified while viewing heap updates.

内存使用堆记录了内存堆中对象快照，可能通过它分析出哪里出了问题。

方法（1）使用AS

　　To retrieve your heap dump from within Android Studio, use the Memory Monitor and HPROF viewer.

方法（2）使用 device monitor

　　You can also still perform these procedures in the Android monitor:

1. Open the Device Monitor.

   From your <sdk>/tools/ directory, launch the monitor tool.

2. In the DDMS window, select your app's process in the left-side panel.
3. Click Dump HPROF file, shown in figure 3.
4. In the window that appears, name your HPROF file, select the save location, then click Save.

　　　　　　　　　　　　Figure 3. The Device Monitor tool, showing the [1] Dump HPROF file button.

方法（2）在代码中使用 dumpHprofData()方法 

　　If you need to be more precise about when the dump is created, you can also create a heap dump at the critical point in your app code by calling dumpHprofData().

　　The heap dump is provided in a format that's similar to, but not identical to one from the Java HPROF tool. The major difference in an Android heap dump is due to the fact that there are a large number of allocations in the Zygote process. But because the Zygote allocations are shared across all app processes, they don’t matter very much to your own heap analysis.

　　To analyze your heap dump, you can use Memory Monitor in Android Studio. You can also use a standard tool like jhat. However, first you'll need to convert the HPROF file from Android's format to the J2SE HPROF format. You can do this using the hprof-conv tool provided in the <sdk>/platform-tools/ directory. Simply run the hprof-conv command with two arguments: the original HPROF file and the location to write the converted HPROF file. For example:

android 下生成的.hprof与标准的.hprof格式不同，它包含了zygote进程的分配信息。
可以在AS中直接把它转换，也可以用命令行工具转换。下面就是命令行转换示例：

hprof-conv heap-original.hprof heap-converted.hprof

　　You can now load the converted file into a heap analysis tool that understands the J2SE HPROF format.

When analyzing your heap, you should look for memory leaks caused by:

从.hprof分析内存时应注意内存泄漏，通常由于下面几个原因：

• Long-lived references to an Activity, Context, View, Drawable, and other objects that may hold a reference to the container Activity or Context.

  长期存在的Activity,Context,View,Drawable,它们可能由于其它对象引用而导致的。

• Non-static inner classes (such as a Runnable, which can hold the Activity instance).

  非静态内部类，它可导致Activity实例长期存在。

• Caches that hold objects longer than necessary.

  缓存可能长期引用一个对象。

7.Triggering Memory Leaks 如何让程序暴漏内存泄漏的方法

　　While using the tools described above, you should aggressively stress your app code and try forcing memory leaks. One way to provoke memory leaks in your app is to let it run for a while before inspecting the heap. Leaks will trickle up to the top of the allocations in the heap. However, the smaller the leak, the longer you need to run the app in order to see it.

当上述工具分析内存时，应积极检查内存泄漏，通常把程序运行到某一个模块后呆一会，大的内存泄漏会慢慢地在堆顶，小的内存漏泄可能需要的时间多些。

　　You can also trigger a memory leak in one of the following ways:

下面这两个方法可以加快让程序出现内存泄漏

1. Rotate the device from portrait to landscape and back again multiple times while in different activity states. Rotating the device can often cause an app to leak an Activity, Context, or View object because the system recreates the Activity and if your app holds a reference to one of those objects somewhere else, the system can't garbage collect it.

   旋转activity

2. Switch between your app and another app while in different activity states (navigate to the Home screen, then return to your app).

   在不同的activity或应用间切换，切到home，再切回到你的应用。

　　Tip: You can also perform the above steps by using the "monkey" test framework. For more information on running the monkey test framework, read the monkeyrunner documentation.

也可以使用 monkey 这个 开源库检查内存泄漏。monkeyrunner