[译]内存泄露的八种花样

这是好久之前发布在简书平台上的一篇有关内存泄漏的译文。
这篇文章说起的8种内存泄漏的场景，如今来看依旧很经典。为了不内存泄漏，开发过程当中须要谨慎谨慎再谨慎。同时，保持良好的开发习惯也相当重要。

具备垃圾回收特性的语言(如Java)的优势在于，它使得开发者不须要显式的对内存的分配和回收进行管理。这个特性下降引起段错误引起应用崩溃的风险，避免没有释放的内存长期占据堆内存，从而编写出更加安全的代码。惋惜这并非银弹，在Java里仍是有其余方式致使内存泄露，这意味着咱们的Android App依然存在浪费没必要要的内存，最终因为内存不足(OOM)致使Crash的可能性。原文连接

传统的内存泄露方式是：在全部相关的引用离开做用域后，没有释放以前申请的内存空间。逻辑上的内存泄露，是没有释放再也不须要的对象的引用的结果。若是一个对象的强引用依然存在，垃圾回收器就不能把这个对象从内存里回收。在Android开发里，Context上下文的泄露就一般就属于这种泄露。由于Context对象如Activity一般引用了一大堆内存，如View的层级和其余资源。若是泄露了Context对象，一般意味着它所引用的全部对象也跟着泄露。Android应用运行在内存受限的设备上，若是有多处地方泄露的话，应用很容易耗光全部的可用内存。

若是对象没有明确的生命周期，那么检测逻辑上的内存泄露更像是一个主观的问题。幸运的是，Activity拥有明肯定义的生命周期，所以咱们能明确的知道一个Activity实例是否已经泄露。Activity的onDestroy()方法在Activity的生命周期的最后被调用，意味着它在编程意图上或Android系统调度上须要进行一些内存的回收。若是这个方法调用完毕后，Activity实例依旧能从堆的根经过强引用链被访问到，垃圾回收器也就没法将它标记为可从内存回收——尽管从本来的意图是将它从内存中删除。所以，咱们能够将一个在生命周期结束后依旧存在的Activity对象标记为被泄露。

Activity是一个很重的对象，所以你不该该选择干预Android框架对它们的调度处理。然而，依旧有方法不经意的致使Activity泄露。在Android上，全部致使内存泄露的陷阱都离不开两个基础场景。第一个内存泄露的类别是进程级别的全局共享静态变量，它们的存在状态不取决于应用的状态，同时还持有指向Activity的引用链。另外一个内存泄露类别是由于线程的运行时间比Activity的生命周期还长，忽视了清除一个指向Activity的强引用链。下面咱们来看下几种可能会遇到的内存泄露的状况。

1. 静态Activity

最容易泄露Activity的方式莫过于定义一个类，类的内部经过静态变量的方式持有Activity，而后在运行中，将Activity实例赋值给这个变量。若是这个静态变量的引用在Activity的生命周期结束前没有置空的话，Activity实例就泄露了。由于被静态变量持有的对象，它将会被保持在内存中，在App的运行过程当中一直存在。若是有一个静态变量持有了Activity的引用，那么这个Activity就没法被垃圾回收器回收。完整代码

void setStaticActivity() {
  activity = this;
}

View saButton = findViewById(R.id.sa_button);
saButton.setOnClickListener(new View.OnClickListener() {
  @Override public void onClick(View v) {
    setStaticActivity();
    nextActivity();
  }
});复制代码

Activity内存泄露

2. 静态View

另外一个相似的场景：若是一个Activity须要常常被访问，那么咱们可能会选择使用单例模式，保持一个实例在内存里，以便它能够被快速的使用到。然而，若前所述，干预Activity的生命周期并将它保持在内存里是一件很危险也没有必要的事情，应该尽量的避免这么作。

但若是咱们有一个View对象，须要花费很大的代价去建立它，而它在Activity的不一样的生命周期里保持不变，那么咱们能不能把在这个实例存在静态变量里，再讲他附加到View的层级结构里去？让咱们来看下。完整代码当咱们的Activity被回收的时候，大部分的内存能够被回收。

void setStaticView() {
  view = findViewById(R.id.sv_button);
}

View svButton = findViewById(R.id.sv_button);
svButton.setOnClickListener(new View.OnClickListener() {
  @Override public void onClick(View v) {
    setStaticView();
    nextActivity();
  }
});复制代码

静态View内存泄露

等下！看到没。你知道一个attach了的view内部会持有一个指向Context的引用，换句话说，那就是咱们的Activity。经过吧一个View设为静态变量，咱们建立了一个能长期持有Activity的引用链，致使Activity被泄露了。千万不要把attach的view设为静态变量，若是实在必须这么作，至少保证在Activity的生命周期结束前把它从View的层级结构里detach)掉。

3. 内部类

除了这，让咱们在咱们的Activity类里在定义一个类，也就是内部类。为了提升代码的可读性和健壮性，封装程序逻辑，咱们可能会这么作。若是咱们建立了一个这样的内部类的实例，并经过静态变量持有了它，会怎样呢？你应该能猜到这又是一个内存泄露的点。

void createInnerClass() {
    class InnerClass {
    }
    inner = new InnerClass();
}

View icButton = findViewById(R.id.ic_button);
icButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) {
        createInnerClass();
        nextActivity();
    }
});复制代码

内部类致使的内存泄露

不幸的是，因为内部类能够直接访问到它的外部类的变量，这个特性意味着内部类会隐式的持有一个对它的外部类的引用，这间接致使了咱们不当心又泄露了Activity。

4. 匿名类

一样的，匿名类也持有一个指向它申明的地方所在的类的引用。若是你在Activity内定义和实例化一个AsyncTask匿名类，那也可能发生内存泄露

void startAsyncTask() {
    new AsyncTask<Void, Void, Void>() {
        @Override protected Void doInBackground(Void... params) {
            while(true);
        }
    }.execute();
}

super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
View aicButton = findViewById(R.id.at_button);
aicButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) {
        startAsyncTask();
        nextActivity();
    }
});复制代码

AsyncTask的内存泄露

5. Handler

一样的原则也适用于后台任务：定义一个匿名的Runnable，而后将它加入Handler的处理队列里。这个Runnable对象会隐含的持有一个指向它定义的时候所在的Activity的引用，而后它会做为一个消息对象加入到Handler的消息队列里去。在Activity生命周期结束以后，只要这个消息还没被Activity处理，那就有一条引用链指向咱们的Activity对象，使得Activity对象没法被回收，进而泄露。

void createHandler() {
    new Handler() {
        @Override public void handleMessage(Message message) {
            super.handleMessage(message);
        }
    }.postDelayed(new Runnable() {
        @Override public void run() {
            while(true);
        }
    }, Long.MAX_VALUE >> 1);
}


View hButton = findViewById(R.id.h_button);
hButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) {
        createHandler();
        nextActivity();
    }
});复制代码

Handler致使的内存泄露

6. 线程

相似的问题咱们能够在线程、定时任务(TimerTask)里发现。

void spawnThread() {
    new Thread() {
        @Override public void run() {
            while(true);
        }
    }.start();
}

View tButton = findViewById(R.id.t_button);
tButton.setOnClickListener(new View.OnClickListener() {
  @Override public void onClick(View v) {
      spawnThread();
      nextActivity();
  }
});复制代码

线程使用不当致使内存泄露

7. 定时任务

只要它们是经过匿名类的方式定义和实例化的，即使是工做在另外的线程，依旧会在Activity被destroy以后，存在一条指向Activity的引用链，致使Activity泄露。

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();
    }
});复制代码

TimerTask致使的内存泄露

8. 系统服务

最后，还有一些系统服务能够经过上下文Context对象上的getSystemService)方法获取到。这些服务运行在他们各自的进程里，协助应用执行某种类型的的后台任务，或者和设备的硬件进行交互。若是Context对象须要系统服务内的某个事件发生的时候通知到这个Context，那么它须要把自身做为一个监听器注册给系统服务。系统服务也由此持有了一个对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();
    }
});复制代码

传感器管理器致使的内存泄露

---

咱们已经见识到了一系列内存泄露，也知道他们是多么容易不当心就泄露一堆的内存。记住，尽管最坏的可能性也就是致使你的应用由于内存不足而崩溃，也不必定会一直这样。可是它会吃掉你应用内的一大部分没必要要的内存。在这个时候，你的应用将会缺乏内存来生成别的对象，进而致使垃圾回收器频繁的执行，以便释放内存给新的对象使用。垃圾回收是一个很是昂贵(耗时)的操做，还会产生用户可感知的卡顿。所以，须要对可能存在的内存泄露保持警戒，并时常对内存泄露进行测试。