一.简介
Android应用模型是基于组件的应用设计模式，组件的运行要有一个完整的Android工程环境，在这个环境下，Activity、Service等系统组件才能够正常工作，而这些组件并不能采用普通的Java对象创建方式，new一下就能创建实例了，而是要有它们各自的上下文环境，也就是我们这里讨论的Context。可以这样讲，Context是维持Android程序中各组件能够正常工作的一个核心功能类。
源码中的注释是这么来解释Context：Context提供了关于应用环境全局信息的接口。它是一个抽象类，它的执行被Android系统所提供。它允许获取以应用为特征的资源和类型，是一个统领一些资源（应用程序环境变量等）的上下文。
就是说，它描述一个应用程序环境的信息（即上下文）；Android提供了该抽象类的具体实现类；通过它我们可以获取应用程序的资源和类(包括应用级别操作，如启动Activity，发广播，接受Intent等)。
主要作用
a.四大组件的交互，包括启动 Activity、Broadcast、Service，获取 ContentResolver 等。
b.获取系统/应用资源，包括 AssetManager、PackageManager、Resources、System Service 以及 color、string、drawable 等。
c.文件，包括获取缓存文件夹、删除文件、SharedPreference 相关等。
d.数据库（SQLite）相关，包括打开数据库、删除数据库、获取数据库路径等。
二.继承关系
既然上面Context是一个抽象类，那么肯定有对应的实现类，通过查看源码，可以看到对应的关系图：
a.ContextImpl类
ContextImpl继承Context抽象类，实现了Context类中的抽象方法，是Context的具体实现类；它为Activity和其他应用程序组件提供基本上下文对象，应用中使用 Context的时候的方法就是它实现的。
b.ContextWrapper
ContextWrapper继承Context抽象类，作为Context类的包装类，其内部维护了一个Context类型的成员变量mBase，mBase最终会指向一个ContextImpl对象，ContextWrapper的方法其内部依赖mBase，ContextWrapper是Context类的修饰类(装饰器模式)，真正的实现类是 ContextImpl，ContextWrapper 里面的方法调用也是调用 ContextImpl 里面的方法。
c.ContextThemeWrapper
ContextThemeWrapper继承ContextWrapper，因此也拥有一个Context类型的成员变量mBase，mBase最终会指向一个ContextImpl对象，它的一个直接子类就是 Activity，所以Activity也就拥有了Context提供的所有功能。
d.Context类型
通过 Context 的继承关系图可以看到，Activity、Service、Application都是Context的子类，可以认为Context一共有三种类型，分别是 Application、Activity 和Service，他们分别承担不同的作用，但是都属于 Context，而他们具有 Context 的功能则是由ContextImpl 类实现的。
1.Application：继承ContextWrapper，因此也拥有一个Context类型的成员变量mBase，mBase最终会指向一个ContextImpl对象，ContextImpl是Context的具体实现类，所以Application也就拥有了Context提供的所有功能。
2.Service：继承ContextWrapper，因此也拥有一个Context类型的成员变量mBase，mBase最终会指向一个ContextImpl对象，ContextImpl是Context的具体实现类，所以Service也就拥有了Context提供的所有功能。
3.Activity：继承ContextThemeWrapper，ContextThemeWrapper继承ContextWrapper，因此也拥有一个Context类型的成员变量mBase，mBase最终会指向一个ContextImpl对象，ContextImpl是Context的具体实现类，所以Activity也就拥有了Context提供的所有功能。
三.作用域
只有 Activity 显示界面，正因为如此，Activity 继承的是 ContextThemeWrapper 提供一些关于主题，界面显示的能力，间接继承了 ContextWrapper ；凡是跟 UI 有关的，都应该用 Activity 作为 Context 来处理，否则要么会报错，要么 UI 会使用系统默认的主题。
四.正确使用Context
一般Context造成的内存泄漏，几乎都是当Context销毁的时候，却因为被引用导致销毁失败，而Application的Context对象可以理解为随着进程存在的，所以我们总结出使用Context的正确姿势：
1：当Application的Context能搞定的情况下，并且生命周期长的对象，优先使用Application的Context。
2：不要让生命周期长于Activity的对象持有Activity的引用。
3：尽量不要在Activity中使用非静态内部类，因为非静态内部类会隐式持有外部类实例的引用，如果使用静态内部类，将外部实例引用作为弱引用持有。
五.其他
a.在自定义MyApplication的构造方法中使用Context
在自定义MyApplication的构造方法中调用Context的getPackageName()[实际是在调用mBase.getPackageName()]时，attachBaseContext(Context base) 还未被系统调用，因此mBase为Null，出现空指针。
Application方法的执行顺序：构造方法>attachBaseContext()方法>onCreate()方法。attachBaseContext(Context base) 是被系统调用的，为mBase赋值为ContextImpl类型的context。
b.一个APP应用Context数量
Context 一共有 Application 、Activity 和 Service 三种类型，因此一个应用程序中 Context 数量的计算公式就可以这样写：
Context 数量 = Activity 数量 + Service 数量 + 1
上面的1代表着 Application 的数量，因为一个应用程序中可以有多个Activity和多个Service，但是只能有一个Application。
c.ContextImpl实例什么时候生成
ContextImpl实例生成对应着mBase的赋值过程：
在启动Activity时，在ActivityThread内部通过handleLaunchActivity()方法一系列调用，在通过Instrucmentation创建完Activity后，会先调用Activity的attach()方法，会传入已创建好的ContextImpl对象，在Attach()方法内部会先调用attachBaseContext(context)方法，会将ContextImpl通过super.attachBaseContext(context)一步一步最后赋值给ContextWrapper的mBase，接下来再调用activity的onCreate()。
d.ContentProvider里的Context初始化
ContentProvider本身不是Context ，但是它有一个成员变量 mContext ，是通过构造函数传入的。mContext初始化对应着ContentProvider创建时机。
应用创建Application是通过调用 ActivityThread.handleBindApplication方法，这个方法的相关流程有：
创建 Application
初始化 Application的Context
调用installContentProviders()并传入刚创建好的context来创建ContentProvider
调用Application.onCreate()
ContentProvider的Context是在Applicaiton创建之后，但是 onCreate方法调用之前初始化的。
以上就是Context的详解及使用中常见的问题！
