深刻理解Android中的context
咱们知道，Android应用都是使用Java语言来编写的，那么你们能够思考一下，一个Android程序和一个Java程序，他们最大的区别在哪里？其实简单点分析，Android程序不像Java程序同样，随便建立一个类，写个main()方法就能跑了，而是要有一个完整的Android工程环境，在这个环境下，咱们有像Activity、Service、BroadcastReceiver等系统组件，而这些组件并非像一个普通的Java对象new一下就能建立实例的了，而是要有它们各自的上下文环境，也就是咱们这里讨论的Context。能够这样讲，Context是维持Android程序中各组件可以正常工做的一个核心功能类。java
一. Context的继承结构
Context自己是一个纯的abstract类 , 它的直系子类有两个：一个是ContextWrapper，一个是ContextImpl。那么从名字上就能够看出，ContextWrapper是上下文功能的封装类， 它的内部包含了一个 Context对象，而ContextImpl则是上下文功能的实现类。而ContextWrapper又有三个直接的子类，ContextThemeWrapper、Service和Application。其中，ContextThemeWrapper是一个带主题的封装类，而它有一个直接子类就是Activity。android
那么在这里咱们至少看到了几个所比较熟悉的面孔，Activity、Service、还有Application。由此，其实咱们就已经能够得出结论了，Context一共有三种类型，分别是Application、Activity和Service。这三个类虽然分别各类承担着不一样的做用，但它们都属于Context的一种，而它们具体Context的功能则是由ContextImpl类去实现的。数据库
那么Context到底能够实现哪些功能呢？这个就实在是太多了，弹出Toast、启动Activity、启动Service、发送广播、操做数据库等等都须要用到Context。因为Context的具体能力是由ContextImpl类去实现的，所以在绝大多数场景下，Activity、Service和Application这三种类型的Context都是能够通用的。不过有几种场景比较特殊，好比启动Activity，还有弹出Dialog。出于安全缘由的考虑，Android是不容许Activity或Dialog凭空出现的，一个Activity的启动必需要创建在另外一个Activity的基础之上，也就是以此造成的返回栈。而Dialog则必须在一个Activity上面弹出（除非是System Alert类型的Dialog），所以在这种场景下，咱们只能使用Activity类型的Context，不然将会出错。安全
二. 相关类介绍
名称：Context app
路径： /frameworks/base/core/java/android/content/Context.javaide
说明： 抽象类，提供了一组通用的API。函数
public abstract class Context {
...
public abstract Object getSystemService(String name); //得到系统级服务
public abstract void startActivity(Intent intent); //经过一个Intent启动Activity
public abstract ComponentName startService(Intent service); //启动Service
//根据文件名获得SharedPreferences对象
public abstract SharedPreferences getSharedPreferences(String name,int mode);
...
}
名称：ContextIml工具
路径 ：/frameworks/base/core/java/android/app/ContextImpl.javathis
说明：该Context类的实现类为ContextIml，该类实现了Context类的功能。请注意，该函数的大部分功能都是直接调用spa
/**
* Common implementation of Context API, which provides the base
* context object for Activity and other application components.
*/
class ContextImpl extends Context{
//全部Application程序公用一个mPackageInfo对象
/*package*/ ActivityThread.PackageInfo mPackageInfo;
@Override
public Object getSystemService(String name){
...
else if (ACTIVITY_SERVICE.equals(name)) {
return getActivityManager();
}
else if (INPUT_METHOD_SERVICE.equals(name)) {
return InputMethodManager.getInstance(this);
}
}
@Override
public void startActivity(Intent intent) {
...
//开始启动一个Activity
mMainThread.getInstrumentation().execStartActivity(
getOuterContext(), mMainThread.getApplicationThread(), null, null, intent, -1);
}
}
名称：ContextWrapper
路径 ：\frameworks\base\core\java\android\content\ContextWrapper.java
说明： 正如其名称同样，该类只是对Context类的一种包装，该类的构造函数包含了一个真正的Context引用，即ContextIml
public class ContextWrapper extends Context {
Context mBase; //该属性指向一个ContextIml实例，通常在建立Application、Service、Activity时赋值
//建立Application、Service、Activity，会调用该方法给mBase属性赋值
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 void startActivity(Intent intent) {
mBase.startActivity(intent); //调用mBase实例方法
}
}
名称：ContextThemeWrapper
路径：/frameworks/base/core/java/android/view/ContextThemeWrapper.java
说明：该类内部包含了主题(Theme)相关的接口，即android:theme属性指定的。只有Activity须要主题，Service不须要主题，因此Service直接继承于ContextWrapper类。
public class ContextThemeWrapper extends ContextWrapper {
//该属性指向一个ContextIml实例，通常在建立Application、Service、Activity时赋值
private Context mBase;
//mBase赋值方式一样有一下两种
public ContextThemeWrapper(Context base, int themeres) {
super(base);
mBase = base;
mThemeResource = themeres;
}
@Override
protected void attachBaseContext(Context newBase) {
super.attachBaseContext(newBase);
mBase = newBase;
}
}
总结：context是一个抽象类，ContextWrapper是对Context的封装，它包含一个Context类型的变 量,ContextWrapper的功能函数内部其实都是调用里面的Context类型变量完成的。 Application,Service,Activity等都是直接或者间接继承自ContextWrapper,可是并无真正的实现其中的功 能，Application，Service，Activity中关于Context的功能都是经过其内部的Context类型变量完成的，而这个变量的 真实对象一定是ContextImpl，因此没建立一个Application,Activity,Servcice便会建立一个 ContextImpl,而且这些ContextImpl中的mPackages和mResources变量都是同样的，因此无论使用Acitivty还 是Service调用getResources获得相同的结果
三. Context的数量
那么一个应用程序中到底有多少个Context呢？其实根据上面的Context类型咱们就已经能够得出答案了。Context一共有Application、Activity和Service三种类型，所以一个应用程序中Context数量的计算公式就能够这样写：
Context数量 = Activity数量 + Service数量 + 1
上面的1表明着Application的数量，由于一个应用程序中能够有多个Activity和多个Service，可是只能有一个Application。
四. Application context的设计
1. 获取Application context的不一样方法间的区别
首先新建一个MyApplication并让它继承自Application，而后在AndroidManifest.xml文件中对MyApplication进行指定，以下所示：
<application
android:name=".MyApplication"
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
......
</applicatio
指定完成后，当咱们的程序启动时Android系统就会建立一个MyApplication的实例，若是这里不指定的话就会默认建立一个Application的实例。
前面提到过，如今不少的Application都是被看成通用工具类来使用的，那么既然做为一个通用工具类，咱们要怎样才能获取到它的实例呢？以下所示：
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);
}
}
运行结果：
除了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);
}
}
运行结果：
咦？好像打印出的结果是同样的呀，连后面的内存地址都是相同的，看来它们是同一个对象。其实这个结果也很好理解，由于前面已经说过了，Application自己就是一个Context，因此这里获取getApplicationContext()获得的结果就是MyApplication自己的实例。
那么有的朋友可能就会问了，既然这两个方法获得的结果都是相同的，那么Android为何要提供两个功能重复的方法呢？实际上这两个方法在做用域上有比较大的区别。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对象。 回顾ContextWrapper源码，在attachBaseContext()方法中，这个方法中传入了一个base参数，并把这个参数赋值给了mBase对象。而attachBaseContext()方法实际上是由系统来调用的，它会把ContextImpl对象做为参数传递到attachBaseContext()方法当中，从而赋值给mBase对象。另外再看getBaseContext()方法，该方法只是了mBase对象而已，而mBase对象其实就是ContextImpl对象，所以刚才的打印结果也获得了印证。
2. Application容易发生的问题
- 状况一：context赋值前调用context方法
Application是Context的其中一种类型，那么是否就意味着，只要是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的方法
}
}
- 状况二：错误使用单例模式
有一些项目，会把自定义Application和单例模式混合到一块儿使用，一个很是典型的例子以下所示：
public class MyApplication extends Application {
private static MyApplication app;
public static MyApplication getInstance() {
if (app == null) {
app = new MyApplication();
}
return app;
}
}
就像单例模式同样，这里提供了一个getInstance()方法，用于获取MyApplication的实例，有了这个实例以后，就能够调用MyApplication中的各类工具方法了。
可是这种写法对吗？大错特错！由于咱们知道Application是属于系统组件，系统组件的实例是要由系统来去建立的，若是这里咱们本身去new一个MyApplication的实例，它就只是一个普通的Java对象而已，而不具有任何Context的能力。
那么若是真的想要提供一个获取MyApplication实例的方法，比较标准的写法又是什么样的呢？其实这里咱们只需谨记一点，Application全局只有一个，它自己就已是单例了，无需再用单例模式去为它作多重实例保护了，代码以下所示：
public class MyApplication extends Application {
private static MyApplication application;
public static MyApplication getInstance() {
return application;
}
@Override
public void onCreate() {
super.onCreate();
application = this;
}
}
getInstance()直接返回application对象就能够了，由于在启动应用Application生命周期执行到onCreate()方法时咱们将application对象赋值成this，this就是当前Application的实例。
- 1. 深刻理解 Android 中的各类 Context
- 2. Android深刻理解Context（二）Activity和Service的Context建立过程
- 3. Golang Context深刻理解
- 4. 深刻理解Go Context
- 5. 深刻理解Golang之context
- 6. 深刻理解Android中ClassLoader
- 7. 【Android】深刻理解 Android 中的Matrix
- 8. Android深刻理解Context（一）Context关联类和Application Context建立过程
- 9. 深刻理解Javascript之Execution Context
- 10. 深刻 Flask 源码理解 Context
- 更多相关文章...
- • Spring中Bean的作用域 - Spring教程
- • 现实生活中的 XML - XML 教程
- • Scala 中文乱码解决
- • C# 中 foreach 遍历的用法
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 深刻理解 Android 中的各类 Context
- 2. Android深刻理解Context（二）Activity和Service的Context建立过程
- 3. Golang Context深刻理解
- 4. 深刻理解Go Context
- 5. 深刻理解Golang之context
- 6. 深刻理解Android中ClassLoader
- 7. 【Android】深刻理解 Android 中的Matrix
- 8. Android深刻理解Context（一）Context关联类和Application Context建立过程
- 9. 深刻理解Javascript之Execution Context
- 10. 深刻 Flask 源码理解 Context