Context那些你不知道的事？，3天拿到网易Android岗offer

Activity、Service、Application 最终都是继承自装饰类 ContextWrapper ，ContextWrapper 通过 attachBaseContext() 方法来获取实际做事的 ContextImpl 对象。所以这些组件的创建过程中，一定会在某一时机调用 attachBaseContext() 方法对 mBase 对象进行赋值，让我们从源码里面找找答案。

四大组件和 Context

Activity 和 Context

先说 Activity，Activity 的启动过程极其复杂，我们就直接从 ActivityThread 的 performLaunchActivity() 方法看起。

private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {

整理一下大致的执行流程：

1. 获取 LoadedApk 对象，表示加载过的 Apk ，通常一个 App 对应着一个 LoadedApk
2. 通过 createBaseContextForActivity() 方法创建 ContextImpl 对象
3. 反射创建 Activity 对象
4. 创建 Application 对象，这里也是用的反射。如果开发者没有声明自己的 Application 的话，就是默认的 androoid.app.Application
5. 调用 activity.attach() ，这个方法很重要，后面详细说
6. 回调 onCreate()

接着就是 Activity 正常的生命周期流程了。

重点看一下 createBaseContextForActivity() 方法和 attach() 方法。

private ContextImpl createBaseContextForActivity(ActivityClientRecord r) {

调用了 ContextImpl.createActivityContext() 方法。

static ContextImpl createActivityContext(ActivityThread mainThread,

装饰类 ContextWrapper 真正需要的 ContextImpl 对象现在已经创建出来了，但是还没有绑定到 Activity 。继续看 Activity.attach() 方法，注意 attach() 方法的第一个参数就是刚刚创建出来的 ContextImpl 对象。

final void attach(Context context, ActivityThread aThread,

你对 attachBaseContext() 方法应该还有印象。ContextWrapper 正是通过这个方法给 mBase对象赋值，拿到真正的 ContextImpl 对象。到这里，整个逻辑就通顺了。

注意 attach() 方法中的 setWindowManager() 方法中的 mToken 参数，这决定了 Application Context 无法创建和显示 Dialog 。后续会进行详细分析。

再回头看看文章开头的问题。

Log.e(“context”, "getApplication in Activity: " + getApplication().getClass().getName());

第一个 getApplication() ，看下源码就知道了：

public final Application getApplication() {

getApplication() 返回的是当前的 Application 对象。开发者没有声明自己实现的 Application 的话，就是系统默认的 android.app.Application。

第二个 getApplicationContext()，它并不是 Activity 中的方法，而是 ContextWrapper 的。直接看源码：

@Override

调用的是 ContextImpl.getApplicationContext() 。

@Override

所以返回的同样是 Application 对象。

第三个，getBaseContext() ，同样是 ContextWrapper 中的方法：

public Context getBaseContext() {

所以这里返回的是 ContextImpl 对象。

最后的打印语句是：

E/context: getApplication in Activity: luyao.android.App

关于 Activity 就说这么多了。下面来看看 Service 。

Service 和 Context

Service 其实和 Activity 的整体流程基本一致，创建服务的主要逻辑在 ActivityThread.handleCreateService() 方法中。这里我就不贴源码了，简单叙述一下：

1. 创建 LoadedApk 对象
2. 反射创建 Service 对象
3. 调用 ContextImpl.createAppCntext() 创建 ContextImpl 对象
4. 创建 Application 对象
5. 调用 service.attach() 进行绑定
6. 回调 service 的 onCreate() 方法

直接看一下 Service.attach() 方法：

public final void attach(

又看到了熟悉的 attachBaseContext() 方法。

Activity 和 Service 都是继承自 ContextWrapper 的，最后都是通过attachBaseContext() 对 ContextImpl 类型的 mBase 赋值。而 ContentProvider 和 BroadcastReceiver 都没有继承 Context，所以它们获取 Context 的方式会有一点不一样。

ContentProvider 和 Context

先来看 ContentProvider，创建 Provider 的逻辑在 Activity.installProvider() 方法中：

private ContentProviderHolder installProvider(Context context,

最后在 ContentProvider.attachInfo() 方法中进行了 ContextImpl 的赋值操作。

private void attachInfo(Context context, ProviderInfo info, boolean testing) {

这样 ContentProvider 也能拿到 Context 对象了。

BroadcastReceiver 和 Context

最后就是 BroadcastReceiver 了，对应 ActivityThread.handleReceiver() 方法：

private void handleReceiver(ReceiverData data) {

大多数步骤和 Activity 还是类似的，只是到最后回调 onReceive() 方法的时候，才会把 ContextImpl 对象传过去。注意，这里并不是直接返回原生的 ContextImpl 对象，而是调用 context.getReceiverRestrictedContext() 返回一个 受限制 的 ReceiverRestrictedContext，你无法使用这个 Context 对象启动 Service 。

这不正是 装饰者模式 的体现？想给广播的 Context 对象加点限制，那就再来一个装饰类 ReceiverRestrictedContext ，它继承了 ContextWrapper , 重写部分方法以限制应用场景。通过增加和组合装饰类，而不是增加子类，来实现功能扩展。

Application 和 Context

四大组件说完了，别忘了 Application 也是 Context 的间接子类。

Application 的创建时机得从应用进程的创建开始说起。Zygote 进程在接收到客户端请求创建应用进程的 socket 请求之后，会 fork 出子进程，并反射调用 ActivityThread 的静态 main() 方法。接着是 AMS 和客户端的一系列 Binder 调用以及 Handler 通信，最终主线程在收到 BIND_APPLICATION 消息之后回调 handleBindApplication() 方法，到这里就是我们需要的逻辑了：

private void handleBindApplication(AppBindData data){

你可能会疑惑怎么没有回调 attBaseContext() 方法，别急，看看 LoadedApk.makeApplication() 方法是如何创建 Application 的。

public Application makeApplication(boolean forceDefaultAppClass,

最后

光有这些思路和搞懂单个知识的应用是还远远不够的，在Android开源框架设计思想中的知识点还是比较多的，想要搞懂还得学会整理和规划：我们常见的**Android热修复框架、插件化框架、组件化框架、图片加载框架、网络访问框架、RxJava响应式编程框架、IOC依赖注入框架、最近架构组件Jetpack等等Android第三方开源框架，**这些都是属于Android开源框架设计思想的。如下图所示：

这位阿里P8大佬针对以上知识点，熬夜整理出了一本长达1042页的完整版如何解读开源框架设计思想PDF文档，内容详细，把Android热修复框架、插件化框架、组件化框架、图片加载框架、网络访问框架、RxJava响应式编程框架、IOC依赖注入框架、最近架构组件Jetpack等等Android第三方开源框架这些知识点从源码分析到实战应用都讲的简单明了。

由于文档内容过多，篇幅受限，只能截图展示部分，更为了不影响阅读，这份文档已经打包在GitHub，有需要的朋友可以直接点此处前往免费下载。

整理不易，觉得有帮助的朋友可以帮忙点赞分享支持一下小编~

5%E6%8B%BF%E9%AB%98%E8%96%AA%EF%BC%81.md)。**

[外链图片转存中…(img-bvi16q0u-1647446457909)]

[外链图片转存中…(img-Pj0XAOqT-1647446457910)]

整理不易，觉得有帮助的朋友可以帮忙点赞分享支持一下小编~

你的支持，我的动力；祝各位前程似锦，offer不断！！！