具有垃圾回收特性的语言(如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();
    }
});

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

---

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