当前位置: 移动技术网 > IT编程>移动开发>Android > MAT分析android内存泄漏

MAT分析android内存泄漏

2019年06月04日  | 移动技术网IT编程  | 我要评论

比特币病毒专杀工具,神话放送e37,服务器杀毒软件

转载请标明出处:https://www.cnblogs.com/tangzh/p/10955429.html

 

泄漏,泄漏,漏~

内存泄漏怎么破,什么是内存泄漏?与内存溢出有什么区别?

 

内存泄漏(memory leak):是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放,造成系统内存的浪费,导致程序运行速度减慢甚至系统崩溃等严重后果。

内存溢出(out of memory):是指程序在申请内存时,没有足够的内存空间供其使用,出现out of memory;

 

内存泄漏不一定会引起奔溃,但是内存溢出一定会

 

java里头有gc垃圾回收机制,他是怎么判断该不该回收呢?

q1:某对象没有任何引用的时候才进行回收?

a:不。无法往上追溯到gcroot引用点的才回收。

 

q2:某对象被别的对象引用就不能进行回收?

a:不。软引用,弱引用,虚引用都可以

 


 

哪些可以作为gcroot引用点:

  • javastack中引用的对象
  • 方法区中静态引用指向的对象
  • 方法区中常量引用指向的对象
  • native方法中jni引用指向的对象
  • thread-活着的线程

 

adb命令验证是否存在内存泄漏:

1、打开要测试的apk,然后返回退出到主界面

2、as的terminal中输入命令:

     adb shell dumpsys meminfo com.status.mattest -d 

     com.status.mattest为包名

 

然后便可以看到内存的一些情况

拉到下面可以看到:

我们退出apk之后,对象本应该都被回收,然而这里可以看到,还有view以及activity占用着内存,由此可以知道内存泄漏了。

 


我们点击as上的按钮,进行分析。

 运行apk后会出现该界面:

 

 

我们点击memory进入内存分析界面:

 

这时候我们需要进行刚刚的操作,打开apk,然后返回键退出,然后点击上图中垃圾桶形状的图标进行垃圾回收,多点几次,直到内存没有什么变化了。

然后点击上图中类似于下载按钮的图标获取内存快照。

 

获取完之后,左边会出现下面这图,head dump便是获取内存快照后出现的,我们可以点击红圈中的图形进行保存

 

 跟着出现的还有这个窗口。

我们可以通过包来分类查看自己的项目.

shallow heap(浅堆) 表示该对象自身占用的堆内存,不包括它引用的对象。
针对非数组类型的对象,它的大小就是对象与它所有的成员变量大小的总和。

retained heap(深堆) 表示当前对象大小+当前对象可直接或间接引用到的对象的大小总和。
换句话说,retained size就是当前对象被gc后,从heap上总共能释放掉的内存。


不过,释放的时候还要排除被gc roots直接或间接引用的对象。他们暂时不会被被当做garbage。

从图中可以看出,出现了内存泄漏的是customutils,mainactivity,mainactivity$1代表maiactivity里面的一个方法。

 

点击mainactivity,可以看到这么对东西,眼花缭乱,我们根本不知道是哪个引起了内存泄漏。那咋办。铺垫结束,mat该上场了。

 

mat

下载mat 

安装步骤很简单。

 

打开mat后,点击file -> open heap dump 打开刚刚保存的内存快照,会发现打不开。

因为我们保存的内存快照是不能直接在mat上打开的,需要进行转化。

 

在as的terminal窗口输入:hprof-conv -z a.hprof b.hprof

a.hprof为刚刚保存后的快照文件,b.hprof为转换后的文件,也就是我们要在mat上打开的文件

 

然后我们在mat上将其打开。

点击finish

 

 

点击histogram

 

 可以通过包名来分类查看

 

从下图中可以看到引起内存泄漏的类,objects那一列不为0的就是,与我们之前看到的一样。

 

mainactivity右键

 

选择图中的选项,意思是过滤掉虚引用,软引用,弱引用

 

之后可以看到引用的路径,customutils里面的instance引用了mainactivity的context,导致了mainactivity内存泄漏。

打开代码看一下

package com.status.mattest;

import android.content.context;

public class customutils {
    private static customutils instance;

    private customutils(context context) {
        this.mcontext = context;
    }

    private context mcontext;

    public static customutils getinstance(context context) {
        if (instance == null) {
            instance = new customutils(context);
        }

        return instance;
    }
}

 

mainactivity中:

package com.status.mattest;

import android.content.intent;
import android.support.v7.app.appcompatactivity;
import android.os.bundle;
import android.view.view;
import android.widget.textview;

public class mainactivity extends appcompatactivity {

    private textview textview;

    @override
    protected void oncreate(bundle savedinstancestate) {
        super.oncreate(savedinstancestate);
        setcontentview(r.layout.activity_main);
        customutils customutils = customutils.getinstance(this);
        textview = findviewbyid(r.id.tv);
        textview.setonclicklistener(new view.onclicklistener() {
            @override
            public void onclick(view v) {
                startactivity(new intent(mainactivity.this, test1activity.class));
            }
        });
    }
}

mainactivity中调用了单例customutils,并且把context传了进去,而我们知道instance作为静态对象,是gcroot引用点,所以activity关闭了它也没法被回收,那么最为被instance引用的activity自然也无法被回收,所以导致了内存泄漏。

 

解决:

把单例模式里面的context换为全局application的context,也就是说单例里面的context的周期应该与进程一样,而不能够与应用一样。当我们关闭应用的时候,进程还在,并没有被杀死。

如对本文有疑问,请在下面进行留言讨论,广大热心网友会与你互动!! 点击进行留言回复

相关文章:

验证码:
移动技术网