Android 内核--Context对象

Context(在Android中翻译为场景):一个Activity就是一个Context，一个Service也是一个Context，应用程序中有多少个Activity或者Service，就会有多少个Context对象； Android把"场景"抽象为Context类，用户和操作系统的每一次交互都是一个场景； 如打电话为有界面的场景，后台服务service为没界面的场景；
Context类本身是一个纯abstract类，为了使用方便，定义了ContextWrapper类，这只是一个包装而已，它的构造函数中必须包含一个真正的Context引用，同时它提供了attachBaseContext()用于给ContextWrapper对象中指定真正的Context对象，调用ContextWrapper的方法都会被转向其所包含的真正的Context对象。 ContextThemeWrapper类，内部包含了主题相关的接口，在此说的主题是指在Manifest.xml中通过android:theme为Application元素或者Activity元素指定的主题；

ContextImpl类真正实现了Context中所有函数，应用程序中调用的各种Context类的方法，其实现均来自于该类； 每一个应用程序都是从ActivityThread类开始的，创建Context对象也是在该类中完成，具体创建ContexImpl类的地方一共有7处；

• PackageInfo.makeApplication()
  performLaunchActivity()
  handleCreateBackupAgent()
  handleCreateService()
  handleBindApplication()
  handleBindApplication()
  attach()

attach()方法仅在Framework进程(system_server)启动时调用，应用程序运行时不会调用到该方法，需要明确的是system_server进程本身也是一个应用程序，所以其入口也是ActivityThread类，只是这个ActivityThread和一些系统服务运行在同一个进程空间中而已。

attach()方法中创建ContextImpl对象的基本逻辑如同以下三小点:

1、Application对应的Context

　　每个应用程序在第一次启动时，都会首先创建一个Application对象，默认的Application是应用程序的包名，用户可以重载默认的Application； 程序第一次启动时，会辗转调用到handleBindApplication()方法中，该方法中有两处创建了ContextImpl对象，但都是在if(data.instrumentationName!=null)条件中，该条件在一般的程序执行时都不会被执行到，只有当创建一个Android UnitTest工程时，相应的Test程序才能满足这个条件；
而如果不是测试工程的话，则调用makeApplication()方法

        // If the app is being launched for full backup or restore, bring it up in
        // a restricted environment with the base application class.
        Application app = data.info.makeApplication(data.restrictedBackupMode, null);

下面是makeApplication函数处理方法代码

            java.lang.ClassLoader cl = getClassLoader();
            ContextImpl appContext = new ContextImpl();
            appContext.init(this, null, mActivityThread);
            app = mActivityThread.mInstrumentation.newApplication(cl, appClass, appContext);
            appContext.setOuterContext(app);

　　即创建一个ContextImpl对象，然后调用init方法，其中第一个参数this指的是当前PackageInfo对象{LoadedApk.Java}，该对象将赋值给ContextImpl类中的重要成员变量mPackageInfo。

　　需要注意的是PackageInfo对象从什么地方来的？就需要回溯到是谁调用了makeApplication()方法；
　　首先，AmS通过远程调用到ActivityThread的bindApplication()方法，该方法的参数包括两种，一种是ApplicationInfo,这是实现了Parcelable接口的数据类，意味着这个对象是由AmS创建的，通过IPC传递到ActivityThread中，另一种是其他的相关参数在bindApplication()方法中，

        public final void bindApplication(String processName,
                ApplicationInfo appInfo, List<ProviderInfo> providers,
                ComponentName instrumentationName, String profileFile,
                Bundle instrumentationArgs, IInstrumentationWatcher instrumentationWatcher,
                int debugMode, boolean isRestrictedBackupMode, Configuration config,
                Map<String, IBinder> services) {
            //////
            AppBindData data = new AppBindData();
            //////
        }

bindApplication方法创建一个本地AppBindData数据类，然后再去调用handleBindApplication。在调用handleBindApplication()的时候，AppBindData对象中的info变量还是空值，然后会使用data.info = getPackageInfoNoChecked方法为info变量赋值，

    private final void handleBindApplication(AppBindData data) {
        mBoundApplication = data;
        /////
        data.info = getPackageInfoNoCheck(data.appInfo);
　　　　 /////

getPackageInfoNoCheck方法如下

    public final LoadedApk getPackageInfoNoCheck(ApplicationInfo ai) {
        return getPackageInfo(ai, null, false, true);
    }
 　　getPackageInfo方法如下：

    private final LoadedApk getPackageInfo(ApplicationInfo aInfo,
            ClassLoader baseLoader, boolean securityViolation, boolean includeCode) {
            LoadedApk packageInfo = ref != null ? ref.get() : null;
            if (packageInfo == null || (packageInfo.mResources != null
                    && !packageInfo.mResources.getAssets().isUpToDate())) {
                //...if (includeCode) {
                    mPackages.put(aInfo.packageName, new WeakReference<LoadedApk>(packageInfo));
                } else {
                    mResourcePackages.put(aInfo.packageName, new WeakReference<LoadedApk>(packageInfo));
                }
            }
            return packageInfo;
    }

这个方法的内部实际上会根据AppBindData中的ApplicationInfo中的mPackageName创建一个PackageInfo对象，并把这个对象保存为ActivityThread类的全局对象，显然，一个应用程序中的所有Activity或者Application对象对应的mPackageName都一样，即为包的名称，所以ActivityThread中会产生一个全局PackageInfo对象。
　　接下来，回到data.info.makeApplication()方法，这是PackageInfo对象的来源；以上流程可以总结如下

2、Activity对象中获取Context对象

　　启动Activity时，AmS会通过IPC调用到ActivityThread的scheduleLaunchActivity方法，该方法包含一个参数ActivityInfo，这是一个实现了Parcelable接口的数据类，意味着该对象是AmS创建的，并通过IPC传递到ActivityThread；另一些参数如下。

        public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
                ActivityInfo info, Bundle state, List<ResultInfo> pendingResults,
                List<Intent> pendingNewIntents, boolean notResumed, boolean isForward) {
            ActivityClientRecord r = new ActivityClientRecord(); 
　　　　 ......
　　　　 }

　　scheduleLaunchActivity方法中会创建一个本地ActivityRecord数据类，ActivityThread内部会为每一个Activity创建一个ActivityRecord对象，并使用这些数据来管理Activity。
　　接下来会调用handleLaunchActivity()，然后再调用performLaunchActivity()，该方法中创建ContextImpl代码如下:

                ContextImpl appContext = new ContextImpl();
                appContext.init(r.packageInfo, r.token, this);
                appContext.setOuterContext(activity);

ContextImpl.init方法中的第一个参数来源即为performLaunchActivity中

        ActivityInfo aInfo = r.activityInfo;
        if (r.packageInfo == null) {
            r.packageInfo = getPackageInfo(aInfo.applicationInfo,
                    Context.CONTEXT_INCLUDE_CODE);
        }

即在performLaunchActiviy开始执行时，首先为r.packageInfo赋值，getpackageInfo方法的执行逻辑和getPackageInfoNoChecked()基本相同，所以，r.packageInfo对象的PackageInfo对象和Application对应的packageInfo对象是同一个。

3、Service对应的Context

　　启动Service时，AmS首先会通过IPC调用到ActivityThread的scheduleCreateService()方法，该方法包含两个参数。第一种是ServiceInfo，这是实现了一个Parcelable接口的类，意味着该对象由Ams创建，并通过IPC传递到ActivityThread内部，第二种是其他参数。

        public final void scheduleCreateService(IBinder token, ServiceInfo info) {
            CreateServiceData s = new CreateServiceData(); // ......
            s.token = token;
            s.info = info;
            queueOrSendMessage(H.CREATE_SERVICE, s);
        }

　　在scheduleCreateService()方法中，会创建一个CreateServiceData的数据对象，ActivityThread会为其所包含的每一个Service创建该数据对象，并通过这些对象来管理Service。
　　接着，会执行handleCreateService()方法，其中创建ContextImpl对象的代码如下：

                ContextImpl context = new ContextImpl();
                context.init(packageInfo, null, this);
                context.setOuterContext(agent);
                agent.attach(context);

同样context.init()方法中packageInfo的赋值操作为handleCreateService方法中通过如下代码实现

        LoadedApk packageInfo = getPackageInfoNoCheck(data.info.applicationInfo);

赋值代码同样使用了getPackageInfoNoCheck()方法，意味着Service对应的Context对象内部的mPackageInfo与Activity、Application中是完全相同的；
总结流程图如下：

4、Context之间的关系

从以上三节可以看出，创建Context对象的过程基本上是相同的，包括代码结构也很类似，不同的是针对Application、Activity、Service使用了不同的数据对象

不同Context子类中PackageInfo的来源如上表
一个应用程序中包含的Context个数为:Service个数 + Activity个数 + 1(Application类本身对应一个Context对象)

应用程序中包含多个ContextImpl对象，而其内部变量mPackageInfo指向同一个PackageInfo对象，这种设计意味着ContextImpl是一种轻量级，而PackageInfo是一个重量级；ContextImpl中的大多数进行包操作的重量级函数实际上都转向了mPackageInfo对象相应的方法，即事实上是调用了同一个PackageInfo对象；