Android開發 - Context解析

Context是什麼

• Context的中文翻譯為：語境; 上下文; 背景; 環境，在開發中我們經常說稱之為“上下文”，那麼這個“上下文”到底是指什麼意思呢？在語文中，我們可以理解為語境，在程式中，我們可以理解為當前物件在程式中所處的一個環境，一個與系統互動的過程。比如微信聊天，此時的“環境”是指聊天的介面以及相關的資料請求與傳輸，Context在載入資源、啟動Activity、獲取系統服務、建立View等操作都要參與

• 那Context到底是什麼呢？一個Activity就是一個Context，一個Service也是一個Context。Android程式設計師把“場景”抽象為Context類，他們認為使用者和作業系統的每一次互動都是一個場景，比如打電話、發簡訊，這些都是一個有介面的場景，還有一些沒有介面的場景，比如後臺執行的服務（Service）。一個應用程式可以認為是一個工作環境，使用者在這個環境中會切換到不同的場景，這就像一個前臺秘書，她可能需要接待客人，可能要列印檔案，還可能要接聽客戶電話，而這些就稱之為不同的場景，前臺秘書可以稱之為一個應用程式

• 原始碼中的註釋是這麼來解釋Context的：Context提供了關於應用環境全域性資訊的介面。它是一個抽象類，它的執行被Android系統所提供。它允許獲取以應用為特徵的資源和型別，是一個統領一些資源（應用程式環境變數等）的上下文。就是說，它描述一個應用程式環境的資訊（即上下文）；是一個抽象類，Android提供了該抽象類的具體實現類；透過它我們可以獲取應用程式的資源和類（包括應用級別操作，如啟動Activity，發廣播，接受Intent等）。既然上面Context是一個抽象類，那麼肯定有他的實現類咯，我們在Context的原始碼中透過IDE可以檢視到他的子類最終可以得到如下關係圖：

​

• Context類本身是一個純abstract類，它有兩個具體的實現子類：ContextImpl和ContextWrapper。其中ContextWrapper類，如其名所言，這只是一個包裝而已，ContextWrapper建構函式中必須包含一個真正的Context引用，同時ContextWrapper中提供了attachBaseContext()用於給ContextWrapper物件中指定真正的Context物件，呼叫ContextWrapper的方法都會被轉向其所包含的真正的Context物件。ContextThemeWrapper類，如其名所言，其內部包含了與主題（Theme）相關的介面，這裡所說的主題就是指在AndroidManifest.xml中透過android:theme為Application元素或者Activity元素指定的主題。當然，只有Activity才需要主題，Service是不需要主題的，因為Service是沒有介面的後臺場景，所以Service直接繼承於ContextWrapper，Application同理。而ContextImpl類則真正實現了Context中的所有函式，應用程式中所呼叫的各種Context類的方法，其實現均來自於該類。一句話總結：Context的兩個子類分工明確，其中ContextImpl是Context的具體實現類，ContextWrapper是Context的包裝類。Activity、Application、Service雖都繼承自ContextWrapper（Activity繼承自ContextWrapper的子類ContextThemeWrapper），但它們初始化的過程中都會建立ContextImpl物件，由ContextImpl實現Context中的方法

Context能幹什麼

• Context到底可以實現哪些功能呢？這個就實在是太多了：彈出Toast、啟動Activity、啟動Service、傳送廣播、運算元據庫等等都需要用到Context，部分例項如下：

  TextView tv = new TextView(getContext());  
    
  ListAdapter adapter = new SimpleCursorAdapter(getApplicationContext(), …);  
    
  AudioManager am = (AudioManager)getContext().getSystemService(Context.AUDIO_SERVICE);
  getApplicationContext().getSharedPreferences(name, mode);  
    
  getApplicationContext().getContentResolver().query(uri, …);  
    
  getContext().getResources().getDisplayMetrics().widthPixels * 5 / 8;  
    
  getContext().startActivity(intent);  
    
  getContext().startService(intent);  
    
  getContext().sendBroadcast(intent); 
  

Context作用域

• 雖然Context神通廣大，但並不是隨便拿到一個Context例項就可以為所欲為，它的使用還是有一些規則限制的。由於Context的具體例項是由ContextImpl類去實現的，因此在絕大多數場景下，Activity、Service和Application這三種型別的Context都是可以通用的。不過有幾種場景比較特殊，比如啟動Activity，還有彈出Dialog。出於安全原因的考慮，Android是不允許Activity或Dialog憑空出現的，一個Activity的啟動必須要建立在另一個Activity的基礎之上，也就是以此形成的返回棧。而Dialog則必須在一個Activity上面彈出（除非是System Alert型別的Dialog），因此在這種場景下，我們只能使用Activity型別的Context，否則將會出錯

• 其中Activity所持有的Context的作用域最廣，無所不能。因為Activity繼承自ContextThemeWrapper，而Application和Service繼承自ContextWrapper，很顯然ContextThemeWrapper在ContextWrapper的基礎上又做了一些操作使得Activity變得更強大。以下說明Application和Service所不推薦的兩種使用情況：

  1. 如果我們用ApplicationContext去啟動一個LaunchMode為standard的Activity的時候會報錯android.util.AndroidRuntimeException: Calling startActivity from outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK flag. Is this really what you want?這是因為非Activity型別的Context並沒有所謂的任務棧，所以待啟動的Activity就找不到棧了。解決這個問題的方法就是為待啟動的Activity指定FLAG_ACTIVITY_NEW_TASK標記位，這樣啟動的時候就為它建立一個新的任務棧，而此時Activity是以singleTask模式啟動的。所有這種用Application啟動Activity的方式不推薦使用，Service同Application

  2. 在Application和Service中去layout inflate也是合法的，但是會使用系統預設的主題樣式，如果你自定義了某些樣式可能不會被使用。所以這種方式也不推薦使用。

  • 一句話總結：凡是跟UI相關的，都應該使用Activity做為Context來處理；其他的一些操作，Service、Activity、Application等例項都可以，當然了，注意Context引用的持有，防止記憶體洩漏。

如何獲取Context

獲取Context物件

• 主要提供以下2種方法：

  1. getView().getContext()：返回當前View物件的Context物件，通常是當前正在展示的Activity物件

  2. getActivity().getApplicationContext()：獲取當前Activity所在的(應用)程序的Context物件，通常我們使用Context物件時，要優先考慮這個全域性的程序Context

getApplication()和getApplicationContext()的區別

• Application本身就是一個Context，所以這裡獲取getApplicationContext()得到的結果就是Application本身的例項。那麼問題來了，既然這兩個方法得到的結果都是相同的，那麼Android為什麼要提供兩個功能重複的方法呢？實際上這兩個方法在作用域上有比較大的區別。getApplication()方法的語義性非常強，一看就知道是用來獲取Application例項的，但是這個方法只有在Activity和Service中才能呼叫的到。那麼也許在絕大多數情況下我們都是在Activity或者Service中使用Application的，但是如果在一些其它的場景，比如BroadcastReceiver中也想獲得Application的例項，這時就可以藉助getApplicationContext()方法了，下面提供兩種獲取方法：

  public classMyReceiver extends BroadcastReceiver{  
      @Override  
      public void onReceive(Context context,Intent intent){  
          //第一種方法
          Application myApp = (Application)context.getApplicationContext();	
          ---
          //第二種方法
          context = getActivity().getApplicationContext();
          Application myApp = (Application)context; 
      }  
  } 
  

Context引起的記憶體洩露

• 但Context並不能隨便亂用，用的不好有可能會引起記憶體洩露的問題，下面就示例兩種錯誤的引用方式：

  1. 錯誤的單例模式：

     public class Singleton {      
         private static Singleton instance;      
         private Context mContext;    
             
         private Singleton(Context context) {          
             this.mContext = context;  
         }      
               
         public static Singleton getInstance(Context context) {         
             if (instance == null) {  
                  instance = new Singleton(context);  
             }         
             return instance;  
         }  
     }  
     

     • 這是一個非執行緒安全的單例模式，instance作為靜態物件，其生命週期要長於普通的物件，其中也包含Activity，假如Activity A去getInstance獲得instance物件，傳入this，常駐記憶體的Singleton儲存了你傳入的Activity A物件，並一直持有，即使Activity被銷燬掉，但因為它的引用還存在於一個Singleton中，就不可能被GC(咔擦)掉，這樣就導致了記憶體洩漏

  2. 錯誤的View持有Activity引用

     public class MainActivity extends Activity {  
         private static Drawable mDrawable;   
          
         @Override  
         protected void onCreate(Bundle saveInstanceState) {          
             super.onCreate(saveInstanceState);  
             setContentView(R.layout.activity_main);          
             ImageView iv = new ImageView(this);  
             mDrawable = getResources().getDrawable(R.drawable.ic_launcher);  
             iv.setImageDrawable(mDrawable);
         }  
     }  
     

     • 有一個靜態的Drawable物件當ImageView設定這個Drawable時，ImageView儲存了mDrawable的引用，而ImageView傳入的this是MainActivity的mContext，因為被static修飾的mDrawable是常駐記憶體的，MainActivity是它的間接引用，MainActivity被銷燬時，也不能被GC(咔擦)掉，所以造成記憶體洩漏

正確使用Context

• 一般Context造成的記憶體洩漏，幾乎都是當Context銷燬的時候，卻因為被引用導致銷燬失敗，而Application的Context物件可以理解為隨著程序存在的，所以我們總結出使用Context的正確姿勢：
  1. 當Application的Context能搞定的情況下，並且生命週期長的物件，優先使用Application的Context
  2. 不要讓生命週期長於Activity的物件持有到Activity的引用
  3. 儘量不要在Activity中使用非靜態內部類，因為非靜態內部類會隱式持有外部類例項的引用，如果使用靜態內部類，外部例項將引用作為弱引用持有

總結

• Context在Android系統中的地位很重要，它幾乎無所不能，但它也不是你想用就能隨便用的，謹防使用不當引起的記憶體問題