IDE : android studio 

android device monitor  ddms 窗口

heap 内存使用的情况

1 打开你的app并且连接上并且打开你的调试程序

2 打开android运行的窗口，能够看道申请的内存和空闲的内存

3 点击update heap 在你需要调试的process

4 右边点击道heap的使用的情况，点击cause gc, 可以实时观看内存的情况

右边的heap途中 heapsize代表当前堆内存

allocated ：app的申请的内存

free: 空闲的内存

objects：总共对象数

下面的表格中：

data object 注意count如果过大，你就考虑是不是什么地方没有内存对象，造成内存泄漏

1－byte array 这个一半默认为图片的内存大小。

Tracking Allocations

1 打开android device monitor

2 选择你需要追踪的app的进程

3 在右边选择 Allocation Traker 的按钮

4 点击start traking

5 试试玩玩你的app

6 点击get Allocations 当你想更新的申请的内存的列表

你可以每个进程的 ，每个类的申请内存的对象大小。如果一个类的申请的内存的大小过大，你就应该怀疑这个类是否存在内存泄漏的问题。

通过命令行的形式观看内存的使用的情况

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

pid 我们通过adb shell ps 找到相应的包名的pid

adb shell ps

追踪我需要需求的app

adb shell dumpsys meminfo <>-d

通常情况下，你只需要关注下Pss Total  和private Dirty.,在一些情况下，你可能关注下Private Clean和Heap Alloc，这些提供了一些关于不同内存的分配的信息

Dalvik Heap：Dalvik分配你的app的内存，其中Pss Total包含了所有的由Zygote的分配的内存，Private Dirty 实际上是有RAM 允许你的app 分配的，Heap Alloc是Dalvik和native heap的数量，其中native heap是用来追踪你的app的。这个值是大于Pss Total和Private Dirty，因为 你的进程是从Zygote进程 fork出来的，并且他是允许分配你的进程分享给其他的。

.so mmap and .dex mmap：

这块ram是使用.so (native) .dex(Dalvik or ART)的code，Pss Total 包括进程间通信的code，Private Clean 是你的code


.oat mmap

This is the amount of RAM used by the code image which is based off of the preloaded classes which are commonly used by multiple apps. This image is shared across all apps and is unaffected by particular apps.

.art mmap

This is the amount of RAM used by the heap image which is based off of the preloaded classes which are commonly used by multiple apps. This image is shared across all apps and is unaffected by particular apps. Even though the ART image contains Object instances, it does not count towards your heap size.

.Heap(only with -d flag)

This is the amount of heap memory for your app. This excludes objects in the image and large object spaces, but includes the zygote space and non-moving space.

.LOS(only with -d flag)

This is the amount of RAM used by the ART large object space. This includes zygote large objects. Large objects are all primitive array allocations larger than 12KB.

.GC(only with -d flag)

This is the amount of internal GC accounting overhead for your app. There is not really any way to reduce this overhead.

.JITCache(only with -d flag)

This is the amount of memory used by the JIT data and code caches. Typically, this is zero since all of the apps will be compiled at installed time.

.Zygote(only with -d flag)

This is the amount of memory used by the zygote space. The zygote space is created during device startup and is never allocated into.

.NonMoving(only with -d flag)

This is the amount of RAM used by the ART non-moving space. The non-moving space contains special non-movable objects such as fields and methods. You can reduce this section by using fewer fields and methods in your app.

.IndirectRef(only with -d flag)

This is the amount of RAM used by the ART indirect reference tables. Usually this amount is small, but if it is too high, it may be possible to reduce it by reducing the number of local and global JNI references used.

Unknown

Any RAM pages that the system could not classify into one of the other more specific items. Currently, this contains mostly native allocations, which cannot be identified by the tool when collecting this data due to Address Space Layout Randomization (ASLR). As with the Dalvik heap, thePss Totalfor Unknown takes into account sharing with Zygote, andPrivate Dirtyis unknown RAM dedicated to only your app.

TOTAL

The total Proportional Set Size (PSS) RAM used by your process. This is the sum of all PSS fields above it. It indicates the overall memory weight of your process, which can be directly compared with other processes and the total available RAM.

ThePrivate DirtyandPrivate Cleanare the total allocations within your process, which are not shared with other processes. Together (especiallyPrivate Dirty), this is the amount of RAM that will be released back to the system when your process is destroyed. Dirty RAM is pages that have been modified and so must stay committed to RAM (because there is no swap); clean RAM is pages that have been mapped from a persistent file (such as code being executed) and so can be paged out if not used for a while.

ViewRootImpl

The number of root views that are active in your process. Each root view is associated with a window, so this can help you identify memory leaks involving dialogs or other windows.

AppContexts and Activities

The number of app Context and Activity objects that currently live in your process. This can be useful to quickly identify leaked Activity objects that can’t be garbage collected due to static references on them, which is common. These objects often have a lot of other allocations associated with them and so are a good way to track large memory leaks.