Android 内存优化（常见的内存泄露以及优化方案）

内存泄露的含义：

如果一个无用对象仍然内其他对象持有引用，使该对象无法被系统回收，以致该对象在堆中所占用的内存单元无法被回收而造成的内存浪费现象，这种情况就叫做内存泄露。

• 单例导致的内存泄露

单例模式的静态特性使得单例对象的生命周期同应用的生命周期一样长，如果一个对象已经没有用处了，但是单例对象还持有他的引用，那么在对象使用完之后的整个应用的生命周期内，其所占的内存空间都不能被正常回收，从而导致内存泄露。

比如我们在单例模式中经常需要传入Context参数，如果我们传入的是Activity或者Service的上下文，就会造成内存泄露。因为当Activity退出时，该Activity就没有用处了，但是因为我们在单例对象中传入了Activity的上下文，所有该单例对象会继续持有该Activity的引用，导致这个Activity无法被回收，就造成了内存泄露。
为了避免这样的问题，我们在单例对象中可以传入全局即整个应用的上下文。

Application Context

因为整个应用的上下文和单例模式的生命周期一样长， 这样就不会导致内存泄露。

单例模式的生命周期对应了应用程序的生命周期，所以我们在构造单例的时候，如果需要传入Context参数，应该避免传入Activity或者Service的上下文，而应该是使用Application的上下文。

• 静态变量导致内存泄露

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

class Info { 
    public Info(Activity activity) { 
    } 
}

如上所示的代码，就会大致内存泄露，因为静态变量存储在方法区，他的生命周期是从类加载开始的，一直到整个进程结束。所以一旦静态变量被初始化之后，他所持有的引用只有等到进程结束后才会释放。上面的情况，sInfo是静态变量，并且只有Activity的引用，所以在等到Activity关闭之后，一直到整个应用关闭，才会被释放，这样就导致了内存泄露。

静态持有很多时候都会因为生命周期的不一致而导致内存泄露，所以我们在新建静态持有的变量的时候需要多考虑一下各个成员之间的关系，并且尽量规避静态持有变量这种写法，以免造成内存泄露。当然我们也可以在适当的时候将静态变量重置为null，使其不再持有引用，这样就可以避免内存泄露。

• 非静态内部类造成的内存泄露

非静态内部类，包括匿名内部类，默认机就会持有外部类的引用，当非静态内部类对象的生命周期比外部类对象的生命周期长时，就会导致内存泄露。在Android 中的典型场景是Handler的使用。

private Handler handler = new Handler(){
  @Override
  public void handlerMessage(Message message){
    if(message.what == 1){
    
    }
  }
}

也许有人会说，handler并未作为静态变量持有Activity的引用，生命周期并不一定会比Activity长，应该不一定会导致内存泄露，显然不是这样的。

handler会作为成员变量保存在发送的消息Message中，即Message对象持有handler的引用，而handler是Activity的非静态内部类，即handler会持有Activity的引用，我们就可以理解为Message对象间接的持有了Activity的引用。
Message被发送后先放到消息队列MessageQueue中，然后等待Looper的轮询处理。
那么当Activity退出后，Message对象可能仍然存在于消息队列MessageQueue中未处理或者正在处理，那么这样就会导致Activity无法被回收，以致发生内存泄露。

通常在Android开发中，如果要使用内部类，但又要规避内存泄露，一般都会采用静态内部类+弱引用额方式。

private static class MyHandler extends Handler{
    private WeakReference<MainActivity> activityWeakReference;
    public MyHandler(Activity acivity){
        activityWeakReference = new WeakReference<>(activity);
    }

    @Override
    public void handlerMessage(Message msg){
        MainActivity activity = activityWeakReference.get();
        if(activity != null){
            if(msg.what == 1){
            
            }
        }
    }
}

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

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

• 未取消注册或者回调导致内存泄露。

比如我们在Activity中注册广播，如果在Activity销毁后不取消注册，那么这个广播会一直存在系统中。
在注册观察者模式时，如果不及时取消也会造成内存泄露。比如使用Retrofit+RxJava注册网络请求的观察者的回调，同样作为匿名内部类持有外部类的引用，所以需要记得在不用或者销毁的时候取消注册。

• Timer和TimerTask导致的内存泄露

当我们的Activity销毁时，有可能Timer还在继续等待执行TimerTask，他持有的Activity的引用不能被回收，因此当我们的Activity销毁时，要立即cancle掉Timer和TimerTask，以避免发生内存泄露。

• 集合中的对象未清理造成内存泄露

如果一个对象放入到ArrayList、HashMap等集合中，这个集合就会持有该对象的引用，当我们不再需要这个对象时，也并没有将他从集合中移除，这样只要这个集合还在使用，这个对象就造成了内存泄露，并且如果集合被静态引用的话，集合里面那些没有用的对象更会造成内存泄露了，所以在集合时要及时将不用的对象从集合中remove或者clear掉集合，以避免内存泄露。

• 资源未关闭导致的内存泄露

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

• 属性动画造成内存泄露

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

• Webview造成内存泄露

解决办法是在销毁WebView之前需要先将WebView从父容器中移除，然后再销毁WebView。

总结

• 构造单例的时候尽量不要用Activity的引用。
• 静态引用时注意应用对象的置空或者少用静态引用
• 使用静态内部类+弱引用代替非静态内部类
• 即使取消广播或者观察者模式
• 耗时任务、属性动画在Activity销毁时记得cancle
• 文件流、Cursor等资源及时关闭
• Activity销毁时WebView的移除和销毁