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