Android全面解析之Context機制
阿新 • • 發佈：2020-12-11
## 前言
很高興遇見你~ 歡迎閱讀我的文章。
在文章[Android全面解析之由淺及深Handler訊息機制](https://blog.csdn.net/weixin_43766753/article/details/108968666)中討論到，Handler可以：
> 避免我們自己去手動寫 死迴圈和輸入阻塞 來不斷獲取使用者的輸入以及避免執行緒直接結束，而是採用事務驅動型設計，使用Handler訊息機制，讓AMS可以控制整個程式的執行邏輯。
這是關於android程式在設計上更加重要的一部分，不太瞭解的讀者可以前往閱讀了解一下。而當我們知道android程式的程式是通過main方法跑起來的，然後通過handler機制來控制程式的執行，那麼四大元件和普通的Java類到底有什麼區別？為什麼同樣是Java類，而ActivityThread、Activity等等這些類就顯得那麼特殊呢？我們的程式碼、寫的佈局是通過什麼路徑使用系統資源把介面展示在螢幕上的？這一切就涉及到我們今天的主角：Context。
## 什麼是Context
回想一下最初學習Android開發的時候，第一用到context是什麼時候？如果你跟我一樣是通過郭霖的《第一行程式碼》來入門android，那麼一般是Toast。Toast的常規用法是：
```kotlin
Toast.makeText(this, "我是toast", Toast.LENGTH_SHORT).show()
```
當初也不知道什麼是Context，只知道他需要一個context型別，把activity物件傳進去即可。從此context貫穿在我開發過程的方方面面，但我始終不知道這個context到底有什麼用？為什麼要這個物件？我們首先來看官方對於Context類的註釋：
```java
/**
* 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 {...}
```
`關於應用程式環境的全域性資訊的介面。 這是一個抽象類，它的實現是由Android系統提供。 它允許訪問特定應用的資源和類，以及向上呼叫應用程式級的操作，如啟動活動，廣播和接收Intent等`。
可以看到Context最重要的作用就是獲取全域性訊息、訪問系統資源、呼叫應用程式級的操作。可能對於這些作用沒什麼印象，想一下，如果沒有context，我們如何做到以下操作：
- 彈出一個toast
- 啟動一個activity
- 獲取程式佈局檔案、drawable檔案等
- 訪問資料庫
這些平時看似簡單的操作，一旦失去了context將無法執行。這些行為都有一個共同點：**需要與系統交匯**。四大元件為什麼配為元件，而我們的寫的就只能叫做一個普通的Java類，正是因為context的這些功能讓四大元件有了不一樣的能力。簡單來說，context是：
> 應用程式和系統之間的橋樑，應用程式訪問系統各種資源的介面。
我們一般使用context最多的是兩種情景：直接呼叫context的方法和呼叫介面時需要context引數。這些行為都意味著我們需要訪問系統相關的資源。
那context是從哪裡來的？AMS！AMS是系統級程序，擁有訪問系統級操作的權利，應用程式的啟動受AMS的調控，在程式啟動的過程中，AMS會把一個“憑證”通過跨程序通訊給到我們的應用程式，我們的程式會把這個“憑證”封裝成context，並提供一系列的介面，這樣我們的程式也就可以很方便地訪問系統資源了。這樣的好處是：
> 系統可以對應用程式級的操作進行調控，限制各種情景下的許可權，同時也可以防止惡意攻擊。
如Application類的context和Activity的context權利是不一樣的，生命週期也不一樣。對於想要作業系統攻擊使用者的程式也進行了阻止，沒有獲得允許的Java類沒有任何權利，而Activity開放給使用者也只有部分有限的權利。而我們開發者獲取context的路徑，也只有從activity、application等元件獲取。
因而，什麼是Context？Context是應用程式與系統之間溝通的橋樑，是應用程式訪問系統資源的介面，同時也是系統給應用程式的一張“許可權憑證”。有了context，一個Java類才可以被稱之為元件。
## Context家族
上一部分我們瞭解什麼是context以及context的重要性，這一部分就來了解一下context在原始碼中的子類繼承情況。先看一個圖：
依然，我們專注於Activity的建立流程，其他的讀者可閱讀[Activity啟動流程](https://blog.csdn.net/weixin_43766753/article/details/107746968)這篇文章瞭解。和Application一樣，Activity的建立時由AMS來控制的，AMS嚮應用程式程序傳送訊息來執行具體的啟動邏輯。最後會執行到`handleLaunchActivity`這個方法：
```java
ActivityThread.class(api29)
public Activity handleLaunchActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions, Intent customIntent) {
...
final Activity a = performLaunchActivity(r, customIntent);
...
return a;
}
```
最終的就是中間這句程式碼，進入看原始碼：
```java
ActivityThread.class(api29)
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
...
// 建立Activity的ContextImpl
ContextImpl appContext = createBaseContextForActivity(r);
Activity activity = null;
try {
// 利用類載入建立activity例項
java.lang.ClassLoader cl = appContext.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
...
}
try {
// 建立Application
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
...
if (activity != null) {
...
// 把activity設定給context，這樣context也可以訪問到activity了
appContext.setOuterContext(activity);
// 呼叫activity的attach方法把contextImpl設定給activity
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor, window, r.configCallback,
r.assistToken);
int theme = r.activityInfo.getThemeResource();
if (theme != 0) {
// 設定主題
activity.setTheme(theme);
}
...
// 回撥onCreate方法
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
...
}
...
}
...
return activity;
}
```
程式碼的邏輯不是很複雜，首先建立Activity的ContextImpl，利用類載入建立activity例項，然後再通過LoadedApk建立Application，這個方法在前面我們講過，如果Application已經建立會直接返回已經建立的物件。然後把activity設定給context，這樣context也可以訪問到activity了。這裡要注意，前面講到使用Activity的context會造成記憶體洩露，那麼可不可以用Activity的contextImpl物件呢？答案是不可以，因為**ContextImpl也會持有Activity的引用**，需要特別注意一下。隨後再呼叫activity的attach方法把contextImpl設定給activity。後面是設定主題和回撥onCreate方法，我們就不深入了，主要看看attach方法：
```java
Activity.class(api29)
final void attach(Context context,...) {
attachBaseContext(context);
...
}
```
這裡省略了大量的程式碼，只保留關鍵一句：`attachBaseContext`，是不是很熟悉？呼叫ContextWrapper的方法來給mBase屬性賦值，和前面Application是一樣的，就不再贅述。
#### Service
依然只關注關鍵程式碼流程，先看Service的啟動流程圖：
Service的建立過程也是受AMS的控制，同樣我們看到建立Service的那一步，最終會呼叫到`handleCreateService`這個方法：
```java
private void handleCreateService(CreateServiceData data) {
...
LoadedApk packageInfo = getPackageInfoNoCheck(
data.info.applicationInfo, data.compatInfo);
Service service = null;
try {
java.lang.ClassLoader cl = packageInfo.getClassLoader();
service = packageInfo.getAppFactory()
.instantiateService(cl, data.info.name, data.intent);
}
...
try {
...
ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
context.setOuterContext(service);
Application app = packageInfo.makeApplication(false, mInstrumentation);
service.attach(context, this, data.info.name, data.token, app,
ActivityManager.getService());
service.onCreate();
mServices.put(data.token, service);
...
}
...
}
```
Service的邏輯就相對簡單了，同樣建立service例項，再建立contextImpl，最後把contextImpl通過Service的attach方法賦值給mBase屬性，最後回撥Service的onCreate方法。過程和上面的很像，這裡就不再深入講了，感興趣的讀者可自行去閱讀原始碼，也可以閱讀[Android中Service的啟動與繫結過程詳解（基於api29）](https://blog.csdn.net/weixin_43766753/article/details/107881248)這篇文章瞭解Service的詳細內容。
#### Broadcast
Broadcast和上面的元件不同，他並不是繼承自Context，所以他的Context是需要通過上述三者來給予。我們一般使用廣播的context是在接受器中，如：
```kotlin
class MyClass :BroadcastReceiver() {
override fun onReceive(context: Context?, intent: Intent?) {
TODO("use context")
}
}
```
那麼onReceive的context物件是從哪裡來的呢？同樣我們先看廣播接收器的註冊流程：
同樣，詳細的廣播相關工作流程可以閱讀[Android廣播Broadcast的註冊與廣播原始碼過程詳解（基於api29）](https://blog.csdn.net/weixin_43766753/article/details/108066203)這篇文章瞭解。因為在建立Receiver的時候並沒有傳入context，所以我們需要追蹤他的註冊流程，看看在哪裡獲取了context。我們先看到ContextImpl的`registerReceiver`方法：
```java
ContextImpl.class(api29)
public Intent registerReceiver(BroadcastReceiver receiver, IntentFilter filter,
String broadcastPermission, Handler scheduler) {
// 注意引數
return registerReceiverInternal(receiver, getUserId(),
filter, broadcastPermission, scheduler, getOuterContext(), 0);
}
```
registerReceiver方法最終會來到這個過載方法，我們可以注意到，這裡有個`getOuterContext`，這個是什麼？還記得Activity的context建立過程嗎？這個方法獲取的就是activity本身。我們繼續看下去：
```java
ContextImpl.class(api29)
private Intent registerReceiverInternal(BroadcastReceiver receiver, int userId,
IntentFilter filter, String broadcastPermission,
Handler scheduler, Context context, int flags) {
IIntentReceiver rd = null;
if (receiver != null) {
if (mPackageInfo != null && context != null) {
...
rd = mPackageInfo.getReceiverDispatcher(
receiver, context, scheduler,
mMainThread.getInstrumentation(), true);
}
...
}
...
}
```
這裡利用context建立了ReceiverDispatcher，我們繼續深入看：
```java
LoadedApk.class(api29)
public IIntentReceiver getReceiverDispatcher(BroadcastReceiver r,
Context context, Handler handler,
Instrumentation instrumentation, boolean registered) {
synchronized (mReceivers) {
LoadedApk.ReceiverDispatcher rd = null;
...
if (rd == null) {
rd = new ReceiverDispatcher(r, context, handler,
instrumentation, registered);
...
}
...
}
}
ReceiverDispatcher.class(api29)
ReceiverDispatcher(..., Context context,...) {
...
mContext = context;
...
}
```
這裡確實把receiver和context建立了ReceiverDispatcher，嗯?怎麼沒有給Receiver?其實這涉及到廣播的內部設計結構。Receiver是沒有跨程序通訊能力的，而廣播需要AMS的調控，所以必須有一個可以跟AMS溝通的物件，這個物件是InnerReceiver，而ReceiverDispatcher就是負責維護他們兩個的聯絡，如下圖：
而onReceive方法也是由ReceiverDispatcher回撥的，最後我們再看到回撥onReceive的那部分程式碼：
```java
ReceiverDispatcher.java/Args.class;
public final Runnable getRunnable() {
return () -> {
...;
try {
...;
// 可以看到這裡回調了receiver的方法，這樣整個接收廣播的流程就走完了。
receiver.onReceive(mContext, intent);
}
}
}
```
Args是Receiver的內部類，mContext就是在建立ReceiverDispatcher時傳入的物件，到這裡我們就知道這個物件確實是Activity了。
但是，，**不一定每個都是Activity**。在原始碼中我們知道是通過`getOuterContext`來獲取context，如果是通過別的context註冊廣播，那麼對應的物件也就不同了，只是我們一般都是在Activity中建立廣播，所以這個context一般是activity物件。
#### ContentProvider
ContextProvider我們用的就比較少了，內容提供器主要是用於應用間內容共享的。雖然ContentProvider是由系統建立的，但是他本身並不屬於Context家族體系內，所以他的context也是從其他獲取的。老樣子，先看ContentProvider的建立流程：
咦？這不是Application建立的流程圖嗎？是的，ContentProvider是伴隨著應用啟動被建立的，來看一張更加詳細的流程圖：
我們把目光聚集到ContentProvider的建立上，也就是`installContentProviders`方法。同樣，詳細的ContentProvider工作流程可以訪問[Android中ContentProvider的啟動與請求原始碼流程詳解（基於api29）](https://blog.csdn.net/weixin_43766753/article/details/108110605)這篇文章。`installContentProviders`是在handleBindApplication中被呼叫的，我們看到呼叫這個方法的地方：
```java
private void handleBindApplication(AppBindData data) {
try {
// 建立Application
app = data.info.makeApplication(data.restrictedBackupMode, null);
...
if (!data.restrictedBackupMode) {
if (!ArrayUtils.isEmpty(data.providers)) {
// 安裝ContentProvider
installContentProviders(app, data.providers);
}
}
}
```
可以看到這裡傳入了application物件，我們繼續看下去：
```java
private void installContentProviders(
Context context, List providers) {
final ArrayList results = new ArrayList<>();
for (ProviderInfo cpi : providers) {
...
ContentProviderHolder cph = installProvider(context, null, cpi,
false /*noisy*/, true /*noReleaseNeeded*/, true /*stable*/);
...
}
...
}
```
這裡呼叫了installProvider，繼續往下看：
```java
private ContentProviderHolder installProvider(Context context,
ContentProviderHolder holder, ProviderInfo info,
boolean noisy, boolean noReleaseNeeded, boolean stable) {
ContentProvider localProvider = null;
IContentProvider provider;
if (holder == null || holder.provider == null) {
...
// 這裡c最終是由context構造的
Context c = null;
ApplicationInfo ai = info.applicationInfo;
if (context.getPackageName().equals(ai.packageName)) {
c = context;
}
...
try {
// 建立ContentProvider
final java.lang.ClassLoader cl = c.getClassLoader();
LoadedApk packageInfo = peekPackageInfo(ai.packageName, true);
...
localProvider = packageInfo.getAppFactory()
.instantiateProvider(cl, info.name);
provider = localProvider.getIContentProvider();
...
// 把context設定給ContentProvider
localProvider.attachInfo(c, info);
}
...
}
...
}
```
這裡最重要的一行程式碼是`localProvider.attachInfo(c, info);`，在這裡把context設定給了ContentProvider，我們再深入一點看看：
```java
ContentProvider.class(api29)
public void attachInfo(Context context, ProviderInfo info) {
attachInfo(context, info, false);
}
private void attachInfo(Context context, ProviderInfo info, boolean testing) {
...
if (mContext == null) {
mContext = context;
...
}
...
}
```
這裡確實把context賦值給了ContentProvider的內部變數mContext，這樣ContentProvider就可以使用Context了。而這個context正是一開始傳進來的Application。
## 從原始碼設計角度看Context
到這裡關於Context的知識也講得差不多了。研究Framework層知識，不能只停留在他是什麼，有什麼作用即可。Framework層他是一個整體，構成了android這個龐大的體系，還需要看Context，在其中扮演著什麼樣的角色，解決了什麼樣的問題。在[window機制](https://blog.csdn.net/weixin_43766753/article/details/108350589)中我講到window的存在是為了解決螢幕上view的顯示邏輯與觸控反饋問題，在[Hanlder機制](https://blog.csdn.net/weixin_43766753/article/details/108968666)中我寫到整個android程式都是基於Handler機制來驅動執行的，而Context呢？
Android系統是一個完整的生態，他搭建了一個環境，讓各種程式可以執行在上面。而任何一個程式，想要執行在這個環境上，必須得到系統的允許，也就是**軟體安裝**。安卓與電腦不同的是，他不是任意一個程式就可以直接訪問到系統的資源。我們在window上可以寫一個java程式，然後直接開啟一個檔案流就可以讀取和修改檔案了。而Android沒這麼簡單，他**任意一個程式的執行都必須經過系統的調控**。也就是，即時程式獲得允許（安裝在手機上了)，程式本身要執行，還得是系統來控制程式執行，程式無法自發地執行在Android環境中。我們通過原始碼可以知道程式的main方法，僅僅只是開啟了執行緒的Looper迴圈，而後續的一切，都必須等待AMS來控制。
那應用程式自己硬要執行可不可以？可以，但是沒卵用。想要獲得系統資源，如啟動四大元件、讀取佈局檔案、讀寫資料庫、呼叫系統櫃攝像頭等等，都必須要通過Context，而context必須要通過AMS來獲取。這就區分了一個程式是一個普通的Java程式，還是android程式。
Context承受的兩大重要職責是：身份許可權、程式訪問系統的介面。一個Java類，如果沒有context那麼就是一個普通的Java類，而當他獲得context那麼他就可以稱之為一個元件了，因為它獲得了訪問系統的許可權，他不再是一個普通的身份，是屬於android“公民”了。而“公民”並不是無法無天，系統也可以通過context來封裝以及限制程式的許可權。要想彈出一個通知，你必須通過這個api，使用者關閉你的通知許可權，你就別想通過第二條路來彈出通知了。同時 程式也無需知道底層到底是如何實現，只管呼叫api即可。四大元件為何稱為四大元件，因為他們生來就有了context，特別是activity和service，包括Application。而我們寫的一切程式，都必須間接或者直接從其中獲取context。
總而言之，context就是負責區分android內外程式的一個機制，限制程式訪問系統資源的許可權。
## 總結
文章從什麼是context開始介紹，再針對context的不同子類進行解析，最後結合原始碼深入地講解了context的建立過程。最後再談了我對context的設計理解。
關於context想說的就已經說完了。雖然這些內容日常很少用得到，但是非常有助於我們對Android整個系統框架的理解。而當我們對系統有更加深入的理解後，寫出來的程式也就會更加健壯。
希望文章對你有幫助。
> 全文到此，原創不易，覺得有幫助可以點贊收藏評論轉發。
> 筆者能力有限，有任何想法歡迎評論區交流指正。
> 如需轉載請私信交流。
>
> 另外歡迎光臨筆者的個人部落格：[傳送門](https://qwerhuan.g
依然，我們專注於Activity的建立流程，其他的讀者可閱讀[Activity啟動流程](https://blog.csdn.net/weixin_43766753/article/details/107746968)這篇文章瞭解。和Application一樣，Activity的建立時由AMS來控制的，AMS嚮應用程式程序傳送訊息來執行具體的啟動邏輯。最後會執行到`handleLaunchActivity`這個方法：
```java
ActivityThread.class(api29)
public Activity handleLaunchActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions, Intent customIntent) {
...
final Activity a = performLaunchActivity(r, customIntent);
...
return a;
}
```
最終的就是中間這句程式碼，進入看原始碼：
```java
ActivityThread.class(api29)
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
...
// 建立Activity的ContextImpl
ContextImpl appContext = createBaseContextForActivity(r);
Activity activity = null;
try {
// 利用類載入建立activity例項
java.lang.ClassLoader cl = appContext.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
...
}
try {
// 建立Application
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
...
if (activity != null) {
...
// 把activity設定給context，這樣context也可以訪問到activity了
appContext.setOuterContext(activity);
// 呼叫activity的attach方法把contextImpl設定給activity
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor, window, r.configCallback,
r.assistToken);
int theme = r.activityInfo.getThemeResource();
if (theme != 0) {
// 設定主題
activity.setTheme(theme);
}
...
// 回撥onCreate方法
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
...
}
...
}
...
return activity;
}
```
程式碼的邏輯不是很複雜，首先建立Activity的ContextImpl，利用類載入建立activity例項，然後再通過LoadedApk建立Application，這個方法在前面我們講過，如果Application已經建立會直接返回已經建立的物件。然後把activity設定給context，這樣context也可以訪問到activity了。這裡要注意，前面講到使用Activity的context會造成記憶體洩露，那麼可不可以用Activity的contextImpl物件呢？答案是不可以，因為**ContextImpl也會持有Activity的引用**，需要特別注意一下。隨後再呼叫activity的attach方法把contextImpl設定給activity。後面是設定主題和回撥onCreate方法，我們就不深入了，主要看看attach方法：
```java
Activity.class(api29)
final void attach(Context context,...) {
attachBaseContext(context);
...
}
```
這裡省略了大量的程式碼，只保留關鍵一句：`attachBaseContext`，是不是很熟悉？呼叫ContextWrapper的方法來給mBase屬性賦值，和前面Application是一樣的，就不再贅述。
#### Service
依然只關注關鍵程式碼流程，先看Service的啟動流程圖：
Service的建立過程也是受AMS的控制，同樣我們看到建立Service的那一步，最終會呼叫到`handleCreateService`這個方法：
```java
private void handleCreateService(CreateServiceData data) {
...
LoadedApk packageInfo = getPackageInfoNoCheck(
data.info.applicationInfo, data.compatInfo);
Service service = null;
try {
java.lang.ClassLoader cl = packageInfo.getClassLoader();
service = packageInfo.getAppFactory()
.instantiateService(cl, data.info.name, data.intent);
}
...
try {
...
ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
context.setOuterContext(service);
Application app = packageInfo.makeApplication(false, mInstrumentation);
service.attach(context, this, data.info.name, data.token, app,
ActivityManager.getService());
service.onCreate();
mServices.put(data.token, service);
...
}
...
}
```
Service的邏輯就相對簡單了，同樣建立service例項，再建立contextImpl，最後把contextImpl通過Service的attach方法賦值給mBase屬性，最後回撥Service的onCreate方法。過程和上面的很像，這裡就不再深入講了，感興趣的讀者可自行去閱讀原始碼，也可以閱讀[Android中Service的啟動與繫結過程詳解（基於api29）](https://blog.csdn.net/weixin_43766753/article/details/107881248)這篇文章瞭解Service的詳細內容。
#### Broadcast
Broadcast和上面的元件不同，他並不是繼承自Context，所以他的Context是需要通過上述三者來給予。我們一般使用廣播的context是在接受器中，如：
```kotlin
class MyClass :BroadcastReceiver() {
override fun onReceive(context: Context?, intent: Intent?) {
TODO("use context")
}
}
```
那麼onReceive的context物件是從哪裡來的呢？同樣我們先看廣播接收器的註冊流程：
同樣，詳細的廣播相關工作流程可以閱讀[Android廣播Broadcast的註冊與廣播原始碼過程詳解（基於api29）](https://blog.csdn.net/weixin_43766753/article/details/108066203)這篇文章瞭解。因為在建立Receiver的時候並沒有傳入context，所以我們需要追蹤他的註冊流程，看看在哪裡獲取了context。我們先看到ContextImpl的`registerReceiver`方法：
```java
ContextImpl.class(api29)
public Intent registerReceiver(BroadcastReceiver receiver, IntentFilter filter,
String broadcastPermission, Handler scheduler) {
// 注意引數
return registerReceiverInternal(receiver, getUserId(),
filter, broadcastPermission, scheduler, getOuterContext(), 0);
}
```
registerReceiver方法最終會來到這個過載方法，我們可以注意到，這裡有個`getOuterContext`，這個是什麼？還記得Activity的context建立過程嗎？這個方法獲取的就是activity本身。我們繼續看下去：
```java
ContextImpl.class(api29)
private Intent registerReceiverInternal(BroadcastReceiver receiver, int userId,
IntentFilter filter, String broadcastPermission,
Handler scheduler, Context context, int flags) {
IIntentReceiver rd = null;
if (receiver != null) {
if (mPackageInfo != null && context != null) {
...
rd = mPackageInfo.getReceiverDispatcher(
receiver, context, scheduler,
mMainThread.getInstrumentation(), true);
}
...
}
...
}
```
這裡利用context建立了ReceiverDispatcher，我們繼續深入看：
```java
LoadedApk.class(api29)
public IIntentReceiver getReceiverDispatcher(BroadcastReceiver r,
Context context, Handler handler,
Instrumentation instrumentation, boolean registered) {
synchronized (mReceivers) {
LoadedApk.ReceiverDispatcher rd = null;
...
if (rd == null) {
rd = new ReceiverDispatcher(r, context, handler,
instrumentation, registered);
...
}
...
}
}
ReceiverDispatcher.class(api29)
ReceiverDispatcher(..., Context context,...) {
...
mContext = context;
...
}
```
這裡確實把receiver和context建立了ReceiverDispatcher，嗯?怎麼沒有給Receiver?其實這涉及到廣播的內部設計結構。Receiver是沒有跨程序通訊能力的，而廣播需要AMS的調控，所以必須有一個可以跟AMS溝通的物件，這個物件是InnerReceiver，而ReceiverDispatcher就是負責維護他們兩個的聯絡，如下圖：
而onReceive方法也是由ReceiverDispatcher回撥的，最後我們再看到回撥onReceive的那部分程式碼：
```java
ReceiverDispatcher.java/Args.class;
public final Runnable getRunnable() {
return () -> {
...;
try {
...;
// 可以看到這裡回調了receiver的方法，這樣整個接收廣播的流程就走完了。
receiver.onReceive(mContext, intent);
}
}
}
```
Args是Receiver的內部類，mContext就是在建立ReceiverDispatcher時傳入的物件，到這裡我們就知道這個物件確實是Activity了。
但是，，**不一定每個都是Activity**。在原始碼中我們知道是通過`getOuterContext`來獲取context，如果是通過別的context註冊廣播，那麼對應的物件也就不同了，只是我們一般都是在Activity中建立廣播，所以這個context一般是activity物件。
#### ContentProvider
ContextProvider我們用的就比較少了，內容提供器主要是用於應用間內容共享的。雖然ContentProvider是由系統建立的，但是他本身並不屬於Context家族體系內，所以他的context也是從其他獲取的。老樣子，先看ContentProvider的建立流程：
咦？這不是Application建立的流程圖嗎？是的，ContentProvider是伴隨著應用啟動被建立的，來看一張更加詳細的流程圖：
我們把目光聚集到ContentProvider的建立上，也就是`installContentProviders`方法。同樣，詳細的ContentProvider工作流程可以訪問[Android中ContentProvider的啟動與請求原始碼流程詳解（基於api29）](https://blog.csdn.net/weixin_43766753/article/details/108110605)這篇文章。`installContentProviders`是在handleBindApplication中被呼叫的，我們看到呼叫這個方法的地方：
```java
private void handleBindApplication(AppBindData data) {
try {
// 建立Application
app = data.info.makeApplication(data.restrictedBackupMode, null);
...
if (!data.restrictedBackupMode) {
if (!ArrayUtils.isEmpty(data.providers)) {
// 安裝ContentProvider
installContentProviders(app, data.providers);
}
}
}
```
可以看到這裡傳入了application物件，我們繼續看下去：
```java
private void installContentProviders(
Context context, List