具有垃圾回收特性的语言(如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();
}
});
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();
}
});
等下！看到没。你知道一个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();
}
});
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();
}
});
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();
}
});
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();
}
});
我们已经见识到了一系列内存泄露，也知道他们是多么容易不小心就泄露一堆的内存。记住，尽管最坏的可能性也就是导致你的应用因为内存不足而崩溃，也不一定会一直这样。但是它会吃掉你应用内的一大部分不必要的内存。在这个时候，你的应用将会缺少内存来生成别的对象，进而导致垃圾回收器频繁的执行，以便释放内存给新的对象使用。垃圾回收是一个非常昂贵(耗时)的操作，还会产生用户可感知的卡顿。因此，需要对可能存在的内存泄露保持警惕，并时常对内存泄露进行测试。
