避免Android中Context引起的内存泄露

参考：http://droidyue.com/blog/2015/04/12/avoid-memory-leaks-on-context-in-android/

什么是 Context？

简单的解释下：

（1）应用所处环境中所有信息的接口
（2）Context 只是一个抽象类，它的具体实现是由 Android 系统中的实现类提供的
（3）允许访问系统资源或类，也可以进行应用层的一些操作，例如：启动 Activity、发送广播，接收 Intent等等……

Context 能干什么？

回顾我们使用 Context 的场景来帮助理解吧：

我们在使用自定义 View 时，使用 BaseAdapter 时，甚至是访问数据库文件时，都需要传入一个 Context参数，大家有没有想过这到底是为什么呢？因为我们初始化自定义 View 需要将 View 与某个页面布局关联，因为我们使用BaseAdapter 时需要某个布局文件作为子 Item，因为我们需要访问应用的数据库文件。此时 Context就像一个系统信息管理员，你告诉它我想要访问系统的布局资源文件，想要访问应用的数据库文件，它就去给你找，然后提供引用给你使用。

所以大家现在应该能理解了吧，Context就是用于获得系统资源的，我们所说的系统资源包括设备本身的信息，也有我们开发者提供的信息（类、包、资源文件等等……）。

Application 类和 Activity、Service 两大 Android 组件都是 Context的具体实现类，而这三个类确实能访问各自职责内的系统资源，例如 Activity 能访问与界面元素相关的资源、Service能访问系统服务、Application 能访问应用包名等信息。

知识点：应用中 Context 的数量 = Activity 的数量 + Service 的数量 + 1（Application的数量）

使用 Context 你不知道的事？

前面已经提到，Context 的实现类能够持有各种各样的系统信息，可能有人会想到：使用 Context不会导致内存泄漏吗？我在这里给大家答案：会！而且我们在开发中经常无意地导致了内存泄漏。有人可能就不服了，我写的代码怎么可能有内存泄漏的问题！

别急，我下面给大家看一段最普通的代码：

例如我们要实现一个 ListView 展示信息的功能，为了自定义子 Item，我们需要传入 Context来读取布局资源：
public class MyBaseAdapter extends BaseAdapter{
private Context mContext;

public MyBaseAdapter(Context context) {
mContext = context;
}

省略……
}

设计完 BaseAdapter 以后，我们肯定要在 MainActivity 里面使用它了：
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);

adapter = new MyBaseAdapter(this);

……省略
}

一般大家都会写下这样的代码对吧？这样写都不会出现 Bug对吧？老板还夸你工作效率高对吧？事实上这样的代码会导致内存泄漏哦～为什么呢？大家不妨回顾我在在Activity中使用Thread导致的内存泄漏里提到的内存泄漏原因，博文中说道：只要类持有对外部类实例对象的引用，垃圾回收机制就不会回收该对象。

在这段代码中，我们将 Activity 的引用传入 MyBaseAdapter，使得 MyBaseAdapter 持有对Activity 的引用，那么相应地，我们也将持有 Activity所获得的资源文件的引用。所以这些资源文件将无法被垃圾回收机制回收，造成内存泄漏的问题。

那么有什么解决办法呢？

我们只需要修改一句代码：
mContext = context.getApplicationContext();
或者
adapter = new MyBaseAdapter(this.getApplication());
就可以避免内存泄漏的问题。大家需要记住的是，在这里我们只是演示了一种最常见，最基础的 Context导致的内存泄漏问题，在实际的开发需求中肯定还有更加复杂的情况，大家应该更多地去思考背后的原因，从根源上解决这些内存泄漏的问题。

常见Context内存泄漏情况

这是一个很隐晦的OutOfMemoryError的情况。先看一个Android官网提供的例子：
Java代码
private static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);

TextView label = new TextView(this);
label.setText("Leaks are bad");

if (sBackground == null) {
sBackground = getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);

setContentView(label);
}

这段代码效率很快，但同时又是极其错误的；
在第一次屏幕方向切换时它泄露了一开始创建的Activity。当一个Drawable附加到一个 View上时，
View会将其作为一个callback设定到Drawable上。上述的代码片段，意味着Drawable拥有一个TextView的引用，
而TextView又拥有Activity（Context类型）的引用，换句话说，Drawable拥有了更多的对象引用。即使Activity被销毁，内存仍然不会被释放。
另外，对Context的引用超过它本身的生命周期，也会导致Context泄漏。所以尽量使用Application这种Context类型。
这种Context拥有和应用程序一样长的生命周期，并且不依赖Activity的生命周期。如果你打算保存一个长时间的对象，
并且其需要一个Context，记得使用Application对象。你可以通过调用Context.getApplicationContext()或Activity.getApplication()轻松得到Application对象。
最近遇到一种情况引起了Context泄漏，就是在Activity销毁时，里面有其他线程没有停。
总结一下避免Context泄漏应该注意的问题：
1.使用Application这种Context类型。
2.注意对Context的引用不要超过它本身的生命周期。
3.慎重的使用“static”关键字。
4.Context里如果有线程，一定要在onDestroy()里及时停掉。