前言
很高興遇見你~ 歡迎閱讀我的文章，
在文章Android全面決議之由淺及深Handler訊息機制中討論到，Handler可以：
避免我們自己去手動寫 死回圈和輸入阻塞 來不斷獲取用戶的輸入以及避免執行緒直接結束，而是采用事務驅動型設計，使用Handler訊息機制，讓AMS可以控制整個程式的運行邏輯，
這是關于android程式在設計上更加重要的一部分，不太了解的讀者可以前往閱讀了解一下，而當我們知道android程式的程式是通過main方法跑起來的，然后通過handler機制來控制程式的運行，那么四大組件和普通的Java類到底有什么區別？為什么同樣是Java類，而ActivityThread、Activity等等這些類就顯得那么特殊呢？我們的代碼、寫的布局是通過什么路徑使用系統資源把界面展示在螢屏上的？這一切就涉及到我們今天的主角：Context，
什么是Context
回想一下最初學習Android開發的時候，第一用到context是什么時候？如果你跟我一樣是通過郭霖的《第一行代碼》來入門android，那么一般是Toast，Toast的常規用法是：
Toast.makeText(this, "我是toast", Toast.LENGTH_SHORT).show()
當初也不知道什么是Context，只知道他需要一個context型別，把activity物件傳進去即可，從此context貫穿在我開發程序的方方面面，但我始終不知道這個context到底有什么用？為什么要這個物件？我們首先來看官方對于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 {...}
關于應用程式環境的全域資訊的介面， 這是一個抽象類，它的實作是由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在原始碼中的子類繼承情況，先看一個圖：
最頂層是Context抽象類，他定義了一系列與系統交匯的介面，ContextWrapper繼承自Context，但是并沒有真正實作Context中的介面，而是把介面的實作都托管給ContextImpl，ContextImpl是Context介面的真正實作者，從AMS拿來的“憑證”也是封裝到了ContextImpl中，然后賦值給ContextWrapper，這里運用到了一種模式：裝飾者模式，Application和Service都繼承自ContextWrapper，那么他們也就擁有Context的介面方法且本身即是context，方便開發者的使用，Activity比較特殊，因為它是有界面的，所以他需要一個主題：Theme，ContextThemeWrapper在ContextWrapper的基礎上增加與主題相關的操作，
這樣的設計有這樣的優點：
- Activity等可以更加方便地使用context，可以把自身當成context來使用，遇到需要context的介面直接把自身傳進去即可，
- 運用裝飾者模式，向外屏蔽ContextImpl的內部邏輯，同時當需要更改ContextImpl的邏輯實作，ContextWrapper的邏輯幾乎不需要更改，
- 更方便地擴展不同情景下的邏輯，如service和activity，情景不同，需要的介面方法也不同，但是與系統互動的介面是相同的，使用裝飾者模式可以拓展出很多的功能，同時只需要把ContextImpl物件賦值進去即可，
context的分類
前面講到Context的家族體系時，了解到他的最終實作類有：Application、Activity、Service，ContextImpl被前三者持有，是Context介面的真正實作，那么這里討論一下這三者有什么不同，和使用時需要注意的問題，
Application
Application是全域Context，整個應用程式只有一個，他可以訪問到應用程式的包資訊等資源資訊，獲取Application的方法一般有兩個：
context.getApplicationContext()
activity.getApplication()
通過context和activity都可以獲取到Application，那這兩個方法有什么區別？沒有區別，我們可以列印來看一下：
override fun onCreate(savedInstanceState: Bundle?) {
...
Log.d("一只修仙的猿", "application：$application")
Log.d("一只修仙的猿", "applicationContext：$applicationContext")
}
可以看到確實是同個物件，但為什么要提供兩個一樣作用的方法？getApplication()方法更加直觀，但是只能在activity中呼叫，getApplicationContext()適用范圍更廣，任意一個context物件皆可以呼叫此方法，
Application類的Context的特點是生命周期長，在整個應用程式運行的期間他都會存在，同時我們可以自定義Application，并在里面做一些全域的初始化操作，或者寫一個靜態的context供給全域獲取，不需要在方法中傳入context，如：
class MyApplication : Application(){
// 全域context
companion object{
lateinit var context: Context
}
override fun onCreate() {
super.onCreate()
// 做全域初始化操作
RetrofitManager.init(this)
context = this
}
}
這樣我們就可以在應用啟動的時候對一些組件進行初始化，同時可以通過MyApplication.context來獲取Application物件，
但是！！！請不要把Application當成工具類使用，由于Application獲取的便利性，有開發者會在Application中撰寫一些工具方法，全域獲取使用，這樣是不行的，自定義Application的目的是在程式啟動的時候做全域初始化作業，而不能拿來取代工具類，這嚴重違背谷歌設計Application的原則，也違背Java代碼規范的單一職責原則，
四大組件
Activity繼承自ContextThemeWrapper，是一個擁有主題的context物件，Activity常用于與UI有關的操作，如添加window等，常規使用可以直接用activity.this，
Service繼承自ContextWrapper，也可以和Activity一樣直接使用service.this來使用context，和activity不同的是，Service沒有界面，所以也不需要主題，
ContextProvider使用的是Application的context，Broadcast使用的是activity的context，這兩點在后面會進行原始碼分析，
BaseContext
嗯？baseContext是什么？把這個拿出來單獨講，細心的讀者可能會發現activity中有一個方法：getBaseContext，這個是ContextWrapper中的mBase物件，也就是ContextImpl，也是context介面的真正邏輯實作，
context的使用問題
使用context最重要的問題之一是注意記憶體泄露，不同的context的生命周期不同，Application是在應用存在的期間會一直存在，而Activity是會隨著界面的銷毀而銷毀，如果當我們的代碼長時間持有了activity的context，如靜態參考或者單例類，那么會導致activity無法被釋放，如下面的代碼：
object MyClass {
lateinit var mContext : Context
fun showToast(context : Context){
mContext = context
}
}
單例類在應用持續的時間都會一直存在，這樣context也就會被一直被持有，activity無法被回收，導致記憶體泄露，
那，我們就都換成Application不就可以了，如下：
object MyClass {
lateinit var mContext : Context
fun showToast(context : Context){
mContext = context.applicationContext
}
}
答案是：不可以，什么時候可以使用Application？不涉及UI以及啟動Activity操作，Activity的context是擁有主題屬性的，如果使用Application來操作UI，那么會丟失自定義的主題，采用系統默認的主題，同時，有些UI操作只有Activity可以執行，如彈出dialog，這涉及到window的token問題，我在這篇文章token驗證進行了詳細的解答，有興趣的讀者可以去閱讀一下，這也是官方對于context不同權限的設計，沒有界面的context，就不應該有操作界面的權利，使用Application啟動的Activity必須指定task以及標記為singleTask，因為Application是沒有任務堆疊的，需要重新開一個新的任務堆疊，因此，我們需要根據不同context的不同職責來執行不同的任務，
Context的創建程序
經過上面的討論，讀者對于context在心中有了一定的理解，但始終覺得少點什么：activity是什么時候被創建的，他的contextImpl是如何被賦值的？Application呢？為什么說ContextProvider的context是Application，Broadcast的context是Activity？contextImpl又是如何被創建的？解決這些疑惑，就必須閱讀原始碼了，閱讀原始碼的好處非常多，上面我的講述，都是基于我閱讀原始碼之后的理解，而“一千個觀眾有一千個哈姆雷特”，閱讀原始碼可以形成自己對整個機制自己的思考和理解，同時可以讓自己對context那些知識真正落實到代碼上，增強自己對知識的自信心，當別人和你意見不同的時候，你可以拍拍胸脯說：我看過原始碼，這個地方就是這樣，是不是非常自信且傲嬌？
然而閱讀原始碼不是越多越好，而是把握整體的流程之后閱讀關鍵原始碼，不要深入原始碼堆中無法自拔，例如我覺得activity的contextImpl是在Activity創建的程序中被賦值的，那么我就會去找activity的啟動流程原始碼，然后只看和context有關的部分，提高效率的同時，還可以切中我們學習的點，下面的原始碼閱讀我們給出整體流程，然后重點理解關鍵代碼，其他的原始碼讀者可自行下載原始碼去跟蹤閱讀一下，
Application
Application應用級別的context，是在應用被創建的時候被創建的，是第一個被創建的context，也是最后一個被銷毀的context，因而追蹤Application的創建需要從應用程式的啟動流程看起，應用啟動的原始碼流程如下（簡化版）：
應用程式從ActivityThread的main方法開始執行，從Handler訊息機制中我們知道main方法主要是開啟執行緒的Looper以及handler，然后由AMS向主執行緒發送message控制應用的啟動程序，因而我們可以把目標鎖定在圖中的最后一個方法：handleBindApplication，Application最有可能在這里被創建：
ActivityThread.class (api29)
private void handleBindApplication(AppBindData data) {
...
// 創建LoadedApk物件
data.info = getPackageInfoNoCheck(data.appInfo, data.compatInfo);
...
Application app;
...
try {
// 創建Application
app = data.info.makeApplication(data.restrictedBackupMode, null);
...
}
try {
...
// 回呼Application的onCreate方法
mInstrumentation.callApplicationOnCreate(app);
}
...
}
handleBindApplication的引數AppBindData是AMS給應用程式的啟動資訊，其中就包含了“權限憑證”——ApplicationInfo等，LoadedApk就是通過這些物件來創建獲取對系統資源的訪問權限，然后通過LoadApk來創建ContextImpl以及Application，
這里我們只關注和context創建有關的邏輯，前面啟動程式的原始碼以及AMS如何處理，這里就不講了，讀者有興趣可以讀ContextProvider啟動流程這篇文章，其中對ContextProvider的啟動程序就有對上述原始碼進行追蹤詳解，
那么接下來我們繼續關注Application是如何創建的：
LoadeApk.class(api29)
public Application makeApplication(boolean forceDefaultAppClass,
Instrumentation instrumentation) {
// 如果application已經存在則直接回傳
if (mApplication != null) {
return mApplication;
}
...
Application app = null;
String appClass = mApplicationInfo.className;
...
try {
java.lang.ClassLoader cl = getClassLoader();
...
// 創建ContextImpl
ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
// 利用類加載器加載我們在AndroidMenifest指定的Application類
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);
// 把Application的參考給comtextImpl，這樣contextImpl也可以很方便地訪問Application
appContext.setOuterContext(app);
}
...
mActivityThread.mAllApplications.add(app);
// 把app設定為mApplication，當我們呼叫context.getApplicationContext就是獲取這個物件
mApplication = app;
if (instrumentation != null) {
try {
// 回呼Application的onCreate方法
instrumentation.callApplicationOnCreate(app);
}
...
}
...
return app;
}
代碼的邏輯也不復雜，首先判斷LoadedApk物件中的mApplication是否存在，否則創建ContextImpl，再利用類加載器和contextImpl創建Application，最后把Application物件賦值給LoadedApk的mApplication，再回呼Application的onCreate方法，我們先來看一下contextImpl是如何創建的：
ContextImpl.class(api29)
static ContextImpl createAppContext(ActivityThread mainThread, LoadedApk packageInfo,
String opPackageName) {
if (packageInfo == null) throw new IllegalArgumentException("packageInfo");
ContextImpl context = new ContextImpl(null, mainThread, packageInfo, null, null, null, 0,
null, opPackageName);
context.setResources(packageInfo.getResources());
return context;
}
這里直接new了一個ContextImpl，同時給ContextImpl賦值訪問系統資源相關的“權限”物件——ActivityThread，LoadedApk等，讓我們再回到Application的創建程序，我們可以猜測，在newApplication包含的邏輯肯定有：利用反射創建Application，再把contextImpl賦值給Application，原因是每個人自定義的Application類不同，需要利用反射來創建物件，其次Application中的mBase屬性是對ContextImpl的參考，看原始碼：
Instrumentation.class(api29)
public Application newApplication(ClassLoader cl, String className, Context context)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
Application app = getFactory(context.getPackageName())
.instantiateApplication(cl, className);
app.attach(context);
return app;
}
Application.class(api29)
final void attach(Context context) {
attachBaseContext(context);
mLoadedApk = ContextImpl.getImpl(context).mPackageInfo;
}
ContextWrapper.class(api29)
Context mBase;
protected void attachBaseContext(Context base) {
if (mBase != null) {
throw new IllegalStateException("Base context already set");
}
mBase = base;
}
結果非常符合我們的猜測，先創建Application物件，再把ContextImpl通過Application的attach方法賦值給Application，然后Application的attach方法呼叫了ContextWrapper的attachBaseContext方法，因為Application也是繼承自ContextWrapper，這樣，就把ContextImpl賦值給Application的mBase屬性了，
再回到前面的邏輯，創建了Application之后需要回呼onCreate方法：
Instrumentation.class(api29)
public void callApplicationOnCreate(Application app) {
app.onCreate();
}
簡單粗暴，直接回呼，到這里，Application的創建以及context的創建流程就走完了，但是需要注意的是，全域初始化需要在onCreate中進行，而不要在Application的構造器中執行，從代碼中我們可以看到ContextImpl是在Application被創建之后再賦值的，
Activity
Activity的context也是在Activity創建的程序中被創建的，這個就涉及到Activity的啟動流程，這里涉及到三個流程：應用程式請求AMS，AMS處理請求，應用程式回應Activity創建事務：
依然，我們專注于Activity的創建流程，其他的讀者可閱讀Activity啟動流程這篇文章了解，和Application一樣，Activity的創建時由AMS來控制的，AMS向應用程式行程發送訊息來執行具體的啟動邏輯，最后會執行到handleLaunchActivity這個方法：
ActivityThread.class(api29)
public Activity handleLaunchActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions, Intent customIntent) {
...
final Activity a = performLaunchActivity(r, customIntent);
...
return a;
}
最終的就是中間這句代碼，進入看原始碼：
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方法：
Activity.class(api29)
final void attach(Context context,...) {
attachBaseContext(context);
...
}
這里省略了大量的代碼，只保留關鍵一句：attachBaseContext，是不是很熟悉？呼叫ContextWrapper的方法來給mBase屬性賦值，和前面Application是一樣的，就不再贅述，
Service
依然只關注關鍵代碼流程，先看Service的啟動流程圖：
Service的創建程序也是受AMS的控制，同樣我們看到創建Service的那一步，最侄訓呼叫到handleCreateService這個方法：
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）這篇文章了解Service的詳細內容，
Broadcast
Broadcast和上面的組件不同，他并不是繼承自Context，所以他的Context是需要通過上述三者來給予，我們一般使用廣播的context是在接受器中，如：
class MyClass :BroadcastReceiver() {
override fun onReceive(context: Context?, intent: Intent?) {
TODO("use context")
}
}
那么onReceive的context物件是從哪里來的呢？同樣我們先看廣播接收器的注冊流程：
同樣，詳細的廣播相關作業流程可以閱讀Android廣播Broadcast的注冊與廣播原始碼程序詳解（基于api29）這篇文章了解，因為在創建Receiver的時候并沒有傳入context，所以我們需要追蹤他的注冊流程，看看在哪里獲取了context，我們先看到ContextImpl的registerReceiver方法：
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本身，我們繼續看下去：
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，我們繼續深入看：
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的那部分代碼：
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）這篇文章，installContentProviders是在handleBindApplication中被呼叫的，我們看到呼叫這個方法的地方：
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物件，我們繼續看下去：
private void installContentProviders(
Context context, List<ProviderInfo> providers) {
final ArrayList<ContentProviderHolder> results = new ArrayList<>();
for (ProviderInfo cpi : providers) {
...
ContentProviderHolder cph = installProvider(context, null, cpi,
false /*noisy*/, true /*noReleaseNeeded*/, true /*stable*/);
...
}
...
}
這里呼叫了installProvider，繼續往下看：
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，我們再深入一點看看：
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機制中我講到window的存在是為了解決螢屏上view的顯示邏輯與觸摸反饋問題，在Hanlder機制中我寫到整個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://www.uj5u.com/yidong/233497.html
標籤：Android
上一篇：iOS審核遇到一些問題
下一篇：Android listview