Activity是从Context类中派生而来的
Context，中文直译为“上下文”
- 它描述的是一个应用程序环境的信息，即上下文
- 该类是一个抽象(abstract class)类，Android提供了该抽象类的具体实现类（后面我们会讲到是ContextIml类）
- 通过它我们可以获取应用程序的资源和类，也包括一些应用级别操作，例如：启动一个Activity，发送广播，接收Intent信息等
应用程序创建Context实例的情况有如下几种情况：
- 创建Application对象时，而且整个App共一个Application对象
- 创建Service对象时
- 创建Activity对象时
因此应用程序App共有的Context数目公式为：
总Context实例个数=Service个数+Activity个数+1(Application对应的Context实例)
Activity.this获取的是这个Activity的Context，this.getApplicationContext()获取的是整个应用程序的Context，这两者的生命周期是不同的。
AlertDialog.Builder builder = new AlertDialog.Builder(this);
AlertDialog对象是依赖于一个View的，而View是和一个Activity对应的。
this:代表当前，在Activity当中就是代表当前的Activity，换句话说就是Activity.this在Activity当中可以缩写为this.
getApplicationContext()：生命周期是整个应用，应用摧毁，它才摧毁。
getApplication()：android开发中共享全局数据。
Context类型
Application － 是一个运行在你的应用进程中的单例。在Activity或者Service中，它可以通过getApplication()函数获得，或者人和继承于context的对象中，通过getApplicationContext()方法获得。不管你是通过何种方法在哪里获得的，在一个进程内，你总是获得到同一个实例。
Activity/Service － 继承于ContextWrapper，它实现了与context同样API，但是代理这些方法调用到内部隐藏的Context实例，即我们所知道的基础context。任何时候当系统创建一个新的Activity或者Service实例的时候，它也创建一个新的ContextImpl实例来做所有的繁重的工作。每一个Activity和Service以及其对应的基础context，对每个实例来说都是唯一的。
BroadcastReciver － 它本身不是context，也没有context在它里面，但是每当一个新的广播到达的时候，框架都传递一个context对象到onReceive()。这个context是一个ReceiverRestrictedContext实例，它有两个主要函数被禁掉：registerReceiver()和bindService()。这两个函数在BroadcastReceiver.onReceive()不允许调用。每次Receiver处理一个广播，传递进来的context都是一个新的实例。
ContentProvider － 它本身也不是一个Context，但是它可以通过getContext()函数给你一个Context对象。如果ContentProvider是在调用者的的本地（例如，在同一个应用进程），getContext()将返回的是Application单例。然而，如果调用这和ContentProvider在不同的进程的时候，它将返回一个新创建的实例代表这个Provider所运行的包。
保存引用
第一个我们需要解决问题是，在一个对象或者类内部保存一个context引用，而它生命周期却超过其保存引用的对象的生命周期。例如，创建一个自定义的单例，它需要一个context来加载资源或者获取ContentProvider，从而保存一个指向当前Activiy或者Service的引用在单例中。
View与Context(或Activity)的关系类似于明星与经纪人的关系，所以创建View时，必须明确指定其Context(即经纪人或大管家)，否则View就成不了明星。
参考
