Application中的 Context 和 Activity 中的Context区别
Context在我们开发中经常用到,不管是Framework提供给我们的四大组件,还是应用级别的Application,还是负责表现层的View相关类,甚至连我们很多时候创建的实体类都会需要持有一个Context的引用。那么Context到底是什么呢?
建议看这个: https://www.jianshu.com/p/b68de4c95b05
Context英文释义是当前上下文,或者当前场景上,
官方文档:Context
public abstractclass Context extends Object
Interface to globalinformation about an application environment. This is an abstract class whoseimplementation is provided by the Android system. It allows access toapplication-specific resources and classes, as well as up-calls forapplication-level operations such as launching activities, broadcasting andreceiving intents, etc.
由官方文档,我们可以知道:
1.该类是一个 抽象(abstract class)类 ;
2.它描述的是一个应用程序环境的信息,即上下文;
3.通过它(Context)我们可以获取应用程序的资源和类,也包括一些应用级别的操作(例如,启动 Activity,广播和服务等);
前面我们讲过 Context 是一个抽象类,通过 Context我们可以获取应用程序的资源和类,调用它们的方法,那么具体定义的方法有哪些呢?我们来看一下 Context 的源码:
源码里的方法太多了,总共 4710 行。我们从以上部分源码看到了熟悉的对象---Application、Activity、Service、Broadcast、这些对象和 Context 的关系到底是什么呢?我们看一下官方文档可知:
1. Acitiivity 继承自ContextThemeWrapper--->再继承ContextWrapper--->Context。
2. Appliction 、Service继承自ContextWrapper--->再继承Context。
3. Application、Service 和 Activity 最终都是继承自Context,所以它们是同一个上下文。
通过以上的继承关系,我们就可以知道,Context的具体作用会包括:
- 启动一个新的Activity
- 启动和停止Service
- 发送广播消息(Intent)
- 注册广播消息(Intent)接收者
- 可以访问APK中各种资源,如Resources和AssetManager
- 创建View
- 访问Package的相关信息
- APK的各种权限管理
由上面分析的继承关系,我们可以知道,Context创建的时机有三个:
①创建Application 对象时, 而且整个App共一个Application对象;
②创建Service对象时;
③创建Activity对象时;
所以应用程序App共有的Context数目公式为:
Service个数 + Activity个数 + 1(Application对应的Context实例)
如上,Android中context可以作很多操作,但是最主要的功能是加载和访问资源。在android中常用的context有两种,一种是application context,一种是activity context,通常我们在各种类和方法间传递的是activity context。
两者的区别:
this 是Activity 的实例,扩展了Context,其生命周期是Activity 创建到销毁。getApplicationContext()返回应用的上下文,生命周期是整个应用,应用摧毁它才被摧毁。Activity.this的context 返回当前activity的上下文,属于activity ,activity摧毁时被摧毁。
使用Context时最需要注意的一个点就是,使用了不正确的context,比如有一个全局的数据操作类用到了context,这个时候就要getApplicationContext 而不是用ACtivity,如果在这个全局操作中引用的是Activity的context,那么就会一直引用Activity的资源,导致GC无法回收这部分内存,从而最终导致了 内存泄漏 。
内存泄漏是开发中常见的错误之一,能不能发现取决于开发者的经验,当然了我们也会依赖现有的内存泄漏库,但是如果我们在开发的源头减少内存泄漏的概率,那么后期的工作会少很多。
以下是避免context相关的内存泄露,给出的几点建议:
以下的表列举的是三种Context对象的对应使用场景:
从表中可以看到,和UI相关的都使用Activity的Context对象。
小结:如上分析,Context在对应开发里的来源就是三个——Activity、Service和Appliaction,那么我们该如何选择使用哪一个Context对象呢?一个比较简单的方法是,当你无法确定使用某个Context对象是否会造成长引用导致内存泄漏时,那么就使用Appliaction的Context对象,因为Appliaction存在于整个应用的生命周期内。
在实际开发中,我们往往会为项目定义一个Applictaion,然后在AndroidMainfest.xml文件中进行注册,
而且在自定义Application往往会定义好一个静态方法,用以全局获取application实例:
Activity和Application都是Context的子类,但是他们维护的生命周期不一样。前者维护一个Acitivity的生命周期,所以其对应的Context也只能访问该activity内的各种资源。后者则是维护一个Application的生命周期。
1.如何判断context是属于哪个activity?
2.全局不同如何获取对应的context?
静态加载一个Fragment,在onCreateView()方法中通过getActivity获取上下文实例:
3.四大组件可以像普通Java类一样,采用new的方式实例化吗?
Android程序不像Java程序一样,随便创建一个类,写个main()方法就能运行,Android应用模型是基于组件的应用设计模式,组件的运行要有一个完整的Android工程环境,在这个环境下,Activity、Service等系统组件才能够正常工作,而这些组件并不能采用普通的Java对象创建方式,new一下就能创建实例了,而是要有它们各自的上下文环境,也就是我们这里讨论的Context。可以这样讲,Context是维持Android程序中各组件能够正常工作的一个核心功能类。