Android中Activity、Service和Application的Context分析

一、什么是Context

Context是android开发者不可逃避的话题，几乎在android开发过程中无处不在。我们先罗列一下Context的使用场景：

1. 开启Activity【startActivity()】
2. 开启服务【startService】
3. 获取Assets[getAsserts()]
4. 获取资源 [getResources()]
5. 自定义View
6. 动态注册广播
7. …….

Context是什么？

• 1、它描述的是一个应用程序环境的信息，即上下文对象。
• 2、该类是一个抽象(abstract class)类，Android提供了该抽象类的具体实现类（ContextIml类)。
• 3、通过它我们可以获取应用程序的资源和类，也包括一些应用级别操作，

二、Context，Activity，Service,Application之间的继承关系

分析：
1.Context是一个抽象类，具体由ContextImpl实现；
2.Activity，Service，Application都间接继承Context；
3.从继承关系来看，Application和Service的继承关系更为相似，Activity还多了一层继承ContextThemeWrapper，这是因为Activity有主题的概念，而Service是没有界面的服务，Application更是一个抽象的东西，它也是通过Activity类呈现的。

---

3.Context类

路径：/frameworks/base/core/java/android/content/Context.java
说明：抽象类，提供了一组通用的API。
Context类本身是一个纯abstract类，为了使用方便，定义了ContextWrapper类，这只是一个包装而已。
一个应用包含的Context个数：Service个数+Activity个数+1(Application类本身对应一个Context对象)。
应用程序中包含多个ContextImpl对象，而其内部变量mPackageInfo指向同一个PackageInfo对象。

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 
     public abstract SharedPreferences getSharedPreferences(String name,int mode); 
     public abstract ContentResolver getContentResolver(); //获取内容解析器
     public abstract PackageManager getPackageManager(); //获取包管理器
     public abstract Context getApplicationContext(); //获取应用的上下文
     public abstract AssetManager getAssets(); //获取Assets
     public abstract Resources getResources(); //获取资源
     public abstract String getPackageName(); //获取包名
     public abstract File getFilesDir();  //获取路径

4.ContextImpl类

路径：/frameworks/base/core/java/android/app/ContextImpl.java
说明：该Context类的实现类为ContextImpl类，该类实现了Context类的功能。

/**
 * 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); 
    } 
} 

5. ContextThemeWrapper类

路径：/frameworks/base/core/java/android/view/ContextThemeWrapper.java
说明：该类内部包含了主题(Theme)相关的接口，即android:theme属性指定的。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;   
         }   
    }   

6.Android四大组件和Context

并不是所有的context实例都是等价的。根据Android应用的组件不同，你访问的context推向有些细微的差别。

Application － 是一个运行在你的应用进程中的单例。在Activity或者Service中，它可以通过getApplication()函数获得，或者在任何继承于context的对象中，通过getApplicationContext()方法获得。不管你是通过何种方法在哪里获得的，在一个进程内，你总是获得到同一个实例。

Activity/Service － 继承于ContextWrapper，它实现了与context同样API，但是代理这些方法调用到内部隐藏的Context实例，即我们所知道的基础context。任何时候当系统创建一个新的Activity或者Service实例的时候，它也创建一个新的ContextImpl实例来做所有的繁重的工作。每一个Activity和Service以及其对应的基础context，对每个实例来说都是唯一的。
ContentProvider － 它本身也不是一个Context，但是它可以通过getContext()函数给你一个Context对象。如果ContentProvider是在调用者的的本地（例如，在同一个应用进程），getContext()将返回的是Application单例。然而，如果调用者和ContentProvider在不同的进程的时候，它将返回一个新创建的实例代表这个Provider所运行的包。

BroadcastReciver － 它本身不是context，也没有context在它里面，但是每当一个新的广播到达的时候，框架都传递一个context对象到onReceive()。这个context是一个ReceiverRestrictedContext实例，它有两个主要函数被禁掉：registerReceiver()和bindService()。这两个函数在BroadcastReceiver.onReceive()不允许调用。每次Receiver处理一个广播，传递进来的context都是一个新的实例。

Context能做的操作是由这个context来源于哪里决定的。下表所列的是，在应用中常见的会收到context对象的，以及对应的每种情况，它可以用于哪些地方：

大家注意看到有一些NO上添加了一些数字，其实这些从能力上来说是YES，但是为什么说是NO呢？下面一个一个解释：
数字1：启动Activity在这些类中是可以的，但是需要创建一个新的task。一般情况不推荐。
数字2：在这些类中去layout inflate是合法的，但是会使用系统默认的主题样式，如果你自定义了某些样式可能不会被使用。
数字3：在receiver为null时允许，在4.2或以上的版本中，用于获取黏性广播的当前值。（可以无视）
注：ContentProvider、BroadcastReceiver之所以在上述表格中，是因为在其内部方法中都有一个context用于使用。

好了，这里我们看下表格，重点看Activity和Application，可以看到，和UI相关的方法基本都不建议或者不可使用Application，并且，前三个操作基本不可能在Application中出现。实际上，只要把握住一点，凡是跟UI相关的，都应该使用Activity做为Context来处理；其他的一些操作，Service,Activity,Application等实例都可以，当然了，注意Context引用的持有，防止内存泄漏。