前言

Context，在翻譯為上下文，也可以理解為環境，是提供一些程序的運行環境基礎信息。基本上在開發項目的時候，時刻都有接觸到。Android程序不像Java程序，隨便創建一個類，寫個main()方法就能跑，而是要有一個完整的Android工程環境，在這個環境下，有像Activity、Service、BroadcastReceiver等系統組件，而這些組件并不是像一個普通的Java對象new一下就能創建實例的了，而是要有它們各自的上下文環境，也就是Context。可以說Context是維持Android程序中各組件能夠正常工作的一個核心功能類。

Context是個抽象類，下圖取自網絡，可以看到Context的繼承結構。

ContextWrapper是上下文功能的封裝類，而ContextImpl則是上下文功能的實現類。

而ContextWrapper又有三個直接的子類， ContextThemeWrapper、Service和Application。其中，ContextThemeWrapper是一個帶主題的封裝類，而它有一個直接子類就是Activity，所以Activity和Service以及Application的Context是不一樣的，只有Activity需要主題，Service不需要主題。

Context一共有三種類型，分別是Application、Activity和Service。

這三個類雖然分別各種承擔著不同的作用，但它們都屬于Context的一種，而它們具體Context的功能則是由ContextImpl類去實現的，因此在絕大多數場景下，Activity、Service和Application這三種類型的Context都是可以通用的。不過有幾種場景比較特殊，比如啟動Activity，還有彈出Dialog。出于安全原因的考慮，Android是不允許Activity或Dialog憑空出現的，一個Activity的啟動必須要建立在另一個Activity的基礎之上，也就是以此形成的返回棧。而Dialog則必須在一個Activity上面彈出（除非是System Alert類型的Dialog），因此在這種場景下，我們只能使用Activity類型的Context，否則將會出錯。

Context應用場景：

NO上數字含義：

1. 一個非Activity的Context可以用于啟動一個Activity，但這樣啟動的Activity需要新創建一個Activity堆疊棧。這個在某些特定情形下或許會適用，一般情況不推薦。
   
2. 這個其實也是可以的，但是這樣導入的布局會用當前系統的默認主題來設置，若是自定義了某些樣式可能不會被使用。
   
3. 在Android 4.2及以上的系統里，若receiver為null，則允許，用于獲取黏性廣播的當前值。
   

每一個Activity和Service以及Application的Context都是一個新的ContextImpl對象。

getApplication()用來獲取Application實例的，但是這個方法只有在Activity和Service中才能調用的到。那么也許在絕大多數情況下我們都是在Activity或者Service中使用Application的，但是如果在一些其它的場景，比如BroadcastReceiver中也想獲得Application的實例，這時就可以借助getApplicationContext()方法，getApplicationContext()比getApplication()方法的作用域會更廣一些，任何一個Context的實例，只要調用getApplicationContext()方法都可以拿到我們的Application對象。

getBaseContext()方法得到的是一個ContextImpl對象。Application、Activity這樣的類其實并不會去具體實現Context的功能，而僅僅是做了一層接口封裝而已，Context的具體功能都是由ContextImpl類去完成的。

Context數量 = Activity數量 + Service數量 + 1 （1為Application）

最后注意下Context的引用，防止內存泄露問題，還有關于Context源碼分析，網上還是很多資料可參考的。

總結

以上就是這篇文章的全部內容了，希望本文的內容對各位Android開發者們能有所幫助，如果有疑問大家可以留言交流。