Android開發之Context認識和運用

談到Context，做Android的可以說是無人不知無人不曉，例如“XXXXActivity.this”、“getApplicationContext()”、“getContext()”等多種形式。雖然大家都知道，可是真正的去用好它也是一門藝術，深入不全免不了也要入坑。

之前我們項目上新增了一個懸浮球功能，獲取的是全局Application的WINDOW_SERVICE，然而那個懸浮球的實例卻採用的Activity的context，存在的問題就是內存回收時將此context回收掉，導致windowManager不能控制這個view了。

java.lang.IllegalArgumentException: View not attached to window manager

本篇就針對的Context深入學習做一個總結吧。

Context是什麼

Context，中文直譯爲“上下文”，它描述的是一個應用程序環境的信息，SDK中對其說明如下：

Interface to global information about an application environment. This is an abstract class whose implementation is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc

從Android系統的角度來理解：Context是一個場景，代表與操作系統的交互的一種過程。Context在加載資源、啓動Activity、獲取系統服務、創建View等操作都要參與。

從程序的角度上來理解：Context是個抽象類，而Activity、Service、Application等都是該類的一個實現。

Context的行爲

Context體現到代碼上來說，是個抽象類，其主要表達的行爲列表如下：

Context行爲分類	常用函數
使用系統提供的服務	getPackageManager()、getSystemService()…
基本功能	startActivity()、sendBroadcast()、registerReceiver()、startService()、bindService()、getContentResolver()…【內部基本上是和AMS打交道】
訪問資源	getAssets()、getResources()、getString()、getColor()、getClassLoader()…
和當前所寄身的進程之間的聯繫	getMainLooper()、getApplicationContext()…
和信息存儲相關	getSharedPreferences()、openFileInput()、openFileOutput()、deleteFile()、openOrCreateDatabase()、deleteDatabase()…

Context的關係譜

Context的系譜中主要包含Context、ContextImpl、ContextWrapper、ContextThemeWrapper以及最終的成員Application、Activity、Service。

這些成員的關係如下圖所示：

Context
├── ContextImpl
└── ContextWrapper
    ├── Application
    ├── ContextThemeWrapper
    │   └── Activity
    └── Service

從繼承關係圖中可以看出，Application類、Service類和Activity類都繼承了Context類。應用程序被啓動後，會爲應用程序創建一個全局的Application對應的Context對象。ContextImpl類是Context的真正實現。ContextWrapper類是Context的包裝類，可以在不改變ContextImpl的情況下，爲其增加一些自定義操作。ContextWrapper中的mBase實際上是一個ContextImpl對象。而ContextImpl類中的mOuterContext是一個Context對象，指向相對應的Activity或Service或Application。

是不是有點繞？沒關係，下邊就簡要分析一下這幾個成員的具體細節。

相關類介紹

Context

路徑： /frameworks/base/core/java/android/content/Context.java
說明：抽象類，提供了一組通用的API。

public abstract class Context {
	 ...
 	 public abstract Object getSystemService(String name);  //獲得系統級服務
	 public abstract void startActivity(Intent intent);     //通過一個Intent啓動Activity
	 public abstract ComponentName startService(Intent service);  //啓動Service
	 //根據文件名得到SharedPreferences對象
	 public abstract SharedPreferences getSharedPreferences(String name,int mode);
	 ...
}

ContextIml

路徑：/frameworks/base/core/java/android/app/ContextImpl.java
說明：該Context類的實現類爲ContextIml，該類實現了Context類的功能。請注意，該函數的大部分功能都是直接調用，其屬性mPackageInfo去完成，這點我們後面會講到。

/**
 * Common implementation of Context API, which provides the base
 * context object for Activity and other application components.
 */
class ContextImpl extends Context{
	//所有Application程序公用一個mPackageInfo對象
    ActivityThread.PackageInfo mPackageInfo;
    
    @Override
    public Object getSystemService(String name){
    	...
    	else if (ACTIVITY_SERVICE.equals(name)) {
            return getActivityManager();
        } 
    	else if (INPUT_METHOD_SERVICE.equals(name)) {
            return InputMethodManager.getInstance(this);
        }
    } 
    @Override
    public void startActivity(Intent intent) {
    	...
    	//開始啓動一個Activity
        mMainThread.getInstrumentation().execStartActivity(
            getOuterContext(), mMainThread.getApplicationThread(), null, null, intent, -1);
    }
}

ContextWrapper

路徑：\frameworks\base\core\java\android\content\ContextWrapper.java
說明：正如其名稱一樣，該類只是對Context類的一種包裝，該類的構造函數包含了一個真正的Context引用，即ContextImpl對象。

public class ContextWrapper extends Context {
    //該屬性指向一個ContextIml實例，一般在創建Application、Service、Activity時賦值
    Context mBase;  

    //創建Application、Service、Activity，會調用該方法給mBase屬性賦值
    protected void attachBaseContext(Context base) {
        if (mBase != null) {
            throw new IllegalStateException("Base context already set");
        }
        mBase = base;
    }

    @Override
    public void startActivity(Intent intent) {
        //調用mBase實例方法
        mBase.startActivity(intent);  
    }
}

ContextThemeWrapper

路徑：/frameworks/base/core/java/android/view/ContextThemeWrapper.java
說明：該類內部包含了主題(Theme)相關的接口，即android:theme屬性指定的。只有Activity需要主題，Service不需要主題，所以Service直接繼承於ContextWrapper類。

public class ContextThemeWrapper extends ContextWrapper {
	 //該屬性指向一個ContextIml實例，一般在創建Application、Service、Activity時賦值
	 private Context mBase;

	 //mBase賦值方式同樣有一下兩種
	 public ContextThemeWrapper(Context base, int themeres) {
	        super(base);
	        mBase = base;
	        mThemeResource = themeres;
	 }
 
	 @Override
	 protected void attachBaseContext(Context newBase) {
	        super.attachBaseContext(newBase);
	        mBase = newBase;
	 }
}

Context的創建時機

熟悉了Context的繼承關係後，我們接下來分析應用程序在什麼情況需要創建Context對象的。

Context的數量

應用程序創建Context實例的情況有如下幾種情況：

• 創建Application 對象時， 而且整個App共一個Application對象
• 創建Activity對象時
• 創建Service對象時

因此應用程序App共有的Context數目公式爲：
總Context實例個數 =1（Application對應的Context實例）+ Activity個數 + Service個數

具體的創建時機

創建Application對象的時機

每個應用程序在第一次啓動時，都會首先創建Application對象。如果對應用程序啓動一個Activity(startActivity)流程比較清楚的話，創建Application的時機在創建handleBindApplication()方法中，該函數位於ActivityThread.java類中 ，如下：

//創建Application時同時創建的ContextIml實例
private final void handleBindApplication(AppBindData data){
    ...
	///創建Application對象
    Application app = data.info.makeApplication(data.restrictedBackupMode, null);
    ...
}
 
public Application makeApplication(boolean forceDefaultAppClass, Instrumentation instrumentation) {
	...
	try {
        java.lang.ClassLoader cl = getClassLoader();
        ContextImpl appContext = new ContextImpl();    //創建一個ContextImpl對象實例
        appContext.init(this, null, mActivityThread);  //初始化該ContextIml實例的相關屬性
        ///新建一個Application對象 
        app = mActivityThread.mInstrumentation.newApplication(
                cl, appClass, appContext);
       appContext.setOuterContext(app);  //將該Application實例傳遞給該ContextImpl實例         
    } 
	...
}

創建Activity對象的時機

通過startActivity()或startActivityForResult()請求啓動一個Activity時，如果系統檢測需要新建一個Activity對象時，就會回調handleLaunchActivity()方法，該方法繼而調用performLaunchActivity()方法，去創建一個Activity實例，並且回調onCreate()、onStart()方法等，函數都位於ActivityThread.java類，如下：

//創建一個Activity實例時同時創建ContextIml實例
private final void handleLaunchActivity(ActivityRecord r, Intent customIntent) {
   ...
   Activity a = performLaunchActivity(r, customIntent);  //啓動一個Activity
}
private final Activity performLaunchActivity(ActivityRecord r, Intent customIntent) {
   ...
   Activity activity = null;
   try {
   	//創建一個Activity對象實例
       java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
       activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);
   }
   if (activity != null) {
       ContextImpl appContext = new ContextImpl();      //創建一個ContextImpl對象實例
       appContext.init(r.packageInfo, r.token, this);   //初始化該ContextIml實例的相關屬性
       appContext.setOuterContext(activity);            //將該Activity信息傳遞給該ContextImpl實例
       ...
   }
   ...    
}

創建Service對象的時機

通過startService或者bindService時，如果系統檢測到需要新創建一個Service實例，就會回調handleCreateService()方法，
完成相關數據操作。handleCreateService()函數位於ActivityThread.java類，如下：

//創建一個Service實例時同時創建ContextIml實例
private final void handleCreateService(CreateServiceData data){
	...
	Service service = null;
    try {
        //創建一個Service實例
        java.lang.ClassLoader cl = packageInfo.getClassLoader();
        service = (Service) cl.loadClass(data.info.name).newInstance();
    } catch (Exception e) {
    }
	...
	ContextImpl context = new ContextImpl(); //創建一個ContextImpl對象實例
    context.init(packageInfo, null, this);   //初始化該ContextIml實例的相關屬性
    //獲得我們之前創建的Application對象信息
    Application app = packageInfo.makeApplication(false, mInstrumentation);
    //將該Service信息傳遞給該ContextImpl實例
    context.setOuterContext(service);
    ...
}

重量級PackageInfo

需要強調一點的是，通過對ContextImp的分析可知，其方法的大多數操作都是直接調用其屬性mPackageInfo(該屬性類
型爲PackageInfo)的相關方法而來。這說明ContextImp是一種輕量級類，而PackageInfo纔是真正重量級的類。而一個App裏的所有ContextIml實例，都對應同一個packageInfo對象。

Context的getSharedPreferences()方法

這裏給大家分析利用Context獲取SharedPreferences類的使用方法，SharedPreferences類想必大家都使用過，其一般獲取方
法就是通過調用getSharedPreferences()方法去根據相關信息獲取SharedPreferences對象。具體流程如下：

1.調用getSharedPreferences()獲取對應的的文件，該函數實現功能如下：

//Context類靜態數據集合，以鍵值對保存了所有讀取該xml文件後所形成的數據集合
private static final HashMap<File, SharedPreferencesImpl> sSharedPrefs = 
	   new HashMap<File, SharedPreferencesImpl>(); 
 
@Override
public SharedPreferences getSharedPreferences(String name, int mode){
	 //其所對應的SharedPreferencesImpl對象 ，該對象已一個HashMap集合保存了我們對該文件序列化結果
	 SharedPreferencesImpl sp;  
     File f = getSharedPrefsFile(name);  //該包下是否存在對應的文件，不存在就新建一個
     synchronized (sSharedPrefs) {       //是否已經讀取過該文件，是就直接返回該SharedPreferences對象
         sp = sSharedPrefs.get(f);
         if (sp != null && !sp.hasFileChanged()) {
             //Log.i(TAG, "Returning existing prefs " + name + ": " + sp);
             return sp;
         }
     }
     //以下爲序列化該xml文件，同時將數據寫到map集合中     
     Map map = null;
     if (f.exists() && f.canRead()) {
         try {
             str = new FileInputStream(f);
             map = XmlUtils.readMapXml(str);
             str.close();
         } 
         ...
     }
     
     synchronized (sSharedPrefs) {
         if (sp != null) {
             //Log.i(TAG, "Updating existing prefs " + name + " " + sp + ": " + map);
             sp.replace(map);   //更新數據集合
         } else {
             sp = sSharedPrefs.get(f);
             if (sp == null) {  
            	 //新建一個SharedPreferencesImpl對象，並且設置其相關屬性
                 sp = new SharedPreferencesImpl(f, mode, map);  
                 sSharedPrefs.put(f, sp);
             }
         }
         return sp;
     }
}

2.SharedPreferences不過是個接口，它定義了一些操作xml文件的方法，其真正實現類爲SharedPreferencesImpl，該類是ContextIml的內部類，該類如下：

//SharedPreferences只是一種接口，其真正實現類是SharedPreferencesImpl類
private static final class SharedPreferencesImpl implements SharedPreferences{
    //保存了該文件序列化結果後的操作，鍵值對形式
	 private Map mMap;  
	 
	 //通過key值獲取對應的value值
	 public String getString(String key, String defValue) {
         synchronized (this) {
             String v = (String)mMap.get(key);
             return v != null ? v : defValue;
         }
     }
	 ...
	 //獲得該SharedPreferencesImpl對象對應的Edito類，對數據進行操作
	 public final class EditorImpl implements Editor {
         //保存了對鍵值變化的集合
		 private final Map<String, Object> mModified = Maps.newHashMap(); 
	 }
}

Context的使用

如何獲取Context

1. View.getContext()，返回當前Activity所在的應用進程的Context對象，通常是當前正在展示的Activity對象。
2. Activity.getApplicationContext()，獲取當前Activity所在的（應用）進程的Context對象，通常我們使用Context對象時，要優先考慮這個全局的進程Context。
3. Activity.this，返回當前的Activity實例，如果是UI控件需要使用Activity作爲Context對象，但是默認的Toast因爲是系統層級的Windows，直接使用ApplicationContext則可。
4. getApplication()，和getApplicationContext獲取的對象一致的，但是getApplication方法只有在Activity和Service中才能調到。例如BroadcasrReceiver中需要獲取Application，則需要藉助getApplicationContext（）方法。

Context的使用場景

先來看一張Context使用場景圖：

大家注意看到有一些NO上添加了一些數字，其實這些從能力上來說是YES，但是爲什麼說是NO呢？下面一個一個解釋：

• 數字1：啓動Activity在這些類中是可以的，但是需要創建一個新的task。一般情況不推薦。
• 數字2：在這些類中去layout inflate是合法的，但是會使用系統默認的主題樣式，如果你自定義了某些樣式可能不會被使用。
• 數字3：在receiver爲null時允許，在4.2或以上的版本中，用於獲取黏性廣播的當前值。（可以無視）

注：ContentProvider、BroadcastReceiver之所以在上述表格中，是因爲在其內部方法中都有一個context用於使用。

這裏我們看下錶格，重點看Activity和Application，可以看到，和UI相關的方法基本都不建議或者不可使用Application。並且，前三個操作基本不可能在Application中出現。實際上，只要把握住一點，凡是跟UI相關的，都應該使用Activity做爲Context來處理；其他的一些操作，Service,Activity,Application等實例都可以，當然了，注意Context引用的持有，防止內存泄漏。

假如我是面試官，問你Service能否啓動Activity呢，想必你也應該知道怎麼回答了吧

Context引起的內存泄漏

Context引起的內存泄漏也是很恐怖的，下邊就舉例兩個場景：

1.錯誤的單例模式

public class Singleton {
    private static Singleton instance;
    private Context mContext;
 
    private Singleton(Context context) {
        this.mContext = context;
    }
 
    public static Singleton getInstance(Context context) {
        if (instance == null) {
            instance = new Singleton(context);
        }
        return instance;
    }
}

這種情況下即使Activity被銷燬掉，但因爲它的引用還存在於一個Singleton中，就不可能被GC掉。

2.View持有Activity引用

public class MainActivity extends Activity {
    private static Drawable mDrawable;
 
    @Override
    protected void onCreate(Bundle saveInstanceState) {
        super.onCreate(saveInstanceState);
        setContentView(R.layout.activity_main);
        ImageView iv = new ImageView(this);
        mDrawable = getResources().getDrawable(R.drawable.ic_launcher);
        iv.setImageDrawable(mDrawable);
    }
}

有一個靜態的Drawable對象當ImageView設置這個Drawable時，ImageView保存了mDrawable的引用，而ImageView傳入的this是MainActivity的mContext，因爲被static修飾的mDrawable是常駐內存的，MainActivity是它的間接引用，MainActivity被銷燬時，也不能被GC掉，所以造成內存泄漏。

所以我們平時使用的時候儘量保證以下幾點：

1. 如果不涉及Activity的主題樣式，儘量使用Application的Context。
2. 不要讓生命週期長於Activity的對象持有其的引用。
3. 儘量不要在Activity中使用非靜態內部類，因爲非靜態內部類會隱式持有外部類示例的引用，如果使用靜態內部類，將外部實例引用作爲弱引用持有。

參考

• https://blog.csdn.net/lmj623565791/article/details/40481055
• https://blog.csdn.net/qinjuning/article/details/7310620
• https://developer.android.com/reference/android/content/Context