性能优化系列-Android 内存泄漏例子

36 篇文章 0 订阅
16 篇文章 0 订阅

性能优化系列-Android 内存泄漏例子

内存泄露(Memory Leak)
Java内存泄漏指的是进程中某些对象(垃圾对象)已经没有使用价值了,但是它们却可以直接或间接地引用到gc roots导致无法被GC回收。Dalvik VM具备的GC机制(垃圾回收机制)会在内存占用过多时自动回收,严重时会造成内存溢出OOM。

内存溢出OOM(Out Of Memory)
当应用程序申请的java heap空间超过Dalvik VM HeapGrowthLimit时,溢出。
效果是能让较多进程常驻内存。

注意:OOM并不代表内存不足,只要申请的heap超过Dalvik VM HeapGrowthLimit时,即使内存充足也会溢出。

还有一点概念要搞清楚, 内存泄漏可以导致内存溢出, 但是内存溢出并不是都是由内存泄漏造成的。

接下来我们聊几种常见的内存泄漏的例子 ,以及优化方案。

  • 静态变量引起的内存泄漏
  • 非静态内部类引起的内存泄漏
  • 资源未关闭引起的内存泄漏
  • 不要用的监听未移除

一、静态变量引起的内存泄漏

在java中静态变量的生命周期是在类加载时开始,类卸载时结束。也就是说,在android中其生命周期是在进程启动时开始,进程死亡时结束。所以在程序的运行期间,如果进程没有被杀死,静态变量就会一直存在,不会被回收掉。如果静态变量强引用了某个Activity中变量,那么这个Activity就同样也不会被释放,
即便是该Activity执行了onDestroy 注意这里Activity 执行onDestory 和 内存回收不是同一概念

这类问题的解决方案为:

1.寻找与该静态变量生命周期差不多的替代对象。

2.若找不到,将强引用方式改成弱引用。

找几段代码看看比较典型的例子如下:

  1. 单例引起的Context内存泄漏
public class Singleton {

    private Context context;
    private static Singleton mInstance;

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

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

当调用getInstance时,如果传入的context是Activity的context。只要这个单例没有被释放,这个Activity也不会被释放。

解决办法当然是, 让context的引用的生命周期和单例一样长。传入Application的context,因为Application的context的生命周期比Activity长,可以理解为Application的context与单例的生命周期一样长,传入它是最合适的。

关键代码:

   //将传入的context转换成Application的context           
   mInstance = new Singleton(context.getApplicationContext());
                    
  1. 集合引发的内存泄漏

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

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

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

二、非静态内部类引起的内存泄漏

内部类的优势之一就是可以访问外部类,不幸的是,导致内存泄漏的原因,就是内部类持有外部类实例的强引用。

在java里,非静态内部类 和 匿名类 都会潜在的引用它们所属的外部类。但是,静态内部类却不会。

如果这个非静态内部类实例做了一些耗时的操作,就会造成外围对象不会被回收,从而导致内存泄漏。

这类问题的解决方案为:

  • 1.将内部类变成静态内部类

  • 2.如果有强引用Activity中的属性,则将该属性的引用方式改为弱引用。

  • 3.在业务允许的情况下,当Activity执行onDestory时,结束这些耗时任务。

  1. 内部线程造成的内存泄漏
public class LeakAty extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.aty_leak);
        test();
    }

    public void test() {
        //匿名内部类会引用其外围实例LeakAty.this,所以会导致内存泄漏    
        new Thread(new Runnable() {
            @Override
            public void run() {
                while (true) {
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }
        }).start();
    }
}

解决方案

将非静态匿名内部类修改为静态匿名内部类

public class LeakAty extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.aty_leak);
        test();
    }

    //加上static,变成静态匿名内部类   
    public static void test() {
        new Thread(new Runnable() {
            @Override
            public void run() {
                while (true) {
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }
        }).start();
    }
}

还如, 关键代码:TimerTask 缺失部分自行脑补,

void scheduleTimer() {
    new Timer().schedule(new TimerTask() {
        @Override
        public void run() {
            while (true) ;
        }
    }, Long.MAX_VALUE >> 1);
}

View ttButton = findViewById(R.id.tt_button);
ttButton.setOnClickListener(new View.OnClickListener(){
    @Override 
    public void onClick (View v){
        scheduleTimer();
        nextActivity();
    }
});

  1. Handler引起的内存泄漏
public class LeakAty extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.aty_leak);
        fetchData();
    }

    private Handler mHandler = new Handler() {
        public void handleMessage(android.os.Message msg) {
            switch (msg.what) {
                case 0:
                    // 刷新数据
                    break;
                default:
                    break;
            }
        };
    };
    private void fetchData() {
        //获取数据     
		mHandler.sendEmptyMessage(0);

    }
}

mHandler 为匿名内部类实例,会引用外围对象LeakAty.this,如果该Handler在Activity退出时依然还有消息需要处理,那么这个Activity就不会被回收。

比如尤其是:

mHandler.postDelayed(sRunnable, 1000 * 60 * 10);

解决方案:


解决方案
public class LeakAty extends Activity {
    private TextView tvResult;
    private MyHandler handler;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.aty_leak);
        tvResult = (TextView) findViewById(R.id.tvResult);
        handler = new MyHandler(this);
        fetchData();
    }

    //第一步,将Handler改成静态内部类。   
    private static class MyHandler extends Handler {
        //第二步,将需要引用Activity的地方,改成弱引用。     
        private WeakReference<LeakAty> atyInstance;

        public MyHandler(LeakAty aty) {
            this.atyInstance = new WeakReference<LeakAty>(aty);
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            LeakAty aty = atyInstance == null ? null : atyInstance.get();
            //如果Activity被释放回收了,则不处理这些消息 没毛病, 如果activity都没回收了, 那么消息肯定也就不用处理了, 直接return。       
            if (aty == null || aty.isFinishing()) {
                return;
            }
            aty.tvResult.setText("fetch data success");
        }
    }

    private void fetchData() {
        // 获取数据     
        handler.sendEmptyMessage(0);
    }

    @Override
    protected void onDestroy() {
        //第三步,在Activity退出的时候移除回调     
        super.onDestroy();
        
        handler.removeCallbacksAndMessages(null);
    }
}

这里用弱引用,万一被回收了怎么办?岂不是会空指针。
需要说明:你弱引用里面的Activity都被干掉了,你一个Handler还想继续玩什么? 所以如果为null, 直接return ,没毛病。

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

小结

虽然静态类与非静态类之间的区别并不大,但是对于Android开发者而言却是必须理解的。
至少我们要清楚,如果一个内部类实例的生命周期比Activity更长,那么我们千万不要使用非静态的内部类。
最好的做法是,使用静态内部类,然后在该类里使用弱引用来指向所在的Activity。

三、资源未关闭引起的内存泄漏

当使用了BraodcastReceiver、Cursor、Bitmap、自定义属性attr等资源时,当不需要使用时,需要及时释放掉,若没有释放,则会引起内存泄漏

四、不要用的监听未移除

  1. 调用了View.getViewTreeObserver().addOnXXXListener ,而没有调用View.getViewTreeObserver().removeXXXListener
  2. 传感器的注册与解注册

void registerListener() {
    SensorManager sensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);
    Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ALL);
    sensorManager.registerListener(this, sensor, SensorManager.SENSOR_DELAY_FASTEST);
}

View smButton = findViewById(R.id.sm_button);
smButton.setOnClickListener(new View.OnClickListener(){
    @Override
    public void onClick (View v){
        registerListener();
        nextActivity();
    }
});

3.PhoneStateListener电话状态监听

假设我们希望在锁屏界面(LockScreen)中,监听系统中的电话服务以获取一些信息(如信号强度等),则可以在LockScreen中定义一个 PhoneStateListener的对象,同时将它注册到TelephonyManager服务中,而对于TelephonyManager 是系统级Service, 生命周期和系统一致。
对于LockScreen对象,当需要显示锁屏界面的时候就会创建一个LockScreen对象,而当锁屏界面消失的时候LockScreen对象就会被释放掉。 但是如果在释放 LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象,则会导致LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失,则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process 进程挂掉。 虽然有些系统程序,它本身好像是可以自动取消注册的(当然不及时),但是我们还是应该在我们的程序中明确的取消注册,程序结束时应该把所有的注册都取消掉。

五、无限循环动画

在Activity中播放属性动画中的一类无限循环动画,没有在ondestory中停止动画,Activity会被动画持有而无法释放。

解决办法 就是及时停止动画,释放资源。

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

  • 构造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. 分析内存使用情况
  2. 内存机制分析
  3. 性能优化-内存优化和布局优化
  4. 详解 Android 性能优化【史诗巨著之内存篇
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值