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。

这些成员的关系如下图所示：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IwoMPHeg-1587557612539)(https://note.youdao.com/yws/api/personal/file/51D6385112C144B29372AD679822B903?method=download&shareKey=23bdb3a3d1169dad244903a5875e43b2)]

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使用场景图：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vo6JTRp9-1587557612542)(https://note.youdao.com/yws/api/personal/file/2A4E0C992D1F4B8BA4DE0AD7CA2456BB?method=download&shareKey=033528fc05a2380b8f8a063fe3cbf373)]

大家注意看到有一些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中使用非静态内部类，因为非静态内部类会隐式持有外部类示例的引用，如果使用静态内部类，将外部实例引用作为弱引用持有。

最后

我是i猩人，总结不易，转载注明出处，喜欢本篇文章的童鞋欢迎点赞、关注哦。

参考

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