一、源码角度解析Context
从系统的角度来理解：Context是一个场景，代表与操作系统的交互的一种过程。
Context是一个抽象类；
Activity、Service、Application是它的子类；
二、Context 应用场景
数字1：启动Activity在这些类中是可以的，但是需要创建一个新的task。一般情况不推荐。
数字2：在这些类中去layout inflate是合法的，但是会使用系统默认的主题样式，如果你自定义了某些样式可能不会被使用。
数字3：在receiver为null时允许，在4.2或以上的版本中，用于获取黏性广播的当前值。（可以无视）
注：ContentProvider、BroadcastReceiver之所以在上述表格中，是因为在其内部方法中都有一个context用于使用。
默认的Toast实际上使用ApplicationContext也可以，因为总有时候在异步线程中做了一些土司操作，这种情况下在Activity关闭时候，很容易造成context为空的情况，所以所有的土司都采用ApplicationContext。
四、Fragment 中 Context 的获取
在Fragment的生命周期中，在生命周期处于onAttach()和onDetach()之间的时候getActivity()方法才不会返回null。因此我们可以在fragment初始化的时候建立Context引用。在fragment销毁的时候销毁引用。代码如下：
private Context mContext;
Override
public void onAttach(Context context) {
super.onAttach(context);
mContext = context;//mContext 是成员变量，上下文引用
}
Override
public void onDetach() {
super.onDetach();
mContext = null;
}
注意：Activity 中有的onAttach有两个方法
void onAttach(Activity activity);
void onAttach(Context context);
五、Context 引发的内存泄露解决
- 不要让生命周期长于Activity的对象持有到Activity的引用
- 尽量使用Application的Context而不是Activity的Context。
- 尽量不要在Activity中使用非静态内部类，因为非静态内部类会隐式持有外部类实例的引用（具体可以查看细话Java：”失效”的private修饰符了解）。如果使用静态内部类，将外部实例引用作为弱引用持有。
解决的方法就是不持有Activity的引用，而是持有Application的Context引用。获取方式查看ContextHolder方式。下面会介绍。
- 单例模式用application的context。
如果我们在Activity A中或者其他地方使用Foo.getInstance()时，我们总是会顺手写一个『this』或者『mContext』（这个变量也是指向this）。 试想一下，当前我们所用的Foo是单例，意味着被初始化后会一直存在与内存中，以方便我们以后调用的时候不会在此次创建Foo对象。但Foo中的 『mContext』变量一直都会持有Activity A中的『Context』，导致Activity A即使执行了onDestroy方法，也不能够将自己销毁。但『applicationContext』就不同了，它一直伴随着我们应用存在（中途也可能 会被销毁，但也会自动reCreate），所以就不用担心Foo中的『mContext』会持有某Activity的引用，让其无法销毁。
实际上，只要把握住一点，凡是跟UI相关的，都应该使用 Activity做为Context来处理(吐司除外)；其他的一些操作，Service,Activity,Application等实例都可以，当然了，注意 Context引用的持有，防止内存泄漏。
六、获取Context的四种方式方式
-
View.getContext,返回当前View对象的Context对象，通常是当前正在展示的Activity对象。 -
Activity.getApplicationContext,获取当前Activity所在的(应用)进程的Context对象，通常我们使用Context对象时，要优先考虑这个全局的进程Context。 -
ContextWrapper.getBaseContext():用来获取一个ContextWrapper进行装饰之前的Context，可以使用这个方法，这个方法在实际开发中使用并不多，也不建议使用。 - Activity.this 返回当前的Activity实例，如果是UI控件需要使用Activity作为Context对象，但是默认的Toast实际上使用ApplicationContext也可以。
七、第三方库通用的获取Context方式
首先我们构造一个存储Context的类ContextHolder，在Application初始化时将Application传入ContextHolder，这个方法在很多第三方库都能见到类似的处理。
public class ContextHolder {
static Context ApplicationContext;
public static void initial(Context context) {
ApplicationContext = context;
}
public static Context getContext() {
return ApplicationContext;
}
}
public class App extends Application {
@Override
public void onCreate() {
super.onCreate();
ContextHolder.initial(this);
}
}
这样我们就能在任意位置调用ContextHolder.getContext()来获取应用Context。
那么有没有可能不需要任何初始化操作就能完成这个需求呢？笔者做了一些尝试。
由于实际上获取应用Context也就是获取当前应用实例，经笔者研究下面2种方法都可以通过反射直接获取当前应用。
try {
Application application = (Application) Class.forName("android.app.ActivityThread").getMethod("currentApplication").invoke(null, (Object[]) null);
} catch (Exception e) {
e.printStackTrace();
}
try {
Application application = (Application) Class.forName("android.app.AppGlobals").getMethod("getInitialApplication").invoke(null, (Object[]) null);
} catch (Exception e) {
e.printStackTrace();
}
经测试，即使应用处于后台仍能正确获取到调用此方法的Application。
参考：
http://blog.csdn.net/lmj623565791/article/details/40481055
http://www.jianshu.com/p/9d75e328f1de
http://www.jianshu.com/p/808b9d92d6cd
http://blog.nimbledroid.com/2016/05/23/memory-leaks-zh.html
