Android Context原理與使用的總結



一、Context繼承體系 與 Context是如何創建的

1. Context繼承體系

只用記住一句:Activity 、 Service 與Application 都是繼承自ContextWrapper,而ContextWrapper implements Context。每個:Activity 、 Service 與Application都是一個Context實例。


2. Context 何時創建、怎樣創建的 - 查看源碼


以上3篇文章都是從源碼角度分析Context何時創建的,但是對於平時的開發來說,僅需要知道Activity 與Service 都是繼承自Context,只要創建新的Activity 或者 Service 實例,都是創建新的Context實例。

Context 總數 = Activity個數 + Service 個數 + 1個ApplicationContext

可以通過命令行 查看Context的個數
adb shell dumpsys meminfo package_name


二、關於Context的疑問

1. getBaseContext 與 getApplicationContext 區別?
持有Activity的Context 相當於持有Context,而持有AppliactionContex全局僅有這一個

2. 視圖中的Context從哪來的?
例如:new TextView(Context);
通常在一個Activity中傳入的就是當前Activity或者Activity.getBaseContext(),所以通過View.getContext()其實就是當前Activity的引用。

常見場景,Adapter通常通過構造器傳遞Context,用於getView 時inflate 視圖。但是getView最有一個參數是parentView 這個是ListView對象本身,可以通過parentView.getContext獲取Context對象減少手動傳遞。

3. Context 會出錯的地方
Dialog.Builder必須傳入Activity,而不能傳入Activity.getApplicationContext()

4. Context作用,查看方法
訪問資源、創建視圖、創建四大組件

Context是什麼?

參考資料: 

三 內存溢出,因爲引用Context導致

1. Context導致內存溢出的原因:
以上文章講解的很詳細可以查看文章,以下是簡單描述:
最常見的內存形式是Bitmap未得到釋放,而圖片通常ImageView持有導致ImageView也不會被GC釋放,創建ImageView肯定需要Context,這個Context是Activity。
Bitmap -> ImageView -> Contex(Activity)
如果Activity總是不能得到釋放,導致內存不足最終OOM


2. 對於生命週期很長的對象,使用ApplicationContext,以下文檔介紹自定義Application可以在項目全局都很方便獲取Application Context的方法

使用自定義Application,需要Context對象時傳入,避免因持有Context導致的內存溢出。因爲ApplicationContext全局僅有一個實例,而多個Activity本身繼承自Context,就是多個Context實例。
Android中Activity共享變量的另一方法:Application context

4. Context內存溢出相關資料
Android學習系列(36)--App調試內存泄露之Context篇(上)
Android學習系列(37)--App調試內存泄露之Context篇(下)

四、自己創建Context

Android獲取其他包的Context實例然後幹壞事




發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章