Android中使用Thread造成内存泄露的分析和解决

Thread 内存泄露

线程也是造成内存泄露的一个重要的源头。线程产生内存泄露的主要原因在于线程生命周期的不可控。

看一下下面是否存在问题

    public class ThreadActivity extends Activity {
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
            new MyThread().start();
        }

        private class MyThread extends Thread {
            @Override
            public void run() {
                super.run();
                dosomthing();
            }
        }
        private void dosomthing(){

        }
    }
 
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18

这段代码很平常也很简单,是我们经常使用的形式。


真的没有问题吗

我们思考一个问题:假设MyThread的run函数是一个很费时的操作,当我们开启该线程后,将设备的横屏变为了竖屏, 
一般情况下当屏幕转换时会重新创建Activity,按照我们的想法,老的Activity应该会被销毁才对,然而事实上并非如此。 
由于我们的线程是Activity的内部类,所以MyThread中保存了Activity的一个引用,当MyThread的run函数没有结束时, 
MyThread是不会被销毁的,因此它所引用的老的Activity也不会被销毁,因此就出现了内存泄露的问题。

这种线程导致的内存泄露问题应该如何解决呢?

  1. 将线程的内部类,改为静态内部类。
  2. 在线程内部采用弱引用保存Context引用。

代码如下:

public class ThreadAvoidActivity extends Activity {
            public void onCreate(Bundle savedInstanceState) {
                super.onCreate(savedInstanceState);
                setContentView(R.layout.activity_main);
                new MyThread(this).start();
            }

            private void dosomthing() {

            }

            private static class MyThread extends Thread {
                WeakReference<ThreadAvoidActivity> mThreadActivityRef;

                public MyThread(ThreadAvoidActivity activity) {
                    mThreadActivityRef = new WeakReference<ThreadAvoidActivity>(
                            activity);
                }

                @Override
                public void run() {
                    super.run();
                    if (mThreadActivityRef == null)
                        return;
                    if (mThreadActivityRef.get() != null)
                        mThreadActivityRef.get().dosomthing();
                    // dosomthing
                }
            }
        }
 
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30

上面的两个步骤其实是切换两个对象的双向强引用链接 
静态内部类:切断Activity 对于 MyThread的强引用。 
弱引用: 切断MyThread对于Activity 的强引用。

AsynTask 内部类会如何呢?

有些人喜欢用Android提供的AsyncTask,但事实上AsyncTask的问题更加严重, 
Thread只有在run函数不结束时才出现这种内存泄露问题,然而AsyncTask内部的实现机制是运用了ThreadPoolExcutor, 
该类产生的Thread对象的生命周期是不确定的,是应用程序无法控制的, 
因此如果AsyncTask作为Activity的内部类,就更容易出现内存泄露的问题。

在看android联系人2.3源码的时候看到一个类WeakAsyncTask, 内部用到了WeakReference软引用, 这样可以解决内存泄露的问题; 其实给AysncTask加上static, 静态的内部类不会持有对外部类的引用, 就能够解决问题, 只不过这样如果AysncTask的方法用到的成员变量都需要加上static;

WeakReference和AsyncTask的美妙结合

为了避免开发者在UI线程上做耗时操作,Android提供了不少异步API,其中之一就是AsyncTask。而对于某些频繁操作数据库的应用(例如,Phonebook)而言,需要一种异步的并且低耗资源的(低耗是两个方面的事情,要么是你占有的多点,但是能快速释放;要么是你本身就占有的少。这两种都可以保证其它应用有资源可用)组件。所以,那就来个WeakAsyncTask吧,唔,美妙的产物,既保证占有资源的快速释放,又保证操作是异步进行。 
那为什么不是soft reference呢? 
这个,来看看weak和soft两者的区别:

* A SoftReference should be cleared and enqueued as late as possible, that is, in case the VM is in danger of running out of memory.
* A WeakReference may be cleared and enqueued as soon as is known to be weakly-referenced.

下面是WeakAsyncTask的源码:

public abstract class WeakAsyncTask<Params, Progress, Result, WeakTarget>
    extends AsyncTask<Params, Progress, Result> {
protected WeakReference<WeakTarget> mTarget;

public WeakAsyncTask(WeakTarget target) {
    mTarget = new WeakReference<WeakTarget>(target);
}

@Override
protected final void onPreExecute() {
    final WeakTarget target = mTarget.get();
    if (target != null) {
        this.onPreExecute(target);
    }
}

@Override
protected final Result doInBackground(Params... params) {
    final WeakTarget target = mTarget.get();
    if (target != null) {
        return this.doInBackground(target, params);
    } else {
        return null;
    }
}

@Override
protected final void onPostExecute(Result result) {
    final WeakTarget target = mTarget.get();
    if (target != null) {
        this.onPostExecute(target, result);
    }
}

protected void onPreExecute(WeakTarget target) {
    // Nodefaultaction
}

protected abstract Result doInBackground(WeakTarget target,
        Params... params);

protected void onPostExecute(WeakTarget target, Result result) {
    // Nodefaultaction
}
}
 
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45

使用也很简单, 用法也几乎和AsyncTask一样:

private static class MyTask extends WeakAsyncTask<Void, Void, String, MainActivity> {
        public MyTask(MainActivity target) {
            super(target);
        }

        @Override
        protected String doInBackground(MainActivity target, Void... params) { // 获取context,
            // 执行一些操作
            Context context = target;
            return "Hello Android    !!!!!";
        }

        @Override
        protected void onPostExecute(MainActivity target, String s) {
            // 执行操作
        }
    }
 
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17

直接调用执行:

new MyTask(this).execute(); 
 
 
  • 1
  • 1

其实还可以根据这个思想写一个WeakHandler! 
Android Weak Handler:可以避免内存泄漏的Handler库 
http://blog.csdn.net/jdsjlzx/article/details/51388862

本文部分来自:http://blog.csdn.net/zhuanglonghai/article/details/37909553

  • 0
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Android线上内存泄露是指在Android应用程序存在未释放的内存对象,导致应用程序的内存使用量不断增加,最终可能导致应用程序崩溃或运行缓慢。 常见的Android线上内存泄露原因包括: 1. 静态变量引用:在Android应用,如果一个对象被一个静态变量引用,那么即使该对象不再需要,系统也无法释放它占用的内存。这种情况下,如果静态变量的生命周期比应用的生命周期长,就会导致内存泄露。 2. 匿名内部类和非静态内部类引用:在Android开发经常使用匿名内部类或非静态内部类,如果这些类引用了外部类的实例,那么外部类的实例就无法被释放,从而导致内存泄露。 3. Handler和Thread引用:在Android使用Handler和Thread时需要注意是否正确释放相关资源,否则可能导致内存泄露。 4. 资源未关闭:在使用一些需要手动关闭的资源,如数据库连接、文件流、网络连接等时,如果没有及时关闭这些资源,就会导致内存泄露。 5. 单例模式的不当使用:如果一个类被设计为单例模式,并且该类持有了大量的数据或引用其他对象,那么该对象的生命周期将与应用程序的生命周期相同,容易导致内存泄露。 要解决Android线上内存泄露问题,可以采取以下步骤: 1. 使用工具进行内存泄露分析Android平台提供了一些工具,如Android Profiler和LeakCanary等,可以帮助定位内存泄漏的原因和位置。 2. 检查代码:仔细检查代码,确保正确地释放对象,包括关闭资源、取消注册等操作。 3. 避免静态引用:尽量避免使用静态引用,特别是对于大对象或持有其他对象引用的对象。 4. 使用弱引用:对于可能导致内存泄露的对象,可以考虑使用弱引用来引用它们,这样当没有强引用指向它们时,系统可以自动回收它们。 5. 注意生命周期:在设计和使用对象时,要注意对象的生命周期,尽量使其与应用程序的生命周期相一致,避免对象持有过长时间。 6. 及时释放资源:在使用需要手动关闭的资源时,要及时关闭这些资源,避免资源泄露。 综上所述,通过分析内存泄漏的原因,并采取相应的措施来修复和预防内存泄漏问题,可以提高Android应用程序的性能和稳定性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值