Context簡介
Context的中文意思是上下文，可以簡單的理解為執行環境，提供一些非常Base的介面，例如獲取資源管理器，App快取目錄等
從Context原始碼中得出Context是個抽象類，其功能的實現應該交給了其子類，那麼我們就看看Context的繼承關係 此圖源自自郭霖大神的Blog 從原始碼可以看出，Context有兩個直接的子類ContextWrapper和ContextImpl，並且Application,Service,Activity都繼承ContextWrapper，下面我們看看ContextWrapper的原始碼: 從原始碼可以看出，ContextWrapper把功能都委託給mBase來做（代理模式） 讓我們再來Context的另外一個實現類ContextImpl的原始碼： 從原始碼可以看出，ContextImpl實現了Context的所有功能。綜上我們可以推斷ContextWrapper中的mBase應該是ContextImpl物件，下面通過Application，Activity，Service的建立流程來證實這個推斷。
Application的建立流程
這張圖主要展示了啟動Activity，Service的簡要過程，在啟動Activity，Service的同時也會建立Application a. ActivityThread就是我們常說的UI執行緒，它負責Activity，Service，Application的排程等工作，感興趣的朋友可以閱讀下他的原始碼. b. ApplicationThread是ActivityThread的一個內部類，本質上是一個IBinder物件，他的主要作用是用於AMS(ActivityManagerService的簡稱)與ActivityThread通訊，例如AMS在處理完Server端ActivityRecord的建立，棧管理後通過ApplicationThread來通知ActivityThread可以建立對應的Activity和執行Activity的生命週期了。 下面我們從AMS回撥啟動Activity的流程來看下Application的建立流程
- AMS會通過呼叫ApplicationThread的scheduleLaunchActivity(...)來告訴ActivityThread它可以建立Activity了
- 然後傳送LAUNCH_ACTIVITY訊息出去
- 接著呼叫 handleLaunchActivity(...)
- 然後呼叫performLauncherActivity(...)
我們關注下createBaseContextForActivity(...)，他建立了CotnextImpl物件，接著呼叫Activity的attach(...)，把ContextImpl物件傳了進去，從而證明了Activity內部對應的mBase就是ContextImpl。 - 然後呼叫了LoadedApk的makeApplication（...）
如果mApplication不為null則直接返回它，mApplication是LoadedApk中的一個全域性物件，一個APP程式只會建立一次。然後建立ContextImpl物件，並且在呼叫Intrumentation的newApplication(...)的時候傳了進去，接著呼叫了Intrmentation的callApplicationOnCreate(...) 接下來我們看看Intrumentation的newApplication(...)和callApplicationOnCreate(...)做了什麼 從程式碼中我們可以看出，Application建立後，呼叫了attach(...)，把ContextImpl物件傳了進去，也就證明了Application內部對應的mBase就是ContextImpl，同時在attach方法中呼叫了執行了Application的生命週期方法attachBaseContext(...) 從程式碼中可以看出，callApplicationOnCreate執行了Application生命週期方法onCreate(...)