Application,Activity,Service的创立流程（1）

Context简介

Context的中文意思是上下文，可以简单的了解为运行环境，提供少量非常Base的接口，例如获取资源管理器，App缓存目录等

从Context源码中得出Context是个笼统类，其功能的实现应该交给了其子类，那么我们就看看Context的继承关系

此图源自自郭霖大神的Blog
从源码可以看出，Context有两个直接的子类ContextWrapper和ContextImpl，并且Application,Service,Activity都继承ContextWrapper，下面我们看看ContextWrapper的源码:

从源码可以看出，ContextWrapper把功能都委托给mBase来做（代理商模式）
让我们再来Context的另外一个实现类ContextImpl的源码：

从源码可以看出，ContextImpl实现了Context的所有功能。综上我们可以推断ContextWrapper中的mBase应该是ContextImpl对象，下面通过Application，Activity，Service的创立流程来证明这个推断。

Application的创立流程

这张图主要展现了启动Activity，Service的简要过程，在启动Activity，Service的同时也会创立Application
a. ActivityThread就是我们常说的UI线程，它负责Activity，Service，Application的调度等工作，感兴趣的朋友可以阅读下他的源码.
b. ApplicationThread是ActivityThread的一个内部类，本质上是一个IBinder对象，他的主要作用是用于AMS(ActivityManagerService的简称)与ActivityThread通信，例如AMS在解决完Server端ActivityRecord的创立，栈管理后通过ApplicationThread来通知ActivityThread可以创立对应的Activity和执行Activity的生命周期了。

下面我们从AMS回调启动Activity的流程来看下Application的创立流程

1. AMS会通过调用ApplicationThread的scheduleLaunchActivity(…)来告诉ActivityThread它可以创立Activity了

   

2. 而后发送LAUNCH_ACTIVITY消息出去

   

3. 接着调用 handleLaunchActivity(…)

   

4. 而后调用performLauncherActivity(…)

   

   我们关注下createBaseContextForActivity(…)，他创立了CotnextImpl对象，接着调用Activity的attach(…)，把ContextImpl对象传了进去，从而证实了Activity内部对应的mBase就是ContextImpl。

5. 而后调用了LoadedApk的makeApplication（…）

   

   假如mApplication不为null则直接返回它，mApplication是LoadedApk中的一个全局对象，一个APP进程只会创立一次。而后创立ContextImpl对象，并且在调用Intrumentation的newApplication(…)的时候传了进去，接着调用了Intrmentation的callApplicationOnCreate(…)
   接下来我们看看Intrumentation的newApplication(…)和callApplicationOnCreate(…)做了什么

   
   从代码中我们可以看出，Application创立后，调用了attach(…)，把ContextImpl对象传了进去，也就证实了Application内部对应的mBase就是ContextImpl，同时在attach方法中调用了执行了Application的生命周期方法attachBaseContext(…)
   

   从代码中可以看出，callApplicationOnCreate执行了Application生命周期方法onCreate(…)

上面的代码都是在UI线程执行的，因而不要在Application的生命周期方法attachBaseContext(…)和onCreate(…)做耗时操作