Andriod中的Context理解与分析

大家在应用程序开发的时候会经常遇到Context，也经常使用，那怎么理解Context呢？

在做Web开发的时候也会有一个Context，一般翻译“成上下文”,也就是代表整个程序运行的环境，直到进程结束之后。那么Android中的Context是不是这样的呢？Android中不是，Android中的Context可以理解成场景，场景是什么什么意思呢？如果把Android程序的整个运行期间成为一个电影的话，那么一个Activity或者一个Service就可以称之为一个场景，一个电影可以包括多个场景。咱们先看下Context相关的继承结构：

从继承关系可以看出，Activity和Service都是基于Context实现的。 Activity不仅基于Context实现，并且还实现了一些重要的其他接口。从设计的角度，继承的才是类的本质，接口仅仅是未来扩充功能。 Activity和Service本质是一个Context，然后扩充了一些功能之后，要么成为Activity，要么成为Service。而Application也可以认为是为了做一些操作方便，才继承的Context。
也就是说有多少个Activity和Service就有多少个场景,也就是有多少个Context对象（Application也算一个）。
这个Context仅代表一个Activity或者一个Service（Application除外）。
Context的真正实现类是ContextImpl，ContextWraper根据名称可以看出是Context的包装类，在ContextWrap中包装了ContextImpl，调用ContexWraper的时候也就调用到了ContextImpl的方法。ContextWraper提供了set ContextImpl 的方法attachBaseContext()。
Activity最终是包含界面的所以他继承了ContextThemeWraper,有Theme这个单词，这个Theme是AndroidMenifest.xml中的Theme标签对应的Theme。因为Service和Application都不包含界面，就没必须继承ContextThemeWraper了，只需继承 ContextWraper即可。

Application对应的Context
每个应用程序在第一次启动的时候都会产生一个Application，这个Application在整个程序运行期间是唯一的，程序员们可以根据自己程序的需要重写这个函数，只需继承一下，在需在AndroidMenifest.xml文件的<application>标签上配置下类全名即可，不配置的话会使用默认的Application。（因为全局是唯一的，可以使用它做一些数据库缓存或者数据传递地方）。
程序第一次启动时，ActivityManagerService会经过ApplicationThread的代理类远程调用真正的ApplicationThread的bindApplication（）方法（这个里把ActivityManagerService当成了Binder客户端，在ActivityThread中的ApplicationThread对象才是真正的Binder服务端）。
ApplicationThread这个类定义在ActivityThread类文件中。代码片段1

这些参数都是从ActivityManagerService通过IPC（Binder方式）传递过来的。如果要在Binder方式中传递对象的话，那么这个类要实现Parceable接口，看下第一个参数appInfo，通过名字可以知道，是代表应用程序的信息类，这个类按道理肯定实现了 Parceable接口，不错确实实现了这个接口。看下这个类的声明。、、代码片段2
还继承自PackageIntemInfo,PacageItemInfo就是通过AndroidMenifest.xml文件解析出的啊<application>标签中的内容代码片段3
从547行开始看，此处创建了一个AppBindData对象data，然后把从ActivityManagerService远程传递过来的参数赋值给data对象，其中第549行就包括了appInfo赋值给了data对象的appInfo。咱们看看AppBindData类到底是什么样的，AppBindData是ActivityThread中的内部类。从下面的代码可以看出只是对传过来的参数进行了简单的封装。、代码片段4 我们再回到代码片段1 中的558行其中参数中H.BIND_APPLICATION是继承自Handler的一个类的一个int常量，第二个参数就是刚封装的数据类型data了。继续代码
代码片段5

继续代码
代码片段6
重点就是what参数和obj参数。在1519行获得一个可回收利用的Message对象，然后把传递过来的消息发送到消息队列（1524行），‘ Looper一直在从消息队列里取消息。当取到刚发送的消息后，会回调Handler的handleMessage()方法，继续到H类中先说明一下，ActivityThread创建时这个H的对象就已经创建好了，这个Handler属于UI线程（主线程）。代码片段7 那咱们还是去H这个类的handleMessage()方法吧其中有个switch结构 H.BIND_APPLICATION对相应的处理如下：
代码片段8 968行把msg中的obj强制转型成AppBindData，做为handleBindApplication(data)的参数继续执行
代码片段9 3122行，把data赋值给了mBoundApplication
代码片段10
3149行，调用getPacageInNocheck()构建一个LoadedApk对象，赋值给data.info。在这个调用中把LoadedApk对象存到了mPackages中。这个LoadedApk对象，这个对象包含了更多的应用程序的信息。
代码片段11 第3260行才是真正的使用反射创建一个Application对象，返回值赋值给mInitialApplication。进入到Loaded.makeApplication()方法，如下代码片段12 454行：forceDefaultAppClass这个参数的意思是，是否强制使用系统提供的默认class类，即android.app.Application’ 459行：创建了一个ContextImpl实例 461行：创建了一个Application实例，mActivityThread.mInstrumentation.newApplication(cl, appClass, appContext)的具体实现如下：
代码片段13
942行：继续调用重载的方法
代码片段14 第958行是设置Application和Context的关联。
调用完整个方法，继续回到代码片段12中 463行设置Context和Application的关联。片段12的代码继续执行到下面，把Application保存到LoadedApk中一份代码片段14 这方法执行完成之后回到代码片段11继续执行代码片段15
在上面的方法中执行了Application的onCreat()方法代码片段16
程序员可以重载Application的onCreate()知道Application创建后的时机，然后做一些相应的操作。
以上就是说明了Application和Context的关系
大致流程如下

没完，待续.....
Activity对应的Context
Service对应的Context

更多相关文章

随机推荐