什么是Context
Context是一个场景，代表与操作系统交互的一种方式，在每一次交互时都需要存在一种场景。Context在资源加载，启动Activity，获取系统服务，创建View等操作都会使用。Context是一个抽象类，他的子类有Activity、Service、Application。一个Activity可以是一个Context，一个Service也可以是一个Context。
Context源码
/**
* Interface to global information about an application environment. This is
* an abstract class whose implementation is provided by
* the Android system. It
* allows access to application-specific resources and classes, as well as
* up-calls for application-level operations such as launching activities,
* broadcasting and receiving intents, etc.
*/
public abstract class Context {
/**
* File creation mode: the default mode, where the created file can only
* be accessed by the calling application (or all applications sharing the
* same user ID).
* @see #MODE_WORLD_READABLE
* @see #MODE_WORLD_WRITEABLE
*/
public static final int MODE_PRIVATE = 0x0000;
public static final int MODE_WORLD_WRITEABLE = 0x0002;
public static final int MODE_APPEND = 0x8000;
public static final int MODE_MULTI_PROCESS = 0x0004;
.
.
.
}
它描述一个应用程序环境的信息（即上下文）；是一个抽象类，Android提供了该抽象类的具体实现类；通过它我们可以获取应用程序的资源和类（包括应用级别操作，如启动Activity，发广播，接受Intent等）。
Context继承关系
Context有两个直系继承子类，一个是ContextImpl、一个是ContextWapper。从名字上可以看出来，ContextWapper是Context的封装类，ContextImpl是Context的上下文实现类。而ContextWrapper又有三个直接的子类，ContextThemeWrapper、Service和Application。其中，ContextThemeWrapper是一个带主题的封装类，而它有一个直接子类就是Activity。而ContextImpl类则真正实现了Context中的所以函数，应用程序中所调用的各种Context类的方法，其实现均来自于该类。
ContextWrapper构造函数中必须包含一个真正的Context引用，同时ContextWrapper中提供了attachBaseContext（）用于给ContextWrapper对象中指定真正的Context对象，调用ContextWrapper的方法都会被转向其所包含的真正的Context对象。
Context数量
因为Context的子类包括：Activity、Service、Application。所以，Context 总数量为：
Context数量=Activity数量+Service数量+1
而四大组件的Broadcast Receiver，Content Provider并不是Context的子类，他们所持有的Context都是其他地方传过去的，所以并不计入Context总数。
如何获取Context
getApplicationContext()
这个函数返回的这个Application的上下文，所以是与app同步的，该context是和引用的生命周期一致的，所以和activity生命周期挂钩的任务不要使用该context，比如网络访问，防止内存泄露。
getBaseContext()
这个函数不应该被使用，用Context代替，而Context是与activity相关连，所以当activity死亡后可能会被destroyed
getApplication()
源码注释：
getApplication() is available to Activity and Services only. Although in current Android Activity and Service implementations, getApplication() and getApplicationContext() return the same object, there is no guarantee that this will always be the case (for example, in a specific vendor implementation). So if you want the Application class you registered in the Manifest, you should never call getApplicationContext() and cast it to your application, because it may not be the application instance (which you obviously experienced with the test framework).
大概的意思是：
getApplication只能被Activity和Services使用，虽然在现在的Android的实现中，getApplication和getApplicationContext返回一样的对象，但也不能保证这两个函数一样（例如在特殊的提供者来说），所以如果你想得到你在Manifest文件里面注册的App class，你不要去调用getApplicationContext，以为你可能得不到你所要的app实例。
getParent()
返回activity的上下文，如果这个子视图的话，换句话说，就是当在子视图里面调用的话就返回一个带有子视图的activity对象。
getActivity()
在fragment中使用，返回该fragment所依附的activity上下文
this
记住Activity，Service类，Application类是继承自Context类的，所以在有的时候需要上下文，只需要使用this关键字即可，但是有的时候再线程里面，this关键字的意义就改变了，但这个时候如果需要上下文，则需要使用 类名.this，这样就可以了。
Context内存泄漏问题
错误的单例模式：
public class Singleton {
private static Singleton instance;
private Context mContext;
private Singleton(Context context) {
this.mContext = context;
}
public static Singleton getInstance(Context context) {
if (instance == null) {
instance = new Singleton(context);
}
return instance;
}
}
这是一个非线程安全的单例模式，instance作为静态对象，其生命周期要长于普通的对象，其中也包含Activity，假如Activity A去getInstance获得instance对象，传入this，常驻内存的Singleton保存了你传入的Activity A对象，并一直持有，即使Activity被销毁掉，但因为它的引用还存在于一个Singleton中，就不可能被GC掉，这样就导致了内存泄漏。
View持有Activity引用：
public class MainActivity extends Activity {
private static Drawable mDrawable;
@Override
protected void onCreate(Bundle saveInstanceState) {
super.onCreate(saveInstanceState);
setContentView(R.layout.activity_main);
ImageView iv = new ImageView(this);
mDrawable = getResources().getDrawable(R.drawable.ic_launcher);
iv.setImageDrawable(mDrawable);
}
}
有一个静态的Drawable对象当ImageView设置这个Drawable时，ImageView保存了mDrawable的引用，而ImageView传入的this是MainActivity的mContext，因为被static修饰的mDrawable是常驻内存的，MainActivity是它的间接引用，MainActivity被销毁时，也不能被GC掉，所以造成内存泄漏。
Handler引发的内存泄漏：
public class SampleActivity extends Activity {
private final Handler mLeakyHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
// ...
}
}
}
这个消息持有这个Activity的Handler引用，这个Handler有隐式地持有他的外部类。直到消息被处理前，这个引用都不会被释放。因此Activity不会被垃圾回收机制回收，泄露他所持有的应用程序资源。
为了解决这个问题，Handler的子类应该定义在一个新文件中或使用静态内部类。静态内部类不会隐式持有外部类的引用。所以不会导致它的Activity泄露。如果你需要在Handle内部调用外部Activity的方法，那么让Handler持有一个Activity的弱引用（WeakReference）以便你不会意外导致context泄露。为了解决我们实例化匿名Runnable类可能导致的内存泄露，我们将用一个静态变量来引用他（因为匿名类的静态实例不会隐式持有他们外部类的引用）。
正确使用Context
一般Context造成的内存泄漏，几乎都是当Context销毁的时候，却因为被引用导致销毁失败，而Application的Context对象可以理解为随着进程存在的，所以我们总结出使用Context的正确姿势：
1：当Application的Context能搞定的情况下，并且生命周期长的对象，优先使用Application的Context。
2：不要让生命周期长于Activity的对象持有到Activity的引用。
3：尽量不要在Activity中使用非静态内部类，因为非静态内部类会隐式持有外部类实例的引用，如果使用静态内部类，将外部实例引用作为弱引用持有。