Android_Context詳解

 Context對(duì)象是如此常見和傳遞使用，它可能會(huì)很容易產(chǎn)生并不是你預(yù)期的情形。加載資源、啟動(dòng)一個(gè)新的Activity、獲取系統(tǒng)服務(wù)、獲取內(nèi)部文件路徑以及創(chuàng)建view(其實(shí)還遠(yuǎn)不止這些)統(tǒng)統(tǒng)都需要Context對(duì)象來完成。我(原文作者)想做的只是給大家提供一些Context是如何工作的見解，以及讓大家在應(yīng)用中更有效的使用Context的技巧。

Context的類型

并不是所有的context實(shí)例都是等價(jià)的。根據(jù)Android應(yīng)用的組件不同，你訪問的context推向有些細(xì)微的差別。

Application - 是一個(gè)運(yùn)行在你的應(yīng)用進(jìn)程中的單例。在Activity或者Service中，它可以通過getApplication()函數(shù)獲得，或者人和繼承于context的對(duì)象中，通過getApplicationContext()方法獲得。不管你是通過何種方法在哪里獲得的，在一個(gè)進(jìn)程內(nèi)，你總是獲得到同一個(gè)實(shí)例。

Activity/Service - 繼承于ContextWrapper，它實(shí)現(xiàn)了與context同樣API，但是代理這些方法調(diào)用到內(nèi)部隱藏的Context實(shí)例，即我們所知道的基礎(chǔ)context。任何時(shí)候當(dāng)系統(tǒng)創(chuàng)建一個(gè)新的Activity或者Service實(shí)例的時(shí)候，它也創(chuàng)建一個(gè)新的ContextImpl實(shí)例來做所有的繁重的工作。每一個(gè)Activity和Service以及其對(duì)應(yīng)的基礎(chǔ)context，對(duì)每個(gè)實(shí)例來說都是唯一的。

BroadcastReciver - 它本身不是context，也沒有context在它里面，但是每當(dāng)一個(gè)新的廣播到達(dá)的時(shí)候，框架都傳遞一個(gè)context對(duì)象到onReceive()。這個(gè)context是一個(gè)ReceiverRestrictedContext實(shí)例，它有兩個(gè)主要函數(shù)被禁掉：registerReceiver()和bindService()。這兩個(gè)函數(shù)在BroadcastReceiver.onReceive()不允許調(diào)用。每次Receiver處理一個(gè)廣播，傳遞進(jìn)來的context都是一個(gè)新的實(shí)例。

ContentProvider - 它本身也不是一個(gè)Context，但是它可以通過getContext()函數(shù)給你一個(gè)Context對(duì)象。如果ContentProvider是在調(diào)用者的的本地(例如，在同一個(gè)應(yīng)用進(jìn)程)，getContext()將返回的是Application單例。然而，如果調(diào)用這個(gè)ContentProvider在不同的進(jìn)程的時(shí)候，它將返回一個(gè)新創(chuàng)建的實(shí)例代表這個(gè)Provider所運(yùn)行的包。

保存引用

第一個(gè)我們需要解決問題是，在一個(gè)對(duì)象或者類內(nèi)部保存一個(gè)context引用，而它生命周期卻超過其保存引用的對(duì)象的生命周期。例如，創(chuàng)建一個(gè)自定義的單例，它需要一個(gè)context來加載資源或者獲取ContentProvider，從而保存一個(gè)指向當(dāng)前Activiy或者Service的引用在單例中。

糟糕的單例

[java]

public class CustomManager {

private static CustomManager sInstance;

public static CustomManager getInstance(Context context) {

if (sInstance == null) {

sInstance = new CustomManager(context);

}

return sInstance;

}

private Context mContext;

private CustomManager(Context context) {

mContext = context;

}

}

這里的問題在于，我們不知道這個(gè)context是從哪里來的，并且如果保存一個(gè)最終指向的是Activity或者Servece的引用是并不安全的。這是一個(gè)問題，是因?yàn)橐粋€(gè)單例在類的內(nèi)部維持一個(gè)唯一的靜態(tài)引用，這意味著我們的對(duì)象，以及所有其他它所引用的對(duì)象，將永遠(yuǎn)不能被垃圾回收。假如這個(gè)Context是一個(gè)Activity，我們將保存與這個(gè)Activity相關(guān)的所有的view以及其他大的對(duì)象，從而造成內(nèi)存泄漏。

為了解決這個(gè)問題，我們修改單例永遠(yuǎn)只是保存Application context：

改善的單例：

[java

public class CustomManager {

private static CustomManager sInstance;

public static CustomManager getInstance(Context context) {

if (sInstance == null) {

//Always pass in the Application Context

sInstance = new CustomManager(context.getApplicationContext());

}

return sInstance;

}

private Context mContext;

private CustomManager(Context context) {

mContext = context;

}

}

現(xiàn)在這個(gè)例子中，我們的Context來自哪里都沒有關(guān)系，因?yàn)槲覀冞@里保存引用是安全的。Application Context 本身就是一個(gè)單例，所以我們?cè)賱?chuàng)建另外一個(gè)static引用，不會(huì)造成任何內(nèi)存泄漏。另外一個(gè)很好的例子是，在后臺(tái)線程或者一個(gè)等待的Handler中保存Context的引用，也可以使用這樣的方法。

為什么我們不能總是引用Application context呢?正如前面說的，引用Application context永遠(yuǎn)不用擔(dān)心內(nèi)存泄漏的問題。問題的答案，就像我在開始的介紹中說的，是因?yàn)椴煌琧ontext并不是等價(jià)的。

Context的能力

Conext能做的通用操作決定于這個(gè)context最初來源于哪里。下表所列的是，在應(yīng)用中常見的會(huì)收到context對(duì)象的，以及對(duì)應(yīng)的每種情況，它可以用于哪些地方：

注：NO1 表示Application context的確可以開始一個(gè)Activity，但是它需要?jiǎng)?chuàng)建一個(gè)新的task。這可能會(huì)滿足一些特定的需求，但是在你的應(yīng)用中會(huì)創(chuàng)建一個(gè)不標(biāo)準(zhǔn)的回退棧(back stack)，這通常是不推薦的或者不是是好的實(shí)踐。

NO2 表示這是非法的，但是這個(gè)填充(inflation)的確可以完成，但是是使用所運(yùn)行的系統(tǒng)默認(rèn)的主題(theme)，而不是你app定義的主題。

NO3 在Android4.2以上，如果Receiver是null的話(這是用來獲取一個(gè)sticky broadcast的當(dāng)前 值的)，這是允許的。

用戶界面UI

從前面的表格中可以看到，application context有很多功能并不是合適去做，而這些功能都與UI相關(guān)。實(shí)際上，只有Activity能夠處理所有與UI相關(guān)的任務(wù)。其他類別的context實(shí)例功能都差不多。

幸運(yùn)的是，在應(yīng)用中這三種操作基本上都不需要在Activity范圍之外進(jìn)行，這很可能是android框架故意這么設(shè)計(jì)的。嘗試顯示一個(gè)使用Aplication context創(chuàng)建的Dialog，或者使用Application context開始一個(gè)Activity，系統(tǒng)會(huì)拋出一個(gè)異常，讓你的application崩潰，非常強(qiáng)的告訴你某些地方出了問題。

一個(gè)并不明顯的問題是填充布局(inflating layout)。如果你已經(jīng)讀過了我(原文作者)的上一篇文章Layout inflation，你就已經(jīng)知道它可能是一個(gè)非常神秘過程，伴隨一些隱藏的行為。使用正確的context關(guān)系到其中的一個(gè)行為。當(dāng)你使用Application context來inflate一個(gè)布局的時(shí)候，框架并不會(huì)報(bào)錯(cuò)，并返回一個(gè)使用系統(tǒng)默認(rèn)的主題創(chuàng)建一個(gè)完美的view給你，而沒有考慮你的applicaiton自定義的theme和style。這是因?yàn)锳citivity是唯一的綁定了在manifast文件種定義主題的Context。其他的Context實(shí)例將會(huì)使用系統(tǒng)默認(rèn)的主題來inflater你的view。導(dǎo)致顯示的結(jié)果并不是你所希望的。

規(guī)則的路口

可能有些讀者已經(jīng)得出兩個(gè)規(guī)則互相矛盾的結(jié)論?？赡苡行┣闆r下，在某些Application的設(shè)計(jì)中，我們可能既必須長期保存一個(gè)的引用，并且為了完成與UI相關(guān)的工作又必須保存一個(gè)Activity。如果出現(xiàn)這種情況，我將會(huì)強(qiáng)烈建議你重新考慮你的設(shè)計(jì)，它將是一個(gè)很好的“反框架”教材。

經(jīng)驗(yàn)法則

絕大多數(shù)情況下，使用在你的所工作的組建內(nèi)部能夠直接獲取的Context。只要這個(gè)引用沒有超過這個(gè)組建的生命周期，你可以安全的保存這個(gè)引用。一旦你要保存一個(gè)context的引用，它超過了你的Activity或者Service的生命周期范圍，甚至是暫時(shí)的，你就需要轉(zhuǎn)換你的引用為Application context。