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

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

阅读量：6149 次

发布时间：2019-06-21

本文共 5520 字，大约阅读时间需要 18 分钟。

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
     
       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
     
       nameList;    private List
      
        list;    @Override    public void onDestroy() {        super.onDestroy();        if (nameList != null){            nameList.clear();            nameList = null;        }        if (list != null){            list.clear();            list = null;        }    }

5、（查看作者原文）

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，这样的设计谁都得不到释放

参考文章：

转载于:https://www.cnblogs.com/shen-hua/p/7233300.html

你可能感兴趣的文章