Context源碼分析

Context是什么？

Context的字面意思是“上下文”，那么這個“上下文”到底指的是什么？“上”指的是什么？“下”指定的是什么？
個人的理解，有助于自己的理解的方式，不一定對，如果有更好的看法可以一塊交流學習。個人的理解，“上”指的是在APP啟動的時候，就與Context有關了，這個時候還是系統啟動階段，就與Context發生了聯系。
“下”指定的是在APP界面正常顯示出來以后，正常與用戶交互的過程中，可以用Context獲取資源，系統服務等。所以Context所謂的上下文就是承上啟下的作用。

1. Context的類的繼承關系
   從上圖可以看到，Context只有一個實現類ContextImpl，Application，Service,Activity都是直接或者間接繼承了ContextWrapper，ContextWrapper中有一個變量mBase，也是個Context類型，實際是ContextImpl的對象，Application，Service,Activity所有的操作都是委托給了mBase實現。

2. Context既然是承上啟下，是個上下文，和APP啟動流程有關，先來看看系統的啟動流程和APP的啟動流程，都在一張圖里，如下：

從上圖可以看到：

• 首先系統的第一個進程 init跑起來，作一些初始化相關的工作，然后通過系統調用fork出了一個zygote進程，init進程通過poll阻塞在那了。

• zygote進程被init進程fork出來以后，做一些jni初始化等，通過調用fork出了一個SystemServer進程，SystemServer進程里面跑的都是安卓的系統服務，zygote通過jni調用java的代碼，fork出了SystemServer進程，打開了java世界的大門，自己通過sokcet監聽阻塞在那了，監聽來自socket的信息。

• SystemServer進程被fork出來以后，里面會開啟非常多的系統服務，比如AMS,PMS,WMS等，SystemServer進程是一個非常重要的進程，系統的很多重要的服務都駐留在此進程中，SystemServer進程是通過Handler機制阻塞在那了。等待發來的消息并處理消息。這樣整個系統就啟動了。

• 在PMS中，會啟動Lanuher APP，用戶就可以看到安卓系統桌面了。如果用戶點擊了桌面上的QQ圖標，Lannuher進程就會通過binder機制與AMS通信，告訴AMS要啟動QQ應用，AMS收到 Lanuher進程發來的消息以后，通過socket發送信息給zygote進程，我們知道zygote進程在fork出了SystemServer進程以后就一直在監聽著socket，所以zygote進程收到SystemServer進程發來的消息后，如果沒有創建過QQ進程，這個時候，zygote就會調用fork系統調用創建一個新的進程，用來跑QQ代碼，這個進程就是QQ進程，QQ App進程創建以后第一個調用的就是Activity.main()方法，如上圖。

Context有什么作用？

1 訪問當前應用的資源

• getResources

• getAssets

2 啟動其它組件

• Activity

• Service

3 獲取系統服務

• getSystemService

Application對象的ContextImpl對象創建過程

1 通過上面的系統啟動流程和APP啟動流程分析可知：第一個APP應用都是由AMS通過binder機制創建一個新的進程，然后調用ActivityThread類中的main方法開始的。很多人可能會感到奇怪為啥Android也是基于Java實現的，為啥沒有看到main方法呢？其實整個App應用的入口就是ActivityThread.main方法.所有有關Application， Activity，Service的創建都是在ActivityThread類中，其實該類就是我們App的主線程。在ActivityThread中有一個方法 performLaunchActivity()方法，在這個方法里面就創建了Application,Activity。我們看一下這個方法。
如下圖

調用mInstrumentation.newActivity()方法創建Activity。newActivity代碼如下圖

可以看到，創建Activity以后，調用了Activity的attach方法，第一個參數就是context，在這里Activity就和context發生了聯系，這個context其實就是ContextImpl的實例。接著上面的第一張圖 performLaunchActivity繼續往下走，如下圖：

通過上圖可以看到，在創建完了activity，并且調用了activity.attach()方法之后，開始創建Application對象，如下

Application app = r.packageInfo.makeApplication(false,mInstrumentation)

makeApplication代碼如下：

隨后又創建了一個ContextImpl的實例，代碼如下

//創建ContextImpl實例ContextImpl appContext = new ContextImpl();//初始化ContextImpl實例appContext.init(this,null,mActivityThread);//把appContext傳給了newApplication方法app = mActivityThread.mInstrumentation.newApplication(cl,appClass,appContext);//與Application發生聯系，ContextImpl實例保存了Application的實例appappContext.setOuterContext(app);

mActivityThread.mAllApplication.add(app);
mApplication = app;

下面看下newApplicaiton()方法,代碼如下：

static public Application newApplication(Class<?> clazz,Context context){    //通過反射創建Application實例
    Application app = (Application)clazz.newInstance();    //把上面傳進來的ContextImpl實例通過attach方法保存了起來
    app.attach(context);    //返回Application實例
    return app;
}

創建完Application并且通過調用application實例的attach方法與ContextImpl實例發生了聯系，接下來就應該調用application的onCreate()方法了。代碼如下：

public void callApplicationOnCreate(Application app){    //調用Application的onCreate方法
    app.onCreate();
}

創建了activity,也創建了application并且調用了application的attach和onCreate方法，接下來應該調用activity的onCreate方法了。還是在performLanucherActivity方法中。如下圖：

如上圖，通過mInstructation的callActivityOnCreate()方法調用activity的onCreate()。這段代碼和調用application的onCreate()方法的邏輯類似，自己可以看一下。這里不再帖出代碼

*** 通過上面的分析可以知道，Context是什么時候創建的，是怎么創建的，何時初始化的，如何與Application和Activity發生聯系的等 ***

Application的生命周期為什么這么長？

我們知道,Application的生命周期是和APP進程一樣長的，Application對應的context也是一樣，為什么Application的生命周期為什么這么長？

通過上面的分析可以知道，APP進程的入口是ActivityThread.main()方法，在這個方法中創建了一個ActivityThread的實例，通過Handler阻塞在那。ActivityThread的實例就會一直存在，如果APP不退出的話，而ActivityThread的實例中保存了application的mAllApplications，這是一個數組，保存Application實例的，在創建Application實例的時候，通過mActivityThread.mAllApplications.add(app)，把app保存起來了，通過強引用可以知道，ActivityThread引用了application實例，而ActivityThread實例又在進程的循環中，一直在阻塞，所以Application的生命周期和進程一樣。

Context的用法注意

下面以一張圖來說明幾種Context的不同點和用法。