前言
網上關於 Context 的文章也已經有不少了，比如值得參考的有：
Android Context完全解析，你所不知道的Context的各種細節
但看了一下，發現還有值得討論的地方，比如這個等式：
Context個數 = Service 個數 + Activity 個數 + 1
老實說，我不明白這個等式有什么意義，而且還是錯的。首先多進程情況下，Application 對象就不止一個；其次，Activity、Service、Application 繼承自 ContextWrapper，它們自己就是一個 Context，里面又有一個 Base Context；最后，還有各種 outer context、display context 什么的，這部分沒深入研究過，但 Context 的數量絕對大於上述等式的兩倍了。
上面這部分算一個討論，下面正式進入正題。
Context 家族
Context 本身是一個抽象類，主要實現類為 ContextImpl，另外有子類 ContextWrapper 和 ContextThemeWrapper，這兩個子類都是 Context 的代理類，主要區別是 ContextThemeWrapper 有自己的主題資源。它們繼承關系如下：
Context 有什么用？
如果要弄清楚 “某個類有什么用” 這樣的問題，其實很簡單，看一下它提供了什么接口就知道了，下面列舉一些主要的：
/**
* 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.
*/
public abstract class Context {
// 四大組件相關
public abstract void startActivity(@RequiresPermission Intent intent);
public abstract void sendBroadcast(@RequiresPermission Intent intent);
public abstract Intent registerReceiver(@Nullable BroadcastReceiver receiver,
IntentFilter filter);
public abstract void unregisterReceiver(BroadcastReceiver receiver);
public abstract ComponentName startService(Intent service);
public abstract boolean stopService(Intent service);
public abstract boolean bindService(@RequiresPermission Intent service,
@NonNull ServiceConnection conn, @BindServiceFlags int flags);
public abstract void unbindService(@NonNull ServiceConnection conn);
public abstract ContentResolver getContentResolver();
// 獲取系統/應用資源
public abstract AssetManager getAssets();
public abstract Resources getResources();
public abstract PackageManager getPackageManager();
public abstract Context getApplicationContext();
public abstract ClassLoader getClassLoader();
public final @Nullable <T> T getSystemService(@NonNull Class<T> serviceClass) { ... }
public final String getString(@StringRes int resId) { ... }
public final int getColor(@ColorRes int id) { ... }
public final Drawable getDrawable(@DrawableRes int id) { ... }
public abstract Resources.Theme getTheme();
public abstract void setTheme(@StyleRes int resid);
public final TypedArray obtainStyledAttributes(@StyleableRes int[] attrs) { ... }
// 獲取應用相關信息
public abstract ApplicationInfo getApplicationInfo();
public abstract String getPackageName();
public abstract Looper getMainLooper();
public abstract int checkPermission(@NonNull String permission, int pid, int uid);
// 文件相關
public abstract File getSharedPreferencesPath(String name);
public abstract File getDataDir();
public abstract boolean deleteFile(String name);
public abstract File getExternalFilesDir(@Nullable String type);
public abstract File getCacheDir();
...
public abstract SharedPreferences getSharedPreferences(String name, @PreferencesMode int mode);
public abstract boolean deleteSharedPreferences(String name);
// 數據庫相關
public abstract SQLiteDatabase openOrCreateDatabase(...);
public abstract boolean deleteDatabase(String name);
public abstract File getDatabasePath(String name);
...
// 其它
public void registerComponentCallbacks(ComponentCallbacks callback) { ... }
public void unregisterComponentCallbacks(ComponentCallbacks callback) { ... }
...
}
public interface ComponentCallbacks {
void onConfigurationChanged(Configuration newConfig);
void onLowMemory();
}
結合注釋，可以發現，Context 就相當於 Application 的大管家，主要負責：
- 四大組件的交互，包括啟動 Activity、Broadcast、Service，獲取 ContentResolver 等
- 獲取系統/應用資源，包括 AssetManager、PackageManager、Resources、System Service 以及 color、string、drawable 等
- 文件，包括獲取緩存文件夾、刪除文件、SharedPreference 相關等
- 數據庫（SQLite）相關，包括打開數據庫、刪除數據庫、獲取數據庫路徑等
- 其它輔助功能，比如設置 ComponentCallbacks，即監聽配置信息改變、內存不足等事件的發生
ContextImpl 、ContextWrapper、ContextThemeWrapper 有什么區別？
ContextWrapper
先看 ContextWrapper：
/**
* Proxying implementation of Context that simply delegates all of its calls to
* another Context. Can be subclassed to modify behavior without changing
* the original Context.
*/
public class ContextWrapper extends Context {
// 注意這個成員
Context mBase;
public ContextWrapper(Context base) {
mBase = base;
}
protected void attachBaseContext(Context base) {
if (mBase != null) {
throw new IllegalStateException("Base context already set");
}
mBase = base;
}
// 這就是經常讓人產生疑惑的 Base Context 了
public Context getBaseContext() {
return mBase;
}
// 下面這些方法全都直接通過 mBase 完成
@Override
public AssetManager getAssets() {
return mBase.getAssets();
}
@Override
public Resources getResources() {
return mBase.getResources();
}
@Override
public PackageManager getPackageManager() {
return mBase.getPackageManager();
}
...
}
可以看到，ContextWrapper 實際上就是 Context 的代理類而已，所有的操作都是通過內部成員 mBase 完成的，另外，Activity、Service 的 getBaseContext 返回的就是這個 mBase。
ContextThemeWrapper
接着看 ContextThemeWrapper，這個類的代碼並不多，主要看 Resource 和 Theme 相關的：
/**
* A context wrapper that allows you to modify or replace the theme of the
* wrapped context.
*/
public class ContextThemeWrapper extends ContextWrapper {
private int mThemeResource;
private Resources.Theme mTheme;
private LayoutInflater mInflater;
private Configuration mOverrideConfiguration;
private Resources mResources;
public ContextThemeWrapper() {
super(null);
}
public ContextThemeWrapper(Context base, @StyleRes int themeResId) {
super(base);
mThemeResource = themeResId;
}
public ContextThemeWrapper(Context base, Resources.Theme theme) {
super(base);
mTheme = theme;
}
@Override
protected void attachBaseContext(Context newBase) {
super.attachBaseContext(newBase);
}
// 在 Recource 初始化之前，傳入配置信息
public void applyOverrideConfiguration(Configuration overrideConfiguration) {
if (mResources != null) {
throw new IllegalStateException(...);
}
if (mOverrideConfiguration != null) {
throw new IllegalStateException(...);
}
mOverrideConfiguration = new Configuration(overrideConfiguration);
}
public Configuration getOverrideConfiguration() {
return mOverrideConfiguration;
}
// 沒有重寫 setResource，即 setResource 行為和父類一樣
@Override
public Resources getResources() {
return getResourcesInternal();
}
private Resources getResourcesInternal() {
if (mResources == null) {
if (mOverrideConfiguration == null) {
mResources = super.getResources();
} else {
// 根據配置信息初始化 Resource
// 注意，這里創建了另一個和 Base Context 不同的 Resource
final Context resContext = createConfigurationContext(mOverrideConfiguration);
mResources = resContext.getResources();
}
}
return mResources;
}
@Override
public void setTheme(int resid) {
if (mThemeResource != resid) {
mThemeResource = resid;
initializeTheme();
}
}
private void initializeTheme() {
final boolean first = mTheme == null;
if (first) {
// 根據 Resource 獲取 Theme
mTheme = getResources().newTheme();
// 復制內容
final Resources.Theme theme = getBaseContext().getTheme();
if (theme != null) {
mTheme.setTo(theme);
}
}
onApplyThemeResource(mTheme, mThemeResource, first);
}
protected void onApplyThemeResource(Resources.Theme theme, int resId, boolean first) {
theme.applyStyle(resId, true);
}
@Override
public Resources.Theme getTheme() {
// 只會初始化一次
if (mTheme != null) {
return mTheme;
}
mThemeResource = Resources.selectDefaultTheme(mThemeResource,
getApplicationInfo().targetSdkVersion);
initializeTheme();
return mTheme;
}
...
}
結合注釋及源碼，可以發現，相比 ContextWrapper，ContextThemeWrapper 有自己的另外 Resource 以及 Theme 成員，並且可以傳入配置信息以初始化自己的 Resource 及 Theme。即 Resource 以及 Theme 相關的行為不再是直接調用 mBase 的方法了，也就說，ContextThemeWrapper 和它的 mBase 成員在 Resource 以及 Theme 相關的行為上是不同的。
ContextImpl
下面看一下 ContextImpl 有關 Theme 以及 Resource 的部分，以分析它和 ContextThemeWrapper 的區別：
/**
* Common implementation of Context API, which provides the base
* context object for Activity and other application components.
*/
class ContextImpl extends Context {
private int mThemeResource = 0;
private Resources.Theme mTheme = null;
private @NonNull Resources mResources;
// 用於創建 Activity Context
static ContextImpl createActivityContext(...) {
ContextImpl context = new ContextImpl(...);
context.setResources(resourcesManager.createBaseActivityResources(...));
return context;
}
// 用於創建 Application Context、Service Context
static ContextImpl createAppContext(ActivityThread mainThread, LoadedApk packageInfo) {
ContextImpl context = new ContextImpl(...);
context.setResources(packageInfo.getResources());
return context;
}
private static Resources createResources(...) {
return ResourcesManager.getInstance().getResources(...);
}
// ContextThemeWrapper 沒有重寫父類的 setResources
// 因此會調用 mBase 的 setResources，即和 ContextImpl 的行為一樣
void setResources(Resources r) {
if (r instanceof CompatResources) {
((CompatResources) r).setContext(this);
}
mResources = r;
}
@Override
public Resources getResources() {
return mResources;
}
/* ---------- 主題相關 ------------ */
@Override
public void setTheme(int resId) {
synchronized (mSync) {
if (mThemeResource != resId) {
mThemeResource = resId;
initializeTheme();
}
}
}
// 直接創建一個 Themem 對象，相比 ContextThemeWrapper，少了一部分內容
private void initializeTheme() {
if (mTheme == null) {
mTheme = mResources.newTheme();
}
mTheme.applyStyle(mThemeResource, true);
}
@Override
public Resources.Theme getTheme() {
synchronized (mSync) {
// 和 ContextThemeWrapper 基本一樣
if (mTheme != null) {
return mTheme;
}
mThemeResource = Resources.selectDefaultTheme(mThemeResource,
getOuterContext().getApplicationInfo().targetSdkVersion);
initializeTheme();
return mTheme;
}
}
}
從代碼中可以看出，ContextImpl 和 ContextThemeWrapper 最大的區別就是沒有一個 Configuration 而已，其它的行為大致是一樣的。另外，ContextImpl 可以用於創建 Activity、Service 以及 Application 的 mBase 成員，這個 Base Context 時除了參數不同，它們的 Resource 也不同。需要注意的是，createActivityContext 等方法中 setResource 是 mBase 自己調用的，Activity、Service 以及 Application 本身並沒有執行 setResource。
小結
-
ContextWrapper、ContextThemeWrapper 都是 Context 的代理類，二者的區別在於 ContextThemeWrapper 有自己的 Theme 以及 Resource，並且 Resource 可以傳入自己的配置初始化
-
ContextImpl 是 Context 的主要實現類，Activity、Service 和 Application 的 Base Context 都是由它創建的，即 ContextWrapper 代理的就是 ContextImpl 對象本身
-
ContextImpl 和 ContextThemeWrapper 的主要區別是， ContextThemeWrapper 有 Configuration 對象，Resource 可以根據這個對象來初始化
-
Service 和 Application 使用同一個 Recource，和 Activity 使用的 Resource 不同
Activity Context、Service Context、Application Context、Base Context 有什么區別？
Activity Context
先看 Activity，Activity 在啟動時，最終會執行 ActivityThread 的 performLaunchActivitiy：
public final class ActivityThread {
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
...
// 這個 Context 將會作為 Activity 的 Base Context
ContextImpl appContext = createBaseContextForActivity(r);
Activity activity = null;
try {
ClassLoader cl = appContext.getClassLoader();
// 創建 Activity
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
StrictMode.incrementExpectedActivityCount(activity.getClass());
} catch (Exception e) {
...
}
try {
// 創建 Application
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
if (activity != null) {
// 初始化 Activity，注意參數 appContext
activity.attach(appContext, ...);
...
}
} catch (...) {
...
}
return activity;
}
private ContextImpl createBaseContextForActivity(ActivityClientRecord r) {
ContextImpl appContext = ContextImpl.createActivityContext(...);
...
}
}
可以看到，Activity 的 Base Context 就是上面分析過的 ContextImpl 的 createActivityContext 創建的。
同時，Service 的 Base Context 的創建過程和 Application 一樣，調用的都是 ContextImpl 的 createAppContext，即 Service Context 和 Application Context 的 Resource 是相同的。因此這里跳過 Service，下面看一下 Application Context。
Application Context
在上面 ActivityThread 的 performLaunchActivity 方法中，可以看到一個 makeApplication 的調用，它是 LoaedApk 的方法：
public final class LoadedApk {
private Application mApplication;
public Application makeApplication(boolean forceDefaultAppClass, Instrumentation instrumentation) {
if (mApplication != null) {
return mApplication;
}
Application app = null;
try {
// 創建 Base Context
ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
// 創建 Application 並設置 Base Context
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);
appContext.setOuterContext(app);
} catch (Exception e) {
...
}
// Application 創建成功，賦值給 mApplication
mApplication = app;
...
return app;
}
// 獲取 mApplication
Application getApplication() {
return mApplication;
}
}
public class Application extends ContextWrapper implements ComponentCallbacks2 {
/* package */ final void attach(Context context) {
// 調用父類的 attachBaseContext 以設置 mBase
attachBaseContext(context);
}
}
可以看到，Instrumentation 是使用反射的方法創建 Application 對象，創建完畢后，會執行 Application 的 attach 方法設置 mBase 成員。
Application 及其 Base Context 的創建過程我們了解了，接下來看一下 getApplicationContext 的實現：
class ContextImpl extends Context {
ActivityThread mMainThread;
LoadedApk mPackageInfo;
@Override
public Context getApplicationContext() {
return (mPackageInfo != null) ?
mPackageInfo.getApplication() : mMainThread.getApplication();
}
}
從代碼中可以看出，getApplicationContext 的返回值可能有兩個：第一個是 LoadedApk 的 getApplication 方法，這個方法的返回值就是剛剛創建的 Application 對象；第二個是 ActivityThread 的 getApplication 方法：
public final class ActivityThread {
Application mInitialApplication;
public Application getApplication() {
return mInitialApplication;
}
public static ActivityThread systemMain() {
// 創建 ActivityThread
ActivityThread thread = new ActivityThread();
thread.attach(true);
return thread;
}
private void attach(boolean system) {
mSystemThread = system;
if (!system) {
...
} else {
try {
mInstrumentation = new Instrumentation();
// 注意參數 getSystemContext().mPackageInfo
ContextImpl context = ContextImpl.createAppContext(
this, getSystemContext().mPackageInfo);
// 創建 Application
mInitialApplication = context.mPackageInfo.makeApplication(true, null);
mInitialApplication.onCreate();
} catch (Exception e) {
...
}
}
...
}
}
ActivityThread 中的 mInitialApplication 是在 systemMain 方法執行時創建的，而這個方法又是 SystemServer 啟動時調用的，結合參數 getSystemContext().mPackageInfo，因此個人推測 mInitialApplication 對應的是系統的某個 apk，即系統級別的 Application，但具體是不是這樣，目前還沒有深入研究過，有興趣的可以自己研究。
為什么不推薦使用 Base Context？
一般情況下，使用代理而不直接使用某個對象，目的可能有兩個：
- 定制自己的行為
- 不影響原對象
其中 Servcie 和 Application 的父類 ContextWrapper 完全沒有自定義的行為，而 Activity 的父類 ContextThemeWrapper 則自定義了 Resource 以及 Theme 的相關行為，因此，個人理解：
- 對於 Service 和 Application 而言，不推薦使用 Base Context，是擔心用戶修改了 Base Context 而導致錯誤的發生
- 對於 Activity 而言，除了擔心用戶的修改之外，Base Context 和 Activity 本身對於 Reource 以及 Theme 的相關行為是不同的（如果應用了 Configuration 的話），使用 Base Context 可能會出現無法預期的現象
對於 Activity 的 getResource 問題，我寫了一份代碼來驗證：
public class MainActivity extends AppCompatActivity {
private Configuration mOverrideConfiguration;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Log.i(TAG, "getResources: " + getResources() + ", getBaseContext().getResources():"
+ getBaseContext().getResources());
}
// 因為 Android 會在 onCreate 之前自動調用 getResource
// 因此需要在這里執行 applyOverrideConfiguration
@Override
public Resources getResources() {
if (mOverrideConfiguration == null) {
mOverrideConfiguration = new Configuration();
applyOverrideConfiguration(mOverrideConfiguration);
}
return super.getResources();
}
}
輸出（我用的是小米手機）：
getResources: android.content.res.MiuiResources@3c660a7,
getBaseContext().getResources():android.content.res.MiuiResources@5143954
可以看到，就像源碼顯示的那樣，應用了 Configuration 之后，Activity 的 getResource 方法返回的和 getBaseContext().getResources() 方法返回的不是同一個對象
小結
- Activity、Service 和 Application 的 Base Context 都是由 ContextImpl 創建的，且創建的都是 ContextImpl 對象，即它們都是 ContextImpl 的代理類
- getApplicationContext 返回的就是 Application 對象本身，一般情況下它對應的是應用本身的 Application 對象，但也可能是系統的某個 Application
- 對於 Service 和 Application 而言，不推薦使用 Base Context，是擔心用戶修改了 Base Context 而導致錯誤的發生
- 對於 Activity 而言，除了擔心用戶的修改之外，Base Context 和 Activity 本身對於 Reource 以及 Theme 的相關行為是不同的（如果應用了 Configuration 的話），使用 Base Context 可能會出現無法預期的現象
總結
Context 的繼承關系如下：
Context 相當於 Application 的大管家，主要負責：
- 四大組件的交互，包括啟動 Activity、Broadcast、Service，獲取 ContentResolver 等
- 獲取系統/應用資源，包括 AssetManager、PackageManager、Resources、System Service 以及 color、string、drawable 等
- 文件，包括獲取緩存文件夾、刪除文件、SharedPreference 相關等
- 數據庫（SQLite）相關，包括打開數據庫、刪除數據庫、獲取數據庫路徑等
- 其它輔助功能，比如設置 ComponentCallbacks，即監聽配置信息改變、內存不足等事件的發生
ContextWrapper、ContextThemeWrapper、ContextImpl 的區別：
- ContextWrapper、ContextThemeWrapper 都是 Context 的代理類，二者的區別在於 ContextThemeWrapper 有自己的 Theme 以及 Resource，並且 Resource 可以傳入自己的配置初始化
- ContextImpl 是 Context 的主要實現類，Activity、Service 和 Application 的 Base Context 都是由它創建的，即 ContextWrapper 代理的就是 ContextImpl 對象本身
- ContextImpl 和 ContextThemeWrapper 的主要區別是， ContextThemeWrapper 有 Configuration 對象，Resource 可以根據這個對象來初始化
Activity Context、Service Context、Application Context、Base Context 的區別：
- Activity、Service 和 Application 的 Base Context 都是由 ContextImpl 創建的，且創建的都是 ContextImpl 對象，即它們都是 ContextImpl 的代理類
- Service 和 Application 使用同一個 Recource，和 Activity 使用的 Resource 不同
- getApplicationContext 返回的就是 Application 對象本身，一般情況下它對應的是應用本身的 Application 對象，但也可能是系統的某個 Application