Android常见内存泄漏优化及解决方案

一.什么是内存泄漏？

如果一个无用对象（不需要再使用的对象）仍然被其他对象持有引用，造成该对象无法被系统回
收，以致该对象在堆中所占用的内存单元无法被释放而造成内存空间浪费，这种情况就是内存泄漏。
在 Android 开发中，一些不好的编程习惯会导致我们的开发的 app 存在内存泄露的情况。下面介
绍一些在 Android 开发中常见的内存泄露场景及优化方案。

1. 单例导致内存泄漏
单例模式在 Android 开发中会经常用到，但是如果使用不当就会导致内存泄漏。因为单例的静态特性使得它的生命周期同应用的生命周期一样长，如果一个对象已经没有用处了，但是单例还持有它的引用，那么在整个应用程序的生命周期它都不能正常被回收，从而导致内存泄漏。

public class ImageUtils{
    private static ImageUtilssInstance;
    private Context mContext;
    private ImageUtils(Context context) {
         this.mContext = context;
    }
    public static ImageUtilsgetInstance(Context context) {
        if (sInstance == null) {
    
            sInstance = new AppSettings(context);
        }
       return sInstance;
    }
}

像上面代码中这样的单例，如果我们在调用 getInstance(Context context)方法的时候传入的
context 参数是 Activity、Service 等上下文，就会导致内存泄漏。
以 Activity 为例，当我们启动一个 Activity，并调用 getInstance(Context context)方法去获取
ImageUtils的单例，传入 Activity.this 作为 context，这样 ImageUtils 类的单例 sInstance 就
持有了 Activity 的引用，当我们退出 Activity 时，该 Activity 就没有用了，但是因为 sIntance 作为静态单例（在应用程序的整个生命周期中存在）会继续持有这个 Activity 的引用，导致这个
Activity 对象无法被回收释放，这就造成了内存泄漏。
为了避免这样单例导致内存泄漏，我们可以将 context 参数改为全局的上下文：

private ImageUtils (Context context) {
        this.mContext = context.getApplicationContext();
}

全局的上下文 Application Context 就是应用程序的上下文，和单例的生命周期一样长，这样就避
免了内存泄漏。

2. 静态变量导致内存泄漏
静态变量存储在方法区，它的生命周期从类加载开始，到整个进程结束。一旦静态变量初始化后，
它所持有的引用只有等到进程结束才会释放。
比如下面这样的情况，在 Activity 中为了避免重复的创建 info，将 sInfo 作为静态变量：

public class MainActivity extends AppCompatActivity {
   private static UserInfo sInfo;
   @Override
   protected void onCreate(Bundle savedInstanceState) {
     super.onCreate(savedInstanceState);
     setContentView(R.layout.activity_main);
     if (sInfo != null) {
         sInfo = new UserInfo(this);
       }
     }
 }
 class UserInfo{
     public UserInfo(Activity activity) {
    }
}

UserInfo作为 Activity 的静态成员，并且持有 Activity 的引用，但是 sInfo 作为静态变量，生命周期
肯定比 Activity 长。所以当 Activity 退出后，sInfo 仍然引用了 Activity，Activity 不能被回收，
这就导致了内存泄漏。
在 Android 开发中，静态持有很多时候都有可能因为其使用的生命周期不一致而导致内存泄漏，
所以我们在新建静态持有的变量的时候需要多考虑一下各个成员之间的引用关系，并且尽量少地
使用静态持有的变量，以避免发生内存泄漏。当然，我们也可以在适当的时候讲静态量重置为 null，
使其不再持有引用，这样也可以避免内存泄漏。

3. 未取消注册或回调导致内存泄漏
比如我们在 Activity 中注册广播，如果在 Activity 销毁后不取消注册，那么这个刚播会一直存在
系统中，同上面所说的非静态内部类一样持有 Activity 引用，导致内存泄漏。因此注册广播后在
Activity 销毁后一定要取消注册。

@Override
protected void onDestroy() {
    super.onDestroy();
    //广播要记得取消注册
    this.unregisterReceiver(mReceiver);
}

在注册观察则模式的时候，如果不及时取消也会造成内存泄漏。比如使用 Retrofit+RxJava 注册网
络请求的观察者回调，同样作为匿名内部类持有外部引用，所以需要记得在不用或者销毁的时候
取消注册。

4. 属性动画造成内存泄漏
动画同样是一个耗时任务，比如在 Activity 中启动了属性动画（ObjectAnimator），但是在销毁
的时候，没有调用 cancle 方法，虽然我们看不到动画了，但是这个动画依然会不断地播放下去，
动画引用所在的控件，所在的控件引用 Activity，这就造成 Activity 无法正常释放。因此同样要
在 Activity 销毁的时候 cancel 掉属性动画，避免发生内存泄漏。

@Override
protected void onDestroy() {
    super.onDestroy();
    //动画要记得取消
    mAnimator.cancel();
}

5. 非静态内部类导致内存泄漏
非静态内部类（包括匿名内部类）默认就会持有外部类的引用，当非静态内部类对象的生命周期
比外部类对象的生命周期长时，就会导致内存泄漏。
非静态内部类导致的内存泄漏在 Android 开发中有一种典型的场景就是使用 Handler，很多开发
者在使用 Handler 是这样写的：

public class MainActivity extends AppCompatActivity {
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    start();
  }
   private void start() {
      Message msg = Message.obtain();
      msg.what = 1;
     mHandler.sendMessage(msg);
  }
   private Handler mHandler = new Handler() {
      @Override
      public void handleMessage(Message msg) {
         if (msg.what == 1) {
            // 做相应逻辑
       }
     }
  };
}

也许有人会说，mHandler 并未作为静态变量持有 Activity 引用，生命周期可能不会比 Activity 长，
应该不一定会导致内存泄漏呢，显然不是这样的！
熟悉 Handler 消息机制的都知道，mHandler 会作为成员变量保存在发送的消息 msg 中，即 msg 持有mHandler 的引用，而 mHandler 是 Activity 的非静态内部类实例，即 mHandler 持有 Activity 的引
用，那么我们就可以理解为 msg 间接持有 Activity 的引用。msg 被发送后先放到消息队列
MessageQueue 中，然后等待 Looper 的轮询处理（MessageQueue 和 Looper 都是与线程相关联的，MessageQueue 是 Looper 引用的成员变量，而 Looper 是保存在 ThreadLocal 中的）。那么当 Activity退出后，msg 可能仍然存在于消息对列 MessageQueue 中未处理或者正在处理，那么这样就会导致Activity 无法被回收，以致发生 Activity 的内存泄漏。通常在 Android 开发中如果要使用内部类，但又要规避内存泄漏，一般都会采用静态内部类+弱引用的方式。

public class MainActivity extends AppCompatActivity {
    private Handler mHandler;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       setContentView(R.layout.activity_main);
       mHandler = new MyHandler(this);
       start();
   }
      private void start() {
          Message msg = Message.obtain();
          msg.what = 1;
          mHandler.sendMessage(msg);
   }
    private static class MyHandler extends Handler {
        private WeakReference activityWeakReference;
          public MyHandler(MainActivity activity) {
             activityWeakReference = new WeakReference<>(activity);
     }
     @Override
     public void handleMessage(Message msg) {
          MainActivity activity = activityWeakReference.get();
         if (activity != null) {
              if (msg.what == 1) {
               // 做相应逻辑
          }
       }
    }
  }
}

mHandler 通过弱引用的方式持有 Activity，当 GC 执行垃圾回收时，遇到 Activity 就会回收并释
放所占据的内存单元。这样就不会发生内存泄漏了。
上面的做法确实避免了 Activity 导致的内存泄漏，发送的 msg 不再已经没有持有 Activity 的引用
了，但是 msg 还是有可能存在消息队列 MessageQueue 中，所以更好的是在 Activity 销毁时就将
mHandler 的回调和发送的消息给移除掉。

@Override
protected void onDestroy() {
    super.onDestroy();
    mHandler.removeCallbacksAndMessages(null);
}

非静态内部类造成内存泄漏还有一种情况就是使用 Thread 或者 AsyncTask。
比如在 Activity 中直接 new 一个子线程 Thread：

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        new Thread(new Runnable() {
          @Override
          public void run() {
             // 模拟相应耗时逻辑
        try {
               Thread.sleep(2000);
         } catch (InterruptedException e) {
           e.printStackTrace();
         }
      }
     }).start();
  }

或者直接新建 AsyncTask 异步任务：

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        new AsyncTask() {
         @Override
         protected Void doInBackground(Void... params) {
              // 模拟相应耗时逻辑
     try {
          Thread.sleep(2000);
        } catch (InterruptedException e) {
          e.printStackTrace();
      }
       return null;
    }
  }.execute();
 }
}

很多初学者都会像上面这样新建线程和异步任务，殊不知这样的写法非常地不友好，这种方式新
建的子线程 Thread 和 AsyncTask 都是匿名内部类对象，默认就隐式的持有外部 Activity 的引用，
导致 Activity 内存泄漏。要避免内存泄漏的话还是需要像上面 Handler 一样使用静态内部类+弱
应用的方式（代码就不列了，参考上面 Hanlder 的正确写法）。

6. Timer 和 TimerTask 导致内存泄漏
Timer 和 TimerTask 在 Android 中通常会被用来做一些计时或循环任务，比如实现无限轮播的
ViewPager：
当我们 Activity 销毁的时候，有可能 Timer 还在继续等待执行 TimerTask，它持有 Activity 的引用不能被回收，因此当我们 Activity 销毁的时候要立即 cancel 掉 Timer 和 TimerTask，以避免发生内存
泄漏。

7. 集合中的对象未清理造成内存泄漏
这个比较好理解，如果一个对象放入到 ArrayList、HashMap 等集合中，这个集合就会持有该对象
的引用。当我们不再需要这个对象时，也并没有将它从集合中移除，这样只要集合还在使用（而
此对象已经无用了），这个对象就造成了内存泄漏。并且如果集合被静态引用的话，集合里面那
些没有用的对象更会造成内存泄漏了。所以在使用集合时要及时将不用的对象从集合 remove，或
者 clear 集合，以避免内存泄漏。

8. WebView 造成内存泄漏
关于 WebView 的内存泄露，因为 WebView 在加载网页后会长期占用内存而不能被释放，因此我
们在 Activity 销毁后要调用它的 destory()方法来销毁它以释放内存。
另外在查阅 WebView 内存泄露相关资料时看到这种情况：Webview 下面的 Callback 持有 Activity 引用，造成 Webview 内存无法释放，即使是调用了Webview.destory()等方法都无法解决问题（Android5.1 之后）。最终的解决方案是：在销毁 WebView 之前需要先将 WebView 从父容器中移除，然后在销毁 WebView。

@Override
protected void onDestroy() {
    super.onDestroy();
   // 先从父控件中移除 WebView
   mWebViewContainer.removeView(mWebView);
   mWebView.stopLoading();
   mWebView.getSettings().setJavaScriptEnabled(false);
   mWebView.clearHistory();
   mWebView.removeAllViews();
   mWebView.destroy();
}

9. 资源未关闭或释放导致内存泄漏
在使用 IO、File 流或者 Sqlite、Cursor 等资源时要及时关闭。这些资源在进行读写操作时通常都
使用了缓冲，如果及时不关闭，这些缓冲对象就会一直被占用而得不到释放，以致发生内存泄漏。
因此我们在不需要使用它们的时候就及时关闭，以便缓冲能及时得到释放，从而避免内存泄漏。

总结：
内存泄露在 Android 内存优化是一个比较重要的一个方面，很多时候程序中发生了内存泄露我们
不一定就能注意到，所有在编码的过程要养成良好的习惯。总结下来只要做到以下这几点就能避
免大多数情况的内存泄漏：
1.构造单例的时候尽量别用 Activity 的引用；
2.静态引用时注意应用对象的置空或者少用静态引用；
3.使用静态内部类+软引用代替非静态内部类；
4.及时取消广播或者观察者注册；
5.耗时任务、属性动画在 Activity 销毁时记得 cancel；
6.文件流、Cursor 等资源及时关闭；
7.Activity 销毁时 WebView 的移除和销毁。