网上看过很多Activity启动过程的源码解析，很多文章会贴上一大段代码，然后从startActivity()函数开始深究整个源码的调用栈。个人感觉这类文章代码细节太多，反而容易迷失在源码调用之中，从而忽略了Activity启动过程的本质。所以本文就简单地定性地对Activity启动过程进行描述，不会贴上大篇幅的源码，同时梳理一下相关的经典问题。也是对以前的所学做一个复习总结。
Activity启动过程中，一般会牵涉到应用启动的流程。应用启动又分为冷启动和热启动。
一般来说，冷启动包括了以下内容：
Looper.loop()。ActivityThread#attach(false)方法进行 Binder 通信，通知system_server进程执行 ActivityManagerService#attachApplication(mAppThread)方法，用于初始化Application和Activity。 在system_server进程中，ActivityManagerService#attachApplication(mAppThread)里依次初始化了Application和Activity，分别有2个关键函数： - thread#bindApplication()方法通知主线程Handler 创建 Application 对象、绑定 Context 、执行 Application#onCreate() 生命周期 - mStackSupervisor#attachApplicationLocked()方法中调用 ActivityThread#ApplicationThread#scheduleLaunchActivity()方法，进而通过主线程Handler消息通知创建 Activity 对象，然后再调用 mInstrumentation#callActivityOnCreate()执行 Activity#onCreate() 生命周期至此，应用启动流程完成。
其中1、2、3的源码流程可以参考Android Application 启动流程分析及其源码调用探究，但代码细节不是本篇重点。
下面说说上述流程中的几个关键角色，以及其作用：
这里稍微说下Android系统下的进程机制，每个应用运行时都是：
众所周知，Android是基于Linux系统的，在Linux中所有的进程都是由init进程直接或者是间接fork出来的。fork进程往往比创建进程效率更高。在Android中，所有的应用的进程都是由zygote进程fork出来的。
提到zygote进程，就不得不介绍下Android开机流程：
Android手机开机Linux内核启动后，会加载system/core/init/init.rc文件，启动init进程。这个进程是Android系统特有的初始化程序，简单介绍下它的工作：
在系统启动后init进程会fork Zygote进程，Zygote作为孵化器进程，它的main函数会创建好自己的环境准备孵化子进程，并开始等待孵化请求：
Zygote进程首先会fork自己孵化出SystemServer进程，它的main函数主要负责：
当系统里面的zygote进程运行之后，后续启动APP，就相当于开启一个新的进程。而Android为了实现资源共用和更快的启动速度，子进程都是通过zygote进程fork出来的。所以说，除了init进程fork出来的第一个进程zygote，其他应用进程都是zygote的子进程，也不难理解为何这个孵化器进程的英文名叫zygote（受精卵），因为所有的应用进程都是由它孵化诞生。
SystemServer是由zygote进程fork出来的第一个进程，SystemServer和Zygote是Android Framework最重要的2个进程。 系统里面重要的服务都是在这个进程里面开启的，比如ActivityManagerService、PackageManagerService、WindowManagerService。
应用启动流程基本是围绕着ActivityManagerService和ActivityThread展开。
平时我们所熟知的前端（Web\Android\iOS）通过网络与服务器通信是客户端-服务端模式的体现，而在Android Framework中，四大组件的创建、生命周期也是通过这样的模式进行通信：
Android开发者都应该知道，通过包名和Activity类名就可以打开一个APP。实际上，项目里的业务代码startActivity()方法并不是直接创建进程、拉起APP的。而是通过一系列的调用，把请求传递给SystemServer的AMS。AMS收到来自客户端的请求后，再通知zygote进程来fork一个新进程，来开启我们的目标App的。 这就像是在浏览器里打开一个网页，浏览器把url和参数发送到服务器，然后还是服务器处理请求，并返回相应的html并展示在浏览器上。
这个过程涉及到3个进程：App进程、AMS(SystemServer进程)、zygote进程。
在Android系统中，任何一个Activity的启动都是由AMS和App进程（主要是ActivityThread）相互配合来完成的。AMS服务统一调度系统中所有进程的Activity启动，而每个Activity的启动过程则由其所属的进程具体来完成。
我们知道AMS与ActivityThread的交互主要是通过进程间通信 (IPC) 。跨进程通信的机制就是将方法调用及其数据分解至操作系统可识别的程度，并将其从本地进程和地址空间传输至远程进程和地址空间，然后在远程进程中重新组装并执行该调用。 Android 提供了执行这些 IPC 事务的方案——Binder机制，因此我们只需关心接口定义和实现 RPC 编程接口。
而App进程与SystemServer进程也是通过Binder机制进行进程间通信，Android为此设计了两个Binder接口：
对于一个Binder接口，在客户端和服务端各有一个实现：Proxy和Native，它们之间的通信主要是通过transact和onTransact触发。一般从命名上可以区分：xxxNative是在本进程内的Binder代理类，xxxProxy是在对方进程的Binder代理类。
多说一句，这些Binder都由ServiceManager统一管理：
- ServiceManager管理所有的Android系统服务，有人把ServiceManager比喻成Binder机制中的DNS服务器，client端应用如果要使用系统服务，调用getSystemService接口，ServiceManager就会通过字符串形式的Binder名称找到并返回对应的服务的Binder对象。
- 它是一个系统服务进程，在native层启动，它在system/core/rootdir/init.rc脚本中描述并由init进程启动。
- ServiceManager启动后，会通过循环等待来处理Client进程的通信请求。
App进程与SystemServer进程的Binder接口如下图：
AMS是一个系统服务，在SystemServer进程启动后完成初始化。在应用启动流程中，充当着服务端的角色。 App中Activity的生命周期由AMS管理，它决定着什么时候该调用onCreate、onResume这些生命周期函数，把Activity放在哪个栈里，上下文之间的关系是怎样的等等。
比如：
和服务端的AMS相对应，ActivityThread在应用启动的Client/Server模式中，是作为客户端那一边的具体实现。它并不是一个线程，但它包含了一个应用进程的主线程运作的全部机制：
我们已经知道应用进程创建以后，App进程的ActivityThread与SystemServer进程的AMS通过Binder进行通信。 在文章前面【2 应用启动流程】提到，在ActivityThread的main方法中，调用 ActivityThread#attach(false)方法进行 Binder 通信，通知system_server进程执行 ActivityManagerService#attachApplication(mAppThread)方法，用于初始化Application和Activity。
可以结合源码流程，稍微总结一下这个通信过程。
从应用进程到系统进程
在ActivityThread创建的时候，会将自己的ApplicationThread绑定到AMS中：
ActivityThread.main()
└── ActivityThread.attach()
└── IActivityManager.attachApplication(mAppThread)
└── Binder.transact()
复制代码应用进程作为客户端，通过IAcitivtyManager接口发起了跨进程调用，跨进程传递的参数mAppThread就是IApplicationThread的实例，执行流程从应用进程进入到系统进程：
ActivityManagerService.onTransact()
└── ActivityManagerService.attachApplication(IApplicationThread thread)
复制代码AMS作为IActivityManager接口的服务端实现，会响应客户端的请求，最终AMS.attachApplication()函数会被执行，该函数接收跨进程传递过来的IApplicationThread实例，将存在系统进程维护的ProcessRecord中。 具体细节可以看AMS的源码，我们只需要知道AMS中维护了所有进程运行时的信息(ProcessRecord)，一旦发生了应用进程的绑定请求，ProcessRecord.thread就被赋值成应用进程的IApplicationThread实例，这样一来，在AMS中就能通过该IApplicationThread实例发起向应用进程的调用。
从系统进程到应用进程
在AMS.attachApplication()的过程中，会有一些信息要传递给应用进程，以便应用进程的初始化，系统进程会发起如下函数调用：
ActivityManagerService.attachApplication()
└── ActivityManagerService.attachApplicationLocked()
└── IApplicationThread.bindApplication(processName, appInfo ...)
└── Binder.transact()
复制代码此时，AMS会反转角色，即系统进程作为客户端，通过IApplicationThread接口向应用进程发起调用。
应用进程响应请求的调用关系如下所示：
ApplicationThread.onTransact()
└── ApplicationThread.bindApplication()
└── ActivityThread.H.handleMessage(BIND_APPLICATION)
└── ActivityThread.handleBindApplication()
└── Application.onCreate()
复制代码ApplicationThread作为IApplicationThread接口的服务端实现，运行在应用进程中，然后ApplicationThread.bindApplication()会被执行，完成一些简单的数据封装(AppBindData)后，通过Handler抛出BIND_APPLICATION消息。这一抛，就抛到了主线程上，ActivityThread.handleBindApplication()会被执行，终于创建了Application 对象，然后调用 Application#attach(context) 来绑定 Context，并调用Application.onCreate()函数。历经应用进程和系统进程之间的一个来回，总算是创建了一个应用程序。
Android源码里有较统一的函数命名方式，在AMS中与Activity管理相关很多函数都会带有Locked后缀，表示这些函数的调用都需要多线程同步操作(synchronized)，它们会读/写一些多线程共享的数据
前面提到在system_server进程中，ActivityManagerService#attachApplication(mAppThread)里依次初始化了Application和Activity，其中的mStackSupervisor#attachApplicationLocked(ProcessRecord)里进行了Activity的初始化。
private IBinder mToken;，IBinder类型表示这个属性是一个远程对象的引用，Token持有了一个ActivityRecord实例的弱引用。在创建一个ActivityRecord的时候，就会创建了一个Token类型的对象。在启动一个新的Activity时，AMS会将ActivityRecord的Token传递给应用进程，调用关系如下所示：
ActivityStackSupervisor.realStartActivityLocked(ActivityRecord, ...)
└── IApplicationThread.scheduleLaunchActivity(...token, ...)
// 将ActivityRecord的Token跨进程传递给应用进程
└── Binder.transact()
复制代码ActivityStackSupervisor.realStartActivityLocked()表示要启动一个Activity实例，ActivityRecord作为参数。从ActivityRecord中提取出Token对象，作为跨进程调用的参数，通过IApplicationThread.scheduleLaunchActivity()传递到应用进程。
在应用进程这一侧，会收到启动Activity的跨进程调用，触发以下函数的调用：
ApplicationThread.onTransact()
└── ApplicationThread.scheduleLaunchActivity(...token, ...)
// token将被封装进ActivityClientRecord这个数据结构中
└── ActivityThread.H.handleMessage()
└── ActivityThread.handleLaunchActivity(LAUNCH_ACTIVITY)
└── ActivityThread.performLaunchActivity(ActivityClientRecord, ...)
// 从ActivityRecord取出token
└── Activity.attch(...token, ...)
复制代码标准的Binder服务端处理流程，收到AMS传递过来的Token对象，进行一下数据封装(ActivityClientRecord)，然后通过Handler抛出一个LAUNCH_ACTIVITY消息。这个消息显然也是抛到了应用进程的主线程去执行，所以ActivityThread.performLaunchActivity()函数会在主线程上执行，该函数从封装的数据结构ActivityClientRecord中取出Token对象，调用Activity.attach()函数，将其绑定到Activity上，如此一来，就建立应用进程的Activity与系统进程中ActivityRecord的关联。
系统进程维护的是ActivityRecord，应用进程维护的是Activity，两者之间的映射关系就是利用Token来维系的。应用进程的Activity在创建的时候，就被赋予了一个Token，拿着这个Token才能完成后续与系统进程的通信。在发生Activity切换时，应用进程会将上一个Activity的Token(AMS.startActivity()的输入参数resultTo)传递给系统进程，系统进程会根据这个Token找到ActivityRecord，对其完成调度后，再通知应用进程：Activity状态发生了变化。
每个Activity都持有Instrumentation对象的一个引用，但是整个应用程序进程只会存在一个Instrumentation对象。 Instrumentation可以理解为应用进程的管家，ActivityThread要创建或暂停某个Activity时，都需要通过Instrumentation来进行具体的操作。
Instrumentation这个类就是完成对Application和Activity初始化和生命周期的工具类。
前面提到，App和AMS是通过Binder传递信息的，ActivityThread接受AMS的命令，然后就是通过Instrumentation真正地创建Activity以及调用Activity的生命周期函数。 比如ApplicationThread接受AMS命令创建Acitivity，最后执行到ActivityThread，通过Instrumentation创建Activity并调用onCreate()生命周期。
//
ActivityThread.performLaunchActivity()
└── mInstrumentation.newActivity(appContext.getClassLoader(), component.getClassName(), activityClientRecord.intent)
└── return (Activity)cl.loadClass(className).newInstance()
└── mInstrumentation.callActivityOnCreate(activity, r.state)
└── activity.performCreate()
└── activity.onCreate(Bundle)
复制代码前面知道应用启动以及Activity启动是一个跨进程通信的过程，这是因为： 每个应用都是一个独立的进程，Activity的生命周期本来就会在不同进程之间互相影响，所以需要一个系统进程对所有Activity进行统一管理。 在一个应用程序安装时，系统会解析出APK中所有Activity的信息，当显示APK中的用户界面时，就需要调度Activity的生命周期函数了。 系统进程(SystemServer)中维护了所有Activity的状态，管理中枢就是ActivityManagerService。
在应用进程这边，Activity的生命周期都是发生在本进程的主线程里，由ActivityThread调用Instrumentation完成。 而在系统进程（SystemServer）这头，则是由AMS维护ActivityRecord等数据结构来进行调度。 Activity管理的数据结构包括： ActivityRecord TaskRecord ActivityStack ActivityDisplay ActivityStackSupervisor ProcessRecord 这些数据结构都属于JAVA实体类，它们的构建和销毁都在系统进程中完成。
它们之间的联系可以参考下图：
图中的方框可以理解为一个包含关系：譬如一个TaskRecord中包含多个ActivityRecord; 图中的连接线可以理解为等价关系，譬如同一个ActivityRecord会被TaskRecord和ProcessRecord引用，两者是从不同维度来管理ActivityRecord。
每种数据结构的属性和行为
前面知道应用进程与AMS通过Binder进行了跨进程通信，那么Binder究竟是如何运作的：
下面简单说说Binder机制 在Android中的具体实现：
Server进程 创建 一个 Binder 对象，并向 ServiceManager 注册服务。
Client进程 需要使用 Server进程的服务时，须 通过Binder驱动 向 ServiceManager进程 获取相应的Service信息。ServiceManager会返回Server进程的Binder代理对象