Android_Context詳解
Context對象是如此常見和傳遞使用，它可能會很容易產(chǎn)生并不是你預期的情形。加載資源、啟動一個新的Activity、獲取系統(tǒng)服務、獲取內(nèi)部文件路徑以及創(chuàng)建view(其實還遠不止這些)統(tǒng)統(tǒng)都需要Context對象來完成。我(原文作者)想做的只是給大家提供一些Context是如何工作的見解，以及讓大家在應用中更有效的使用Context的技巧。
Context的類型
并不是所有的context實例都是等價的。根據(jù)Android應用的組件不同，你訪問的context推向有些細微的差別。
Application - 是一個運行在你的應用進程中的單例。在Activity或者Service中，它可以通過getApplication()函數(shù)獲得，或者人和繼承于context的對象中，通過getApplicationContext()方法獲得。不管你是通過何種方法在哪里獲得的，在一個進程內(nèi)，你總是獲得到同一個實例。
Activity/Service - 繼承于ContextWrapper，它實現(xiàn)了與context同樣API，但是代理這些方法調(diào)用到內(nèi)部隱藏的Context實例，即我們所知道的基礎context。任何時候當系統(tǒng)創(chuàng)建一個新的Activity或者Service實例的時候，它也創(chuàng)建一個新的ContextImpl實例來做所有的繁重的工作。每一個Activity和Service以及其對應的基礎context，對每個實例來說都是唯一的。
BroadcastReciver - 它本身不是context，也沒有context在它里面，但是每當一個新的廣播到達的時候，框架都傳遞一個context對象到onReceive()。這個context是一個ReceiverRestrictedContext實例，它有兩個主要函數(shù)被禁掉：registerReceiver()和bindService()。這兩個函數(shù)在BroadcastReceiver.onReceive()不允許調(diào)用。每次Receiver處理一個廣播，傳遞進來的context都是一個新的實例。
ContentProvider - 它本身也不是一個Context，但是它可以通過getContext()函數(shù)給你一個Context對象。如果ContentProvider是在調(diào)用者的的本地(例如，在同一個應用進程)，getContext()將返回的是Application單例。然而，如果調(diào)用這個ContentProvider在不同的進程的時候，它將返回一個新創(chuàng)建的實例代表這個Provider所運行的包。
保存引用
第一個我們需要解決問題是，在一個對象或者類內(nèi)部保存一個context引用，而它生命周期卻超過其保存引用的對象的生命周期。例如，創(chuàng)建一個自定義的單例，它需要一個context來加載資源或者獲取ContentProvider，從而保存一個指向當前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的引用是并不安全的。這是一個問題，是因為一個單例在類的內(nèi)部維持一個唯一的靜態(tài)引用，這意味著我們的對象，以及所有其他它所引用的對象，將永遠不能被垃圾回收。假如這個Context是一個Activity，我們將保存與這個Activity相關的所有的view以及其他大的對象，從而造成內(nèi)存泄漏。
為了解決這個問題，我們修改單例永遠只是保存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來自哪里都沒有關系，因為我們這里保存引用是安全的。Application Context 本身就是一個單例，所以我們再創(chuàng)建另外一個static引用，不會造成任何內(nèi)存泄漏。另外一個很好的例子是，在后臺線程或者一個等待的Handler中保存Context的引用，也可以使用這樣的方法。
為什么我們不能總是引用Application context呢?正如前面說的，引用Application context永遠不用擔心內(nèi)存泄漏的問題。問題的答案，就像我在開始的介紹中說的，是因為不同context并不是等價的。
Context的能力
Conext能做的通用操作決定于這個context最初來源于哪里。下表所列的是，在應用中常見的會收到context對象的，以及對應的每種情況，它可以用于哪些地方：
| Application | Activity | Service | ContentProvider | BroadcastReceiver | |
|---|---|---|---|---|---|
| Show a Dialog | NO | YES | NO | NO | NO |
| Start an Activity | NO1 | YES | NO1 | NO1 | NO1 |
| Layout Inflation | NO2 | YES | NO2 | NO2 | NO2 |
| Start a Service | YES | YES | YES | YES | YES |
| Bind to a Service | YES | YES | YES | YES | NO |
| Send a Broadcast | YES | YES | YES | YES | YES |
| Register BroadcastReceiver | YES | YES | YES | YES | NO3 |
| Load Resource Values | YES | YES | YES | YES | YES |
注：NO1 表示Application context的確可以開始一個Activity，但是它需要創(chuàng)建一個新的task。這可能會滿足一些特定的需求，但是在你的應用中會創(chuàng)建一個不標準的回退棧(back stack)，這通常是不推薦的或者不是是好的實踐。
NO2 表示這是非法的，但是這個填充(inflation)的確可以完成，但是是使用所運行的系統(tǒng)默認的主題(theme)，而不是你app定義的主題。
NO3 在Android4.2以上，如果Receiver是null的話(這是用來獲取一個sticky broadcast的當前 值的)，這是允許的。
用戶界面UI
從前面的表格中可以看到，application context有很多功能并不是合適去做，而這些功能都與UI相關。實際上，只有Activity能夠處理所有與UI相關的任務。其他類別的context實例功能都差不多。
幸運的是，在應用中這三種操作基本上都不需要在Activity范圍之外進行，這很可能是android框架故意這么設計的。嘗試顯示一個使用Aplication context創(chuàng)建的Dialog，或者使用Application context開始一個Activity，系統(tǒng)會拋出一個異常，讓你的application崩潰，非常強的告訴你某些地方出了問題。
一個并不明顯的問題是填充布局(inflating layout)。如果你已經(jīng)讀過了我(原文作者)的上一篇文章Layout inflation，你就已經(jīng)知道它可能是一個非常神秘過程，伴隨一些隱藏的行為。使用正確的context關系到其中的一個行為。當你使用Application context來inflate一個布局的時候，框架并不會報錯，并返回一個使用系統(tǒng)默認的主題創(chuàng)建一個完美的view給你，而沒有考慮你的applicaiton自定義的theme和style。這是因為Acitivity是唯一的綁定了在manifast文件種定義主題的Context。其他的Context實例將會使用系統(tǒng)默認的主題來inflater你的view。導致顯示的結(jié)果并不是你所希望的。
規(guī)則的路口
可能有些讀者已經(jīng)得出兩個規(guī)則互相矛盾的結(jié)論。可能有些情況下，在某些Application的設計中，我們可能既必須長期保存一個的引用，并且為了完成與UI相關的工作又必須保存一個Activity。如果出現(xiàn)這種情況，我將會強烈建議你重新考慮你的設計，它將是一個很好的“反框架”教材。
經(jīng)驗法則
絕大多數(shù)情況下，使用在你的所工作的組建內(nèi)部能夠直接獲取的Context。只要這個引用沒有超過這個組建的生命周期，你可以安全的保存這個引用。一旦你要保存一個context的引用，它超過了你的Activity或者Service的生命周期范圍，甚至是暫時的，你就需要轉(zhuǎn)換你的引用為Application context。
下載文檔
