Context通俗上的讲叫做上下文,正如读书时我们常常需要通过上下文来判断某句话的意思,在程序中我们也会碰到Context,在Android中Context的出现次数是相当多的。本文主要站在Android的角度分析了Context的用意以及设计思想,仅供参考。
从个人的角度来说,我其实更加喜欢称这里的上下文为环境,试想我们在饭店吃饭,那么饭店为我们提供了就餐的环境,这环境里就包括了食物、筷子、勺子、杯子、餐桌等等我们就餐时需要或可能需要的东西。而这环境就是Context。那我们可以用下面的代码来标志这些。
这个就餐环境提供我们就餐时需要或可能需要的东西,比如你可能需要筷子,但是其他人可能需要勺子或者刀叉。这个因人为异,但是餐厅的里提供了这些东西,无论你用不用,他都在那里。
那么Android的Context呢?我们来看看Activity的继承关系
首先Context是一个抽象类,该类声明了一系列抽象的方法,比如注册广播,启动服务、获取AssetManager、获取当前的包名、获取Resources等等,各种方法。这里可以参考Context的API文档,不再累述。这些抽象方法都是在ContextWrapper中实现的,最后是Activity。
在Activity中启动一个Activity、获取一个服务、注册一个广播、启动一个服务、获取资源等等是非常方便的。这些的方便是由于Activity是一个环境,这个环境为我们提供了些常用方法调用。假想我们都在Activity这个环境中,想要去启动一个服务,我只需要调用环境中提供startActivity就一切Ok了,当然,你得告诉环境要启动的Activity。
其实不只是Activity,Service也同样继承了Context,唯一不同的是Activity的直接父类是ContextThemeWrapper,而Service的直接父类是ContextWrapper。这里也是分开一个是前台UI、一个是处理后台逻辑的关键点。
就个人来看,如果把Context称为运行环境一点都不为过,其实更准确点来说他是对运行环境的一个代理。正如饭店服务员一样,无论你需要餐巾纸还是筷子都向服务员要,服务员充当了这个代理,当然具体怎样吃还看你习惯。从Android Context的继承结构以及源码中可以看出设计者希望Context只是提供一份运行环境的清单,以及一些简单的实现,而ContextWrapper也仅仅是提供了一层封装,这样的封装是有好处的,看源码的构造函数:
我们在创建的时候会传入一个Context,这个Context就是这个环境真正的实现吧,也就是我们通常的getBaseContext(),而getApplicationContext()会继续调用到mBase.getApplicationContext()。这里其实就有了我们所见的3个Context了。
一个Activity是一个Context,getBaseContext()是一个Context,getApplicationContext()又是一个Context,这里我们不再深入追究,有兴趣的可以参看源码,仔细了解这套关系。
转自:http://www.incoding.org/admin/archives/821.html