Application和Activity,Service一樣是android框架的一個(gè)系統(tǒng)組件，當(dāng)android程序啟動(dòng)時(shí)系統(tǒng)會(huì)創(chuàng)建一個(gè)application對(duì)象，用來(lái)存儲(chǔ)系統(tǒng)的一些信息。通常我們是不需要指定一個(gè)Application的，這時(shí)系統(tǒng)會(huì)自動(dòng)幫我們創(chuàng)建。打開(kāi)每一個(gè)應(yīng)用程序的manifest文件,可以看到activity都是包含在application標(biāo)簽之中，如下：

android系統(tǒng)會(huì)為每個(gè)程序運(yùn)行時(shí)創(chuàng)建一個(gè)Application類的對(duì)象且僅創(chuàng)建一個(gè)，所以Application是單例 (singleton)模式的一個(gè)類.且application對(duì)象的生命周期是整個(gè)程序中最長(zhǎng)的，它的生命周期就等于這個(gè)程序的生命周期。因?yàn)樗侨值膯卫模栽诓煌腁ctivity,Service中獲得的對(duì)象都是同一個(gè)對(duì)象。因此在安卓中我們可以避免使用靜態(tài)變量來(lái)存儲(chǔ)長(zhǎng)久保存的值，而用Application。

為了更好的利用Application的這一特性，比如我們需要Application來(lái)保存一些靜態(tài)值，需要自定義繼承于Application的類，然后在這個(gè)類中定義一個(gè)變量來(lái)保存。在默認(rèn)情況下應(yīng)用系統(tǒng)會(huì)自動(dòng)生成Application 對(duì)象，但是如果我們自定義了Application，那就需要告知系統(tǒng)，實(shí)例化的時(shí)候，是實(shí)例化我們自定義的，而非默認(rèn)的。比如我們自定義了一個(gè)AppContext類：

為了讓系統(tǒng)實(shí)例化的時(shí)候找到，我們必須在manifest中修改application標(biāo)簽屬性：

關(guān)鍵的是這句：android:name=".AppContext"

通常Application全局對(duì)象是通過(guò)Context或者Activity的getApplicationContext()方法獲得的比如我們?cè)趹?yīng)用程序中想要獲得我們剛剛定義的AppContext對(duì)象，就需要在activity中這樣做：

appContext = (AppContext)this.getApplicationContext();

如果有Context對(duì)象，還可以：appContext = (AppContext)mContext.getApplicationContext();

但是很多時(shí)候我們的代碼可能在activity之外，且沒(méi)有context對(duì)象的引用，但是又需要獲得AppContext對(duì)象，原始的做法可能是想辦法將activity或者context傳遞到需要調(diào)用的地方，但是這樣代碼耦合度太高，可讀性差。我們有更優(yōu)雅的做法。

我們談到Application對(duì)象是全局的，單例的，既然是單例應(yīng)該有一個(gè)類方法能讓我們獲得這個(gè)單例對(duì)象才是，但Application本身沒(méi)有，我們只能在自定義的時(shí)候想辦法。

Application是系統(tǒng)的一個(gè)組件，也就有自己的生命周期函數(shù)，讓人感到意外的是他的生命周期函數(shù)中居然也有onCreate(),onCreate是被自動(dòng)調(diào)用的，我們可以利用這點(diǎn)來(lái)獲得這個(gè)Application對(duì)象。

在AppContext中加入如下幾行代碼：

這樣我們就能在app工程的任何地方通過(guò)AppContext.getInstance()來(lái)獲得Application全局對(duì)象。比如我定義了一個(gè)工具類，在工具內(nèi)中我們需要使用

Context的getExternalFilesDir()方法。但是這個(gè)工具類沒(méi)有直接的辦法獲取到context，于是我們可以：