Context被译为上下文,可理解为场景,一个场景就是用户和操作系统交互的一种过程,如打电话场景包括电话对应的界面,还有隐藏在界面后的数据。Context是一个抽象类,Activity基于Context,Service也基于Context。Activity除了基于Context,还实现了一些其他重要的接口。从设计的角度看,interface仅仅是某些功能,而extends才是类的本质,即Activity的本质是一个Context,其所实现的其他接口只是为了扩充Context的功能而已,扩充之后的类称之为一个Activity或者Service。
Context继承关系:
ContextWrapper类:这只是一个包装而已,ContextWrapper构造函数必须包含一个真正的Context引用,同时ContextWrapper中提供了attachBaseContext用于给ContextWrapper对象中指定真正的Context对象,调用ContextWrapper的方法都会被转向其所包含的真正的Context对象。
ContextThemeWrapper类:其内部包含了与主题相关的接口,这里说的主题是指在AndroidMainifest.xml中通过android:theme为Application元素或者Activity元素指定的主题。
当然只有Activity需要主题,Service是不需要主题的。因为Service是没有界面的后台场景,所有Service直接继承于ContextWrapper。
ContextImpl类:该类真正实现了Context中所有的函数,应用程序中调用的各种Context类的方法,其实现均来自该类。
Application中的Context
Activity中的Context
Service中的Context
上面三种情况下的Context对象的创建过程基本是相同的,包括的代码的结构也十分类似,它们都对应了相同的PackageInfo。不同的是针对Application,Activity,Service使用了不同的数据对象。
实际一个应用程序中包含的Context个数 = Activity个数 + Service个数 + 1(Application)
应用程序包含多个ContextXmpl对象,而其内部变量mPackageInfo却指向同一个PackageInfo对象。这意味着ContextXmpl是个轻量级的类,PackageInfo是个重量级的类,ContextXmpl中的大多数进行包操作的重量级函数实际上都是转向了mPackageInfo对象相应的方法。