Android 内存泄漏总结

内存泄漏的原因

内存泄漏也称为存储渗漏， 用动态存储分配函数动态开辟的空间，在使用完毕后未释放， 结果导致一直占据该内存单元格。 内存泄漏简单地说就是申请了一块内存空间，使用完毕后没有释放掉。它的一般表现方式是程序运行时间越长，占用内存越多，最终用尽全部内存，整个系统崩溃。由程序申请的一块内存，且没有任何一个指针指向它，那么这块内存就泄露了。

从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。

Android应用内存泄漏的的原因有以下几个：

1查询数据库后没有关闭游标cursor 2 构造Adapter时，没有使用 convertView 重用 3 Bitmap对象不在使用时调用recycle()释放内存 4 对象被生命周期长的对象引用，如activity被静态集合引用导致activity不能释放

内存泄漏的发现:

通过DDMS中的heap工具，去发现是否有内存溢出。

内存泄漏如何解决：

通过内存分析工具 MAT(Memory Analyzer Tool)，找到内存泄露的对象

内存泄漏的解决方法

可以使用Eclipse DDMS的Heap进行测试。

  首先，我们在DDMS的界面的设备选项中找到手机设备，可以看到它里面正在运行的进程：



  点一下“Update Heap"图标，然后在Heap选项中查看我们标注的进程的内存使用情况：


   点一下"Cause GC", 相当于向虚拟机执行一次GC请求，然后无需再按就可以动态的查看该应用程序的内存使用情况。

   最值得关注的就是”data object“的"Total Size"，它决定了是否存在内存泄露的危险。一般情况下，它都是固定在一个稳定的数值范围，如果回落非常大，或者该数值非常大，像是3.55后就会被kill掉，说明该应用程序的内存使用情况不佳，代码结构需要优化。

内存泄漏解决方法进阶

测试跟你说你的XXActivity泄露了，你如何确认是否真的泄漏？

确认泄漏后，你又如何定位是哪里的问题导致内存泄漏？

Android日常开发中，内存泄漏的重灾区就是Activity，相信这两个是每个Android开发者都碰到过的问题，遇到这种问题，我们一般都会祭出我们的杀手锏：Dump Java Heap然后MAT静态分析GC链。然后今天我想另辟蹊径，从更简单的角度定位并解决这种问题。 确认泄漏

我们先来看一个抽象的Activity伪代码：

public class LeakActivity extends Activity {

ComplexLogicA; // 复杂的业务逻辑代码

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    ComplexLogicB; // 复杂的业务逻辑代码
    LeakLogic; // 引起泄漏的业务逻辑代码
    ComplexLogicC;
    ComplexLogicD;
}

@Override
protected void onResume() {
    super.onResume();

    ComplexLogicE;
    ComplexLogicF;
    ComplexLogicG;
}

OtherComplexLogin... // 其他业务逻辑代码

}

如果我们想确认这个Activity是否存在泄漏，只需让其覆盖Object的finalize方法，在里面添加一句Logcat打印：

public class LeakActivity extends Activity {

ComplexLogicA; // 复杂的业务逻辑代码

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    ComplexLogicB; // 复杂的业务逻辑代码
    LeakLogic; // 引起泄漏的业务逻辑代码
    ComplexLogicC;
    ComplexLogicD;
}

@Override
protected void onResume() {
    super.onResume();

    ComplexLogicE;
    ComplexLogicF;
    ComplexLogicG;
}

@Override
protected void finalize() throws Throwable {
    super.finalize();

    Log.d("", "====LeakActivity has been recycled!");
}

OtherComplexLogin... // 其他业务逻辑代码

}

然后运行你的项目，打开这个Activity，然后按返回，退出Activity，然后通过IDE强制触发一次GC操作：

(Android Studio)

然后查看Logcat，是否有对应的打印，就能确认Activity是否存在内存泄漏了：有打印，则无内存泄漏，无打印则肯定有内存泄漏了！ 定位泄漏原因

定位泄漏原因这个就是比较简单粗暴的排除法，首先把所有复杂业务逻辑注视掉，直到内存泄漏现在不存在：

public class LeakActivity extends Activity {

// ComplexLogicA; // 复杂的业务逻辑代码

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

// ComplexLogicB; // 复杂的业务逻辑代码 // LeakLogic; // 引起泄漏的业务逻辑代码 // ComplexLogicC; // ComplexLogicD; }

@Override
protected void onResume() {
    super.onResume();

// ComplexLogicE; // ComplexLogicF; // ComplexLogicG; }

@Override
protected void finalize() throws Throwable {
    super.finalize();

    Log.d("", "====LeakActivity has been recycled!");
}

// OtherComplexLogin... // 其他业务逻辑代码 }

然后再进出一次Activity，触发GC，确认Activity泄漏已经不存在。然后再把业务逻辑一个个补回来，直到泄漏现象重现。

这样我们就能100%的找出泄漏的原因所在。 知识点

这里用到的一个知识点就是Java中Object类的finalize方法。当GC准备回收一个Java Object（所有Java对象都是Object的子类）的时候，GC会调用这个Object的finalize方法。这个方法有点类似于C++中析构函数，本意是让你用来回收一些已经不需要的资源的（主要是针对Native资源）。其实Java日常开发中，并不鼓励依赖于这个方法来实现回收的逻辑，因为如果你重度依赖于finalize的话，finalize本身也有可能造成内存泄漏，但是我们这里只是用来作为是否已经回收的依据，还是可以的。