一、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的引用。
通常在一個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導致
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
Android中Activity共享變量的另一方法:Application context
4. Context內存溢出相關資料
Android學習系列(36)--App調試內存泄露之Context篇(上)Android學習系列(37)--App調試內存泄露之Context篇(下)
四、自己創建Context
Android獲取其他包的Context實例然後幹壞事