刚开始学Android的时候对Context的概念有点懵逼，很多概念不怎么懂。今天在郭神博客找到了篇文章，自己整理一遍，温故而知新。
郭神博客：http://blog.csdn.net/guolin_blog/article/details/47028975
我们知道，Android应用都是使用Java语言来编写的。
那么Android程序和Java程序最大的区别在哪里？划分界限又是什么？
简单分析：Android程序不像Java程序一样，随便创建一个类，写个main()方法就能跑了。
Android需要一个完整的工程环境，在这个环境下，我们有像Activity，Service，BroadcastReceiver等系统组件，而这些组件并不是像一个普通的Java对象new一下就能创建实例的。而是要有它们各自的上下文环境，也就是我们这里讨论的Context。
可以这么说，Context是维持Android程序中各个组件能够正常工作的一个核心功能类。
Context的集成结构：
Context的集成结构还是稍微有些复杂的，可以看到直系子类有两个，一个是ContextWrapper，一个是ContextImpl。从名字上就可以看出，ContextWrapper是上下文功能的封装类，而ContextImpl则是上下文功能的实现类。ContextWrapper又有三个直接的子类，ContextThemeWrapper，Service和Application。其中，ContextThemeWrapper是一个带主题的封装类，而它有一个直接子类就是Activity。
那么在这里我们至少看到了几个比较熟悉的面孔，Activity，Service，还有Application。由此，其实我们就可以得出结论了，Context一共有三种类型：Application，Activity和Service。这三个类虽然分别承担着不同的作用，但他们都属于Context的一种，他们具体Context的功能则是由ContextImpl类去实现的。
那么Context到底可以实现哪些功能呢？这个实在太多了，弹出Toast，启动Activity,发送广播，启动Service，操作数据库等等都需要用到Context。由于Context的具体能力是由ContextIpl类去实现的，因此在绝大多数场景下，Activity，Service和Application这三种类型的Context都是可以通用的。不过有几种场景比较特殊，比如启动Activity，还有弹出Dialog。出于安全原因的考虑，Android是不允许Activity或Dialog凭空出现的，一个Activity的启动必须要建立在另一个Activity的基础之上，也就以此形成的返回栈。而Dialog则必须在一个Activity上面弹出(除非是System Alert类型的Dialog)，因此在这种场景下，我们只能使用Activity类型的Context，否则就会报错。
Context的数量：
根据上面的Context类型我们就已经可以得到答案了。Contex一共有Application，Activity和Service三中类型，因此一个应用程序中Context数量的计算公式就可以这样写：
Context数量 = Activity数量 + Service数量 +1
Application Context的设计：
基本上每一个应用程序都会有一个自己的Application，并让他继承自系统的Application类，然后在自己的Application类中去封装一些通用的操作。然后再AndroidManifest.xml进行指定。如何获取到它的实例呢？
MyApplication myApp = (MyApplication) getApplication();
可以看到，只需调用getApplication()就能拿到我们自定义的Application的实例了。
那么除了getApplication()方法 还有一个getApplicationContext()方法，这两个方法在作用域上存在很大的区别。
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
MyApplication myApp = (MyApplication) getApplication();
Log.d("TAG", "getApplication is " + myApp);
Context appContext = getApplicationContext();
Log.d("TAG", "getApplicationContext is " + appContext);
}
}
getApplication()方法的语义性非常强，一看就知道是用来获取Application实例的，但是这个方法只能在Activity和Service中才能调用得到。那么也许在绝大多数情况下我们都是在Activity或者Service中使用Application的，但是如果在一些其他的场景，比如BroadcastReceiver中也想或Application的实例，这是就可以借助getApplicationContext()方法了.如图
public class MyReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
MyApplication myApp = (MyApplication) context.getApplicationContext();
Log.d("TAG", "myApp is " + myApp);
}
}
也就是说，getApplicationContext()方法的作用域会更广一些，任何一个Context的实例，只要调用getApplicationContext()方法都可以拿到我们的Application对象。
除了这两个方法之外，其实还有一个getBaseContext()方法，这个baseContext又是什么东西呢？我们还是通过打印的方式来验证一下：
这次得到的是不同的对象了，getBaseContext()方法得到的是一个ContextImpl对象。这个ContextImpl是不是感觉有点似曾相识？回去看一下Context的继承结构图吧，ContextImpl正是上下文功能的实现类。也就是说像Application、Activity这样的类其实并不会去具体实现Context的功能，而仅仅是做了一层接口封装而已，Context的具体功能都是由ContextImpl类去完成的。
使用Application的问题：
在构造方法中调用Context的方法就会崩溃，在onCreate()方法中调用Context的方法就一切正常，那么这两个方法之间到底发生了什么事情呢？我们重新回顾一下ContextWrapper类的源码，ContextWrapper中有一个attachBaseContext()方法，这个方法会将传入的一个Context参数赋值给mBase对象，之后mBase对象就有值了。而我们又知道，所有Context的方法都是调用这个mBase对象的同名方法，那么也就是说如果在mBase对象还没赋值的情况下就去调用Context中的任何一个方法时，就会出现空指针异常，上面的代码就是这种情况。Application中方法的执行顺序如下图所示：
