什麼是Android Context？

一個Context意味著一個場景，一個場景就是我們和軟體進行互動的一個過程。比如和妹紙約會的月下小橋，比如當你使用微信的時候，場景包括聊天介面、通訊錄、朋友圈，以及背後的一些資料。

那麼從安卓程式的角度來看，Context是什麼？其實一個Activity就是一個Context，一個Service也是一個Context。

一個應用程式可以認為是一個約會環境，使用者在這個環境中會切換到不同的場景，比如先去有情調的飯店吃飯，再去電影院看個電影，然後再去xxx（此處省略一萬字…）。

Activity類的確是基於Context，而Service類也是基於Context。Activity除了基於Context類外，還實現了一些其他重要的介面，從架構設計的角度看，interface僅僅是某些功能，而extends才是類的本質，即Activity的本質是一個Context，其所實現的其他介面只是為了擴充Context的功能而已，擴充後的類稱之為一個Activity或Service。

一個應用程式中應該有多少個Context物件

我們在應用程式開發中經常會呼叫Context的一些方法，這些方法看起來似乎會返回一些全域性的物件，而不僅僅是某個Activity，可能會有點疑問，一個應用程式到底有多少個Context物件呢？比如，Context.getResources（）返回該應用程式所對應的Resource類物件，無論從哪個Activity中呼叫，都會返回同一個Resource物件。

• 一個Activity就是一個場景（Context），一個Service也是一個場景，所以，應用程式中有多少個Activity或者Service就會有多少個Context物件，也就是有多少個場景。
• getResource（）等方法返回的是同一個全域性物件。

Context 繼承關係是怎麼樣的呢？

Context類本身是一個純abstract類。為了使用方便又定義了Context包裝類-ContextWrapper，穿上了一身裝備顯得也比較強大，ContextWrapper建構函式中必須包含一個真正的Context引用，同時ContextWrapper中有attachBaseContext（）用於給ContextWrapper物件中指定真正的Context物件。

ContextThemeWrapper內部包含了與主題相關的介面，這裡的主題就是指在AndroidManifest.xml中通過android：theme為Application或者Activity指定的主題。

只有Activity才需要主題，Service默默的後臺工作者不需要穿的那麼鮮豔，所以Service直接繼承於ContextWrapper。

ContextImpl類真正實現了Context中所有的函式，真正的八塊腹肌，我們所呼叫的各種Context類的方法其實實現均來自於該類。

什麼時候建立的Context？

每一個應用程式在客戶端都是從ActivityThread類開始的，建立Context物件也是在該類中完成，具體建立ContextImpl類的地方一共有6處：

• PackageInfo.makeApplication（）
• performLaunchActivity（）
• handleCreateBackupAgent（）
• handleCreateService（）
• handleBindApplication（）
• attach（）

其中attach（）方法僅在Framework程序啟動時呼叫，應用程式執行時不會呼叫到該方法。

Application對應的Context

程式第一次啟動時，會輾轉呼叫到makeApplication（）方法。具體程式碼如下：

ContextImpl appContext = new ContextImpl();
appContext.init(this,null,mActivityThread);
....
appContext.setOuterContext(app);

Activity對應的Context

啟動Activity時，Ams會通過IPC呼叫到ActivityThread的scheduleLaunchActivity（）方法，該方法包含兩種引數。一種是ActivityInfo，這是一個實現了Parcelable介面的資料類，意味著該物件是Ams建立的，並通過IPC傳遞到ActivityThread；另一種是其他的一些引數。

scheduleLaunchActivity（）方法中會根據以上兩種引數構造一個本地ActivityRecord資料類，ActivityThread內部會為每一個Activity建立一個ActivityRecord物件，並使用這些資料物件來管理Activity。

然後會呼叫handleLaunchActivity（），再呼叫performLaunchActivity（），該方法中建立ContextImpl的程式碼如下：

ContextImpl appContext = new ContextImpl();
appContext.init(r.packageInfo,r.token,this);
appContext.setOuterContext(activity);

在performLaunchActivity（）開始執行時，會為r.packageInfo變數賦值。r.packageInfo物件的PackageInfo物件和Application對應的packageInfo物件是同一個。

Service對應的Context

啟動Service時，Ams會通過IPC呼叫到ActivityThread的scheduleCreateService（）方法，該方法也包含兩種引數。第一種是ServiceInfo，這是實現了一個Parcelable介面的資料類，該物件由AmS建立，並通過IPC傳遞到ActivityThread內部；第二種是其他引數。

在scheduleCreateService（）方法中，會使用以上兩種引數構造一個CreateServiceData的資料物件，ActivityThread會為其所包含的每一個Service建立該資料物件，並通過這些物件來管理Service。

然後在執行handleCreateService（）方法，建立ContextImpl物件程式碼如下：

ContextImpl appContext = new ContextImpl();
appContext.init(packageInfo,null,this);
...
appContext.setOuterContext(service);

Service對應的Context物件內部的mPackageInfo與Activity、Application中是完全相同的。

這幾個Context之間的關係

從以上可以看出，建立Context物件的過程基本上是相同的，不同的僅僅是針對Application、Activity、Service使用了不同的資料物件。

一個應用程式包含的Context個數應該為：Context個數 = Service個數+Activity個數+1，最後的1是Application類本身也會對應一個Context物件。

應用程式中包含多個ContextImpl物件，而內部變數mPackageInfo卻指向同一個PackageInfo物件，這種設計結構一般意味著ContextImpl是一種輕量級類，而PackageInfo是一個重量級類。事實上確實是這樣，ContextImpl中的大多數進行包操作的重量級函式實際上都是轉向了mPackageInfo物件相應的方法，也就是事實上呼叫了同一個PackageInfo物件。

如有問題請留言，轉載請註明出處

備註：以上部分思想來自於《Android核心剖析》