Application,Activity,Service的创建流

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(...)做耗时操作