【转】Android Context

　　

Android中Context详解 ---- 你所不知道的Context

　　原文出处：http://blog.csdn.net/qinjuning

 

　　前言：本文是我读《Android内核剖析》第7章 后形成的读书笔记 ，在此向欲了解Android框架的书籍推荐此书。

　　大家好，  今天给大家介绍下我们在应用开发中最熟悉而陌生的朋友-----Context类 ，说它熟悉，是应为我们在开发中 时刻的在与它打交道，例如：Service、BroadcastReceiver、Activity等都会利用到Context的相关方法 ；

　　说它陌生，完全是因为我们真正的不懂Context的原理、类结构关系。一个简单的问题是，一个应用程序App中存在多少个Context实例对象呢？一个、两个？ 在此先卖个关子吧。读了本文，相信您会豁然开朗的 。

　　

　　Context，中文直译为“上下文”，SDK中对其说明如下：

　　Interface to global information about an application environment. This is an abstract class whose implementation is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc

 

　　从上可知一下三点：

　　1、它描述的是一个应用程序环境的信息，即上下文。

　　2、该类是一个抽象(abstract class)类，Android提供了该抽象类的具体实现类(后面我们会讲到是ContextIml类)。

　　3、通过它我们可以获取应用程序的资源和类，也包括一些应用级别操作，例如：启动一个Activity，发送广播，接受Intent信息 等。

 

　　于是，我们可以利用该Context对象去构建应用级别操作(application-level operations) 。

 

　　一、Context相关类的继承关系

　　

 

　　相关类介绍： 

　　Context类    路径： /frameworks/base/core/java/android/content/Context.java

　　说明：  抽象类，提供了一组通用的API。

      源代码(部分)如下：   

  1. public abstract class Context {  
  2.      ...  
  3.      public abstract Object getSystemService(String name);  //获得系统级服务  
  4.      public abstract void startActivity(Intent intent);     //通过一个Intent启动Activity  
  5.      public abstract ComponentName startService(Intent service);  //启动Service  
  6.      //根据文件名得到SharedPreferences对象  
  7.      public abstract SharedPreferences getSharedPreferences(String name,int mode);  
  8.      ...  
  9. }  

 

　　ContextIml.java类  路径 ：/frameworks/base/core/java/android/app/ContextImpl.java

　　说明：该Context类的实现类为ContextIml，该类实现了Context类的功能。请注意，该函数的大部分功能都是直接调用其属性mPackageInfo去完成，这点我们后面会讲到。    

　　源代码(部分)如下：

  1. /** 
  2.  * Common implementation of Context API, which provides the base 
  3.  * context object for Activity and other application components. 
  4.  */  
  5. class ContextImpl extends Context{  
  6.     //所有Application程序公用一个mPackageInfo对象  
  7.     /*package*/ ActivityThread.PackageInfo mPackageInfo;  
  8.       
  9.     @Override  
  10.     public Object getSystemService(String name){  
  11.         ...  
  12.         else if (ACTIVITY_SERVICE.equals(name)) {  
  13.             return getActivityManager();  
  14.         }   
  15.         else if (INPUT_METHOD_SERVICE.equals(name)) {  
  16.             return InputMethodManager.getInstance(this);  
  17.         }  
  18.     }   
  19.     @Override  
  20.     public void startActivity(Intent intent) {  
  21.         ...  
  22.         //开始启动一个Activity  
  23.         mMainThread.getInstrumentation().execStartActivity(  
  24.             getOuterContext(), mMainThread.getApplicationThread(), null, null, intent, -1);  
  25.     }  
  26. }  

 

　　ContextWrapper类 路径 ：\frameworks\base\core\java\android\content\ContextWrapper.java

　　说明： 正如其名称一样，该类只是对Context类的一种包装，该类的构造函数包含了一个真正的Context引用，即ContextIml对象。   

　　源代码(部分)如下：

  1. public class ContextWrapper extends Context {  
  2.     Context mBase;  //该属性指向一个ContextIml实例，一般在创建Application、Service、Activity时赋值  
  3.       
  4.     //创建Application、Service、Activity，会调用该方法给mBase属性赋值  
  5.     protected void attachBaseContext(Context base) {  
  6.         if (mBase != null) {  
  7.             throw new IllegalStateException("Base context already set");  
  8.         }  
  9.         mBase = base;  
  10.     }  
  11.     @Override  
  12.     public void startActivity(Intent intent) {  
  13.         mBase.startActivity(intent);  //调用mBase实例方法  
  14.     }  
  15. }  

 

 

　　ContextThemeWrapper类 路径：/frameworks/base/core/java/android/view/ContextThemeWrapper.java

　　说明：该类内部包含了主题(Theme)相关的接口，即android:theme属性指定的。只有Activity需要主题，Service不需要主题，所以Service直接继承于ContextWrapper类。

　　源代码(部分)如下：

  1. public class ContextThemeWrapper extends ContextWrapper {  
  2.      //该属性指向一个ContextIml实例，一般在创建Application、Service、Activity时赋值  
  3.        
  4.      private Context mBase;  
  5.     //mBase赋值方式同样有一下两种  
  6.      public ContextThemeWrapper(Context base, int themeres) {  
  7.             super(base);  
  8.             mBase = base;  
  9.             mThemeResource = themeres;  
  10.      }  
  11.   
  12.      @Override  
  13.      protected void attachBaseContext(Context newBase) {  
  14.             super.attachBaseContext(newBase);  
  15.             mBase = newBase;  
  16.      }  
  17. }  

　　Activity类 、Service类 、Application类本质上都是Context子类， 更多信息大家可以自行参考源代码进行理解。

 

二、 什么时候创建Context实例 

 　　熟悉了Context的继承关系后，我们接下来分析应用程序在什么情况需要创建Context对象的？应用程序创建Context实例的情况有如下几种情况：

      1、创建Application 对象时， 而且整个App共一个Application对象

      2、创建Service对象时

      3、创建Activity对象时

　　因此应用程序App共有的Context数目公式为：

 　　　　总Context实例个数 = Service个数 + Activity个数 + 1（Application对应的Context实例）

 

　　具体创建Context的时机

　　1、创建Application对象的时机

　　每个应用程序在第一次启动时，都会首先创建Application对象。如果对应用程序启动一个Activity(startActivity)流程比较清楚的话，创建Application的时机在创建handleBindApplication()方法中，该函数位于 ActivityThread.java类中 ，如下：

  1. //创建Application时同时创建的ContextIml实例  
  2. private final void handleBindApplication(AppBindData data){  
  3.     ...  
  4.     ///创建Application对象  
  5.     Application app = data.info.makeApplication(data.restrictedBackupMode, null);  
  6.     ...  
  7. }  
  8.   
  9. public Application makeApplication(boolean forceDefaultAppClass, Instrumentation instrumentation) {  
  10.     ...  
  11.     try {  
  12.         java.lang.ClassLoader cl = getClassLoader();  
  13.         ContextImpl appContext = new ContextImpl();    //创建一个ContextImpl对象实例  
  14.         appContext.init(this, null, mActivityThread);  //初始化该ContextIml实例的相关属性  
  15.         ///新建一个Application对象   
  16.         app = mActivityThread.mInstrumentation.newApplication(  
  17.                 cl, appClass, appContext);  
  18.        appContext.setOuterContext(app);  //将该Application实例传递给该ContextImpl实例           
  19.     }   
  20.     ...  
  21. }  

 

　　2、创建Activity对象的时机

　　通过startActivity()或startActivityForResult()请求启动一个Activity时，如果系统检测需要新建一个Activity对象时，就会回调handleLaunchActivity()方法，该方法继而调用performLaunchActivity()方法，去创建一个Activity实例，并且回调onCreate()，onStart()方法等， 函数都位于 ActivityThread.java类 ，如下：

  1. //创建一个Activity实例时同时创建ContextIml实例  
  2. private final void handleLaunchActivity(ActivityRecord r, Intent customIntent) {  
  3.     ...  
  4.     Activity a = performLaunchActivity(r, customIntent);  //启动一个Activity  
  5. }  
  6. private final Activity performLaunchActivity(ActivityRecord r, Intent customIntent) {  
  7.     ...  
  8.     Activity activity = null;  
  9.     try {  
  10.         //创建一个Activity对象实例  
  11.         java.lang.ClassLoader cl = r.packageInfo.getClassLoader();  
  12.         activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);  
  13.     }  
  14.     if (activity != null) {  
  15.         ContextImpl appContext = new ContextImpl();      //创建一个Activity实例  
  16.         appContext.init(r.packageInfo, r.token, this);   //初始化该ContextIml实例的相关属性  
  17.         appContext.setOuterContext(activity);            //将该Activity信息传递给该ContextImpl实例  
  18.         ...  
  19.     }  
  20.     ...      
  21. }  

　　

　　3、创建Service对象的时机

　　通过startService或者bindService时，如果系统检测到需要新创建一个Service实例，就会回调handleCreateService()方法，

 完成相关数据操作。handleCreateService()函数位于 ActivityThread.java类，如下：

  1. //创建一个Service实例时同时创建ContextIml实例  
  2. private final void handleCreateService(CreateServiceData data){  
  3.     ...  
  4.     //创建一个Service实例  
  5.     Service service = null;  
  6.     try {  
  7.         java.lang.ClassLoader cl = packageInfo.getClassLoader();  
  8.         service = (Service) cl.loadClass(data.info.name).newInstance();  
  9.     } catch (Exception e) {  
  10.     }  
  11.     ...  
  12.     ContextImpl context = new ContextImpl(); //创建一个ContextImpl对象实例  
  13.     context.init(packageInfo, null, this);   //初始化该ContextIml实例的相关属性  
  14.     //获得我们之前创建的Application对象信息  
  15.     Application app = packageInfo.makeApplication(false, mInstrumentation);  
  16.     //将该Service信息传递给该ContextImpl实例  
  17.     context.setOuterContext(service);  
  18.     ...  
  19. }  

 

　　另外，需要强调一点的是，通过对ContextImp的分析可知，其方法的大多数操作都是直接调用其属性mPackageInfo(该属性类型为PackageInfo)的相关方法而来。这说明ContextImp是一种轻量级类，而PackageInfo才是真正重量级的类。而一个App里的所有ContextIml实例，都对应同一个packageInfo对象。

　　最后给大家分析利用Context获取SharedPreferences类的使用方法，SharedPreferences类想必大家都使用过，其一般获取方法就是通过调用getSharedPreferences()方法去根据相关信息获取SharedPreferences对象。具体流程如下：

　　A 、调用  getSharedPreferences()获取对应的的文件，该函数实现功能如下：

 
  1. //Context类静态数据集合，以键值对保存了所有读取该xml文件后所形成的数据集合  
  2. private static final HashMap<File, SharedPreferencesImpl> sSharedPrefs =   
  3.        new HashMap<File, SharedPreferencesImpl>();   
  4.   
  5. @Override  
  6. public SharedPreferences getSharedPreferences(String name, int mode){  
  7.      //其所对应的SharedPreferencesImpl对象 ，该对象已一个HashMap集合保存了我们对该文件序列化结果  
  8.      SharedPreferencesImpl sp;    
  9.      File f = getSharedPrefsFile(name);  //该包下是否存在对应的文件，不存在就新建一个  
  10.      synchronized (sSharedPrefs) {       //是否已经读取过该文件，是就直接返回该SharedPreferences对象  
  11.          sp = sSharedPrefs.get(f);  
  12.          if (sp != null && !sp.hasFileChanged()) {  
  13.              //Log.i(TAG, "Returning existing prefs " + name + ": " + sp);  
  14.              return sp;  
  15.          }  
  16.      }  
  17.      //以下为序列化该xml文件，同时将数据写到map集合中       
  18.      Map map = null;  
  19.      if (f.exists() && f.canRead()) {  
  20.          try {  
  21.              str = new FileInputStream(f);  
  22.              map = XmlUtils.readMapXml(str);  
  23.              str.close();  
  24.          }   
  25.          ...  
  26.      }  
  27.        
  28.      synchronized (sSharedPrefs) {  
  29.          if (sp != null) {  
  30.              //Log.i(TAG, "Updating existing prefs " + name + " " + sp + ": " + map);  
  31.              sp.replace(map);   //更新数据集合  
  32.          } else {  
  33.              sp = sSharedPrefs.get(f);  
  34.              if (sp == null) {    
  35.                  //新建一个SharedPreferencesImpl对象，并且设置其相关属性  
  36.                  sp = new SharedPreferencesImpl(f, mode, map);    
  37.                  sSharedPrefs.put(f, sp);  
  38.              }  
  39.          }  
  40.          return sp;  
  41.      }  
  42. }  

 

　　B、 SharedPreferences 不过是个接口，它定义了一些操作xml文件的方法，其真正实现类为SharedPreferencesImpl ，该类是ContextIml的内部类，该类如下： 

  1. //soga，这种形式我们在分析Context ContextIml时接触过   
  2. //SharedPreferences只是一种接口，其真正实现类是SharedPreferencesImpl类  
  3. private static final class SharedPreferencesImpl implements SharedPreferences{  
  4.      private Map mMap;  //保存了该文件序列化结果后的操作， 键值对形式  
  5.        
  6.      //通过key值获取对应的value值  
  7.      public String getString(String key, String defValue) {  
  8.          synchronized (this) {  
  9.              String v = (String)mMap.get(key);  
  10.              return v != null ? v : defValue;  
  11.          }  
  12.      }  
  13.      ...  
  14.      //获得该SharedPreferencesImpl对象对应的Edito类，对数据进行操作  
  15.      public final class EditorImpl implements Editor {  
  16.          private final Map<String, Object> mModified = Maps.newHashMap(); //保存了对键值变化的集合  
  17.      }  
  18. }  

 

　　基本上获取SharedPreferences 对象就是这么来的，关于Context里的更多方法请大家参照源代码认真学习吧。

 

 

 

 

 

 

 

 

 

 

 

 Android源码分析-全面理解Context

 原文出处：http://www.cnblogs.com/android100/p/Android-Context.html

前言

Context在android中的作用不言而喻，当我们访问当前应用的资源，启动一个新的activity的时候都需要提供Context，而这个Context到底是什么呢，这个问题好像很好回答又好像难以说清楚。从字面意思，Context的意思是“上下文”，或者也可以叫做环境、场景等，尽管如此，还是有点抽象。从类的继承来说，Context作为一个抽象的基类，它的实现子类有三种：Application、Activity和Service（估计这么说，暂时不管ContextWrapper等类），那么这三种有没有区别呢？为什么通过任意的Context访问资源都得到的是同一套资源呢？getApplication和getApplicationContext有什么区别呢？应用中到底有多少个Context呢？本文将围绕这些问题一一展开，所用源码版本为Android4.4。

什么是Context

Context是一个抽象基类，我们通过它访问当前包的资源（getResources、getAssets）和启动其他组件（Activity、Service、Broadcast）以及得到各种服务（getSystemService），当然，通过Context能得到的不仅仅只有上述这些内容。对Context的理解可以来说：Context提供了一个应用的运行环境，在Context的大环境里，应用才可以访问资源，才能完成和其他组件、服务的交互，Context定义了一套基本的功能接口，我们可以理解为一套规范，而Activity和Service是实现这套规范的子类，这么说也许并不准确，因为这套规范实际是被ContextImpl类统一实现的，Activity和Service只是继承并有选择性地重写了某些规范的实现。

Application、Activity和Service作为Context的区别

首先，它们都间接继承了Context，这是它们的相同点。

不同点，可以从几个方面来说：首先看它们的继承关系

Activity的继承关系

Service和Application的继承关系

通过对比可以清晰地发现，Service和Application的类继承关系比较像，而Activity还多了一层继承ContextThemeWrapper，这是因为Activity有主题的概念，而Service是没有界面的服务，Application更是一个抽象的东西，它也是通过Activity类呈现的。

下面来看一下三者在Context方面的区别

上文已经指出，Context的真正实现都在ContextImpl中，也就是说Context的大部分方法调用都会转到ContextImpl中，而三者的创建均在ActivityThread中完成，我之前写过一篇文章Android源码分析-Activity的启动过程，在文中我指出Activity启动的核心过程是在ActivityThread中完成的，这里要说明的是，Application和Service的创建也是在ActivityThread中完成的。下面我们看下三者在创建时是怎么和ContextImpl相关联的。

Activity对象中ContextImpl的创建

代码为ActivityThread中的performLaunchActivity方法 

  1. if (activity != null) {  
  2.     Context appContext = createBaseContextForActivity(r, activity);  
  3.     /** 
  4.      *  createBaseContextForActivity中创建ContextImpl的代码 
  5.      *  ContextImpl appContext = new ContextImpl(); 
  6.      *  appContext.init(r.packageInfo, r.token, this); 
  7.      *  appContext.setOuterContext(activity); 
  8.      */  
  9.     CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager());  
  10.     Configuration config = new Configuration(mCompatConfiguration);  
  11.     if (DEBUG_CONFIGURATION) Slog.v(TAG, "Launching activity "  
  12.             + r.activityInfo.name + " with config " + config);  
  13.     activity.attach(appContext, this, getInstrumentation(), r.token,  
  14.             r.ident, app, r.intent, r.activityInfo, title, r.parent,  
  15.             r.embeddedID, r.lastNonConfigurationInstances, config);  
  16.   
  17.     if (customIntent != null) {  
  18.         activity.mIntent = customIntent;  
  19.     }  
  20.     ...  
  21. }  

可以看出，Activity在创建的时候会new一个ContextImpl对象并在attach方法中关联它，需要注意的是，创建Activity使用的数据结构是ActivityClientRecord。

 

Application对象中ContextImpl的创建

代码在ActivityThread中的handleBindApplication方法中，此方法内部调用了makeApplication方法 

  1. public Application makeApplication(boolean forceDefaultAppClass,  
  2.         Instrumentation instrumentation) {  
  3.     if (mApplication != null) {  
  4.         return mApplication;  
  5.     }  
  6.   
  7.     Application app = null;  
  8.   
  9.     String appClass = mApplicationInfo.className;  
  10.     if (forceDefaultAppClass || (appClass == null)) {  
  11.         appClass = "android.app.Application";  
  12.     }  
  13.   
  14.     try {  
  15.         java.lang.ClassLoader cl = getClassLoader();  
  16.         ContextImpl appContext = new ContextImpl();  
  17.         appContext.init(this, null, mActivityThread);  
  18.         app = mActivityThread.mInstrumentation.newApplication(  
  19.                 cl, appClass, appContext);  
  20.         appContext.setOuterContext(app);  
  21.     } catch (Exception e) {  
  22.         if (!mActivityThread.mInstrumentation.onException(app, e)) {  
  23.             throw new RuntimeException(  
  24.                 "Unable to instantiate application " + appClass  
  25.                 + ": " + e.toString(), e);  
  26.         }  
  27.     }  
  28.     ...  
  29. }  

看代码发现和Activity中ContextImpl的创建是相同的。

 

Service对象中ContextImpl的创建

通过查看代码发现和Activity、Application是一致的。分析到这里，那么三者的Context有什么区别呢？没有区别吗？尽管如此，有一些细节是确定的：Dialog的使用需要Activity，在桌面上我们采用Application的Context无法弹出对话框，同时在桌面上想启动新的activity，我们需要为intent设置FLAG_ACTIVITY_NEW_TASK标志，否则无法启动activity，这一切都说明，起码Application的Context和Activity的Context还是有区别的，当然这也可能不是Context的区别，因为在桌面上，我们的应用没有界面，这意味着我们能干的事情可能受到了限制，事情的细节目前我还没有搞的很清楚。

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就是典型的例子。 

  1. public Resources getTopLevelResources(String resDir, int displayId,  
  2.         Configuration overrideConfiguration, CompatibilityInfo compatInfo, IBinder token) {  
  3.     final float scale = compatInfo.applicationScale;  
  4.     ResourcesKey key = new ResourcesKey(resDir, displayId, overrideConfiguration, scale,  
  5.             token);  
  6.     Resources r;  
  7.     synchronized (this) {  
  8.         // Resources is app scale dependent.  
  9.         if (false) {  
  10.             Slog.w(TAG, "getTopLevelResources: " + resDir + " / " + scale);  
  11.         }  
  12.         WeakReference<Resources> wr = mActiveResources.get(key);  
  13.         r = wr != null ? wr.get() : null;  
  14.         //if (r != null) Slog.i(TAG, "isUpToDate " + resDir + ": " + r.getAssets().isUpToDate());  
  15.         if (r != null && r.getAssets().isUpToDate()) {  
  16.             if (false) {  
  17.                 Slog.w(TAG, "Returning cached resources " + r + " " + resDir  
  18.                         + ": appScale=" + r.getCompatibilityInfo().applicationScale);  
  19.             }  
  20.             return r;  
  21.         }  
  22.     }  
  23.   
  24.     //if (r != null) {  
  25.     //    Slog.w(TAG, "Throwing away out-of-date resources!!!! "  
  26.     //            + r + " " + resDir);  
  27.     //}  
  28.   
  29.     AssetManager assets = new AssetManager();  
  30.     if (assets.addAssetPath(resDir) == 0) {  
  31.         return null;  
  32.     }  
  33.   
  34.     //Slog.i(TAG, "Resource: key=" + key + ", display metrics=" + metrics);  
  35.     DisplayMetrics dm = getDisplayMetricsLocked(displayId);  
  36.     Configuration config;  
  37.     boolean isDefaultDisplay = (displayId == Display.DEFAULT_DISPLAY);  
  38.     final boolean hasOverrideConfig = key.hasOverrideConfiguration();  
  39.     if (!isDefaultDisplay || hasOverrideConfig) {  
  40.         config = new Configuration(getConfiguration());  
  41.         if (!isDefaultDisplay) {  
  42.             applyNonDefaultDisplayMetricsToConfigurationLocked(dm, config);  
  43.         }  
  44.         if (hasOverrideConfig) {  
  45.             config.updateFrom(key.mOverrideConfiguration);  
  46.         }  
  47.     } else {  
  48.         config = getConfiguration();  
  49.     }  
  50.     r = new Resources(assets, dm, config, compatInfo, token);  
  51.     if (false) {  
  52.         Slog.i(TAG, "Created app resources " + resDir + " " + r + ": "  
  53.                 + r.getConfiguration() + " appScale="  
  54.                 + r.getCompatibilityInfo().applicationScale);  
  55.     }  
  56.   
  57.     synchronized (this) {  
  58.         WeakReference<Resources> wr = mActiveResources.get(key);  
  59.         Resources existing = wr != null ? wr.get() : null;  
  60.         if (existing != null && existing.getAssets().isUpToDate()) {  
  61.             // Someone else already created the resources while we were  
  62.             // unlocked; go ahead and use theirs.  
  63.             r.getAssets().close();  
  64.             return existing;  
  65.         }  
  66.   
  67.         // XXX need to remove entries when weak references go away  
  68.         mActiveResources.put(key, new WeakReference<Resources>(r));  
  69.         return r;  
  70.     }  
  71. }  

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

 

代码：单例模式的ResourcesManager类 

  1. public static ResourcesManager getInstance() {  
  2.     synchronized (ResourcesManager.class) {  
  3.         if (sResourcesManager == null) {  
  4.             sResourcesManager = new ResourcesManager();  
  5.         }  
  6.         return sResourcesManager;  
  7.     }  
  8. }  

getApplication和getApplicationContext的区别

 

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

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

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

 

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

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

应用中Context的数量

到此已经很明了了，一个应用中Context的数量等于Activity的个数 + Service的个数 + 1，这个1为Application。

 posted on 2014-05-06 11:23  yeing  阅读(204)  评论(0)    收藏  举报