Android开发——常见的内存泄漏以及解决方案（一）

0. 前言  

转载请注明出处：http://blog.csdn.net/seu_calvin/article/details/52333954

Android的内存泄漏是Android开发领域永恒的话题，那今天就总结一下常见的内存泄漏吧。也给自己提个醒，在以后的编码过程中多注意这个问题。在Android Studio里可以通过一些分析工具比如MAT来找出潜在的内存泄漏，在Android Device Monitor中对相应进行进行Dump HPROF File，并对这个文件在SDK的platform-tools目录下进行<hprof-conv infilePath outfileName>即可在platform-tools目录下生成使用MAT工具查看的hprof文件。

还有如果不清楚Java里的OOM、以及内存泄漏和内存溢出区别的小伙伴，可以参考我之前写过的Java技术——Java中的内存泄漏。

此篇将从静态变量引用Activity、匿名类、内部类、Handler、以及监听器等方面的实例说明内存泄漏的发生原因以及解决方案。

1. 单例模式导致内存泄漏（实质是静态变量引用Activity）

如果不了解单例模式的小伙伴可以查看我之前写过的设计模式——单例模式解析。已经对单例模式分析的很清楚了。这里就不多赘述了。

单例由于其静态的特性使得其生命周期跟应用一样长，处理不当极易导致内存泄漏。

public class SingleUtils {
    private static SingleUtils mInstance = null;
    private Context context;
    private SingleUtils (Context context){
        this.context = context;
    }

    public static SingleUtils getInstance(Context context){
        if(mInstance == null){
            mInstance = new SingleUtils (context);
        }
        return mInstance;
    }

public Object getObject(){//根据业务逻辑传入参数
    //返回业务逻辑结果，这里需要用到context
    }
}

如果你看了上面链接文中介绍的单例模式，那么就很容易理解下面单例类中返回实例的代码造成了内存泄漏，我们传入了上下文context（传入上下文是为了实现单例类中的业务逻辑），这个上下文可能是Android应用中的一个Activity界面，当它finish掉的时候，这个单例类的静态对象拥有了这个Activity的引用，静态变量是驻扎在JVM的方法区，静态变量引用的对象是不会被GC回收的，因为它们所引用的对象本身就是GC ROOT。导致该Activty一直驻留在内存中，并发生内存泄漏。

解决方案：

在单例中我们尽可能的引用生命周期较长的对象，将第10行代码修改如下即可。

mInstance = new SingleUtils (context.getApplicationContext());

2. 内部类导致内存泄漏

非静态内部类会持有外部类的引用，如果我们在一个外部类中定义一个静态变量，这个静态变量是引用内部类对象，内部类能够引用外部类的成员这一优势，就是通过持有外部类的引用来实现的，但是这将会导致内存泄漏，因为这相当于间接导致静态引用外部类。

public class MyActivity extends Activity {
    //非静态内部类User创建的静态实例mUser
    private static InnerClass mInnerClass = null;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        mInnerClass = new InnerClass();
    }
     class InnerClass{
    }
}

解决方案：

（1）在onDestroy方法中调用mInnerClass的判空，若不为空，手动置为null即可。

（2）将内部类定义为静态内部类，使其不能与外部类建立关系。

3．匿名导致内存泄漏

匿名内部类同样会持有一个外部类的引用，因此如果在Activity内定义了一个匿名的AsyncTask对象。如果Activity被销毁之后AsyncTask仍然在执行，那就会组织垃圾回收器回收Activity对象，进而导致内存泄漏，直到执行结束才能回收Activity。

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    new AsyncTask<Void, Void, Void>() {
        @Override
        protected Void doInBackground(Void... params) {
            //子线程中持有Activity的引用
            //子线程在Activity销毁后依然会继续执行，导致该Activity内存泄漏
            while (true) ;
        }
    }.execute();
}

解决方案：

（1）在onDestroy中中断子线程的运行。

（2）由于线程池利于管理，可以使用全局的线程池代替在类中创建子线程。

4．Handler导致内存泄漏

定义一个匿名的Runnable对象会间接地引用定义它的Activity对象，而它会被提交到Handler的MessageQueue中，如果它在Activity销毁时还没有被处理（如下例中延迟时间执行），那就会导致内存泄漏了。

private final Handler handler = new Handler() {
    @Override
    public void handleMessage(Message msg) {

    }
};

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);

    handler.postDelayed(new Runnable() {
        @Override
        public void run() { /* ... */ }
    }, Integer.MAX_VALUE);
}

解决方案：

（1）在onDestroy中清空不必要的Message消息。

（2）可以将Handler放入到静态内部类中（静态内部类不会持有外部类的引用）。如果想要在handler内部去调用所在的外部类Activity，可以在handler内部使用弱引用的方式指向所在Activity，这样不会导致内存泄漏。

5．监听器导致内存泄漏

系统服务可以通过context.getSystemService获取，它们负责执行某些后台任务，或者为硬件访问提供接口。如果 context对象想要在服务内部的事件发生时被通知，那就需要把自己注册到服务的监听器中。然而，这会让服务持有Activity的引用，如果忘记在Activity销毁时取消注册，那就会导致Activity泄漏了。

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();
    }
});

下一篇将会从资源角度来说明内存泄漏的问题。