Android_Context詳解

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

Context的類型

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

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

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

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

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

保存引用

第一個我們需要解決問題是，在一個對象或者類內(nèi)部保存一個context引用，而它生命周期卻超過其保存引用的對象的生命周期。例如，創(chuàng)建一個自定義的單例，它需要一個context來加載資源或者獲取ContentProvider，從而保存一個指向當(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;

}

}

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

為了解決這個問題，我們修改單例永遠(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)在這個例子中，我們的Context來自哪里都沒有關(guān)系，因?yàn)槲覀冞@里保存引用是安全的。Application Context 本身就是一個單例，所以我們再創(chuàng)建另外一個static引用，不會造成任何內(nèi)存泄漏。另外一個很好的例子是，在后臺線程或者一個等待的Handler中保存Context的引用，也可以使用這樣的方法。

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

Context的能力

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