Android之内存泄漏以及解决办法(持更)

最新推荐文章于 2024-04-24 16:41:00 发布

姚镜堂

最新推荐文章于 2024-04-24 16:41:00 发布

阅读量7k

点赞数 12

分类专栏：内存泄漏文章标签： android 内存泄露线程内存 LeakCanary

本文链接：https://blog.csdn.net/qq_16628781/article/details/67761590

版权

内存泄漏专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Android之内存泄漏以及解决办法

文章链接：http://blog.csdn.net/qq_16628781/article/details/67761590

知识点：

单例造成的内存泄漏原因和解决方法；
Handler造成的内存泄漏原因和解决方法；
耗时线程造成的内存泄漏原因和解决方法；
非静态内部类造成的内存泄漏原因和解决方法；
WebView引起的内存泄漏原因和解决方法；
资源未关闭造成的内存泄漏原因和解决方法；
集合对象造成的内存泄漏和解决方法；
listview的adapter没有缓存造成的内存泄漏和解决方法；
内存泄漏和内存溢出的区别；
新名词记录{内存泄漏；LeakCanary：检测APP内存泄漏的第三方工具；}

概述

2017.4.28-这里需要明确两个概念

内存泄漏和内存溢出的区别：

内存泄漏：在程序中动态分配给对象内存空间，当此对象所在的程序结束之后，此对象所占用的内存并没有被释放，那么就造成内存泄漏了。判断条件：对象同时满足“可达”和未使用两个条件，就可以判断为内存泄漏。这里描述的是状态。
内存溢出：就是系统分配一个10大小的内存空间给一个对象，但是这个对象实际需要20的空间来存放，那么这就造成了内存溢出。这里描述的是结果。
联系点：内存泄露导致堆栈内存不断增大，从而引发内存溢出，内存泄漏时内存溢出的引发原因之一。
知道了内存泄漏和内存溢出的区别，就可以进行下面的查看了。

内存泄漏，这是一个很容易被人忽视的知识点。在不知不觉中，你的APP突然就崩了，而且只报了一个oom，或者是什么错误都没有，修复也就无从下手了。其实这个很有可能是由于你的APP最终占用的内存超过了设备给你的内存的上限，所以APP爆掉了。

众所周知，移动设备的资源很有限，Android系统给每个APP的内存都有一个阈值，一般是16M。如果程序里有对象一直占用APP内存空间的一部分，而且越来越大，那么你的APP最终的内存大小可能就超过阈值，从而引发内存溢出，最后系统因为“不好意思，你吃饭吃得过分了”，需要把你赶出屋子。表现就是你的APP闪退了。

谁都不愿看到自己的APP在用户的手上闪退了。不能闪退，这已经是不能低的底线了。所以这篇文章就是你应该要看的文章了。并且开始检查你的APP中是否下面几个相类似的用法，有的话，赶紧去看看会不会内存泄漏了。

我在这里是利用LeakCanary进行内存泄漏的检测的，LeakCanary的只是不属于本文的范畴，有需要的可以去搜索LeakCanary看看介绍和使用。

新加内容：

构造Adapter时，没有使用缓存造成的内存泄漏

listview的缓存策略我们都知道：创建（屏幕可见的item + 1 ）个item，在一个item被划出屏幕时，系统会帮我们缓存起来，以便下次回收利用。如果我们在使用listview的时候，没有用到convertView，而是每次都重新new一个viewholder，那么可以想象当我们一个listview里面有10000条数据或更多，那么占用的APP内存就很大很大了，最终极有可能内存溢出。

所以，这里的解决方法是：在给listview的adapter里面，尽量的使用convertView进行item的回收利用，而不是每次都重新的创建新的item，这样不仅消耗性能，而且还容易造成内存泄漏。代码如下：

public View getView(int position, View convertView, ViewGroup parent) { 
ViewHolder viewholder = new ViewHolder(); 
convertView = mInflater.inflate(R.layout.item_layout, null);//item_layout是listview的每一个item布局文件
viewHolder.tv_userName = convertView.findViewById(R.id.tv_userName);
viewHolder.tv_userName.setText("yaojt");
return view; 
}

上面的listview的适配器中，每显示一天item，就会创建一个viewholder，不仅仅造成加载的时候消耗CPU等资源，会造成卡顿；加之如果item有上千条上万条，或者有大图片在item里面，那么当滑出屏幕的item没有能够及时的得到回收，就会造成内存泄漏了。所以上面的方法是一个潜在的风险。
那么如何来解决呢？我们需要用到listview的回收机制，当item滑出屏幕之后，变为不可见，系统会回收此item，那么我们就可以利用已经有的item，而不是重新创建一个。如此一来，内存里面最多就只有屏幕可见item数+1个item了。那么问题就比较好的解决了。
修改后的代码如下所示：

public View getView(int position, View convertView, ViewGroup parent) { 
ViewHolder viewholder = null; 
if (convertView == null) { 
viewholder = new ViewHolder(); 
convertView = mInflater.inflate(R.layout.item_layout, null);//item_layout是listview的每一个item布局文件
viewHolder.tv_userName = convertView.findViewById(R.id.tv_userName);
converView.setTag(viewholder);//这里将viewholder缓存起来，再利用
... 
} else { 
viewholder = convertView.getTag();//这里取出缓存的viewholder直接使用
... 
}
viewHolder.tv_userName.setText("yaojt");
return view; 
}

集合对象没有没有清理造成的内存泄漏

我们通常会把一些对象的引用利用集合来管理，当我们不需要该对象时，如果没有把它的引用从集合中清理掉，这样这个集合就会越来越大，占用的内存也越来越大。如果这个集合是static的话，会随程序常驻内存不会被释放掉，那情况就更严重了。

例如在我们需要监听屏幕点亮和关闭LockScreen。监听每次关闭屏幕事件，都会注册几个callback在ArrayList< InfoCallback>、ArrayList< SimStateCallback>集合中，但是当点亮屏幕之后，这些callback并没有及时的remove掉。可能一次两次集合不会很大，heap增长也不会很明显，不会出现大的问题。但是比如关闭和点亮屏幕这种用户很常操作的动作，可能不过一个小时，上述的集合可能体积就很大很大了，由于锁屏是驻留在system_server进程里，所以导致结果是手机重启。

所以这里的解决方法就是：对于不使用的集合，需要及时的removed。如果可以预计到集合的大小，尽量规定一个集合的大小，因为如果一个集合的size小了，Java会以*2+1的体积扩展集合容量。

单例造成的内存泄漏

单例模式的“威名”做开发的人一定都听过。单例模式的好处主要是提供一个实例，统一访问变量，不会造成过多的资源消耗。但是在Android开发中，我们经常会因为错误的使用单例模式而造成内存泄漏。

例如，实例化单例模式的时候，我们经常要传入一个context，如果单例的生命周期比我们的context生命周期更长，那么当我们的context需要释放时(context通常是activity)，就会因为单例实例引用着context，因为这是强引用，导致context不能被及时回收，从而造成内存泄漏。

看下面的单例内存泄漏的例子：

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

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

    public static LoginImp getInstance(Context context) {
        if (mInstance == null) {
            synchronized (LoginImp.class) {
                if (mInstance == null) {
                    mInstance = new LoginImp(context);
                }
            }
        }
        return mInstance;
    }

    public void login() {
    }

}

这里我们看到，如果我们在一个activity里面获取LoginImp实例，然后调用登录方法，在关闭此activity，就会造成内存泄漏。Android开发中我们尤其需要注意生命周期这一个概念，无论是任何对象的，因为移动设备的资源毕竟很有限。

解决方法：
既然是实例的生命周期可能比传入的context生命周期要长，那么我们可以根据context获得有更长的生命周期的对象，比如application对象的生命周期是和APP的生命周期一样长的，就和传入的context进行了解耦。修改后的代码如下：

//私有构造函数，获得application对象
private LoginManager(Context context) {
        this.mContext = context;
        //解决 办法要保证Context和AppLication的生命周期一样，而不是直接饮用context对象
        //this.mContext = context.getApplicationContext();
    }

课外音：我们这里使用到synchronized关键字，正确的使用方式是上面的单例模式那样子的，需要作双重的非空判断，才能够使单例真正的“单例”。如果需要连接更多，请看这里。

Handler造成的内存泄漏

Handler大家也是见得很多很多了吧。如果使用不当，那么也有内存泄漏的可能性。下面看一种情况。

public class MainActivity extends AppCompatActivity {
    private Handler mHandler = new Handler();
    private TextView mTextView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mTextView = (TextView) findViewById(R.id.text);//模拟内存泄露
        mHandler.postDelayed(new Runnable() {
            @Override
            public void run() {
                dosomething();
            }
        }, 3 * 60 * 1000);
        this.finish();
    }

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

在上面的代码中，mHandler会隐式的持有外部类的对象，这个外部类就是MainActivity。在mHandle中，我们延时执行180秒之后才开始dosomething()，但是我们立马finish()结束MainActivity，由于mHandler对MainActivity有着引用，所以MainActivity得不到释放，资源无法及时回收，从而造成内存泄漏。

那么这个问题如何来解决呢？

很简单，只要在MainActivity结束的时候，移除mHandler的引用不就可以了嘛。代码如下：

@Override
    protected void onDestroy() {
        super.onDestroy();
        //移除mHandler的引用即可
        mHandler.removeCallbacksAndMessages(null);
    }

又或者，我们可以使用软引用，代替mHandler对MainActivity的强引用，软引用在内存吃紧的情况下，Java回收机制会优先于回收软引用的对象。我们可以继承Handler，然后对传入的对象进行软引用。代码如下：

private SoftHandler mHandler = new SoftHandler(this);

public static class SoftHandler extends Handler {
    private final WeakReference<Activity> mActivity;

    public SoftHandler(Activity activity) {
        mActivity = new WeakReference<Activity>(activity);
    }

    @Override public void handleMessage(Message msg) {
        super.handleMessage(msg);
    }
}

补充，这里还有一种泄漏的方式：

public class MainActivity extends AppCompatActivity {
    private Handler mHandler = new Handler();
    private TextView mTextView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //这里声明的是后台handler
        Thread mThread = newHandlerThread("handler1", Process.THREAD_PRIORITY_BACKGROUND);   
        mThread.start();  
MyHandler mHandler = new MyHandler( mThread.getLooper( ) );  
    }

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

解释：HandlerThread的run方法是一个死循环，它不会自己结束，线程的生命周期超过了activity生命周期，当横竖屏切换，HandlerThread线程的数量会随着activity重建次数的增加而增加。

解决的方法就是在应该在onDestroy时将线程停止掉，调用如下方法：

mThread.getLooper().quit();

耗时线程造成的内存泄漏

现在第三方的包都帮我们做好了很多线程的工作，比如很多网络请求库，io库等等。但是我们也有可能直接使用AsyncTask原生类进行操作。AsyncTask在doInBackGround()方法里面做耗时的操作。时间长短不是我们能够控制的，在耗时操作过程中，我们需要结束发起此耗时操作的activity，那么这个activity就不能被及时的回收，造成内存泄漏。

解决方法是，在对activity进行finish的时候，也去检测AsyncTask是否还存活着，如果存活就结束掉AsyncTask对象。代码如下：

private AsyncTask asyncTask;

    @Override
    protected void onDestroy() {
        super.onDestroy();
        destroyAsyncTask();
    }

    //检测和结束AsyncTask对象
    private void destroyAsyncTask() {
        if (asyncTask != null && !asyncTask.isCancelled()) {
            asyncTask.cancel(true);
        }
        asyncTask = null;
    }

非静态内部类造成的内存泄漏

这个引起内存泄漏的方式，和Handler是一样的：都是隐式的持有了activity对象。只要改成static静态的内部类，就能够是内部类不会对activity有一个隐式的持有activity对象了。

代码如下：

public class MainActivity extends AppCompatActivity {
    private static UserBean mUserBean;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //模拟内存泄露
        if (mUserBean == null) {
            mUserBean= new UserBean();
            mUserBean.setAge(24);
            mUserBean.setName("yaojt");
        }
        finish();
    }
    //修改后：加入static修饰内部类
   static class UserBean { 
        private int age;
        private String name;

        public int getAge() {
            return age;
        }

        public void setAge(int age) {
            this.age = age;
        }

        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
        }
    }
}

WebView引起的内存泄漏

HTML大行其道的今天，Android也很早加入对HTML的支持了，支持在原生页面中利用WebView控件加载HTML页面。但是WebView会在解析网页时，占用很多的内存。如果打开了十多个HTML页面，因为之前的页面不会被释放，用于快速返回前一个页面，所以占用内存就很很可能会爆，导致APP闪退。

解决方法是在我们推出承载WebView的activity之前，需要清除掉HTML页面占用的内存，释放资源。代码如下：

private void destroyWebView() {
        if (mWebView != null) {
            mLinearLayout.removeView(mWebView);
            mWebView.pauseTimers();
            mWebView.removeAllViews();
            mWebView.destroy();
            mWebView = null;
        }
    }

资源未关闭造成的内存泄漏

这个就比较好理解了，说的就是例如我们访问本地数据库的时候，为了不经常启动和关闭数据库，会保持一段时间对数据库的联系，但是我们在最后绝对不要忘了要及时关闭数据库。还有其他可能会因为未关闭而引起的内存泄漏问题：BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等等。解决方法就比较简单了，关闭连接就OK了。例如cursor游标需要在最后关闭掉。

cursor.close();

总结

上面就是几种在我们开发过程中，比较常遇到的内存泄漏的问题，我们需要特别注意上面的几个问题，因为有可能一开始内存泄漏问题不是很明显，但是操作到一段时间之后，APP就可能挂掉了。而你可能找不到哪里报错了，就算知道了是oom，你也很难知道如何来修复，因为内存泄漏的问题是“日积夜累”而发生的。

说白了就是：我们要在应该释放某些引用的时候，就要及时的释放掉，不能让它一直占用着资源。

如有任何问题，请及时与我联系。谢谢。

姚镜堂

关注

12
点赞
踩
32

收藏

觉得还不错? 一键收藏
0
评论
Android之内存泄漏以及解决办法(持更)

Android之常见内存泄漏以及解决办法文章链接知识点：单例造成的内存泄漏原因和解决方法；Handler造成的内存泄漏原因和解决方法；耗时线程造成的内存泄漏原因和解决方法；非静态内部类造成的内存泄漏原因和解决方法；WebView引起的内存泄漏原因和解决方法；资源未关闭造成的内存泄漏原因和解决方法；新名词记录{内存泄漏；LeakCanary：检测APP内存泄漏的第三方工具；}概述内存泄
复制链接

扫一扫