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对象;

 

posted @ 2013-07-13 22:21 Livingstone 阅读(...) 评论(...) 编辑 收藏