Android内存泄露问题分享

不少人认为 JAVA程序，因为有垃圾回收机制，应该没有内存泄露。 其实如果我们一个程序中，已经不再使用某个对象，但是因为仍然有引用指向它，垃圾回收器就无法回收它，当然该对象占用的内存就无法被使用，这就造成了内存泄露。如果我们的java运行很久,而这种内存泄露不断的发生，最后就没内存可用了。当然java的内存泄漏和C/C++是不一样的。如果java程序完全结束后，它所有的对象就都不可达了，系统就可以对他们进行垃圾回收，它的内存泄露仅仅限于它本身，而不会影响整个系统的。C/C++的内存泄露就比较糟糕了，它的内存泄露是系统级，即使该C/C++程序退出，它的泄露的内存也无法被系统回收，永远不可用了，除非重启机器。     Android 的一个应用程序的内存泄露对别的应用程序影响不大。 为了能够使得Android应用程序安全且快速的运行，Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote 服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的。 Android 为不同类型的进程分配了不同的内存使用上限，如果程序在运行过程中出现了内存泄漏的而造成应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被 kill 掉，这使得仅仅自己的进程被 kill 掉，而不会影响其他进程（如果是 system_process 等系统进程出问题的话，则会引起系统重启）

1、持有Context引用造成的泄漏。

在Android应用程序中，很多操作都用到了Context对象，但是大多数都是用来加载和访问资源的。这就是为什么所有的显示控件都需要一个Context对象作为构造方法的参数。
在Android应用程序中通常可以使用两种Context对象：Activity和Application。当类或方法需要Context对象的时候常见的作法是使用第一个作为Context参数。
但这就意味着View对象对整个activity保持引用，因此也就保持对activity内的所有东西的引用，也就是整个View结构和它所有的资源都无法被及时的回收，而且对activity的长期引用是比较隐蔽.

先看一个Android官网提供的例子：   

private static Drawable sBackground;

@Override

protected void onCreate(Bundle state) {

  super.onCreate(state);

   

  TextView label = new TextView(this);

  label.setText("Leaks are bad");

   

  if (sBackground == null) {

    sBackground = getDrawable(R.drawable.large_bitmap);

  }

  label.setBackgroundDrawable(sBackground);

   

  setContentView(label);

}

这段代码效率很快，但同时又是极其错误的； 在第一次屏幕方向切换时它泄露了一开始创建的Activity。当一个Drawable附加到一个 View上时， View会将其作为一个 callback设定到Drawable上。上述的代码片段，意味着这个静态的Drawable拥有一个TextView的引用， 而TextView又拥有Activity（Context类型）的引用，换句话说，Drawable拥有了更多的对象引用。即使Activity被销毁，内存仍然不会被释放。

另外，对Context的引用超过它本身的生命周期，也会导致该Context无法回收，从而导致内存泄漏。所以尽量使用Application这种Context类型。 这种Context拥有和应用程序一样长的生命周期，并且不依赖Activity的生命周期。如果你打算保存一个长时间的对象， 并且其需要一个 Context，记得使用Application对象。你可以通过调用Context.getApplicationContext()或 Activity.getApplication()轻松得到Application对象。总结一下避免Context泄漏应该注意的问题：

(1) 尽量使用Application这种Context类型。

(2) 注意对Context的引用不要超过它本身的生命周期。

(3) 避免非静态的内部类，尽量使用静态类，避免生命周期问题，注意内部类对外部对象引用导致的生命周期变化。

(4) Context里如果有线程，一定要在onDestroy()里及时停掉。

2、线程之间通过Handler通信引起的内存泄漏

Android中线程之间进行通信时最常用的作法是通过接收消息的目标线程所持有Handler对象来创建Message对象，然后再向目标线程发送该Message。在目标线程中Handler在执行handleMessage()时会根据相应Message来执行相应不同功能。另外一种作法是通过Handler对象向目标线程直接发送Runnable对象来执行该Runnable对象中不同的功能代码。在通过Handler进行通信时如果不注意，也很有可能引起内存泄漏。

在sendMessage完成之后显示的将msg成员变量置为null，并且在退出整个应用程序之前，将handler置为null。

3、将变量的作用域设置为最小

最小化作用域意味着对垃圾收集器更快的可见。让我们举一个例子。我们有一个变量定义在方法级,当方法执行完毕后,也就是说,控制跳出方法后,则该变 量将不会被引用。这也就意味着它已经可以被垃圾回收。但是如果该变量是类级的,这时垃圾回收器就需要等待直到对该类的所有的引用都被移除后才能进行垃圾回收。优化属性的作用域是必须的。同样这也是封装原则。最小化作用域降低了通过包访问变量并减少了耦合。

4、构造Adapter时，没有使用缓存的convertView

初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的view对象，同时ListView会将这些view对象 缓存起来。当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的，getView()的第二个形参View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。

由此可以看出，如果我们不去使用convertView，而是每次都在getView()中重新实例化一个View对象的话，即浪费时间，也造 成内存垃圾，给垃圾回收增加压力，如果垃圾回收来不及的话，虚拟机将不得不给该应用进程分配更多的内存，造成不必要的内存开支。

5、Bitmap的回收和置空

Bitmap 对象不在使用时调用 recycle()释放内存，有时我们会手工的操作 Bitmap 对象,
如果一个Bitmap 对象比较占内存, Bitmap对象在不使用时，我们应该先调用recycle()释放内存，然后才它设置为null。
虽然recycle()从源码上看，调用它应该能立即释放Bitmap的主要内存，但是测试结果显示它并没能立即释放内存。
但是我它应该还是能大大的加速Bitmap的主要内存的释放。

6、资源对象没关闭造成的内存泄露

资源性对象比如（Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄露。因为有些资源性对象，比如SQLiteCursor（在析构函数finalize（）,如果我们没有关闭它，它自己会调close()关闭），如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。 因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null.在我们的程序退出时一定要确保我们的资源性对象已经关闭。程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。

7、各种注册没取消

这种情况造成的内存泄露这种Android的内存泄露比纯java的内存泄露还要严重，因为其他一些Android程序可能引用我们的Anroid程序的对象（比如注册机制）。即使我们的Android程序已经结束了，但是别的引用程序仍然还有对我们的Android程序的某个对象的引用，泄露的内存依然不能被垃圾回收。比如 假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen中定义一个PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process进程挂掉。虽然有些系统程序，它本身好像是可以自动取消注册的（当然不及时），但是我们还是应该在我们的程序中明确的取消注册，程序结束时应该把所有的注册都取消掉。

8、集合容器对象没清理造成的内存泄露

我们通常把一些对象的引用加入到了集合容器（比如ArrayList）中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。所以要在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。

9、static关键字的滥用

当类的成员变量声明成static后，它是属于类的而不是属于对象的，如果我们将很大的资源对象（Bitmap，context等）声明成static，那么这些资源不会随着对象的回收而回收， 会一直存在，所以在使用static关键字定义成员变量的时候要慎重。

10、WebView对象没有销毁

当我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其占用的内存长期也不能被回收，从而造成内存泄露。

11、GridView的滥用

GridView和ListView的实现方式不太一样。GridView的View不是即时创建的，而是全部保存在内存中的，比如一个GridView有100项，虽然我们只能看到10项，但是其实整个100项都是在内存中的。所以在应用程序退出之前，要讲gridView和adapter全部置为null。