原文链接：https://blog.csdn.net/LoveFHM/article/details/139291276
一、什么是Context？
Context是一个抽象基类。在翻译为上下文，是提供一些程序的运行环境基础信息。
如下图：Context下有两个子类，ContextWrapper是上下文功能的封装类（起到方法传递的作用，主要实现还是ContextImpl），而ContextImpl则是上下文功能的实现类。
- 如下图：ContextWrapper又有三个直接的子类，ContextThemeWrapper、Service和Application。其中，ContextThemeWrapper是一个带主题的封装类，所说的主题就是指在AndroidManifest.xml中通过android：theme为Application元素或者Activity元素指定的主题，而它有一个直接子类就是Activity，所以Activity和Service以及Application的Context是不一样的，只有Activity需要主题，Service不需要主题。
- 其中最核心的类就是ContextImpl类。ContextImpl类继承了抽象类Context并且实现所有的抽象方法，并且自身还实现了很多get，create,check开头的方法。
- 一个应用程序进程中有多少个 Context ，这个数量等于 Activity 和 Service 的总个数加 1，1指的是 Application 的数量。
二、Context的子类及其作用
Context一共有三种类型，分别是Application、Activity和Service。
这三个类虽然分别各种承担着不同的作用，但它们都属于Context的一种，而它们具体Context的功能则是由ContextImpl类去实现的，因此在绝大多数场景下，Activity、Service和Application这三种类型的Context都是可以通用的。
在我们的实际开发中，context会被大量的使用到，例如startActivity，访问资源，toast弹出，dialog，启动service，发送广播等等。
不过有几种场景要特别注意，
比如启动Activity，还有弹出Dialog。出于安全原因的考虑，Android是不允许Activity或Dialog凭空出现的，一个Activity的启动必须要建立在另一个Activity的基础之上，也就是以此形成的返回栈。而Dialog则必须在一个Activity上面弹出（除非是系统级别吐司），因此在这种场景下，我们只能使用Activity类型的Context，否则将会出错。
再比如我们用ApplicationContext去启动一个LaunchMode为standard的Activity的时候会报错，因为这时候的ApplicationContext，它没有任务栈啊，解决这个问题的方法就是为待启动的Activity指定FLAG_ACTIVITY_NEW_TASK标记位，这样启动的时候就为它创建一个新的任务栈。
三、Context的获取
-
View.getContext,返回当前View对象的Context对象，通常是当前正在展示的Activity对象。
例如我们在adapter里面
image.png - Activity.getApplicationContext,获取当前Activity所在的(应用)进程的Context对象，通常我们使用Context对象时，要优先考虑这个全局的进程Context。
getApplication和getApplicationContext的区别。如果你在Activity里面打印这个两个方法的话，得到对象内存地址是一样的，也就是这两个方法获取的对象是一样的？实际上，这两个获取到的对象就是同一个对象，Application本身就是一个Context，所以这里获取getApplicationContext()得到的结果就是Application本身的实例。他们只是可以使用的范围是不一样的
getApplication这个方法一看就知道是用来获取Application实例的，只有Activity和Service才有,要想在别的地方获取Application就只能通过getApplicationContext获取（例如广播）。
- ContextWrapper.getBaseContext():用来获取一个ContextWrapper进行装饰之前的Context（用得少，不介绍）
四、Context内存泄漏
这个context的内存泄漏在app开发中随处可见，一个activity本来应该被回收了，但是因为内部类啊，或者有些静态方法的引用导致无法被回收。
所以说，我们应当
- 当Application的Context能搞定的情况下，并且生命周期长的对象，优先使用Application的Context。
- 不要让生命周期长于Activity的对象持有到Activity的引用。
- 尽量不要在Activity中使用非静态内部类，因为非静态内部类会隐式持有外部类实例的引用，如果使用静态内部类，将外部实例引用作为弱引用持有。
五、Context的创建源码分析
application，activity和service的创建流程，其实都是通过反射后创建application，activity和service对象的同时创建了一个ContextImpl对象，并与之关联。
简要流程：
- application
- ActivityThread.main方法--> ActivityManagerService.bindApplication方法 --> ActivityThread.handleBindApplication --> 创建Instrumentation，创建Application；
- 每个应用进程对应一个Instrumentation，对应一个Application；
- Instrumentation与Application都是通过java反射机制创建；
- Application 创建过程中会同时创建一个 ContextImpl 对象，并建立关联；
- acticity
- Activity中创建ContextImpl对象的具体实现在ActivityThread的performLauncherActivity方法中；
- Activity的创建伴随着ContextImpl的创建，二者相互持有对方的引用；
- service
- ActivityThread的main方法走到thread.attach(false);
- 调用mgr.attachApplication(mAppThread);方法，熟悉吧
- 实际上调用ActivityManagerService的attachApplication(),再调用attachApplicationLocked方法，这里面创建application，activity和service
- 关于service，他会走到 didSomething |= mServices.attachApplicationLocked(app, processName);执行service的后续操作，mServices是ActiveServices，走到attachApplicationLocked方法里，
- 调用app.thread.scheduleCreateService(),这不就来了。
- ActivityThread里的scheduleCreateService通过- sendMessage(H.CREATE_SERVICE, s);发送创建Service的消息
- 在handler的handleMessage里走到handleCreateService()
核心代码：
private void handleCreateService(CreateServiceData data) {
Service service = null;
try {
//（1）通过类加载器来加载 Service 对象
java.lang.ClassLoader cl = packageInfo.getClassLoader();
service = (Service) cl.loadClass(data.info.name).newInstance();
} catch (Exception e) {
//......
}
//（2）这里创建 ContextImpl 对象
ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
context.setOuterContext(service);
Application app = packageInfo.makeApplication(false, mInstrumentation);
service.attach(context, this, data.info.name, data.token, app,ActivityManagerNative.getDefault());
//（3）这里调用 Service 的 onCreate 方法
service.onCreate();
mServices.put(data.token, service);
}
