深入解析Android App开发中Context的用法

Context在开发Android应用的过程中扮演着非常重要的角色,比如启动一个Activity需要使用context.startActivity方法,将一个xml文件转换为一个View对象也需要使用Context对象,可以这么说,离开了这个类,Android开发寸步难行,对于这样一个类,我们又对他了解多少呢。我就说说我的感受吧,在刚开始学习Android开发时,感觉使用Context的地方一直就是传入一个Activity对象,久而久之感觉只要是Context的地方就传入一个Activity就行了,那么我们现在就来详细的分析一下Context和Activity的关系吧!
在开始本文之前我们先放置一个问题在这里:
我们平时在获取项目资源时使用context.getResources()的时候为什么放回的是同一个值,明明是使用不同的Activity调用getResources返回结果却是一样的。

Context本身是一个纯的abstract类,ContextWrapper是对Context的一个包装而已,它的内部包含了一个Context对象,其实对ContextWrapper的方法调用最终都是调用其中的Context对象完成的,至于ContextThremeWrapper,很明显和Theme有关,所以Activity从ContextThemmWrapper继承,而Service从ContextWrapper继承,ContextImpl是唯一一个真正实现了Context中方法的类。
 
从上面的继承关系来看,每一个Activity就是一个Context,每一个Service就是一个Context,这也就是为什么使用Context的地方可以被Activity或者Service替换了。
 

创建Context
根据前面所说,由于实现了Context的只有ContextImpl类,Activity和Service本没有真正的实现,他们只是内部包含了一个真实的Context对象而已,也就是在在创建Activity或者Service的时候肯定要创建爱你一个ContextImpl对象,并赋值到Activity中的Context类型变量中。那我们就来看看Andorid源码中有哪些地方创建了ContextImpl.
据统计Android中创建ContextImpl的地方一共有7处:

  • 在PackageInfo.makeApplication()中
  • 在performLaunchActivity()中
  • 在handleCreateBackupAgent()中
  • 在handleCreateService()中
  • 2次在hanldBinderAppplication()中
  • 在attach()方法中


由于创建ContextImpl的基本原理类似,所以这里只会分析几个比较有代表性的地方:
1、  Application对应的Context
在应用程序启动时,都会创建一个Application对象,所以辗转调用到handleBindApplication()方法。

private final void handleBindApplication(AppBindData data) { 
    mBoundApplication = data; 
    mConfiguration = new Configuration(data.config); 
 
    .... 
    data.info = getPackageInfoNoCheck(data.appInfo); 
 
      ... 
     
    Application app = data.info.makeApplication(data.restrictedBackupMode, null); 
    mInitialApplication = app; 
 
   .... 
 } 

其中data.info是LoadedApk类型的,到getPackageInfoNoCheck中看看源码

public final LoadedApk getPackageInfoNoCheck(ApplicationInfo ai) { 
    return getPackageInfo(ai, null, false, true); 
} 

里面其实调用的是getPackageInfo,继续跟进:

if (includeCode) { 
        ref = mPackages.get(aInfo.packageName); 
      } else { 
        ref = mResourcePackages.get(aInfo.packageName); 
      } 
      LoadedApk packageInfo = ref != null ? ref.get() : null; 
      if (packageInfo == null || (packageInfo.mResources != null 
          && !packageInfo.mResources.getAssets().isUpToDate())) { 
        if (localLOGV) Slog.v(TAG, (includeCode ? "Loading code package " 
            : "Loading resource-only package ") + aInfo.packageName 
            + " (in " + (mBoundApplication != null 
                ? mBoundApplication.processName : null) 
            + ")"); 
        packageInfo = 
          new LoadedApk(this, aInfo, this, baseLoader, 
              securityViolation, includeCode && 
              (aInfo.flags&ApplicationInfo.FLAG_HAS_CODE) != 0); 
if (includeCode) { 
          mPackages.put(aInfo.packageName, 
              new WeakReference<LoadedApk>(packageInfo)); 
        } else { 
          mResourcePackages.put(aInfo.packageName, 
              new WeakReference<LoadedApk>(packageInfo)); 
        } 

由于includeCode传入的是true,所以首先从mPackages中获取,如果没有,则new一个出来,并放入mPackages里面去,注意,这里的mPackages是ActivityThread中的属性。
下面继续分析一下LoadedApk这个类中的makeApplication函数

try { 
      java.lang.ClassLoader cl = getClassLoader(); 
      //创建一个ContextImpl对象 
      ContextImpl appContext = new ContextImpl(); 
      appContext.init(this, null, mActivityThread); 
      app = mActivityThread.mInstrumentation.newApplication( 
          cl, appClass, appContext); 
      appContext.setOuterContext(app); 
    } catch (Exception e) { 
      if (!mActivityThread.mInstrumentation.onException(app, e)) { 
        throw new RuntimeException( 
          "Unable to instantiate application " + appClass 
          + ": " + e.toString(), e); 
      } 
    } 

这里创建了一个ContextImpl对象,并调用了它的init方法,现在进入init方法。 

mPackageInfo = packageInfo; 
mResources = mPackageInfo.getResources(mainThread); 

对mPackageInof和mResources两个变量初始化
回到makeApplication中,创建了一个Application对象,并将appContext传进去,其实就是将appContext传递给ContextWrapper中的Context类型变量(Application也是继承ContextWrapper)
2、Activity中的Context
在创建一个Activity时,经过辗转调用,会执行handleLaunchActivity(),然后调用performLaunchActivity(),该方法创建ContextImpl代码如下:

r.packageInfo= getPackageInfo(aInfo.applicationInfo,
          Context.CONTEXT_INCLUDE_CODE);
 
ContextImplappContext = new ContextImpl();
        appContext.init(r.packageInfo,r.token, this);
        appContext.setOuterContext(activity);
 
activity.attach(appContext,this, getInstrumentation(), r.token,
            r.ident, app, r.intent,r.activityInfo, title, r.parent,
            r.embeddedID,r.lastNonConfigurationInstance,
            r.lastNonConfigurationChildInstances, config);

由于getPackageInfo函数之前已经分析过了,稍微有点区别,但是大致流程是差不多的,所以此处的appContext执行init之后,其中的mPackages变量和mResources变量时一样的,activity通过attach函数将该appContext赋值到ContextWrapper中的Context类型变量。

3、Service中的Context
同样 在创建一个Service时,经过辗转调用会调用到scheduleCreateService方法,之后会巧用handleCreateService

LoadedApkpackageInfo = getPackageInfoNoCheck(
        data.info.applicationInfo);
 
ContextImplcontext = new ContextImpl();
      context.init(packageInfo, null,this);
 
      Application app =packageInfo.makeApplication(false, mInstrumentation);
      context.setOuterContext(service);
      service.attach(context, this,data.info.name, data.token, app,
          ActivityManagerNative.getDefault());

其思路和上面两个基本一样,在此就不再详述。

Context对资源的访问
很明确,不同的Context得到的都是同一份资源。这是很好理解的,请看下面的分析

得到资源的方式为context.getResources,而真正的实现位于ContextImpl中的getResources方法,在ContextImpl中有一个成员 private Resources mResources,它就是getResources方法返回的结果,mResources的赋值代码为:

mResources = mResourcesManager.getTopLevelResources(mPackageInfo.getResDir(),
          Display.DEFAULT_DISPLAY, null, compatInfo, activityToken);

下面看一下ResourcesManager的getTopLevelResources方法,这个方法的思想是这样的:在ResourcesManager中,所有的资源对象都被存储在ArrayMap中,首先根据当前的请求参数去查找资源,如果找到了就返回,否则就创建一个资源对象放到ArrayMap中。有一点需要说明的是为什么会有多个资源对象,原因很简单,因为res下可能存在多个适配不同设备、不同分辨率、不同系统版本的目录,按照android系统的设计,不同设备在访问同一个应用的时候访问的资源可以不同,比如drawable-hdpi和drawable-xhdpi就是典型的例子。

public Resources getTopLevelResources(String resDir, int displayId, 
    Configuration overrideConfiguration, CompatibilityInfo compatInfo, IBinder token) { 
  final float scale = compatInfo.applicationScale; 
  ResourcesKey key = new ResourcesKey(resDir, displayId, overrideConfiguration, scale, 
      token); 
  Resources r; 
  synchronized (this) { 
    // Resources is app scale dependent. 
    if (false) { 
      Slog.w(TAG, "getTopLevelResources: " + resDir + " / " + scale); 
    } 
    WeakReference<Resources> wr = mActiveResources.get(key); 
    r = wr != null ? wr.get() : null; 
    //if (r != null) Slog.i(TAG, "isUpToDate " + resDir + ": " + r.getAssets().isUpToDate()); 
    if (r != null && r.getAssets().isUpToDate()) { 
      if (false) { 
        Slog.w(TAG, "Returning cached resources " + r + " " + resDir 
            + ": appScale=" + r.getCompatibilityInfo().applicationScale); 
      } 
      return r; 
    } 
  } 
 
  //if (r != null) { 
  //  Slog.w(TAG, "Throwing away out-of-date resources!!!! " 
  //      + r + " " + resDir); 
  //} 
 
  AssetManager assets = new AssetManager(); 
  if (assets.addAssetPath(resDir) == 0) { 
    return null; 
  } 
 
  //Slog.i(TAG, "Resource: key=" + key + ", display metrics=" + metrics); 
  DisplayMetrics dm = getDisplayMetricsLocked(displayId); 
  Configuration config; 
  boolean isDefaultDisplay = (displayId == Display.DEFAULT_DISPLAY); 
  final boolean hasOverrideConfig = key.hasOverrideConfiguration(); 
  if (!isDefaultDisplay || hasOverrideConfig) { 
    config = new Configuration(getConfiguration()); 
    if (!isDefaultDisplay) { 
      applyNonDefaultDisplayMetricsToConfigurationLocked(dm, config); 
    } 
    if (hasOverrideConfig) { 
      config.updateFrom(key.mOverrideConfiguration); 
    } 
  } else { 
    config = getConfiguration(); 
  } 
  r = new Resources(assets, dm, config, compatInfo, token); 
  if (false) { 
    Slog.i(TAG, "Created app resources " + resDir + " " + r + ": " 
        + r.getConfiguration() + " appScale=" 
        + r.getCompatibilityInfo().applicationScale); 
  } 
 
  synchronized (this) { 
    WeakReference<Resources> wr = mActiveResources.get(key); 
    Resources existing = wr != null ? wr.get() : null; 
    if (existing != null && existing.getAssets().isUpToDate()) { 
      // Someone else already created the resources while we were 
      // unlocked; go ahead and use theirs. 
      r.getAssets().close(); 
      return existing; 
    } 
 
    // XXX need to remove entries when weak references go away 
    mActiveResources.put(key, new WeakReference<Resources>(r)); 
    return r; 
  } 
} 

根据上述代码中资源的请求机制,再加上ResourcesManager采用单例模式,这样就保证了不同的ContextImpl访问的是同一套资源,注意,这里说的同一套资源未必是同一个资源,因为资源可能位于不同的目录,但它一定是我们的应用的资源,或许这样来描述更准确,在设备参数和显示参数不变的情况下,不同的ContextImpl访问到的是同一份资源。设备参数不变是指手机的屏幕和android版本不变,显示参数不变是指手机的分辨率和横竖屏状态。也就是说,尽管Application、Activity、Service都有自己的ContextImpl,并且每个ContextImpl都有自己的mResources成员,但是由于它们的mResources成员都来自于唯一的ResourcesManager实例,所以它们看似不同的mResources其实都指向的是同一块内存(C语言的概念),因此,它们的mResources都是同一个对象(在设备参数和显示参数不变的情况下)。在横竖屏切换的情况下且应用中为横竖屏状态提供了不同的资源,处在横屏状态下的ContextImpl和处在竖屏状态下的ContextImpl访问的资源不是同一个资源对象。

 

代码:单例模式的ResourcesManager类

public static ResourcesManager getInstance() { 
  synchronized (ResourcesManager.class) { 
    if (sResourcesManager == null) { 
      sResourcesManager = new ResourcesManager(); 
    } 
    return sResourcesManager; 
  } 
} 

getApplication和getApplicationContext的区别
 

getApplication返回结果为Application,且不同的Activity和Service返回的Application均为同一个全局对象,在ActivityThread内部有一个列表专门用于维护所有应用的application

 

  final ArrayList<Application> mAllApplications = new ArrayList<Application>();

getApplicationContext返回的也是Application对象,只不过返回类型为Context,看看它的实现

@Override 
public Context getApplicationContext() { 
  return (mPackageInfo != null) ? 
      mPackageInfo.getApplication() : mMainThread.getApplication(); 
} 

上面代码中mPackageInfo是包含当前应用的包信息、比如包名、应用的安装目录等,原则上来说,作为第三方应用,包信息mPackageInfo不可能为空,在这种情况下,getApplicationContext返回的对象和getApplication是同一个。但是对于系统应用,包信息有可能为空,具体就不深入研究了。从这种角度来说,对于第三方应用,一个应用只存在一个Application对象,且通过getApplication和getApplicationContext得到的是同一个对象,两者的区别仅仅是返回类型不同。


在此总结一下:
(1)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得到相同的结果
(2)在一个apk中,Context的数量等于Activity个数+Service个数+1.

声明:本文内容来源于网络,版权归原作者所有,内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎发送邮件至:notice#cainiaojc.com(发邮件时,请将#更换为@)进行举报,并提供相关证据,一经查实,本站将立刻删除涉嫌侵权内容。