android 常见内存泄漏原因及解决办法

一、Handler 引起的内存泄漏。

public class SecondActivity extends ActionBarActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.second_layout);

        mHandler.postDelayed(new Runnable() {
            @Override
            public void run() {
                // ...
            }
        }, 1000);

        findViewById(R.id.tv_view).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Intent intent = new Intent();
                intent.setClass(SecondActivity.this, ThirdActivity.class);
                startActivity(intent);
            }
        });
    }

    private final Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            // ...
        }
    };
}

SecondActivity代码中有一个延迟1秒执行的消息Message，当界面从SecondActivity跳转到ThirdActivity时，SecondActivity自动进入后台，此时如果系统资源紧张（或者打开设置里面的“不保留活动”选项），SecondActivity将会被finish。但问题来了，由于SecondActivity的Handler对象mHandler为非静态匿名内部类对象，它会自动持有外部类SecondActivity的引用，从而导致SecondActivity无法被回收，造成内存泄漏。

解决办法：将Handler声明为静态内部类，就不会持有外部类SecondActivity的引用，其生命周期就和外部类无关，如果Handler里面需要context的话，可以通过弱引用方式引用外部类。参考代码如下：

public class SecondActivity extends ActionBarActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.second_layout);

        mHandler.postDelayed(mRunnable, 1000);

        findViewById(R.id.tv_view).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Intent intent = new Intent();
                intent.setClass(SecondActivity.this, ThirdActivity.class);
                startActivity(intent);
            }
        });
    }
    
    private static final Runnable mRunnable = new Runnable() {
        @Override
        public void run() { 
            // ...
        }
    };

    private final MyHandler mHandler = new MyHandler(this);
    
    private static class MyHandler extends Handler {
        private final WeakReference mActivity;

        public MyHandler(SecondActivity activity) {
            mActivity = new WeakReference(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            SecondActivity activity = mActivity.get();
            if (activity != null) {
                // ...
            }
        }
    }
}

通过上面的方法，创建一个静态Handler内部类，其持有的对象context使用弱引用，可以避免SecondActivity内存泄漏，但是Looper线程的消息队列中可能还有待处理的消息，所以在Activity的onDestroy方法中，还要记住移除消息队列中待处理的消息。参考代码如下：

public class SecondActivity extends ActionBarActivity {
    // ...
    @Override
    public void onDestroy() {
        super.onDestroy();
        mHandler.removeCallbacks(mRunnable);
    }
    // ...
}

Hander提供了如下方法移除消息队列中的消息。

public final void removeCallbacks(Runnable r)；
public final void removeCallbacks(Runnable r, Object token)；
public final void removeMessages(int what)；
public final void removeMessages(int what, Object object)；
public final void removeCallbacksAndMessages(Object token)；

二、单例模式引起的内存泄漏

由于单例的生命周期是和app的生命周期一致的，如果使用不当很容易引发内存泄漏。如下代码：

public class Singleton {
    private static Singleton mInstance;
    private Context mContext;

    public static Singleton getInstance(Context context) {
        if (mInstance == null) {
            mInstance = new Singleton(context);
        }
        return mInstance;
    }

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

这是一个单例模式的标准写法，表面上看没有任何问题，但是细心的同学会发现，构建该单例的一个实例时需要传入一个Context，此时传入的Context就非常关键，如果此时传入的是Activity，由于Context会被创建的实例一直持有，当Activity进入后台或者开启设置里面的不保留活动时，Activity会被销毁，但是单例持有它的Context引用，Activity又没法销毁，导致了内存泄漏。

参考解决办法：

1、一般在我们开发的应用中，都会实现Application，在里面做一些全局性的事情。可以在该实现里面对外提供一个单例，通过此实例来获取ApplicationContext。代码如下：

public class MyApplication extends Application {
    // ...
    private static MyApplication mInstance;
    public static MyApplication getAppInstance() {
        return mInstance;
    }
    @Override
    public void onCreate() {
        super.onCreate();
        mInstance = this;
    }
    // ...
}

2、重构Singleton，把构建单例时的context去掉，避免外面使用的人传入错误参数，代码如下：

public class Singleton {
    private static Singleton mInstance;
    private Context mContext;

    public static Singleton getInstance() {
        if (mInstance == null) {
            mInstance = new Singleton();
        }
        return mInstance;
    }

    private Singleton() {
        this.mContext = MyApplication.getAppInstance().getApplicationContext();
    }
}

三、非静态内部类创建静态实例引起的内存泄漏

请看下面的代码：

public class SecondActivity2 extends ActionBarActivity {
    private static InnerClass mInner = null;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.second_layout);

        if (mInner == null) {
            mInner = new InnerClass();
        }
    }

    public class InnerClass {

    }
}

上述代码中，SecondActivity2包含一个内部类InnerClass，并且在onCreate代码中创建了InnerClass的静态实例mInner，该实例和app的生命周期是一致的。在某些场景，如Activity需要频繁切换，需要不断加载大量图片的场合，是会出现上述代码的，每次Activity启动之后都会使用该单例，避免重复一些有压力的操作。但是这样会引起内存泄漏，因为非静态的内部类InnerClass会自动持有外部类SecondActivity2的引用，创建的静态实例mInner就会一直持有SecondActivity2的引用，导致SecondActivity2需要销毁的时候没法正常销毁。

怎么知道静态实例mInner持有SecondActivity2的引用呢？debug程序之后你会清晰的发现静态实例mInner确实持有外部类SecondActivity2的引用，见下图：

上述代码的正确做法是把内部类InnerClass修改为静态的就可以避免内存泄漏了，因为静态内部类InnerClass不在持有外部类SecondActivity2的引用了。见下图：

当然，也可以把InnerClass单独抽出来作为一个内，写成单例模式，完成同样的功能，同时也可以避免内存泄漏。

四、非静态匿名内部类引起的内存泄漏

在android开发中，相信大家都会不知不觉地用到大量匿名内部类，如接受广播、点击事件、Handler消息处理等等。但是要注意，如果匿名内部类被异步线程使用，可能会引起内存泄漏。请看如下代码：

public class SecondActivity3 extends ActionBarActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.second_layout);

        new Thread(mRunnable).start();
    }

    private Runnable mRunnable = new Runnable() {
        @Override
        public void run() {
            while (true) {
                try {
                    Thread.sleep(1000);
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        }
    };
}

上述代码中，mRunnable 是非静态匿名内部类，会自动持有外部类SecondActivity3的引用，但是mRunnable被异步线程Thread使用，这样就会导致SecondActivity3在销毁的时候没法正常销毁，从而引起内存泄漏。

正确的做法应该是把mRunnable设置为静态的，这样就不会自动持有外部类SecondActivity3的引用，也就不会引起内存泄漏了。

五、注册/反注册未成对使用引起的内存泄漏

在andorid开发中，我们经常会在Activity的onCreate中注册广播接受器、EventBus等，如果忘记成对的使用反注册，可能会引起内存泄漏。开发过程中应该养成良好的相关，在onCreate或onResume中注册，要记得相应的在onDestroy或onPause中反注册。

六、资源对象没有关闭引起的内存泄漏

在android中，资源性对象比如Cursor、File、Bitmap、视频等，系统都用了一些缓冲技术，在使用这些资源的时候，如果我们确保自己不再使用这些资源了，要及时关闭，否则可能引起内存泄漏。因为有些操作不仅仅只是涉及到Dalvik虚拟机，还涉及到底层C/C++等的内存管理，不能完全寄希望虚拟机帮我们完成内存管理。

在这些资源不使用的时候，记得调用相应的类似close（）、destroy（）、recycler（）、release（）等函数，这些函数往往会通过jni调用底层C/C++的相应函数，完成相关的内存释放。

七、集合对象没有及时清理引起的内存泄漏

我们通常会把一些对象装入到集合中，当不使用的时候一定要记得及时清理集合，让相关对象不再被引用。如果集合是static、不断的往里面添加东西、又忘记去清理，肯定会引起内存泄漏。

使用 LeakCanary 检测 Android 的内存泄漏

内存泄漏防不胜防，通过LeakCanary工具，我们能在开发测试阶段发现绝大多数的内存泄漏。这个工具是开源的，使用也非常方便，而且能够相对准确定位出是哪里出现内存泄漏。

下面以AndroidStudio为例介绍LeakCanary的使用：

1、在build.gradle中配置leakcanary的引用

compile 'com.squareup.leakcanary:leakcanary-android:1.4-beta2'

2、使用RefWatcher监测本该被回收的对象

LeakCanary.install() 会返回一个预定义的 RefWatcher，同时也会启用一个 ActivityRefWatcher，用于自动监控调用 Activity.onDestroy() 之后泄露的 activity。

在自己的Application中添加如下代码：

public class MyApplication extends Application {
    
    private RefWatcher mRefWatcher;

    public static RefWatcher getRefWatcher(Context context) {
        MyApplication application = (MyApplication) context.getApplicationContext();
        return application.mRefWatcher;
    }

    private static MyApplication mInstance;

    public static MyApplication getAppInstance() {
        return mInstance;
    }

    @Override public void onCreate() {
        super.onCreate();
        mRefWatcher = LeakCanary.install(this);
        mInstance = MyApplication.this;
    }
}

LeakCanary就会自动监测内存泄漏，如果有内存泄漏在手机上面会提示，通知栏也会有通知，点击进去之后可以看到具体内存泄露的地方。debug的话，在控制台也会有相关的log输出。

总结：

1、Handler持有的引用最好使用弱引用，在Activity被释放的时候要记得清空Message，取消Handler对象的Runnable；

2、非静态内部类、非静态匿名内部类会自动持有外部类的引用，为避免内存泄露，可以考虑把内部类声明为静态的；

3、对于生命周期比Activity长的对象，要避免直接引用Activity的context，可以考虑使用ApplicationContext；

4、广播接收器、EventBus等的使用过程中，注册/反注册应该成对使用；

5、不再使用的资源对象Cursor、File、Bitmap等要记住正确关闭；

6、集合里面的东西、有加入就应该对应有相应的删除。

网易云新用户大礼包：https://www.163yun.com/gift