1.Context概述

• Context是一个抽象类，其通用实现在ContextImpl类中。它的主要作用是一个访问application环境全局信息的接口，通过它可以访问application的资源和相关的类，其主要功能如下：
  1. 启动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类型。