Android内存优化--常见的内存泄漏以及优化方案

无用的内存（没有使用的对象）仍然被其他对象持有引用，造成该对象无法被系统回收，以致该对象在堆中所占用的内存单元无法被释放而造成内存空间浪费，这中情况就是内存泄露。

在开发的过程中，我们的一些编程习惯有可能会导致app内存溢出情况，下面举简单的几个例子说明：

1、单利模式：

单利模式在开发中我们经常使用，如果使用不当就会造成内存泄漏，单利模式都是静态的，它的生命周期一般都会很长，如果一个对象已经没有用处了，但是单例还持有它的引用，那么在整个应用程序的生命周期它都不能正常被回收，从而导致内存泄露。说了这么多，上代码：

    public class Books {

        public static Books instance;

        private Context context;

        private Books(Context context){
              this.context = context;`
          }

        public static Books getInstance(Context context){
             if (instance==null){
                  instance =new Books(context);
             } 
          return instance;
      }
    }

在上面的代码片段中,在调用getInstance(context)方法时，传入context，activity，service上下文都会造成内存泄漏。

以activity为例，当我们启动一个activity 在其中调用getInstance(context)传入this获取Books单例，这样Books类的单例instance就持有了Activity的引用，当退出activity时，activity便销毁，然而Books单利为静态单利，在应用程序的整个生命周期中存在会继续持有这个activity的引用，导致这个activity对象无法被回收释放，这就造成了内存泄露。

为了避免这样单例导致内存泄露，我们可以将context参数改为全局的上下文：

    private Books(Context context){
        this.context = context.getApplication();
    }

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

单例模式对应应用程序的生命周期，所以我们在构造单例的时候尽量避免使用activity的上下文，而是使用Application的上下文。

2、静态变量:

静态变量存储在方法区，它的生命周期从类加载开始，到整个进程结束。一旦静态变量初始化后，它所持有的引用只有等到进程结束才会释放。

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

3、动画及吐司:

动画在开发中是一个不能少的环节，也是一个很耗时的操作，然而在开发中很多时候都忘记对动画进行关闭，即使当前界面已经销毁，我们看不见动画的存在，只要没有调用cancel() 便依然执行，从而导致activity或者fragment中的内存无法释放，资源无法得到及时的回收。

     @Override
        protected void onDestroy() {
            super.onDestroy();
            if (objectAnimator!=null){
                objectAnimator.cancel();
                objectAnimator = null;
            }
            if(toast!=null){
                toast.cancel();
              }
         }

4、非静态内部类：
非静态内部类（包括匿名内部类）默认就会持有外部类的引用，当非静态内部类对象的生命周期比外部类对象的生命周期长时，就会导致内存泄露。

非静态内部类导致的内存泄露在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) {
                     // todo
                }
            }
          };
      }

在上面的代码片段中虽然没有内部类的写法，也不会造成内存。

熟悉Handler消息机制的都知道，Handler会作为成员变量保存在发送的消息msg中，即msg持有Handler的引用，而Handler是Activity的非静态内部类实例，即Handler持有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<MainActivity> 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) {
                        // todo
                    }
                }
            }
        }
    }

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

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

5、未取消注册

比如我们在activity中注册了广播，在销毁activity时没有对广播进行取消，那么这个广播会一直存在系统中，同上面所说的非静态内部类一样持有Activity引用，导致内存泄露。因此注册广播后在Activity销毁后一定要取消注册。

6、集合和资源未关闭和置空

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

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

总结

开发过程中内存管理是一个重点，也培养程序员对系统资源的管理，内存泄漏最终会导致内存溢出 OOM异常。

构建单例模式的时候尽量不要用activity做引入。

使用到静态变量的时候，在内存回收的时候将其静态变量置空。

使用动画和吐司的时候，虽然给我们的感觉是已经结束了，只要没有调用cancel() 内存都会一直被占用，得不到释放。

使用静态内部类+软引用代替非静态内部类。

及时取消广播或者观察者注册。