Android Studio和MAT结合使用来分析内存问题

Posted 2020-09-06 一点点征服

Android开发中时常会遇到内存泄漏的问题，而android系统对单个App又有一定的内存限制，此值可以通过一下方式获取：

ActivityManager am = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);
int memoryClass = am.getMemoryClass();

上述代码中momeryClass的值可以当做每个App的内存限制。这个值根据不同的设备厂商都是不一样的，比如我的模拟器的值是32M，如果在我的模拟器上运行的一个App，分配的内存空间超过32M，则会报OOM(内存溢出)！而内存泄漏也是一个导致内存溢出的隐患，因此必须掌握解决内存溢出的方法。

本章主要讲解使用Android Studio查看是否有内存泄漏问题，然后使用MAT(Memory Analyzer Tool)来分析并解决内存泄漏问题。

Android Studio分析是否有内存泄漏

---

打开Android Studio中的Android Monitor中的Memory面板，可以看到有一个实时变化的堆内存曲线图，如下图所示

上图中重点列出了3部分内容：

1. 被测试的终端设置，如图所示我是在模拟器Nexus_S上做测试
2. 被测试的进程，点击可选择其他Application或者进程
3. 当前被测试的进程中内存分配情况
   
   • Allocated代表已分配的空间
   • Free代表可用剩余空间
   • Allocated + Free不能超App内存限制(32M)

4. 内存分析的工具栏，从上向下一共4个按钮，依次是：
   终止检测的开关，没什么实质性的作用

   就是手动调用GC，我们在抓内存前，一定要手动点击 Initiate GC按钮手动触发GC，这样抓到的内存使用情况就是不包括Unreachable对象的（Unreachable指的是可以被垃圾回收器回收的对象，但是由于没有GC发生，所以没有释放，这时抓的内存使用中的Unreachable就是这些对象）

   获取hprof文件（hprof文件是我们使用MAT工具分析内存时使用的文件），但这里直接产生的文件MAT还不能直接使用，需用转换成标准的hprof文件。可以使用AndroidStudio转换或者用hprof-conv命令转化，网上可以查到

   开始分配追踪，第一次点击可以指定追踪内存的开始位置，第二次点击可以结束追踪的位置。这样我们截取了一段要分析的内存，等待几秒钟AndroidStudio会给我们打开一个Allocation视图（感觉和MAT工具差不多，不过MAT工具更加强大，我们也可以获取hprof文件，使用MAT来分析）

写一段代码动态演示一下：

xml布局文件如下,定义一个Button，并设置onClick属性

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <Button
        android:text="测试Memory Monitor"
        android:onClick="click"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

</LinearLayout>

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14

Activity代码如下：声明Button被点击回调的click方法

public void click(View view) {
        for (int i = 0; i < 10000; i++) {
            ImageView imageView = new ImageView(this);
            list.add(imageView);
        }
}

• 1
• 2
• 3
• 4
• 5
• 6

• 1
• 2
• 3
• 4
• 5
• 6

通过上面代码，可以预见，每次点击Button时，都会动态生成10000个ImageView并添加到List中保存起来，Memory的效果图如下：

可以看到，刚开始系统分配了2M左右的内存，当点击一次Button之后，内存增加到8M，再次点击内存增加到24M左右。
上述情况下，当我们按下返回退出Activity时，然后点击Init GC按钮执行垃圾回收操作，进程中的内存会重新回到2M，如下图：

这种情况下，代码是安全稳定的代码，但是如果Activity中有内存泄漏会是何种情况呢，接下来我们先把之前的代码修改一下，认为构造一个内存泄漏的场景，如下代码所示：

public class MainActivity extends AppCompatActivity {

    private List<ImageView> list = new ArrayList<>();

    static MemoryLeak memoryLeak;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        if (memoryLeak == null) {
            memoryLeak = new MemoryLeak();
        }

    }

    public void click(View view) {
        for (int i = 0; i < 10000; i++) {
            ImageView imageView = new ImageView(this);
            list.add(imageView);
        }
    }

    class MemoryLeak {
        void doSomeThing() {
            System.out.println("Wheee!!!");
        }
    }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29

可以看到，在MainActivity中，添加了一个非静态内存类MemoryLeak，然后声明了一个静态MemoryLeak引用。
运行上述代码，然后再次执行点击Button的操作，可以看到内存同样会上升到8M左右，再次点击上升到16M左右，但是此时按下返回按钮并执行垃圾回收操作之后，Allocated + Free的总空间并没有重新回到2M左右，而是一直徘徊于8M左右 说明存在内存泄漏！！！ 但是为什么会是8M呢？？

Android Studio生成内存字节文件

---

刚才在介绍Studio的Memory面板时，有提到一个工具栏Dump Java Heap，通过点击此按钮就可以导出一个hprof文件，此过程会比较慢，需要耐心等待，当下图中心的圆圈停止转动之后hprof文件也就导出成功

导出完成后将自动打开这个文件，如下图所示：

点击Analyzer Tasks右边的绿色运行箭头，Android Studio会自动的根据此hprof文件分析有哪些类是有内存泄漏的，如下图所示：

确实有一个MainActivity存在内存泄漏的情况，但是跟我之前预想的有一点出入，本来以为向网上很多人说的那样，每次打开一个MainActivity时都会造成内存泄漏，但是现在事实就摆在眼前。仔细想了一下也恍然大悟了，MemoryLeak在第一个MainActivity中被声明是static静态的，当第二个被打开的MainActivity并不会再重新初始化MemoryLeak对象了，因此static MemoryLeak对象在内存中只是持有了第一个MainActivity的对象的引用，因此当我们调用多次GC操作之后，实际上只有第一个MainActivity不会被GC回收掉！！

如果再将Activity的代码修改一下

package material.danny_jiang.com.adbmemoryanalyze;

import android.app.ActivityManager;
import android.content.Context;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.util.Log;
import android.view.View;
import android.widget.ImageView;

import java.util.ArrayList;
import java.util.List;

public class MainActivity extends AppCompatActivity {

    private List<ImageView> list = new ArrayList<>();

    //private static MemoryLeak memoryLeak;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        //memoryLeak = new MemoryLeak();

    }

    public void click(View view) {
        for (int i = 0; i < 10000; i++) {
            ImageView imageView = new ImageView(this);
            list.add(imageView);
        }

        new Thread() {
            @Override
            public void run() {
                super.run();
                while (true) {
                    try {
                        System.out.println("Thread running!!");
                        Thread.sleep(300);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }
        }.start();
    }

    class MemoryLeak {
        void doSomeThing() {
            System.out.println("Wheee!!!");
        }
    }
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35
• 36
• 37
• 38
• 39
• 40
• 41
• 42
• 43
• 44
• 45
• 46
• 47
• 48
• 49
• 50
• 51
• 52
• 53
• 54
• 55
• 56
• 57

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35
• 36
• 37
• 38
• 39
• 40
• 41
• 42
• 43
• 44
• 45
• 46
• 47
• 48
• 49
• 50
• 51
• 52
• 53
• 54
• 55
• 56
• 57

可以看到，我讲造成内存泄漏的场景由内部类改成了内部线程类，并且在线程中无限循环打印log。

再次执行进入MainActivity–返回键–进入MainActivity–返回键的操作

然后再生成hprof文件并打开，并执行Analyzer Tasks，可以看到如下图片的信息：

上图可以看出打开的每一个MainActivity都会造成内存泄漏。 擦嘞！！为什么这会儿又是这种情况呢？？？这个问题就牵涉到Java中线程的问题了—Java中的Thread有一个特点就是她们都是直接被GC Root所引用，也就是说Dalvik虚拟机对所有被激活状态的线程都是持有强引用，导致GC永远都无法回收掉这些线程对象，除非线程被手动停止并置为null或者用户直接kill进程操作。看到这相信你应该也是心中有答案了吧 : 我在每一个MainActivity中都创建了一个线程，此线程会持有MainActivity的引用，即使退出Activity当前线程因为是直接被GC Root引用所以不会被回收掉，导致MainActivity也无法被GC回收。所以当使用线程时，一定要考虑在Activity退出时，及时将线程也停止并释放掉

MAT内存分析工具

---

正常来讲，根据上面我讲的使用Studio来分析简单的内存泄漏已经足够了，但是在Studio之前有一款更加强大的内存分析工具MAT，谷歌工程师称它更加的Powerful！！。接下来就看一下如何使用MAT来分析内存问题

1 首先在eclipse官网下载MAT工具

https://www.eclipse.org/mat/

2 下载完MAT并安装好之后，需要先生成hprof文件。

这两我还是使用之前线程造成内存泄漏的案例来演示，

• 首先第一次打开MainActivity时，点击dump heap生成一个hprof文件
• 其次进行一系列的操作, 比如点击Button，按下返回键，再次进入MainActivity等等，这里我重复了4遍如上操作，然后再点击dump heap生成hprof文件

3 点击Studio的Captures栏，显示刚才生成的hprof文件，如下图所示：

这两个文件我们需要使用MAT去打开并对比分析，但是MAT不能直接打开这两个文件，需要将它转换成MAT能够识别的文件，Captures栏中，右键点击每一个hprof文件，然后选择Export to standard .hprof并保存到电脑目录中,如下图：

4 使用MAT打开转换后的hprof文件，显示如下图

可以看到有两个dump的面板，其中每一个都显示了一个内存的饼状图。其中用的最多的功能是左下角的Histogram, 点击 Actions下的 Histogram项将得到 Histogram结果：

它按类名将所有的实例对象列出来，可以点击表头进行排序,在表的第一行可以输入正则表达式来匹配结果 :

在Histogram中，可以右键某一想查看的对象，然后选中List Objects来查看此对象的所有实例，如下图

选中之后，会跳出所有实例对象面板，在此面板中可以可以继续某一特定实例在内存中的Path To GC Root(从GC开始的强引用)。在之前的案例操作中，我重复的进入MainActivity4次，并依次点击Button运行线程，因此正常来说MainActivity应该有4个实例在内存当中，如下图

exclude all phantom/weak/soft的意思是讲所有的虚引用/软引用/弱引用都排除掉，因为只有强引用才会造成内存泄漏！点击之后显示下图信息：

可以看到，MainActivity最终都是被一个叫做MainActivity1的对象引用，而MainActivity1就是在click方法中创建的匿名内部类Thread对象。 最终我们找到了内存泄漏的根本原因 : 当Activity退出之后，Thread因为被GC Root直接引用，所以不会被GC回收掉，而Thread又持有Activity的引用导致Activity也无法被GC正常回收掉，造成了Activity的内存泄漏，大功告成！！！

如何发现内存泄漏

---

上面分别介绍了使用Android studio和MAT分析内存的方法。Android studio自带的内存分析工具直观方便，但其功能却不如MAT强大，特别是没有有效的搜索、排序等功能。遇到一些棘手的问题，可能还是要借助MAT来分析内存。

上面的例子是我们人为制造了一个内存泄漏，然后有意用工具检测他。但实际开发中，我们如何发现内存泄漏呢？我想可以首先使用studio自带或DDMS中的heap分析工具，观察在反复执行某个操作时（例如打开某个页面、点击某个按钮、加载某个资源等等）时，内存在执行GC后能始终维持在稳定的值附近。如果内存呈线性增长的趋势，那一定是发生了内存泄漏。此时，就要dump出内存镜像，然后使用工具分析了。

在分析内存时，第一是可以使用工具自带的泄漏检查器帮助定位。另外，可以在执行操作（怀疑造成内存泄漏的操作）前后，分别dump出一份内存镜像，然后使用MAT的Compare Basket对比两个文件的内存情况，这样可以帮助定位到是哪个对象发生了泄漏。然后再找到这个对象的GC Roots，这样就可以进一步定位到具体的代码了。

常见内存泄漏问题总结

请查看链接：http://blog.csdn.net/zxm317122667/article/details/52106741