Android_Context詳解

Context可能是Android應用中最常用的元素，而它也可能是最容易誤用的。

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

Context的類型

並不是所有的context實例都是等價的。根據Android應用的組件不同，你訪問的context推向有些細微的差別。

Application － 是一個運行在你的應用進程中的單例。在Activity或者Service中，它可以通過getApplication()函數獲得，或者人和繼承於context的對象中，通過getApplicationContext()方法獲得。不管你是通過何種方法在哪裡獲得的，在一個進程內，你總是獲得到同一個實例。

Activity/Service － 繼承於ContextWrapper，它實現了與context同樣API，但是代理這些方法調用到內部隱藏的Context實例，即我們所知道的基礎context。任何時候當系統創建一個新的Activity或者Service實例的時候，它也創建一個新的ContextImpl實例來做所有的繁重的工作。每一個Activity和Service以及其對應的基礎context，對每個實例來說都是唯一的。

BroadcastReciver － 它本身不是context，也沒有context在它裡面，但是每當一個新的廣播到達的時候，框架都傳遞一個context對象到onReceive()。這個context是一個ReceiverRestrictedContext實例，它有兩個主要函數被禁掉：registerReceiver()和bindService()。這兩個函數在BroadcastReceiver.onReceive()不允許調用。每次Receiver處理一個廣播，傳遞進來的context都是一個新的實例。

ContentProvider － 它本身也不是一個Context，但是它可以通過getContext()函數給你一個Context對象。如果ContentProvider是在調用者的的本地（例如，在同一個應用進程），getContext()將返回的是Application單例。然而，如果調用這個ContentProvider在不同的進程的時候，它將返回一個新創建的實例代表這個Provider所運行的包。

保存引用

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

糟糕的單例

1. public class CustomManager {
2. private static CustomManager sInstance;
3.  
4. public static CustomManager getInstance(Context context) {
5. if (sInstance == null) {
6. sInstance = new CustomManager(context);
7. }
8.  
9. return sInstance;
10. }
11.  
12. private Context mContext;
13.  
14. private CustomManager(Context context) {
15. mContext = context;
16. }
17. }

     

    這裡的問題在於，我們不知道這個context是從哪裡來的，並且如果保存一個最終指向的是Activity或者Servece的引用是並不安全的。這是一個問題，是因為一個單例在類的內部維持一個唯一的靜態引用，這意味著我們的對象，以及所有其他它所引用的對象，將永遠不能被垃圾回收。假如這個Context是一個Activity，我們將保存與這個Activity相關的所有的view以及其他大的對象，從而造成內存洩漏。

    為了解決這個問題，我們修改單例永遠只是保存Application context：

     

    改善的單例：

     

    [java 
    1. public class CustomManager {
    2. private static CustomManager sInstance;
    3.  
    4. public static CustomManager getInstance(Context context) {
    5. if (sInstance == null) {
    6. //Always pass in the Application Context
    7. sInstance = new CustomManager(context.getApplicationContext());
    8. }
    9.  
    10. return sInstance;
    11. }
    12.  
    13. private Context mContext;
    14.  
    15. private CustomManager(Context context) {
    16. mContext = context;
    17. }
    18. }

         

        現在這個例子中，我們的Context來自哪裡都沒有關系，因為我們這裡保存引用是安全的。Application Context 本身就是一個單例，所以我們再創建另外一個static引用，不會造成任何內存洩漏。另外一個很好的例子是，在後台線程或者一個等待的Handler中保存Context的引用，也可以使用這樣的方法。

         

        為什麼我們不能總是引用Application context呢？正如前面說的，引用Application context永遠不用擔心內存洩漏的問題。問題的答案，就像我在開始的介紹中說的，是因為不同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，但是它需要創建一個新的task。這可能會滿足一些特定的需求，但是在你的應用中會創建一個不標准的回退棧（back stack），這通常是不推薦的或者不是是好的實踐。

        NO2 表示這是非法的，但是這個填充（inflation）的確可以完成，但是是使用所運行的系統默認的主題（theme），而不是你app定義的主題。

        NO3 在Android4.2以上，如果Receiver是null的話（這是用來獲取一個sticky broadcast的當前 值的），這是允許的。

        用戶界面UI

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

        幸運的是，在應用中這三種操作基本上都不需要在Activity范圍之外進行，這很可能是android框架故意這麼設計的。嘗試顯示一個使用Aplication context創建的Dialog，或者使用Application context開始一個Activity，系統會拋出一個異常，讓你的application崩潰，非常強的告訴你某些地方出了問題。

         

        一個並不明顯的問題是填充布局（inflating layout）。如果你已經讀過了我（原文作者）的上一篇文章Layout inflation，你就已經知道它可能是一個非常神秘過程，伴隨一些隱藏的行為。使用正確的context關系到其中的一個行為。當你使用Application context來inflate一個布局的時候，框架並不會報錯，並返回一個使用系統默認的主題創建一個完美的view給你，而沒有考慮你的applicaiton自定義的theme和style。這是因為Acitivity是唯一的綁定了在manifast文件種定義主題的Context。其他的Context實例將會使用系統默認的主題來inflater你的view。導致顯示的結果並不是你所希望的。

         

        規則的路口

        可能有些讀者已經得出兩個規則互相矛盾的結論。可能有些情況下，在某些Application的設計中，我們可能既必須長期保存一個的引用，並且為了完成與UI相關的工作又必須保存一個Activity。如果出現這種情況，我將會強烈建議你重新考慮你的設計，它將是一個很好的“反框架”教材。

         

        經驗法則

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