Android Context介绍

Context类型

我们知道，Android应用都是使用Java语言来编写的，那么大家可以思考一下，一个Android程序和一个Java程序，他们最大的区别在哪里？划分界限又是什么呢？其实简单点分析，Android程序不像Java程序一样，随便创建一个类，写个main()方法就能跑了，而是要有一个完整的Android工程环境，在这个环境下，我们有像Activity、Service、BroadcastReceiver等系统组件，而这些组件并不是像一个普通的Java对象new一下就能创建实例的了，而是要有它们各自的上下文环境，也就是我们这里讨论的Context。可以这样讲，Context是维持Android程序中各组件能够正常工作的一个核心功能类。

下面我们来看一下Context的继承结构：

Context的继承结构还是稍微有点复杂的，可以看到，直系子类有两个，一个是ContextWrapper，一个是ContextImpl。那么从名字上就可以看出，ContextWrapper是上下文功能的封装类，而ContextImpl则是上下文功能的实现类。而ContextWrapper又有三个直接的子类，ContextThemeWrapper、Service和Application。其中，ContextThemeWrapper是一个带主题的封装类，而它有一个直接子类就是Activity。

那么在这里我们至少看到了几个所比较熟悉的面孔，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，否则将会出错。

 

和UI相关的方法基本都不建议或者不可使用Application。实际上，只要把握住一点，凡是跟UI相关的，都应该使用Activity做为Context来处理；其他的一些操作，Service,Activity,Application等实例都可以，当然了，注意Context引用的持有，防止内存泄漏。

Context数量

那么一个应用程序中到底有多少个Context呢？其实根据上面的Context类型我们就已经可以得出答案了。Context一共有Application、Activity和Service三种类型，因此一个应用程序中Context数量的计算公式就可以这样写：

Context数量 = Activity数量 + Service数量 + 1  

上面的1代表着Application的数量，因为一个应用程序中可以有多个Activity和多个Service，但是只能有一个Application。

Android获取各种Context

1. getApplicationContext() ：

这个函数返回的这个Application的上下文，所以是与app挂钩的，所以在整个生命周期里面都是不变的，这个好理解，但是使用的时候要注意，该context是和引用的生命周期一致的，所以和activity生命周期挂钩的任务不要使用该context，比如网络访问，防止内存泄露

2. getBasecontext()：

stackoverflow上面写的是，这个函数不应该被使用，用Context代替，而Context是与activity相关连，所以当activity死亡后可能会被destroyed,我举个我自己写的例子

public Dialog displayDialog(int choice) {  
    switch(choice){  
    case 0:  
    　　AlertDialog aDialog = new AlertDialog.Builder(this)  
    　　.setIcon(R.drawable.ic_launcher)  
    　　.setTitle("Hello World")  
    　　.setPositiveButton("OK", new DialogInterface.OnClickListener() {  
   
　　　　　　@Override 
　　　　　　public void onClick(DialogInterface arg0, int arg1) {  
　　　　　　　　Toast.makeText(getBaseContext(), "OK clicked", Toast.LENGTH_SHORT).show();  
　　　　　　}  
　　　　});
　　}
}

这个例子中的getBaseContext()就不能被this代替，因为上面的this返回的是这个activity的context，而在这个onClick函数中如果使用this的话，则返回的是这个AlertDialog的context，所以要使用的是当前activity名.this 去使用，比如当前activity为 TestActivity，那么在里面就是用TestActivity.this即可.

 3. getApplication():

getApplication只能被Activity和Services使用，虽然在现在的Android的实现中，getApplication和getApplicationContext返回一样的对象，但也不能保证这两个函数一样（例如在特殊的提供者来说），所以如果你想得到你在Manifest文件里面注册的App class，你不要去调用getApplicationContext，以为你可能得不到你所要的app实例（你显然有测试框架的经验）。。。。

4. getParent() ：

返回activity的上下文，如果这个子视图的话，换句话说，就是当在子视图里面调用的话就返回一个带有子视图的activity对象，一目了然。。。

5.getActivity():

在fragment中使用，返回该fragment所依附的activity上下文

6.this

记住Activity，Service类，Application类是继承自Context类的，所以在有的时候需要上下文，只需要使用this关键字即可，但是有的时候再线程里面，this关键字的意义就改变了，但这个时候如果需要上下文，则需要使用 类名.this，这样就可以了

 

this、getContext()、getApplicationContext()、getApplication()、getBaseContext() 之间的区别

• 使用this, 说明当前类是context的子类，一般是activity application等;

        this:代表当前,在Activity当中就是代表当前的Activity，换句话说就是Activity.this在Activity当中可以缩写为this.

        Activity.this的context 返回当前activity的上下文，属于activity ，activity 摧毁他就摧毁

• 使用getApplicationContext 取得的是当前app所使用的application，这在AndroidManifest中唯一指定。意味着，在当前app的任意位置使用这个函数得到的是同一个Context;

        getApplicationContext(): 返回应用的上下文，生命周期是整个应用，应用摧毁，它才摧毁。

• 使用getContext获取的是当前对象所在的Context, Context通常翻译成上下文，我通常当成场景来理解。
• getApplication():andorid 开发中共享全局数据;
• getBaseContext() 返回由构造函数指定或setBaseContext()设置的上下文

 

我们在平时的开发中，有时候可能会需要一些全局数据，来让应用中得所有Activity和View都能访问到，大家在遇到这种情况时，可能首先会想到自己定义一个类，然后创建很多静态成员，不过andorid已经为我们提供了这种情况的解决方案：在Android中，有一个名为Application的类，我们可以在Activity中使用getApplication()，方法来获得，它是代表我们的应用程序的类，使用它可以获得当前应用的主题，资源文件中的内容等，这个类更灵活的一个特性就是可以被我们继承，来添加我们自己的全局属性。