Android开发中常见的内存泄露案例以及解决方法总结

1、单例模式引起的内存泄露

由于单例模式的静态特性，使得它的生命周期和我们的应用一样长，如果让单例无限制的持有Activity的强引用就会导致内存泄漏
如错误代码示例：

public class UserInfoBean {
    private static UserInfoBean userInfoBean;

    private Context mContext;

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

    public static UserInfoBean getUserInfoBean(Context context) {
        if (userInfoBean == null) {
            synchronized (UserInfoBean.class) {
                if (userInfoBean == null) {
                    userInfoBean = new UserInfoBean(context);
                }
            }
        }
        return userInfoBean;
    }
}

正确代码：

将 this.mContext = context改成：this.mContext = context.getApplicationContext();或者代码中用到的Context可以使用自己定义的MyApplication中的MyApplication.getInstance获取；

2、Handler引起的内存泄露

Handler引起的内存泄漏在开发中最为常见的。Handler、Message、MessageQueue都是相互关联在一起的，如果Handler发送的Message尚未被处理，那么该Message以及发送它的Handler对象都会被线程MessageQueue一直持有。

由于Handler属于TLS（Thread Local Storage）变量，生命周期和Activity是不一致的，因此这种实现方式很难保证跟Activity的生命周期一直，所以很容易无法释放内存

如错误代码：

 private final Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            // ...
        }
    };
@Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mHandler.sendMessageDelayed(Message.obtain(), 60000*5);
    }  

在上面的例子中生命了一个延时5分钟执行的Message，当该Activity退出的时候，延时任务（Message）还在主线成的MessageQueue中等待，此时的Message持有Handler的强引用，并且由于Handler是我们的Activity类的非静态内部类，所以Handler会持有该Activity的强引用，此时该Activity退出时无法进行内存回收，造成内存泄漏。

解决办法：将Handler声明为静态内部类，这样它就不会持有外部类的引用了，Handler的的生命周期就与Activity无关了。不过倘若用到Context等外部类的非static对象，还是应该通过使用Application中与应用同生命周期的Context比较合适

正确代码：

private static final class MyHandler extends Handler {
        private WeakReference<HomeMainActivity> mActivity;

        public MyHandler(HomeMainActivity mainActivity) {
            mActivity = new WeakReference<>(mainActivity);
　　　　　　//or
　　　　　　//mActivity=mainActivity.getApplicationContext;
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            HomeMainActivity mainActivity = mActivity.get();
            if (null != mActivity) {
                //相关处理
            }
        }
    }

private final MyHandler mHandler = new MyHandler(this);

mHandler.sendMessageDelayed(Message.obtain(), 60000*5);

虽然我们结束了Activity的内存泄漏问题，但是经过Handler发送的延时消息还在MessageQueue中，Looper也在等待处理消息，所以我们要在Activity销毁的时候处理掉队列中的消息。

@Override
    protected void onDestroy() {
        super.onDestroy();
        //传入null，就表示移除所有Message和Runnable
        mHandler.removeCallbacksAndMessages(null);
    }

 3、匿名内部类在异步线程中的使用引起的内存泄漏

Android开发经常会继承实现 Activity 或者 Fragment 或者 View。如果使用了匿名类，而又被异步线程所引用，如果没有任何措施同样会导致内存泄漏的：

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_inner_bad);

        Runnable runnable1 = new MyRunnable();
        Runnable runnable2 = new Runnable() {
            @Override
            public void run() {

            }
        };
    }

    private static class MyRunnable implements Runnable{

        @Override
        public void run() {

        }
    }
}

runnable1 和 runnable2的区别就是，runnable2使用了匿名内部类，我们看看引用时的引用内存

可以看到，runnable1是没有什么特别的。但runnable2多出了一个MainActivity的引用，若是这个引用再传入到一个异步线程，此线程在和Activity生命周期不一致的时候，也就造成了Activity的泄露。

4、集合引发的内存泄漏

我们通常会把一些对象的引用加入到集合容器（比如ArrayList）中，当我们不再需要该对象时，并没有把它的引用从集合中清理掉，当集合中的内容过于大的时候，并且是static的时候就造成了内存泄漏，所有最好在onDestory清空；

    private List<String> nameList;
    private List<Fragment> list;

    @Override
    public void onDestroy() {
        super.onDestroy();
        if (nameList != null){
            nameList.clear();
            nameList = null;
        }
        if (list != null){
            list.clear();
            list = null;
        }
    }

5、Android WebView Memory Leak WebView内存泄漏（查看作者原文）

WebView解析网页时会申请Native堆内存用于保存页面元素，当页面较复杂时会有很大的内存占用。如果页面包含图片，内存占用会更严重。并且打开新页面时，为了能快速回退，之前页面占用的内存也不会释放。有时浏览十几个网页，都会占用几百兆的内存。这样加载网页较多时，会导致系统不堪重负，最终强制关闭应用，也就是出现应用闪退或重启。

要使用WebView不造成内存泄漏，首先应该做的就是不能在xml中定义webview节点，而是在需要的时候动态生成。即：可以在使用WebView的地方放置一个LinearLayout类似ViewGroup的节点，然后在要使用WebView的时候，动态生成即：

WebView      mWebView = new WebView(getApplicationgContext());
LinearLayout mll      = findViewById(R.id.xxx);
mll.addView(mWebView);

然后一定要在onDestroy()方法中显式的调用

protected void onDestroy() {       super.onDestroy(); mWebView.removeAllViews(); mWebView.destroy() }

注意： new  WebView(getApplicationgContext()) ;必须传入ApplicationContext如果传入Activity的Context的话，对内存的引用会一直被保持着。有人用这个方法解决了当Activity被消除后依然保持引用的问题。但是你会发现，如果你需要在WebView中打开链接或者你打开的页面带有flash，获得你的WebView想弹出一个dialog，都会导致从ApplicationContext到ActivityContext的强制类型转换错误，从而导致你应用崩溃。这是因为在加载flash的时候，系统会首先把你的WebView作为父控件，然后在该控件上绘制flash，他想找一个Activity的Context来绘制他，但是你传入的是ApplicationContext。后果，你可以晓得了哈。

其他常见的引起内存泄漏原因

• 构造Adapter时，没有使用缓存的 convertView
• Bitmap在不使用的时候没有使用recycle()释放内存
• 非静态内部类的静态实例容易造成内存泄漏：即一个类中如果你不能够控制它其中内部类的生命周期（譬如Activity中的一些特殊Handler等），则尽量使用静态类和弱引用来处理（譬如ViewRoot的实现）。
• 警惕线程未终止造成的内存泄露；譬如在Activity中关联了一个生命周期超过Activity的Thread，在退出Activity时切记结束线程。一个典型的例子就是HandlerThread的run方法是一个死循环，它不会自己结束，线程的生命周期超过了Activity生命周期，我们必须手动在Activity的销毁方法中调用thread.getLooper().quit();才不会泄露。
• 对象的注册与反注册没有成对出现造成的内存泄露；譬如注册广播接收器、注册观察者（典型的譬如数据库的监听）等。
• 创建与关闭没有成对出现造成的泄露；譬如Cursor资源必须手动关闭，WebView必须手动销毁，流等对象必须手动关闭等。
• 不要在执行频率很高的方法或者循环中创建对象（比如onMeasure），可以使用HashTable等创建一组对象容器从容器中取那些对象，而不用每次new与释放。
• 避免代码设计模式的错误造成内存泄露；譬如循环引用，A持有B，B持有C，C持有A，这样的设计谁都得不到释放

参考文章：

1.【Android 性能优化】—— 详解内存优化的来龙去脉

2.Android WebView Memory Leak WebView内存泄漏