0. 前言
Context相信所有的Android开发人员基本上每天都在接触，因为它太常见了。但实际上Context有太多小的细节并不被大家所关注，那么今天我们就来学习一下那些你所不知道的细节。
1. Context类继承结构
Activity、Service、BroadcastReceiver等系统组件，并不像一个普通的Java对象new一下就能创建实例了，它们要有各自的上下文环境，也就是我们这里讨论的Context。可以这样讲，Context是维持Android程序中各组件能够正常工作的一个核心功能类。
下面我们来看一下Context的继承结构：
Context的继承结构从上图一目了然。可以看到，直系子类有两个，一个是ContextWrapper（上下文功能的封装类），一个是ContextImpl（上下文功能的实现类）。而ContextWrapper又有三个直接的子类，ContextThemeWrapper（带主题的封装类）、Service和Application。其中，ContextThemeWrapper有一个直接子类就是Activity。
Context一共有三种类型，分别是Application、Activity和Service。因为一个应用程序中可以有多个Activity和多个Service，但是只能有一个Application，因此一个应用程序的Context数量 = Activity数量+ Service数量 + 1 个Application的数量。
2. Context类继承功能概述
上述Application、Activity和Service这三个类虽然分别各种承担着不同的作用，但它们都属于Context的一种，而它们具体Context的功能则是由ContextImpl类去实现的。那么Context到底可以实现哪些功能呢？这个就实在是太多了——弹出Toast、启动Activity、启动Service、发送广播、操作数据库等等都需要用到Context。
由于Context的具体能力是由ContextImpl类去实现的，因此在绝大多数场景下，Activity、Service和Application这三种类型的Context都是可以通用的。不过有几种场景比较特殊，比如启动Activity，还有弹出Dialog。出于安全原因的考虑，Android规定一个Activity的启动必须要建立在另一个Activity的基础之上，也就是以此形成的返回栈。而Dialog则必须在一个Activity上面弹出，因此在这种场景下，我们只能使用Activity类型的Context，否则将会出错。
但是在Service里就不能做Toast吗？其实也是可以的，只是需要如下权限：
<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
AlertDialog dialog = new AlertDialog.Builder(this).setTitle("标题").setMessage("内容").setPositiveButton("确定", null).create();
dialog.getWindow().setType(WindowManager.LayoutParams.TYPE_SYSTEM_ALERT);
dialog.show();
3 Application Context相关问题
基本上每一个应用程序都会有一个自己的Application，并让它继承系统的Application类，然后在自己的Application类中去封装一些通用的操作。虽然这种做法没有什么副作用，但这不是Google所推荐的一种做法，因为使用一个简单的单例类也可以实现同样的功能。这只是说明还是有不少人对于Application理解的还有些欠缺。那么这里我们先来对Application的设计进行分析，然后再看一下平时使用Application常见的问题。
3.1 Application Context的配置
首先新建一个MyApplication并让它继承自Application，然后在AndroidManifest.xml文件中对MyApplication进行配置，只有配置了才能在我们的程序启动时系统创建一个MyApplication的实例，否则默认创建一个Application的实例。
3.2 Application Context的使用
现在很多的Application都是被当作通用工具类来使用的，那么既然作为一个通用工具类，我们要怎样才能获取到它的实例呢？使用代码和输出如下所示：
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//1.使用getApplication
MyApplication myApp = (MyApplication) getApplication();
Log.d("TAG", "getApplication is " + myApp);
//2.使用getApplicationContext
Context appContext = getApplicationContext();
Log.d("TAG", "getApplicationContext is " + appContext);
//3.使用getBaseContext
Context baseContext = getBaseContext ();
Log.d("TAG", " getBaseContext is " + baseContext);
}
}
从输出结果来看，前两个方法打印出的结果是一样的，连后面的内存地址都是相同的，看来它们是同一个对象。其实这个结果也很好理解，因为前面已经说过了，Application本身就是一个Context，所以这里获取getApplicationContext()得到的结果就是MyApplication本身的实例。
这两个方法的区别在于作用域。getApplication()方法的语义性非常强，一看就知道是用来获取Application实例的，getApplication()只有在Activity和Service中才能调用的到。那么也许在绝大多数情况下我们都是在Activity或者Service中使用Application的，但是如果在一些其它的场景，比如BroadcastReceiver中也想获得Application的实例，这时就可以借助getApplicationContext()方法了。
最后的getBaseContext得到的是一个ContextImpl对象。ContextImpl正是上下文功能的实现类，Context的具体功能都是由ContextImpl类去完成的。那么这样的设计到底是怎么实现的呢？因为Application、Activity、Service都是直接或间接继承自ContextWrapper的，我们就直接看ContextWrapper的源码，如下所示：
/**
* Proxying implementation of Context that simply delegates all of its calls to
* another Context. Can be subclassed to modify behavior without changing
* the original Context.
*/
public class ContextWrapper extends Context {
Context mBase; /**
* Set the base context for this ContextWrapper. All calls will then be
* delegated to the base context. Throws
* IllegalStateException if a base context has already been set.
*
* @param base The new base context for this wrapper.
*/
protected void attachBaseContext(Context base) {
if (mBase != null) {
throw new IllegalStateException("Base context already set");
}
mBase = base;
} /**
* @return the base context as set by the constructor or setBaseContext
*/
public Context getBaseContext() {
return mBase;
} @Override
public AssetManager getAssets() {
return mBase.getAssets();
} @Override
public Resources getResources() {
return mBase.getResources();
} @Override
public ContentResolver getContentResolver() {
return mBase.getContentResolver();
} @Override
public Looper getMainLooper() {
return mBase.getMainLooper();
} @Override
public Context getApplicationContext() {
return mBase.getApplicationContext();
} @Override
public String getPackageName() {
return mBase.getPackageName();
} @Override
public void startActivity(Intent intent) {
mBase.startActivity(intent);
} @Override
public void sendBroadcast(Intent intent) {
mBase.sendBroadcast(intent);
} @Override
public Intent registerReceiver(
BroadcastReceiver receiver, IntentFilter filter) {
return mBase.registerReceiver(receiver, filter);
} @Override
public void unregisterReceiver(BroadcastReceiver receiver) {
mBase.unregisterReceiver(receiver);
} @Override
public ComponentName startService(Intent service) {
return mBase.startService(service);
} @Override
public boolean stopService(Intent name) {
return mBase.stopService(name);
} @Override
public boolean bindService(Intent service, ServiceConnection conn,
int flags) {
return mBase.bindService(service, conn, flags);
} @Override
public void unbindService(ServiceConnection conn) {
mBase.unbindService(conn);
} @Override
public Object getSystemService(String name) {
return mBase.getSystemService(name);
} ......
}
从上述源码可以看出ContextWrapper中的方法的实现都调用了mBase对象中对应的方法。第16行的attachBaseContext()方法其实是由系统来调用的，它会把ContextImpl对象作为参数传递到attachBaseContext()方法当中，从而赋值给mBase对象，之后ContextWrapper中的所有方法其实都是通过这种委托的机制交由ContextImpl去具体实现的，所以说ContextImpl是上下文功能的实现类是非常准确的。
那么另外再看一下我们刚刚打印的getBaseContext()方法，在第26行。这个方法只有一行代码，就是返回了mBase对象而已，而mBase对象其实就是ContextImpl对象，因此刚才的打印结果也得到了印证。
4. Application Context中的空指针问题
先看下面两个例子：
//第一种使用方式
public class MyApplication extends Application {
public MyApplication() {
String packageName = getPackageName();
Log.d("TAG", "package name is " + packageName);
}
}
//第二种使用方式
public class MyApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
String packageName = getPackageName();
Log.d("TAG", "package name is " + packageName);
}
}
结果标明，第一种使用方式有空指针错误，第二种则运行正常。即在构造方法中调用Context的方法就会崩溃，在onCreate()方法中调用Context的方法就一切正常。这是为什么呢？我们重新回顾一下ContextWrapper类的源码，ContextWrapper中有一个attachBaseContext()方法，这个方法会将传入的一个Context参数赋值给mBase对象，之后mBase对象就有值了。而我们又知道，所有Context的方法都是调用这个mBase对象的同名方法，那么也就是说如果在mBase对象还没赋值的情况下就去调用Context中的任何一个方法时，就会出现空指针异常。Application中方法的执行顺序如下图所示：
Application中在onCreate()方法里去初始化各种全局的变量数据是一种比较推荐的做法，但是如果你想把初始化的时间点提前到极致，也可以去重写attachBaseContext()方法，如下所示：
public class MyApplication extends Application {
@Override
protected void attachBaseContext(Context base) {
// 在这里调用Context的方法会空指针错误
super.attachBaseContext(base);
// 在这里可以正常调用Context的方法
}
}
5. Application Context和单例模式
上文中已经提到过了，Google不推荐我们使用自定义的Application，基本上只有需要做一些全局初始化的时候才可能需要用到自定义Application。但多数项目只是把自定义Application当成了一个通用工具类，虽然没什么副作用但使用单例模式实现可能更加优雅。
但是把自定义Application和单例模式混合到一起使用，那就大错特错了。一个非常典型的例子如下所示：
public class MyApplication extends Application {
private static MyApplication app;
public static MyApplication getInstance() {
if (app == null) {
app = new MyApplication();
}
return app;
}
}
因为我们知道Application是属于系统组件，系统组件的实例是要由系统来去创建的，如果这里我们自己去new一个MyApplication的实例，它就只是一个普通的Java对象而已，而不具备任何Context的能力。我们只需谨记一点，Application全局只有一个，它本身就已经是单例了，无需再用单例模式去为它做多重实例保护了，正确代码如下所示：
public class MyApplication extends Application {
private static MyApplication app;
// getInstance()方法里面不需要任何逻辑判断，直接返回app对象就可以了
public static MyApplication getInstance() {
return app;
}
@Override
public void onCreate() {
super.onCreate();
//this就是当前Application的实例，那么app也就是当前Application的实例了
app = this;
}
}
本文转载整理自郭大侠博客。最后请大家多点下面的赞支持~