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

性能优化系列-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());
                    

2. 集合引发的内存泄漏

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

    private static List nameList;
    private static List 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();
    }
});

2. 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 atyInstance;

        public MyHandler(LeakAty aty) {
            this.atyInstance = new WeakReference(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 性能优化【史诗巨著之内存篇