“文章相关内容已授权『郭霖』公众号发布
”
前言
很高兴遇见你~ 欢迎阅读我的文章。
在文章Android全面解析之由浅及深Handler消息机制中讨论到，Handler可以：
“避免我们自己去手动写 死循环和输入阻塞 来不断获取用户的输入以及避免线程直接结束，而是采用事务驱动型设计，使用Handler消息机制，让AMS可以控制整个程序的运行逻辑。
”
这是关于android程序在设计上更加重要的一部分，不太了解的读者可以前往阅读了解一下。而当我们知道android程序的程序是通过main方法跑起来的，然后通过handler机制来控制程序的运行，那么四大组件和普通的Java类到底有什么区别？为什么同样是Java类，而ActivityThread、Activity等等这些类就显得那么特殊呢？我们的代码、写的布局是通过什么路径使用系统资源把界面展示在屏幕上的？这一切就涉及到我们今天的主角：Context。
“这是context系列文章的开篇，限于篇幅分为三部分：
第一部分：也就是本文，主要讲解什么是context以及关于context家族和相关实现类。
第二部分：主要讲不同Context的创建流程，包括Application、Activity、Service。
第三部分：也是最终篇，讲解剩下两个四大组件的context来源以及从更高的角度理解context。读者可前往主页选择感兴趣的部分阅读，也可以完整阅读系统化学习context。
”
什么是Context
回想一下最初学习Android开发的时候，第一用到context是什么时候？如果你跟我一样是通过郭霖的《第一行代码》来入门android，那么一般是Toast。Toast的常规用法是：
Toast.makeText(this, "我是toast", Toast.LENGTH_SHORT).show()
当初也不知道什么是Context，只知道他需要一个context类型，把activity对象传进去即可。从此context贯穿在我开发过程的方方面面，但我始终不知道这个context到底有什么用？为什么要这个对象？我们首先来看官方对于Context类的注释：
/**
* 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.
*/
public abstract class Context {...}
关于应用程序环境的全局信息的接口。 这是一个抽象类，它的实现是由Android系统提供。 它允许访问特定应用的资源和类，以及向上调用应用程序级的操作，如启动活动，广播和接收Intent等。
可以看到Context最重要的作用就是获取全局消息、访问系统资源、调用应用程序级的操作。可能对于这些作用没什么印象，想一下，如果没有context，我们如何做到以下操作：
- 弹出一个toast
- 启动一个activity
- 获取程序布局文件、drawable文件等
- 访问数据库
这些平时看似简单的操作，一旦失去了context将无法执行。这些行为都有一个共同点：需要与系统交汇。四大组件为什么配为组件，而我们的写的就只能叫做一个普通的Java类，正是因为context的这些功能让四大组件有了不一样的能力。简单来说，context是：
“应用程序和系统之间的桥梁，应用程序访问系统各种资源的接口。
”
我们一般使用context最多的是两种情景：直接调用context的方法和调用接口时需要context参数。这些行为都意味着我们需要访问系统相关的资源。
那context是从哪里来的？AMS！AMS是系统级进程，拥有访问系统级操作的权利，应用程序的启动受AMS的调控，在程序启动的过程中，AMS会把一个“凭证”通过跨进程通信给到我们的应用程序，我们的程序会把这个“凭证”封装成context，并提供一系列的接口，这样我们的程序也就可以很方便地访问系统资源了。这样的好处是：
“系统可以对应用程序级的操作进行调控，限制各种情景下的权限，同时也可以防止恶意攻击。
”
如Application类的context和Activity的context权利是不一样的，生命周期也不一样。对于想要操作系统攻击用户的程序也进行了阻止，没有获得允许的Java类没有任何权利，而Activity开放给用户也只有部分有限的权利。而我们开发者获取context的路径，也只有从activity、application等组件获取。
因而，什么是Context？Context是应用程序与系统之间沟通的桥梁，是应用程序访问系统资源的接口，同时也是系统给应用程序的一张“权限凭证”。有了context，一个Java类才可以被称之为组件。
Context家族
上一部分我们了解什么是context以及context的重要性，这一部分就来了解一下context在源码中的子类继承情况。先看一个图：
最顶层是Context抽象类，他定义了一系列与系统交汇的接口。ContextWrapper继承自Context，但是并没有真正实现Context中的接口，而是把接口的实现都托管给ContextImpl，ContextImpl是Context接口的真正实现者，从AMS拿来的“凭证”也是封装到了ContextImpl中，然后赋值给ContextWrapper，这里运用到了一种模式：装饰者模式。Application和Service都继承自ContextWrapper，那么他们也就拥有Context的接口方法且本身即是context，方便开发者的使用。Activity比较特殊，因为它是有界面的，所以他需要一个主题：Theme，ContextThemeWrapper在ContextWrapper的基础上增加与主题相关的操作。
这样的设计有这样的优点：
- Activity等可以更加方便地使用context，可以把自身当成context来使用，遇到需要context的接口直接把自身传进去即可。
- 运用装饰者模式，向外屏蔽ContextImpl的内部逻辑，同时当需要更改ContextImpl的逻辑实现，ContextWrapper的逻辑几乎不需要更改。
- 更方便地扩展不同情景下的逻辑。如service和activity，情景不同，需要的接口方法也不同，但是与系统交互的接口是相同的，使用装饰者模式可以拓展出很多的功能，同时只需要把ContextImpl对象赋值进去即可。
context的分类
前面讲到Context的家族体系时，了解到他的最终实现类有：Application、Activity、Service，ContextImpl被前三者持有，是Context接口的真正实现。那么这里讨论一下这三者有什么不同，和使用时需要注意的问题。
Application
Application是全局Context，整个应用程序只有一个，他可以访问到应用程序的包信息等资源信息。获取Application的方法一般有两个：
context.getApplicationContext()
activity.getApplication()
通过context和activity都可以获取到Application，那这两个方法有什么区别？没有区别。我们可以打印来看一下：
override fun onCreate(savedInstanceState: Bundle?) {
...
Log.d("一只修仙的猿", "application：$application")
Log.d("一只修仙的猿", "applicationContext：$applicationContext")
}
可以看到确实是同个对象。但为什么要提供两个一样作用的方法？getApplication()方法更加直观，但是只能在activity中调用。getApplicationContext()适用范围更广，任意一个context对象皆可以调用此方法。
Application类的Context的特点是生命周期长，在整个应用程序运行的期间他都会存在。同时我们可以自定义Application，并在里面做一些全局的初始化操作，或者写一个静态的context供给全局获取，不需要在方法中传入context。如：
class MyApplication : Application(){
// 全局context
companion object{
lateinit var context: Context
}
override fun onCreate() {
super.onCreate()
// 做全局初始化操作
RetrofitManager.init(this)
context = this
}
}
这样我们就可以在应用启动的时候对一些组件进行初始化，同时可以通过MyApplication.context来获取Application对象。
但是！！！请不要把Application当成工具类使用。由于Application获取的便利性，有开发者会在Application中编写一些工具方法，全局获取使用，这样是不行的。自定义Application的目的是在程序启动的时候做全局初始化工作，而不能拿来取代工具类，这严重违背谷歌设计Application的原则，也违背Java代码规范的单一职责原则。
四大组件
Activity继承自ContextThemeWrapper，是一个拥有主题的context对象。Activity常用于与UI有关的操作，如添加window等。常规使用可以直接用activity.this。
Service继承自ContextWrapper，也可以和Activity一样直接使用service.this来使用context。和activity不同的是，Service没有界面，所以也不需要主题。
ContentProvider使用的是Application的context，Broadcast使用的是activity的context，这两点在后面会进行源码分析。
BaseContext
嗯？baseContext是什么？把这个拿出来单独讲，细心的读者可能会发现activity中有一个方法：getBaseContext。这个是ContextWrapper中的mBase对象，也就是ContextImpl，也是context接口的真正逻辑实现。
context的使用问题
使用context最重要的问题之一是注意内存泄露。不同的context的生命周期不同，Application是在应用存在的期间会一直存在，而Activity是会随着界面的销毁而销毁，如果当我们的代码长时间持有了activity的context，如静态引用或者单例类，那么会导致activity无法被释放。如下面的代码：
object MyClass {
lateinit var mContext : Context
fun showToast(context : Context){
mContext = context
}
}
单例类在应用持续的时间都会一直存在，这样context也就会被一直被持有，activity无法被回收，导致内存泄露。
那，我们就都换成Application不就可以了，如下：
object MyClass {
lateinit var mContext : Context
fun showToast(context : Context){
mContext = context.applicationContext
}
}
答案是：不可以。什么时候可以使用Application？不涉及UI以及启动Activity操作Activity的context是拥有主题属性的，如果使用Application来操作UI，那么会丢失自定义的主题，采用系统默认的主题。同时，有些UI操作只有Activity可以执行，如弹出dialog，这涉及到window的token问题，我在这篇文章token验证进行了详细的解答，有兴趣的读者可以去阅读一下。这也是官方对于context不同权限的设计，没有界面的context，就不应该有操作界面的权利。使用Application启动的Activity必须指定task以及标记为singleTask，因为Application是没有任务栈的，需要重新开一个新的任务栈。因此，我们需要根据不同context的不同职责来执行不同的任务。
总结
文章讲解了什么是context、context家族、已经不同的context实现类。 通过本文可以了解什么是context以及与context相关的类。
那么接下来就要开始深入讲源码相关内容了。很多读者一听到源码就下意识地表示拒绝。其实源码没有想象中那么枯燥无味，甚至可以说还是挺有趣的。阅读完源码会对context有更加深刻的理解。
“全文到此，原创不易，觉得有帮助可以点赞收藏评论转发。 笔者才疏学浅，有任何想法欢迎评论区交流指正。 如需转载请评论区或私信交流。
另外欢迎光临笔者的个人博客：传送门
”
