Android全面解析之Context机制(一) :初识Android 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，那这两个方法有什么区别？没有区别。但为什么要提供两个一样作用的方法？getApplication()方法更加直观，但是只能在activity中调用。getApplicationContext()适用范围更广，任意一个context对象皆可以调用此方法。

Application类的Context的特点是生命周期长，在整个应用程序运行的期间他都会存在。同时我们可以自定义Application，并在里面做一些全局的初始化操作，或者写一个静态的context供给全局获取，不需要在方法中传入context。如：

class MyApplication : Application(){// 全局contextcompanion 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 : Contextfun showToast(context : Context){mContext = context}
}

单例类在应用持续的时间都会一直存在，这样context也就会被一直被持有，activity无法被回收，导致内存泄露。

那，我们就都换成Application不就可以了，如下：

object MyClass {lateinit var mContext : Contextfun 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的不同职责来执行不同的任务。