Context完全解析，Context解析

Context完全解析，Context解析
  
1· Context類型
       我們知道，Android應用都是使用Java語言來編寫的，那麼大家可以思考一下，一個Android程式和一個Java程式，他們最大的區別在哪裡？劃分界限又是什麼呢？其實簡單點分析，Android程式不像Java程式一樣，隨便建立一個類，寫個main()方法就能跑了，而是要有一個完整的Android工程環境，在這個環境下，我們有像Activity、Service、BroadcastReceiver等系統組件，而這些組件並不是像一個普通的Java對象new一下就能建立執行個體的了，而是要有它們各自的上下文環境，也就是我們這裡討論的Context。可以這樣講，Context是維持Android程式中各組件能夠正常工作的一個核心功能類。      下面我們來看一下Context的繼承結構：

 

         Context的繼承結構還是稍微有點複雜的，可以看到，直系子類有兩個，一個是ContextWrapper，一個是ContextImpl。那麼從名字上就可以看出，ContextWrapper是上下文功能的封裝類，而ContextImpl則是上下文功能的實作類別。而ContextWrapper又有三個直接的子類， ContextThemeWrapper、Service和Application。其中，ContextThemeWrapper是一個帶主題的封裝類，而它有一個直接子類就是Activity。

          那麼在這裡我們至少看到了幾個所比較熟悉的面孔，Activity、Service、還有Application。由此，其實我們就已經可以得出結論了，Context一共有三種類型，分別是Application、Activity和Service。這三個類雖然分別各種承擔著不同的作用，但它們都屬於Context的一種，而它們具體Context的功能則是由ContextImpl類去實現的。

          那麼Context到底可以實現哪些功能呢？這個就實在是太多了，彈出Toast、啟動Activity、啟動Service、發送廣播、操作 資料庫等等等等都需要用到Context。由於Context的具體能力是由ContextImpl類去實現的，因此在絕大多數情境下，Activity、Service和Application這三種類型的Context都是可以通用的。不過有幾種情境比較特殊，比如啟動Activity，還有彈出Dialog。出於安全原因的考慮，Android是不允許Activity或Dialog憑空出現的，一個Activity的啟動必須要建立在另一個Activity的基礎之上，也就是以此形成的返回棧。而Dialog則必須在一個Activity上面彈出（除非是System Alert類型的Dialog），因此在這種情境下，我們只能使用Activity類型的Context，否則將會出錯。         

2. Context數量

          那麼一個應用程式中到底有多少個Context呢？其實根據上面的Context類型我們就已經可以得出答案了。Context一共有Application、Activity和Service三種類型，因此一個應用程式中Context數量的計算公式就可以這樣寫：

 

Context數量 = Activity數量 + Service數量 + 1  

 

        上面的1代表著Application的數量，因為一個應用程式中可以有多個Activity和多個Service，但是只能有一個Application。