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的引用在單例中。

糟糕的單例

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的引用是並不安全的。這是一個問題，是因為一個單例在類的內部維持一個唯一的靜態引用，這意味著我們的對象，以及所有其他它所引用的對象，將永遠不能被垃圾回收。假如這個Context是一個Activity，我們將保存與這個Activity相關的所有的view以及其他大的對象，從而造成內存洩漏。

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

改善的單例：

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;  
  }  
}

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

為什麼我們不能總是引用Application context呢？正如前面說的，引用Application context永遠不用擔心內存洩漏的問題。問題的答案，就像我在開始的介紹中說的，是因為不同context並不是等價的。

Context的能力

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

Application Activity Service ContentProvider BroadcastReceiver 顯示Dialog NO YES NO NO NO 啟動Activity NO1 YES NO1 NO1 NO1 Layout Inflation NO2 YES NO2 NO2 NO2 啟動Service YES YES YES YES YES 綁定到Service YES YES YES YES NO 發送Broadcast YES YES YES YES YES 注冊BroadcastReceiver YES YES YES YES NO3 加載Resource YES YES YES YES YES

注：

1. NO1 表示Application context的確可以開始一個Activity，但是它需要創建一個新的task。這可能會滿足一些特定的需求，但是在你的應用中會創建一個不標准的回退棧（back stack），這通常是不推薦的或者不是是好的實踐。
2. NO2 表示這是非法的，但是這個填充（inflation）的確可以完成，但是是使用所運行的系統默認的主題（theme），而不是你app定義的主題。
3. 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。