内存泄漏探讨下(解决方法)

    |     2016年3月3日   |   Android经验   |     0 条评论   |    1114

 

当发生内存泄漏时首先要查找内存泄漏然后进行解决.内存泄漏的检查工具用Heap,分析工具为MAT.

开发环境DDMS可以找到这两个程序.

一、内存泄漏的检查工具Heap

工欲善其事必先利其器,要检测“内存泄漏”的发生,需要借助DDMS中的Heap工具及MAT工具,Heap工具用于大致分析是否存在“内存泄漏”,而MAT工具则用于分析“内存泄漏”发生在哪里。

Heap工具的使用介绍

201601120923191

具体操作

  • 1.在Devices设备列表中,找到你所在的设备,点击你想要监控的进程。
  • 2.点击“Update Heap”按钮更新堆内存的情况。
  • 3.点击“Heap”视图,查看内存的情况。
  • 4.每次在Activity的退出和进入的时候点击“Cause GC”,手动调用GC释放应用的内存。
  • 5.观察data oject那一行,每一次点击“Casue GC”的时候,观察Total Size的值,如果该值不断增加,则说明该应用程序存在“内存泄漏”。

我们先模拟一下内存泄漏,然后通过Heap工具来判断一下是否存在内存泄漏。
上一段存在内存泄漏的代码:

public class LeakAty extends Activity {

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

 }

 /**
  * 测试内存泄漏的代码
  */
 private void testLeak() {
  new Thread(new Runnable() {

   @Override
   public void run() {
    while (true) {
     try {
      Thread.sleep(1000);
     } catch (InterruptedException e) {
      e.printStackTrace();
     }
    }
   }
  }).start();
 }

上述的代码存在内存泄漏,new Runnable(){}是一个非静态的匿名内部类,所以它会强引用创建它的外围对象LeakAty,我们来测试一下内存泄漏的过程,开启手机的方向旋转功能,不断地旋转手机,让LeakAty不断地创建新的实例。理论上如果不存在上述泄漏的代码,之前的Activity会在onDestory之后被回收内存。而一旦存在上述泄漏的代码,新创建的Ruannale实例会一直处于运行状态,它不会被回收,而它强引用的LeakAty当然也不会被回收,所以在屏幕不断旋转,之前创建的LeakAty就不会被释放,会导致旋转n次,内存中就存在n+1个的LeakAty实例。
Heap工具第一次按下Cause GC按钮的截图:

201601120923202

上图的data object的Total Size的大小为1.031M。经过多次的旋转屏幕之后,我们再看一下截图

201601120923203

Total Size变成了2.059M,从1.031M到2.059M,每次调用GC的过程中data object的总大小没有回落,所以可以证实上面的代码确实是存在内存泄漏的问题,那么泄漏发生在哪里?答案可以通过MAT工具来分析得到。

三、内存泄漏的分析工具MAT

要通过MAT分析,需要提供一个.hprof文件。我们可以通过”Dump HPROF file”按钮转存当前的堆内存信息。我们将其保存为1.hprof。

201601120923204

导出的1.hprof的格式需要通过..\sdk\tools\目录下的hprof-conv.exe工具进行转换才能被MAT成功导入,我们将其转换成out1.hprof
201601120923205

将out1.hprof导入到MAT工具中,File->Open Heap Dump…

201601120923206

点击左边的标签Overview,Actions->Histogram

201601120923207

在Histogram界面中,因为我们想要知道Activity是否泄漏了,所以输入关键词Activity,然后按下回车键。

201601120923208

之后便可以得到Activity的相关的搜索结果,下图的搜索结果中Activity的实例有7个。点击选中下图标红色框框的地方,右键->Merge Shortest Paths to GC Roots->exclude all phantom/weak/soft etc. references。排除虚引用、弱引用、软引用的实例,剩下的都是强引用实例。

201601120923209

从过滤出来的强引用的列表中,我们可以看到这七个实例都是被Thread所引用了。所以证实上面的代码确实存在内存泄漏。

2016011209232010

 

四、使用 LeakCanary 检测 Android 的内存泄漏

什么是 LeakCanary 呢?为什么选择它来检测 Android 的内存泄漏呢?

别急,让我来慢慢告诉大家!

LeakCanary 是国外一位大神 Pierre-Yves Ricau 开发的一个用于检测内存泄露的开源类库。一般情况下,在对战内存泄露中,我们都会经过以下几个关键步骤:

1、了解 OutOfMemoryError 情况。

2、重现问题。

3、在发生内存泄露的时候,把内存 Dump 出来。

4、在发生内存泄露的时候,把内存 Dump 出来。

5、计算这个对象到 GC roots 的最短强引用路径。

6、确定引用路径中的哪个引用是不该有的,然后修复问题。

很复杂对吧?

如果有一个类库能在发生 OOM 之前把这些事情全部都搞定,然后你只要修复这些问题就好了。LeakCanary 做的就是这件事情。你可以在 debug 包中轻松检测内存泄露。

转载请注明来源:内存泄漏探讨下(解决方法)
回复 取消