Android内存泄露的解决之道

摘要：导致了当旋转屏幕时，无法被回收，而造成内存泄露。但是，她却会造成严重的内存泄露。参考内存泄露问题的整理内存泄露使用中可能引发的内存泄漏介绍了内存泄露有关的解决办法，下一篇总结遇到时的解决之道。

面试的时候经常会被问道内存泄露优化，和碰到OOM该怎么出来，今天就做个总结。

根本原因就是一个永远不会被使用的对象，因为一些引用没有断开，没有满足GC条件，导致不会被回收，这就造成了内存泄露。比如在Activity中注册了一个广播接收器，但是在页面关闭的时候没有进行unRegister，就会出现内存溢出的现象。如果我们的java运行很久，而这种内存泄露不断的发生，最后就没内存可用了，最终就是我们常看到的OOM错误。

在Android应用程序中通常可以使用两种Context对象：Activity和Application。当类或方法需要Context对象的时候常见的做法是使用第一个作为Context参数。这样就意味着View对象对整个activity保持引用，因此也就保持对activty的所有的引用。

假设一个场景，当应用程序有个比较大的bitmap类型的图片，每次旋转是都重新加载图片所用的时间较多。为了提高屏幕旋转是Activity的创建速度，最简单的方法时将这个Bitmap对象使用static修饰。
  当一个Drawable绑定在View上，实际上这个View对象就会成为这份Drawable的一个callback成员变量。而静态变量的生命周期要长于Activity。导致了当旋转屏幕时，Activity无法被回收，而造成内存泄露。

解决的方法：
使用Application对象，这个对象会随着应用程序的存在而存在，而不依赖于activity的生命周期。如果打算对context对象进行长期的引用，一定要记住用application对象
总结：避免context泄露：

尽量使用Application的context类型。

对Context的引用不要超过它本身的生命周期，慎重的对Context使用“static”关键字。Context里如果有线程，一定要在onDestroy()里及时停掉。

    public class SampleActivity extends Activity {
      private final Handler mLeakyHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
          // ... 
        }
      }
    }

在使用handler时，这时一段很常见的代码。但是，她却会造成严重的内存泄露。
假设当Handler中有延迟的的任务或是等待执行的任务队列过长，由于消息持有对handler的引用，而handler又持有对其外部类的潜在引用，这条引用关系会一直保持到消息得到处理，而导致了activity无法被垃圾回收器回收，而导致了内存泄露。

在java里，非静态内部类 和 匿名类 都会潜在的引用它们所属的外部类。但是，静态内部类却不会

解决方法：

可以把handler类放在多带带的类文件中，或者使用静态内部类便可以避免泄露。

如果想在handler内部去调用所在的Activity,那么可以在handler内部使用弱引用的方式去指向所在Activity.使用Static + WeakReference的方式来达到断开Handler与Activity之间存在引用关系的目的。

Bitmap对象不在使用时调用recycle()释放内存。2.3以后的bitmap应该是不需要手动recycle了，内存已经在java层了

资源性对象比如(Cursor，File文件等)往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄漏。因为有些资源性对象，比如 SQLiteCursor(在析构函数finalize(),如果我们没有关闭它，它自己会调close()关闭)，如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null.在我们的程序退出时一定要确保我们的资源性对象已经关闭。

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

在Android程序里面存在很多需要register与unregister的监听器，我们需要确保及时unregister监听器。

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

当我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其占用的内存长期也不能被回收，从而造成内存泄露。
解决方法：
为webView开启另外一个进程，通过AIDL与主线程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。

参考：
Andriod 内存泄露问题的整理
Android_内存泄露
Handler使用中可能引发的内存泄漏

介绍了内存泄露有关的解决办法，下一篇总结遇到OOM时的解决之道。