使用 Memory Profiler 排查内存泄露

使用 Memory Profiler 排查内存泄漏

内存泄漏和内存溢出

**Memory Profiler **是 Android Profiler 中的一个组件，可帮助您识别导致应用卡顿、冻结甚至崩溃的内存泄漏和流失。 它显示一个应用内存使用量的实时图表，让您可以捕获堆转储、强制执行垃圾回收以及跟踪内存分配。

shell命令查看内存情况：

adb shell dumpsys meminfo com.example.a.sample -d

图 1. Memory Profiler

如图 1 所示，Memory Profiler 的默认视图包括以下各项：

1. 用于强制执行垃圾回收 Event 的按钮。
2. 用于捕获堆转储的按钮。
3. 用于记录内存分配情况的按钮。 此按钮仅在连接至运行 Android 7.1 或更低版本的设备时才会显示。
4. 用于放大/缩小时间线的按钮。
5. 用于跳转至实时内存数据的按钮。
6. Event 时间线，其显示 Activity 状态、用户输入 Event 和屏幕旋转 Event。
7. 内存使用量时间线，其包含以下内容：
   一个显示每个内存类别使用多少内存的堆叠图表，如左侧的 y 轴以及顶部的彩色键所示。
   虚线表示分配的对象数，如右侧的 y 轴所示。
   用于表示每个垃圾回收 Event 的图标。
   不过，如果您使用的是运行 Android 7.1 或更低版本的设备，则默认情况下，并不是所有分析数据均可见。 如果您看到一条消息，其显示“Advanced profiling is unavailable for the selected process”，则需要启用高级分析以查看下列内容：

• Event 时间线
• 分配的对象数
• 垃圾回收 Event
  在 Android 8.0 及更高版本上，始终为可调试应用启用高级分析。

在您的堆转储中，请注意由下列任意情况引起的内存泄漏：

1. 长时间引用 Activity、Context、View、Drawable 和其他对象，可能会保持对 Activity 或 Context 的引用。
2. 可以保持 Activity 实例的非静态内部类，如 Runnable。
3. 对象保持时间超出所需时间的缓存。

查看内存分配

要检查分配记录，请按以下步骤操作：

1. 浏览列表以查找堆计数异常大且可能存在泄漏的对象。 为帮助查找已知类，点击 Class Name 列标题以按字母顺序排序。 然后点击一个类名称。 此时在右侧将出现 Instance View 窗格，显示该类的每个实例，如图 下中所示。
2. 在 Instance View 窗格中，点击一个实例。 此时下方将出现 Call Stack 标签，显示该实例被分配到何处以及哪个线程中。
3. 在 Call Stack 标签中，点击任意行以在编辑器中跳转到该代码。

image.png

捕获堆转储

堆转储显示在您捕获堆转储时您的应用中哪些对象正在使用内存。 特别是在长时间的用户会话后，堆转储会显示您认为不应再位于内存中却仍在内存中的对象，从而帮助识别内存泄漏。 在捕获堆转储后，您可以查看以下信息：

• 您的应用已分配哪些类型的对象，以及每个类型分配多少。
• 每个对象正在使用多少内存。
• 在代码中的何处仍在引用每个对象。
• 对象所分配到的调用堆栈。 （目前，如果您在记录分配时捕获堆转储，则只有在 Android 7.1 及更低版本中，堆转储才能使用调用堆栈。）

实测内存泄漏

1. 内部类

 new Handler().postDelayed(new Runnable() {
             @Override
            public void run() {
            }
        }, 15000); 

跳转到新的LeakActivity里执行这段代码，然后退出这个LeakActivity。执行gc。

下图4处的 gc 是系统执行的，此时 postDelayed 执行完毕。选取5和4中间的时间节点查看内存，在下图1处按照 Arrange by package 分类,直接查看当前包名下的实例。

• Arrange by class：基于类名称对所有分配进行分组。
• Arrange by package：基于软件包名称对所有分配进行分组。
• Arrange by callstack：将所有分配分组到其对应的调用堆栈。
  5是在LeakActivity结束后gc，此时还有LeakActivity的实例，说明LeakActivity不能被回收，发生了内存泄漏。在3处可以看到，他dealloc time 没有时间，也说明内存并没有被重新分配，也就是没有被回收。
  把时间节点选取到4后面，就没有LeakActivity的实例了。

可以看到，在5和4直接的时间，已经退出了LeakActivity，但是没有被 gc 回收，因为 handler 还在执行。他持有着 acitvity 的引用。

image.png

重新操作一遍上述流程，在退出LeakActivity后dump内存：

image.png

右边的3处Depth 是3，表示这个实例被引用的步进是3，当引用为0时才能被回收。

image.png

在上图右键，跳到代码里，定位的地方就是实例被引用的地方，正是这个方法。这个runnable被装进Messagerqueue里。等待执行。而handler 是匿名内部类 ，匿名内部类的构造方法不再是默认的无参的构造方法，而是有一个参数（外部类）的构造方法，runnable也是匿名内部类，又持有handle，所以Depth=3。静态内部类才不会持有外部类，所以我们把这两个类改为静态内部类：

       private static final Runnable run = new Runnable() {
        @Override
        public void run() {
        }
    };

另外，handle一般需要context去执行操作，所以我们传递进去context：

        static class MyHandle extends Handler {

        WeakReference weakReference;

        public MyHandle(Context context) {
            weakReference = new WeakReference<>(context);
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            if (weakReference.get() != null) {
//                ((LeakActivity) weakReference.get()).showToast();
            }
        }
    }

如果不想这么麻烦怎么办？我们知道哪些情况引起的内存泄漏，一般都是持有引用的实例比activity的生命周期长，所以我们可以在onDestroy里，执行 handle.removeCallbacksAndMessages(null)，这样也不会造成内存泄漏了。

2. 线程

class MyThread extends Thread {

        @Override
        public void run() {
            super.run();

            while (true) {

                try {
                    sleep(2000);
                    System.out.println("ssssssss");
                } catch (InterruptedException e) {


                }
            }

        }
    }

开启这个线程new MyThread().start();然后dump内存，也发生了内存泄漏，方法和上图一样，怎么避免呢？方法和上面一样有两种：

1. 改为静态内部类
2. onDestroy的时候停止这个线程

3. 监听

  findViewById(R.id.btnDelay).getViewTreeObserver()
  .addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
          @Override
            public void onGlobalLayout() {
                //计算宽高等耗时操作
            }
        });

查看如下getViewTreeObserver源码发现，无论是否finish，ViewTreeObserver都不会为空，所以它的生命周期比activity长。但是如果没有耗时操作的话，getViewTreeObserver就不再被引用，也会被回收。如果有耗时操作，add后要remove. 一般有add 记得 让remove 成对出现。

  public ViewTreeObserver getViewTreeObserver() {
        if (mAttachInfo != null) {
            return mAttachInfo.mTreeObserver;
        }
        if (mFloatingTreeObserver == null) {
            mFloatingTreeObserver = new ViewTreeObserver(mContext);
        }
        return mFloatingTreeObserver;
    }

4. 单例

    如下我们常见的一个单例,单例和app的生命周期一样长，所以register的时候持有context，知道app运行结束，所以在activity销毁的时候，记得移除单例持有的context，下图的unRegister。

class MySingleton {
    private static final MySingleton ourInstance = new MySingleton();

    private Context context;

    static MySingleton getInstance() {
        return ourInstance;
    }

    private MySingleton() {
    }

    void register(Context context) {
        this.context = context;
    }

    void unRegister() {
        this.context = null;
    }
}

4. 静态成员变量

静态成员变量 的生命周期也比activity长，所以如果静态成员变量持有context，activity也无法回收。

   static NorClass sNorClass;

public class NorClass {

    Context context;


    public NorClass(Context context) {
        this.context = context;
    }


}