1.Context概述
- Context是一个抽象类，其通用实现在ContextImpl类中。它的主要作用是一个访问application环境全局信息的接口，通过它可以访问application的资源和相关的类，其主要功能如下：
- 启动Activity
- 启动和停止Service
- 发送广播 消息
- 注册广播消息接受者
- 访问APK中各种资源
- 访问Package的相关信息
- APK的各种权限管理
简单的说：Context负责Activity，Service，Intent，资源，Package和权限。
2.Context家族关系
- 第一层：
一个Context抽象类， - 第二层
一个ContextImpl的实现类，里面拥有一个PackageInfo类的实例，PackageInfo类是关于整个包信息的类。
一个ContextWraper是Context的一个包装类，里面有一个ContextImpl类的实例，通过整个实例去调用ContextImpl里面的方法。 - 第三层
Service和Application直接继承ContextWrapper，但是Activity需要先引入主题，所以有了ContextThemeImpl类。
3.Context使用
-
应用程序在以下几种情况下创建Context实例：
- 创建Application 对象时， 而且整个App共一个Application对象
- 创建Service对象时
- 创建Activity对象时
所以Context个数=Activity数+Service数+1(Application)
每个Context各有不同。
4.Context内存泄露问题
- 静态资源导致的内存泄漏
有时候旋转屏幕时候，会先销毁原来的Activity，重新建立一个Activity，这时候图片我们并不想重新加载，所以将图片设置为静态对象。
但是静态对象的view.setBackgroundDrawable();方法很容易造成内存泄露。
public class MyCustomResource {
//静态变量drawable
private static Drawable drawable;
private View view；
public MyCustomResource(Context context) {
Resources resources = context.getResources();
drawable = resources.getDrawable(R.drawable.ic_launcher);
view = new View(context);
view.setBackgroundDrawable(drawable);
}
}
public void setBackgroundDrawable(Drawable background) {
..........
/**此处的this就是当前View对象，而View对象又是有Context对象获得
因此，变量background持有View对象的引用，View持有Context的引用，
所有background间接持有Context对象的引用了*/
background.setCallback(this);
.......
}
这时候想要销毁原来的Activity时，发现静态对象Drawable间接持有Context对象的引用，导致Activity的内存无法完全释放内存，这时候就造成了内存泄露。
因此，Android系统在在3.0版本之后修改了setBackgroundDrawable内部方法中的 background.setCallback(this);方法，里面的实现使用了弱引用来持有View对象的引用，从而避免了内存泄漏隐患。所以，以后代码中避免使用静态资源，或者使用弱引用来解决相应的问题也是可以的。
- 单例模式导致内存泄漏
public class CustomManager {
private static CustomManager sInstance;
public static CustomManager getInstance(Context context) {
if (sInstance == null) {
sInstance = new CustomManager(context);
}
return sInstance;
}
private Context mContext;
private CustomManager(Context context) {
mContext = context;
}
}
这样单例，有内存泄露的隐患，如果是在Activity中创建这个单例的话，传入的context为Activity的context，如果想要销毁Activity，但是单例的生命周期是整个APP，导致Activity的内存释放不完全。
所以需要修改成如下：
public class CustomManager {
private static CustomManager sInstance;
public static CustomManager getInstance(Context context) {
if (sInstance == null) {
sInstance = new CustomManager(context.getApplicationContext());
}
return sInstance;
}
private Context mContext;
private CustomManager(Context context) {
mContext = context;
}
}
将context改为整个Application的Context，这时候单例与Activity就无关了，Activity释放的时候就不会出现内存泄露的问题了。
- 总结
以后在使用Context对象获取静态资源，创建单例对象或者静态方法的时候，请多考虑Context的生命周期，一定要记得不要使用Activity的Context，切记要使用生命周期长的Application的Context对象。但是并不是所有情况使用Application的Context对象，在创建Dialog，View控件的时候都必须使用Activity的Context对象。
根据生命周期选择适合的Context类型。
