1，从startActivity说起：
|
|
|
|
Activity里面有一个重要的成员变量 mInstrumentation，该变量用于调度Activity各项生命活动，非常重要。
当start一个Activity时，调用该成员execStartActivity方法，
|
|
ar即是启动Activity的结果，后面对启动结果进行某种解析，稍后再谈。
|
|
2，进入Instrumentation中：
关键点在一次binder过程，即调用ATMS的startActivity()函数，
|
|
3，进入ATMS中，查看startActivity函数
//来到系统进程
|
|
获取ActivityStartController，通过享元模式从pool中拿到一个ActivityStarter，在通过构造者模式设置参数信息，比如设置回调、启动参数options等。
下一步，调用ActivityStarter的execute方法。
4，进入ActivityStarter：
在该类中，有一个重要成员 mRequest，显而易见，这是保存启动Activity所有参数的集合类，其set方法列举了所有参数，
|
|
request在execute中被使用，
|
|
executeRequest函数注释：
执行活动启动请求，开启活动启动之旅。首先是执行几个初步检查。
通常的 Activity 启动流程会经过 {@link startActivityUnchecked} 到 {@link startActivityInner}。
于是乎，对request参数做检查后，一切没什么问题了，调用如下
//开始启动
|
|
|
|
5，进入RootWindowContainer：
调用ActivityStack，进入ActivityStack中调度
|
|
6，进入ActivityStack：
|
|
7，进入TaskDisplayArea：
|
|
8，进入ActivityStack：
注意此次的Stack是上一个Activity的Stack，即马上pause的Stack，startPausingLocked函数中，设置prev状态为当前正在pause的Activity，然后，执行pause事务
|
|
9，进入ClientLifecycleManager：
根据client和stateRequest生成transaction，进一步调用schedule方法，处理事务，transaction是一个ClientTransaction类，
|
|
10，进入ClientTransaction：
以下调用拿到即将pause的用户进程Binder，即一次IPC，在用户进程执行事务，client是一个IApplicationThread
|
|
11，进入ActivityThread：
来到即将pause用户进程
|
|
ActivityThread下有个Handler，专门用来处理消息。如下，发送消息，类型为EXECUTE_TRANSACTION
|
|
//handleMessage片段如下，msg.obj存放的就是transaction，那么在成员变量mTransactionExecutor解析事务，
|
|
12，进入TransactionExecutor：
|
|
如果事务中设置了callback，先executeCallbacks，由于当前Activity需要pause，即没有设置回调，直接看生命周期处理，executeLifecycleState，
|
|
execute函数走PauseActivityItem，
13，进入PauseActivityItem：
|
|
handlePauseActivity中，调用performPauseActivity，
|
|
|
|
可以看到，此处走Activity的onPause周期，最后设置r的状态为pause，r就是ActivityRecord，事实意义的窗口，
execute完后，回到TransactionExecutor中，执行postExecute函数，处理事件结果，
14，回到TransactionExecutor：
|
|
15，回到PauseActivityItem：
通知ATMS，已经pause。
|
|
16，远程 ActivityTaskManagerService：
回到系统进程,r即是paused的ActivityRecord，处理paused后的一些事务吧，进入ActivityRecord中，
|
|
17，进入ActivityRecord：
r.activityPaused(false)中，stack.completePauseLocked(true /* resumeNext */, null /* resumingActivity */);
进而可看到，要resumeNext了，调用stack，进行调度，
18，进入ActivityStack：
|
|
19，进入RootWindowContainer：
|
|
20，回到ActivityStack：
这个是即将resume的Stack，
|
|
|
|
21，进入ActivityStackSupervisor：
|
|
22，进入ATMS：
简单发送一个启动进程的消息 → ActivityManagerInternal::startProcess,
|
|
23，进入ActivityManagerInternal，AMS.LocalServer：
|
|
进一步调用AMS的startProcessLocked，
|
|
24，进入ProcessList：
|
|
25，进入Process：
|
|
26，进入ZygoteProcess：
来到Zygote进程了哦
|
|
下一步进入attemptZygoteSendArgsAndGetResult(zygoteState, msgStr);
|
|
注意，这是socket通信的客户端，zygote如何创建一个新进程呢？进入zygote中查看，
插叙Zygote创生阶段：系统init阶段，执行了zygote main函数，启动了一个ZygoteService服务，然后进入runSelectPool，即socket监听，
在无限循环中，监听AMS的消息
|
|
处理收到的消息，返回的command有其艺术感，因为是ActivityThread的main方法！
|
|
传说中的孵化过程就在processOneCommand中
|
|
进入processOneCommand中，关键如下，
|
|
解释：
因为已经fork了zygote，以下两条分支会在两个进程中得到执行！一个是原本的zygote进程，一个是新生的zygote孵化进程。
pid为0，表示这是一个新的子进程，因为fork之后，可以理解为复制了zygote进程，但pid仍为初始值。如注释，这条路主要用于启动ActivityThread的main方法。
而else语句，fork之后，pid生成的肯定大于0（即子进程的pid），所在进程为zygote进程，继而进入handleParent中，将生成的pid写入socket通道中。
|
|
//handleParentProc
|
|
在ProcessList中，以下函数将app与pid进行了绑定。
|
|
//handleChildProc
//zygote fork之后，出现了两个zygote，其中一个pid为0，这里走child路线，由于肯定不是zygote进程，所以需要关闭socket。
|
|
继续往下走，
|
|
findStaticMethod!!!最终调用ActivityThread的main方法，即新进程的入口！
孵化的子进程，command就是静态方法，由于return语句，所以退出了无限循环，返回给caller，退出循环后调用caller.run()。
|
|
|
|
一片新天地开启！
Zygote进程呢？zygote进程的处理是返回command，为null，mIsForkChild为false，走如下else分支，只是简单把连接关闭，移除fd，peers，继续无限循环！
|
|
27，进入ActivityThread：
来到新启动的用户进程，以下主线程就是所谓的UI线程
|
|
attach函数，绑定上下文环境，又一个重要的过程，因为要与AMS通信，建立一些系统关系。
|
|
28，AMS：
来到系统进程
|
|
进一步看attachApplicationLocked函数 里面这一段，显然，新创建的Activity，进入mAtmInternal.attachApplication中，
|
|
29，ATMS：
没干啥事，委托给RootWindowContainer
|
|
30，RootWindowContainer：
|
|
看到realStartActivityLocked没？
|
|
31，ActivityStackSupervisor：
|
|
32，ClientLifecyckeManager：
|
|
33，来到ClientTransaction：
IPC调用，下一步就进入用户进程，也就是刚启动的进程
|
|
34，回到ActivityThread：
|
|
然后在Handler中处理，不再赘述
|
|
35，来到TranslationExecutor：
|
|
回忆之前设置的callback哈，先走回调，
|
|
36，来到LaunchActivityItem：
|
|
37，来到ActivityThread：
|
|
看到perfromLaunchActivity没？核心方法！
|
|
这里有很多关键，比如attach函数，如何与window建立联系，再则说view的measure、layout、draw等等 。需单独一章分析。在此处，通过mInstrumentation回调了onCreate方法。
38，来到Instructiontation：
|
|
39，来到Activity：
|
|
注意，走到onCreate，此时window还没与Activity建立联系呢。
|
|
40，回到TransactionExecutor：
|
|
executeCallbacks执行完毕，完成了onCreate过程，执行executeLifecycleState函数，
|
|
确定下一个周期，来到cycleToPath(r, lifecycleItem.getTargetState(), true /* excludeLastState */, transaction);
下一个状态在TransactionExecutorHelper中确定，
|
|
返回后，根据拿到的周期序列，在performLifecycleSequence中处理，调试后拿到的是2，也就是执行start。
执行handleStartActivity
|
|
41，回到ActivityThread：
|
|
42，回到ActivityThread，继续Resume：
|
|
43，回到ActivityThread：
大结局，之前的所有步骤哈，肯定都在此循环中进行，因为Zygote产生的如下子进程已经进入无限循环，接收消息了。
在前面启动Activity过程中，不是有许多handleTransaction、handleLaunchActivity等等许多函数嘛，其实就在此Handler中执行。
至此，Activity详细启动流程，完毕。
|
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
关于一些回调的细节：
首先，在ActivityThread中handleLaunchActivity时，会将反射产生的Activity与系统上下文经历联系，主要在Activity的attach函数中，
|
|
最近列表的添加，在ActivityStart的startActivityInner函数末尾
|
|