Android中的Context詳解

Jlog發表於2016-02-01
AndroidContext

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。

相關文章