轉(zhuǎn)載自：http://blog.csdn.net/singwhatiwanna/article/details/21829971 (來自singwhatiwanna的博客)
前言
Context在android中的作用不言而喻，當(dāng)我們訪問當(dāng)前應(yīng)用的資源，啟動一個新的activity的時候都需要提供Context，而這個Context到底是什么呢，這個問題好像很好回答又好像難以說清楚。從字面意思，Context的意思是“上下文”，或者也可以叫做環(huán)境、場景等，盡管如此，還是有點抽象。從類的繼承來說，Context作為一個抽象的基類，它的實現(xiàn)子類有三種：Application、Activity和Service（姑且這么說，暫時不管ContextWrapper等類），那么這三種有沒有區(qū)別呢？為什么通過任意的Context訪問資源都得到的是同一套資源呢？getApplication和getApplicationContext有什么區(qū)別呢？應(yīng)用中到底有多少個Context呢？本文將圍繞這些問題一一展開，所用源碼版本為Android4.4。
什么是Context
Context是一個抽象基類，我們通過它訪問當(dāng)前包的資源（getResources、getAssets）和啟動其他組件（Activity、Service、Broadcast）以及得到各種服務(wù)（getSystemService），當(dāng)然，通過Context能得到的不僅僅只有上述這些內(nèi)容。對Context的理解可以來說：Context提供了一個應(yīng)用的運行環(huán)境，在Context的大環(huán)境里，應(yīng)用才可以訪問資源，才能完成和其他組件、服務(wù)的交互，Context定義了一套基本的功能接口，我們可以理解為一套規(guī)范，而Activity和Service是實現(xiàn)這套規(guī)范的子類，這么說也許并不準(zhǔn)確，因為這套規(guī)范實際是被ContextImpl類統(tǒng)一實現(xiàn)的，Activity和Service只是繼承并有選擇性地重寫了某些規(guī)范的實現(xiàn)。
Application、Activity和Service作為Context的區(qū)別
首先，它們都間接繼承了Context，這是它們的相同點。
不同點，可以從幾個方面來說：首先看它們的繼承關(guān)系
Activity的繼承關(guān)系
Service和Application的繼承關(guān)系
通過對比可以清晰地發(fā)現(xiàn)，Service和Application的類繼承關(guān)系比較像，而Activity還多了一層繼承ContextThemeWrapper，這是因為Activity有主題的概念，而Service是沒有界面的服務(wù)，Application更是一個抽象的東西，它也是通過Activity類呈現(xiàn)的。
下面來看一下三者在Context方面的區(qū)別
上文已經(jīng)指出，Context的真正實現(xiàn)都在ContextImpl中，也就是說Context的大部分方法調(diào)用都會轉(zhuǎn)到ContextImpl中，而三者的創(chuàng)建均在ActivityThread中完成，我之前寫過一篇文章Android源碼分析-Activity的啟動過程，在文中我指出Activity啟動的核心過程是在ActivityThread中完成的，這里要說明的是，Application和Service的創(chuàng)建也是在ActivityThread中完成的。下面我們看下三者在創(chuàng)建時是怎么和ContextImpl相關(guān)聯(lián)的。
Activity對象中ContextImpl的創(chuàng)建
代碼為ActivityThread中的performLaunchActivity方法
if (activity != null) {
Context appContext = createBaseContextForActivity(r, activity);
/**
* createBaseContextForActivity中創(chuàng)建ContextImpl的代碼
* ContextImpl appContext = new ContextImpl();
* appContext.init(r.packageInfo, r.token, this);
* appContext.setOuterContext(activity);
*/
CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager());
Configuration config = new Configuration(mCompatConfiguration);
if (DEBUG_CONFIGURATION) Slog.v(TAG, "Launching activity "
+ r.activityInfo.name + " with config " + config);
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config);
if (customIntent != null) {
activity.mIntent = customIntent;
}
...
}
可以看出，Activity在創(chuàng)建的時候會new一個ContextImpl對象并在attach方法中關(guān)聯(lián)它，需要注意的是，創(chuàng)建Activity使用的數(shù)據(jù)結(jié)構(gòu)是ActivityClientRecord。
Application對象中ContextImpl的創(chuàng)建
代碼在ActivityThread中的handleBindApplication方法中，此方法內(nèi)部調(diào)用了makeApplication方法
public Application makeApplication(boolean forceDefaultAppClass,
Instrumentation instrumentation) {
if (mApplication != null) {
return mApplication;
}
Application app = null;
String appClass = mApplicationInfo.className;
if (forceDefaultAppClass || (appClass == null)) {
appClass = "android.app.Application";
}
try {
java.lang.ClassLoader cl = getClassLoader();
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);
}
}
...
}
看代碼發(fā)現(xiàn)和Activity中ContextImpl的創(chuàng)建是相同的。
Service對象中ContextImpl的創(chuàng)建
通過查看代碼發(fā)現(xiàn)和Activity、Application是一致的。分析到這里，那么三者的Context有什么區(qū)別呢？沒有區(qū)別嗎？盡管如此，有一些細(xì)節(jié)是確定的：Dialog的使用需要Activity，在桌面上我們采用Application的Context無法彈出對話框，同時在桌面上想啟動新的activity，我們需要為intent設(shè)置FLAG_ACTIVITY_NEW_TASK標(biāo)志，否則無法啟動activity，這一切都說明，起碼Application的Context和Activity的Context還是有區(qū)別的，當(dāng)然這也可能不是Context的區(qū)別，因為在桌面上，我們的應(yīng)用沒有界面，這意味著我們能干的事情可能受到了限制，事情的細(xì)節(jié)目前我還沒有搞的很清楚。
Context對資源的訪問
很明確，不同的Context得到的都是同一份資源。這是很好理解的，請看下面的分析
得到資源的方式為context.getResources，而真正的實現(xiàn)位于ContextImpl中的getResources方法，在ContextImpl中有一個成員 private Resources mResources，它就是getResources方法返回的結(jié)果，mResources的賦值代碼為：
mResources = mResourcesManager.getTopLevelResources(mPackageInfo.getResDir(),
Display.DEFAULT_DISPLAY, null, compatInfo, activityToken);
下面看一下ResourcesManager的getTopLevelResources方法，這個方法的思想是這樣的：在ResourcesManager中，所有的資源對象都被存儲在ArrayMap中，首先根據(jù)當(dāng)前的請求參數(shù)去查找資源，如果找到了就返回，否則就創(chuàng)建一個資源對象放到ArrayMap中。有一點需要說明的是為什么會有多個資源對象，原因很簡單，因為res下可能存在多個適配不同設(shè)備、不同分辨率、不同系統(tǒng)版本的目錄，按照android系統(tǒng)的設(shè)計，不同設(shè)備在訪問同一個應(yīng)用的時候訪問的資源可以不同，比如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;
}
}
根據(jù)上述代碼中資源的請求機制，再加上ResourcesManager采用單例模式，這樣就保證了不同的ContextImpl訪問的是同一套資源，注意，這里說的同一套資源未必是同一個資源，因為資源可能位于不同的目錄，但它一定是我們的應(yīng)用的資源，或許這樣來描述更準(zhǔn)確，在設(shè)備參數(shù)和顯示參數(shù)不變的情況下，不同的ContextImpl訪問到的是同一份資源。設(shè)備參數(shù)不變是指手機的屏幕和android版本不變，顯示參數(shù)不變是指手機的分辨率和橫豎屏狀態(tài)。也就是說，盡管Application、Activity、Service都有自己的ContextImpl，并且每個ContextImpl都有自己的mResources成員，但是由于它們的mResources成員都來自于唯一的ResourcesManager實例，所以它們看似不同的mResources其實都指向的是同一塊內(nèi)存(C語言的概念)，因此，它們的mResources都是同一個對象（在設(shè)備參數(shù)和顯示參數(shù)不變的情況下）。在橫豎屏切換的情況下且應(yīng)用中為橫豎屏狀態(tài)提供了不同的資源，處在橫屏狀態(tài)下的ContextImpl和處在豎屏狀態(tài)下的ContextImpl訪問的資源不是同一個資源對象。
代碼：單例模式的ResourcesManager類
public static ResourcesManager getInstance() {
synchronized (ResourcesManager.class) {
if (sResourcesManager == null) {
sResourcesManager = new ResourcesManager();
}
return sResourcesManager;
}
}
getApplication和getApplicationContext的區(qū)別
getApplication返回結(jié)果為Application，且不同的Activity和Service返回的Application均為同一個全局對象，在ActivityThread內(nèi)部有一個列表專門用于維護所有應(yīng)用的application：
final ArrayList<Application> mAllApplications = new ArrayList<Application>()
為什么說getApplication返回的都是同一個Application對象呢，是因為Activity和Service的getApplication返回的Application對象是由ActivityThread創(chuàng)建它們的時候通過它們的attach方法來傳遞給它們的，也就是說所有Activity和Service所持有的Application均是ActivityThread內(nèi)部的Application，由于一個應(yīng)用只有一個包信息，所以ActivityThread內(nèi)部只可能創(chuàng)建出一個Application，原因是當(dāng)執(zhí)行packageInfo.makeApplication的時候，如果已經(jīng)創(chuàng)建過Application了，packageInfo.makeApplication方法就不會再創(chuàng)建新的Application。關(guān)于一個應(yīng)用只有一個包信息，從代碼的邏輯來看的確是這樣的，在ActivityThread內(nèi)部同樣有一個列表專門用于維護所有應(yīng)用的包信息：
final ArrayMap<String, WeakReference<LoadedApk>> mPackages = new ArrayMap<String, WeakReference<LoadedApk>>()
getApplicationContext返回的也是Application對象，只不過返回類型為Context，看看它的實現(xiàn)
@Override
public Context getApplicationContext() {
return (mPackageInfo != null) ?
mPackageInfo.getApplication() : mMainThread.getApplication();
}
上面代碼中mPackageInfo是包含當(dāng)前應(yīng)用的包信息、比如包名、應(yīng)用的安裝目錄等，原則上來說，作為第三方應(yīng)用，包信息mPackageInfo不可能為空，在這種情況下，getApplicationContext返回的對象和getApplication是同一個。但是對于系統(tǒng)應(yīng)用，包信息有可能為空，具體就不深入研究了。從這種角度來說，對于第三方應(yīng)用，一個應(yīng)用只存在一個Application對象，且通過getApplication和getApplicationContext得到的是同一個對象，兩者的區(qū)別僅僅是返回類型不同。
應(yīng)用中Context的數(shù)量
到此已經(jīng)很明了了，一個應(yīng)用中Context的數(shù)量等于Activity的個數(shù) + Service的個數(shù) + 1，這個1為Application
