(七十)android Context详解

1、Context概念

Context，我们在android开发中经常见到这个名词，尤其是某些方法的参数列表，像是我们Toast中的makeText()中的第一个参数，就是Context。可以这么说，Context是 android中的基础，只有切实掌握好Context的概念和用法，我们才能写出更好的代码。那么，现在就让我们一起来看一下所谓的Context。

Context：提供应用环境全局信息的接口，并且这个接口是由抽象类实现的，它的执行被android系统所提供，允许我们获取以应用为特征的资源和类型，同时启动应用级的操作，如启动Activity，broadcasting和接收intent。

从这段话就可以发现，Context就是一个作为接口使用的抽象类，而且这个接口提供的是应用的全局信息，因为是android系统所提供的，所以我们大多时候都是可以直接得到的。

但是在程序的角度Context又是什么呢？在程序的角度，我们可以有比较权威的答案，Context是个抽象类，我们可以直接通过看其如下所示的类结构来说明答案：可以看到Activity、Service、Application都是Context的子类。也就是说，Android系统的角度来理解：Context是一个场景，代表与操作系统的交互的一种过程。从程序的角度上来理解：Context是个抽象类，而Activity、Service、Application等都是该类的一个实现。 ContextThemeWrapper类 说明：该类内部包含了主题(Theme)相关的接口，即android:theme属性指定的。只有Activity需要主题，Service不需要主题，所以Service直接继承于ContextWrapper类。

2、Context的类型

大家在需要Context的时候，如果是在Activity中，大多直接传个this，当在匿名内部类的时候，因为this不能用，需要写XXXActivity.this，很多哥们会偷懒，直接就来个getApplicationContext。那么大家有没有想过，XXXActivity.this和getApplicationContext的区别呢？

XXXActivity.this和getApplicationContext返回的肯定不是一个对象，一个是当前Activity的实例，一个是项目的Application的实例。既然区别这么明显，那么各自的使用场景肯定不同，乱使用可能会带来一些问题。

Context的类型有两种，一种是Activity-context，另一种是Application-context，这两种的区别就在于它们的生命周期不一样，Activity-context是随着Activity的销毁而销毁，另一个是伴随着整个Application的销毁而销毁

2.1 Activity-context

并不像我们上面的Application-Context需要特意去获得，可以在一个Activity中使用this就可以获得当前Activity的Context。还是拿上面例子中的Toast.makeText(this, s, Toast.LENGTH_LONG).show()，其中的this就是当前的Activity-Context，但是，一味的使用this是很危险的，我们要注意的就是，在匿名内部类如果单纯只是使用this是会出错的，因为内部类中使用this得到的是内部类的对象引用，而不是我们要得到的外部类的引用，于是，这时候就必须使用类名.this这种方式，这种做法在按钮的事件监听中是特别要注意的。

2.2 Application-context

Application-Context的生命周期是整个应用，所以，对于它的使用必须慎重，大部分情况下都要避免使用它，因为它会导致内存泄露的问题。我们先来举个例子，如果我们现在在一个Activity中引入一个Application-Context，那么，当我们这个Activity关闭的时候，这个Application-Context是不会消失的，因为它的生命周期要比我们的Activity长，如果只是一些用来计算的数据还好，但是如果这个Context与我们的Activity的创建有关，或者与我们在Activity要销毁的资源比如图片资源有关，那么，问题就大条了！因为我们的Activity或图片就不能正常销毁，因为它与Application-Context相关联，如果不能正常的释放掉与它们相关的内存，就会出现所谓的内存泄露的问题。这种问题有时候是非常隐晦的，以至于我们根本无法察觉到，所以我们必须遵守相关的使用原则。
Application-Context的生命周期为整个Application，所以如果是一些需要在整个应用期间都存在的资源，我们可以将它放进一个Application-Context中,然后通过获取这个Context来使用它们。

3、Context的应用场景

大家注意看到有一些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引用的持有，防止内存泄漏。

4、本文引用自/article/1580277.html和/article/4889745.html