前言
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上數字含義:
- 一個非Activity的Context可以用於啟動一個Activity,但這樣啟動的Activity需要新建立一個Activity堆疊棧。這個在某些特定情形下或許會適用,一般情況不推薦。
- 這個其實也是可以的,但是這樣匯入的布局會用當前系統的預設主題來設定,若是自訂了某些樣式可能不會被使用。
- 在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開發人員們能有所協助,如果有疑問大家可以留言交流。