[转载]Andriod中的Context理解与分析（1）-Android开发进阶&经验分享-eoe Android开发者社区_Android开发论坛

[转载]Andriod中的Context理解与分析（1）-Android开发进阶&经验分享-eoe Android开发者社区_Android开发论坛 – Powered by Discuz!.

大家在应用程序开发的时候会经常遇到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)的具体实现如下：