1.打开Memory Profiler窗口

  首先你的手机得连接到电脑；点击android profiler工具打开图像化界面如下图：

选择你需要观测的进程：

2.Memory Profiler窗口介绍

Android Profiler中包含如下的分析组件，个人觉得3.0后的android studio提供的这个工具，比之前的android monitor工具好用了很多，它包含了，CPUProfiler（应用线程 cpu占用分析） ,

Memory Profiler（内存分析）,NETWORKProfiler（流量分析）,ENERGYProfiler（电量分析），目前只关注了内存的分析，其他几项后续持续调研并添加；

一个完整的Memory Profiler窗口如下：

A：代表当前app的状态，比如当前正在ServiceOptionActivity页面，蓝色代表正在当前运行的界面，如果是灰色这代表已经离开当前页面，可以用来观测acitivity的跳转；

B：几种内存类型介绍：

Java : java代码分配的内存；

Native : c/c++代码分配的内存(有时候其实并没有使用到c/c++代码,但还是会有Native的内存分配，因为Android Framework会去通过java代码访问一些需要使用Native的资源，如图像资源Bitmap)；

Graphics : 图像缓存等，包括GL surfaces, GL textures等；

Stack : 应用中的原生堆栈和 Java 堆栈使用的内存。 这通常与您的应用运行多少线程有关；

Code : 您的应用用于处理代码和资源（如 dex 字节码、已优化或已编译的 dex 码、.so 库和字体）的内存；

Other : 系统不知道是什么类型的内存，放在这里；

Allocated : 应用分配的 Java/Kotlin 对象数。 它没有计入 C 或 C++ 中分配的对象；

C：是android profiler提供的一些工具选择：

如+，-用于放大缩小界面，或者暂停或者重新开始检测；

D：当选择了某一个切面，dump了一个hprof文件进行分析的时候，就会使用到这里的选择，

前一个选择项选择heap类型

App heap：应用在其中分配内存的主堆；

Image heap：系统启动映像，包含启动期间预加载的类。 此处的分配保证绝不会移动或消失；

Zygote heap：写时复制堆，其中的应用进程是从 Android 系统中派生的；

后一个选择项控制数据的排列方式：

Arrange by class：基于类名称对所有分配进行分组；

Arrange by package：基于软件包名称对所有分配进行分组；

Arrange by callstack：将所有分配分组到其对应的调用堆栈。 此选项仅在记录分配期间捕获堆转储时才有效。即使如此，堆中的对象也很可能是在您开始记录之前分配的，

因此这些分配会首先显示，且只按类名称列出；

E： 应用分配的 Java/Kotlin 对象数；

F： 应用分配的Native占用的空间；

G： 当前实例的大小；

H： 此实例支配的内存大小，包括了该实例直接或者间接应用到的其他对象，也就是说该对象被GC掉了后，对于的这些内存也会被回收；

I：正在分析的hprof文件，你实际dump的内存数据，注意为了保持数据的准确性，在每次dump前需要手动触发几次GC这样保证这里的数据确实存在引用链导致数据无法被回收；

J： 用于触发GC，已经切换观测项，可以在这里切换去观测其他性能数据，在dump数据前需要点击手动触发GC;

3.分析出现内存泄漏的方式：

比如现在我已经关闭了某一个activity页面，这个时候我手动触发了几次GC，然后dump一个内存hprof文件，但是，发现当前的activity还在内存中，并且占有了很多内存空间，就说明存在该界面内存泄漏

如下图，我们找到我们的程序包名，然后查看这些对象存在是否合理：

如果你发现一个类存在问题，假设如下图：

可以点击Jump to source跳转至源码进行具体分析，也可以在instance view中观测改对象的一些引用链信息，便于我们分析对象哪里被持有了导致不能被GC；