Laucher中activtyA启动APP进程中的ActivityB

第一步：解析要启动的Activity信息

Launcher通过Instrumentation类，在Instrumentation中通过ServiceManager拿到AMS的Binder和AMS通信，调用AMS里面的startActivity方法，同时把Launcher进程的包名和所对应的ApplicationThread(Binder)，intent里面所包含的信息全部传递给AMS的ActivityStart里面的静态的Request。

ActivityStart这个类专门用于解析Activity信息，配置activity关联的任务和堆栈，里面有一个静态的Request类，这个类里面的参数包含了启动activityA的相关信息和被启动activityB的相关信息。

static class Request {
...
IApplicationThread caller;//Launcher的Binder，也代表着谁来调用我们的启动流程
Intent intent;//startActivity里面传入的Intent
NeededUriGrants intentGrants;
// A copy of the original requested intent, in case for ephemeral app launch.
Intent ephemeralIntent;
String resolvedType;
ActivityInfo activityInfo;
ResolveInfo resolveInfo;
IVoiceInteractionSession voiceSession;
IVoiceInteractor voiceInteractor;
IBinder resultTo;
String resultWho;
int requestCode;//activity启动的返回结果
...
}

AMS创建和管理ActivityStart是通过ActivityStartController。AMS每次启动一个Activity都会需要创建一个ActivityStart类来管理Activity的启动信息。在App中启动Activity是一件非常频繁的事情，如果每一次启动Activity都重新创建ActivityStart对象的话，当相关方法执行完毕，ActivityStart对象会被回收。频繁的创建和频繁的回收就势必会造成内存抖动。我们在JVM的新生代使用的垃圾回收算法是复制清除算法，在老年代是标志清除算法或者标记整理清除算法，除了标记清除算法外，其余两种都会造成对象的移动，除了垃圾回收线程外的其余所有线程都必须暂停，会造成一定的卡顿。所以在AMS中并不是直接去创建ActivityStart对象的，通过ActivityStartController去创建和管理ActivityStart对象。使用了享元设计模式。当相关方法执行完毕，把ActivityStart对象先清除里面所有的数据，然后放置在被final修饰(final修饰的变量存在在常量池，是一个GC root)的一个对象的里面的池子里面，池子的容量是3。每次创建先从池子里面拿，拿不到再创建ActivityStart对象，用完后抹除对象里面所有的数据放回到池子里面。这样做避免了内存抖动。和Message的创建是一样的。

ActivityStartController创建完ActivityStart后，把Launcher的包名，Launcher的ApplicationThread和intent里面所有的信息存储到ActivityStart的Request类里面。然后在ActivityStart里面创建两个ActivityRecord，这个ActivityRecord我理解为Activity在AMS里面的一种体现吧，我们的Activity目前还没创建，真正创建实在ActivityThread的handLaunchActivty里面，在创建Activity之前，AMS怎么对Activity操作呢？就弄了一个ActivityRecord来代表Activity。ActivityRecord里面就包含了一个Activity的所有信息，比如说Activity所处的栈，处于哪个栈。
ActivityStart一共干了一下几种事情：

1. 存储Launcher所有的App的binder，解析intent里面的参数，也就是ActivityA和ActivityB的相关参数，存储到内部的静态类Request里面
2. 把ActivityA和ActivityB在AMS端的代表，ActivityRecord创建出来，ActivityRecord里面包含了Activity的相关信息，其中就包括Activity的相关得的栈信息。
3. 启动之前还没来得及启动的Activity，我的理解是一个屏幕内同时启动两个Activity就是在这里进行处理的，确保启动一个的时候，另外一个Activity也会被启动。
4. 初始化启动模式，为ActivityRecord存储的启动模式赋值，然后将相关启动模式塞到Intent里面
5. 创建一个启动时的黑白屏。因为这个时候我们的APP进程还没有被启动，而App进程启动的过程是很缓慢的，可能需要个2秒，但是如果不给这个黑白屏的话，在这两秒之内，用户会以为点击没效果，或者认为自己没有点中app图标，会疯狂点击。先给一个黑白屏让用户知道操作系统已经接受到他的点击事件了。
6. 把后续的操作交给RootWindowContainer去执行。RootWindowContainer是窗口容器的根容器，管理所有的窗口容器。窗口是需要基于Activity来显示的，后续的操作在resumeFocusedStacksTopActivitys里面进行，个人理解是恢复目前栈的栈顶Activity，可见性和窗口脱不了关系。所以谷歌工程师可能想通过RootWindowContainer来控制Activity的后续流程。

第二步：ActivityStackSupervisor启动Activity

ActivityRecord：一个ActivityRecord对应着一个Activity，保存一个Activity的所有信息；但是一个Activity可能对应着多个ActivityRecord，这与Activity的启动模式有关，一个Activity可能会被启动多次。

Task：Android系统中的每个Activity都位于一个Task中。一个Task能够包括多个Activity，同一个Activity也可能有多
个实例。 在AndroidManifest.xml中，我们能够通过 android:launchMode 来控制Activity在Task中的实例。Task管
理的意义还在于近期任务列表以及Back栈。 当你通过多任务键（有些设备上是长按Home键。有些设备上是专门提
供的多任务键）调出多任务时，事实上就是从ActivityManagerService获取了近期启动的Task列表。

ActivityStack：Task是它的父类，是一个管理类，管理着所有 Activity ，内部维护了 Activity 的所有状态、特
殊状态的Actvity和Activity以及相关的列表数据。

ActivityStackSupervisor： ActivityStack 是由 ActivityStackSupervisor 来进行管理，而这个是在ATMS的
initialize 中被创建出来的。ATMS初始化的时候，会创建一个ActivityStackSupervisor对象用于统一管理一些事
务：1）将显示层次结构相关的内容移动到RootWindowContainer中；2）将与activity生命周期相关的事务的处理转
交给ActivityLifeCyler处理；3）处理点击物理按键Menu键后任务栈的处理。

RootWindowContainer通过拿到ActivityStack执行ActivtyA的onPase方法，之后把后续流程交给ActivityStackSupervisor来处理。ActivityStackSupervisor是ActivityStack的大管家，管理着所有的ActivityStack。在ActivityStackSupervisor里面会判断当前要启动的Activity所在的进程有没有被创建，如果没有被创建的话。会通过ProcessList去拿到对应的RrocessRecord。

ProcessRecord记录App进程相关信息的重要类，AMS管理所有App进程，每一个App进程都对应着一个ProcessRecord类，里面存储着App进程的所有信息。AMS为了管理这些进程信息，创建了一个ProcessList，通过ProcessList来管理这些ProcessRecord。
ProcessList里面会有一个列表存放这最近使用的进程所对应的ProcessReocrd。

ActivityStackSupervisor里面会为当前进程创建一个RrocessRecord，通过ProcessList对ProcessRecord进行管理。然后通过ProcessList调用Process工具类，通过Process工具类去调用ZygoteProcess的start方法，通过socket发送消息给到zygotesever。

ZygoteInit进程在被创建出来后，在main方法里面执行了这几件事情：

1. 加载系统类，加载系统资源，加载一些共享so库，加载字体资源，加载webview相关资源
2. 创建socket服务，zygoteserver
3. Fork出的第一个进程 system_server
4. 在zygoteserver死循环等待socket消息，循环等待fork出其他的应用进程，比如Launcher，比如app

一旦我们通过Launcher和AMS通信，要求启动App进程里面的ActivityB，在ActivityStackSupervior里面判断ActivityB所在的进程没有被启动，则会通过ProcessList创建一个ProcessRecord存储当前要创建的进程的信息，然后再通过对工具类Process的调用进阶对ZygoteProcess的调用发送一条socket信息。这时候在ZygoteServer中的死循环就能检测到这条socket信息。然后获取socket命令，拿到发送过来的要fork的进程的相关信息，最后通过fork操作得到两个pid。之所以是得到两个pid是因为fork操作是把zygote进程完整复制一遍，就像细胞分裂一样。原来在zygote进程里面进行fork操作的地方在我们的子进程里面也会存在，也会返回一个结果。pid如果大于0是父进程Zygote，等于0是子进程，小与0说明执行fork操作失败。fork进程后第一时间把我们子进程的socket关闭，因为zygote进程的socket是进行跨进程通信使用，但是我们子进程跨进程通信使用的是binder。然后初始化运行环境，把我们子进程的binder驱动打开，创建binder线程池，最后通过反射去找到ActivityThread的main方法执行。

拿到socket消息后一共干了这几件事情：

1. 通过fork操作fork出子进程，fork操作会返回两个pid，因为fork操作是把zygote进程完整复制一遍，就像细胞分裂一样。原来在zygote进程里面进行fork操作的地方在我们的子进程里面也会存在，也会返回一个结果。
2. 关闭子进程的socket服务，因为ygote进程的socket是进行跨进程通信使用，但是我们子进程跨进程通信使用的是binder
3. 初始化运行环境
4. 把子进程的binder驱动打开，创建binder线程池
5. 反射找到Activity的main方法执行

为什么zygote跨进程通信要使用socket，Linnux里面是不允许在多线程环境下进行fork操作的，fork操作只会把父进程里面发起fork的那个线程复制到子进程里面，而Binder天生就是多线程的，如果有一个线程在等锁的话，那么在子进程里面他将永远在等锁。

为什么要使用反射来执行main方法，拿到socket消息后的所有操作都被封装成了一个runable，最后的runable的run方法就是拿到进程对应的main方法，执行main方法。封装正runable后统一使用反射来调用有点类似泛型，我只需要写一套代码，然后不管是system_service的fork还是activityThread的启动只需要用着一套代码就行了。实现了代码的复用，也方便统一管理。

在ActivityThread里面做了这几件事：

1. 为我们App进程创建一个Looper对象，并且使用ThreadLocal的set方法保存，赋值为一个static修饰的sMainLooper引用上面
2. 调用Looper的loop方法，启动一个死循环，不断的从MessageQuene里面取出Message，没有message的时候通过linnux的epoll wait机制让出cpu资源，进行休眠
3. 通过执行ActivityThread的attach方法，先通过ServiceManage拿到AMS的Binder，然后通过ActivityManager.Stub.asInterface拿到AMS的本地代理，通过和AMS所在的进程System_service进行跨进程通信，把我们App进程的Binder，ApplicationThread传递给AMS。

接下来的事情又回到AMS端了

在System_service进程的SystemServiceManager管理的AMS里面做了这几件事：

1. 把我们的APP的Binder存到对应的ProcessRecord里面
2. 把ProcessRecord的顺序在ProcessList重新排序一下
3. 通过App的Binder调用App端的ApplicationThread的attachApplication，创建一个Application
4. 回调到ActivityStackSupervisor里面完成剩余的Activity启动流程

通过Binder调用App端创建Application和后面的通过Binder把ClientTranstion传递给App端是通过Binder异步通信。所以有可能存在着Activity创建时，Application还没被创建的问题。会在Activity创建后调用makeApplication确保一下Application是被成功创建的，然后再去执行Activity的相关生命周期。

在ActivityThread里面创建Application做了这几件事情：

1. ApplicationThread通过sendMessage的方式去切换到主线程，因为AMS和App端跨进程通信使用的是Binder的异步机制，所以ApplicationThread里面的方法都是在异步线程里面执行的，需要通过handler切换到主线程里面。
2. 通过makeApplication函数，在内部通过反射来创建Application
3. 执行Appliaction的attach方法，在这个方法里面执行attachBaseContext
4. 创建contentProvide
5. 执行Application的onCreate方法

接下来回到Activity的启动流程，我们目前已经解析完了Activity的启动参数，创建出Activity的进程，创建出一个Application了。接下来会回到ActivityStackSupervior里面，先执行一下ActivityA的onPause方法，让ActivityA处于一个可见不可交互状态。然后在ActivityStackSupervior里面，把ActivityB的生命周期封装成一个事务ClientTranstion，在ClientTranstion事务里面保存了AMS希望App端处理的ActivityB的起始生命周期状态LaunchActivityItem，ActivityB的结束生命周期状态ResumeActivityItem。然后通过ClientLifecycleManager对ClientTranstion进行管理，拿到app端的binder，通过跨进程通信，在ClientLifecycleManager里面把当前的ClientTranstion传递给ActivityThread。

ActivityStackSupervisor里面一共干了以下几件事：

1. 根据当前Activity的所在进程有没有被创建去执行Activity的启动逻辑，没有被创建的话通过ProcessList去创建ProcessRecord，再通过工具类Process去操作ZygoteProcess发送socket信息，在ZygoteServer里面收到信息fork出进程。App进程被fork出来第一时间关掉socket服务，然后初始化运行环境，启动binder驱动和binder线程池，最后通过反射去找打ActivityThread的main方法执行。在main方法里面又调用attach，跨进程通信把app的binder传递给System_service里面的AMS。AMS保存当前的App进程的binder到对应的ProcessRecord里面，并且更新ProcessRecord在ProcessList里面的位置。又通过Binder和App进程通信，跨进程调用bindApplication。在App进程里面先通过sendMessage方法，把相关信息通过handler发送到主线程。在主线程通过makeApplication反射创建一个Application，执行application的attach方法，attachBaseContent方法，再创建contentProvide方法，最后才执行Application的onCreate方法。
2. 执行ActivityA的onPause方法
3. 把AMS希望App端执行的ActivityB的起始生命周期LaunchActivityItem，结束生命周期ResumeActivityItem包装成一个ClientTranstion。通过ClientLifecycleManager管理ClientTranstion，在ClientLifecycleManager里面拿到App对应的binder，跨进程通信把事务ClientTranstion传递给App端

ActivityThread对Activity生命周期的管理

在ActivityThread里面接受到AMS传递的生命周期事务ClientTranstion后，通过sendMessage切换到主线程。利用事务处理器TranstioneExector处理事务里面的生命周期，起始生命周期LaunchActivityItem和结束生命周期ResumeActivityItem。在处理LauncherActivityItem方法的时候，首先创建ActivityClientRecord，ActivityClientRecord是Activity在App进程里面的一个实体，里面会存有一个变量Activity。然后会调用handleLaunchActivity方法，把这个创建的ActivityClientRecord传递给它，实际上调用performLaunchActivity反射创建一个Activity，之前说过AMS和App跨进程通信创建Application和AMS和App跨进程通信传输ClientTranstion是使用了Binder的异步通信机制，所以创建Activity后会进行makeApplication，确保在执行activity的onCreate方法前，application已经被成功创建出来。执行完onCreate后，把当前的生命周期状态ON_CREATE存储在ActivityClientRecord里面。接下来事务处理器拿到结束生命周期ResumeActivityItem的生命周期状态ON_RESUME，计算存储在ActivityClientRecord里面的生命周期状态和结束生命周期状态，发现中间还有一个ON_START生命周期，接着执行ON_START生命周期。最后再执行ON_RESUME生命周期。在handleResumeActivity执行完ActivityB的onResume方法后，会通过IdlerHandler的queueIdle方法里面拿到AMS的Binder，然后和AMS通信，跑到ActivityStackSupervisor类里面，找到Activity对应的ActivityRecord，在ActivityRecord里面把onStop包装成一个事务ClientTranstion，然后通过ClientLicycleManager对事物进行管理，拿到对应的App进程的Binder，最后把包装好的事务跨进程通信传递回Launcher进程，使用事务处理器TranstionExector进行生命周期的执行。

在ActivityThread里面对生命周期管理主要分为以下几步：

1. 拿到AMS跨进程通信传递过来的生命周期事务ClientTranstion，通过sendMessage从子线程发送到主线程的事务处理器处理。
   在主线程的事务处理器里面先执行起始生命周期LaunchActivityItem的exect方法，创建一个ActivityClientRecord，然后把这个对象传递给ActivityThread的handlerlaunchActivity
2. 在handlerlaunchActivity方法里面通过反射创建出Activity，然后通过makeApplication方法确保此时的Application是被成功创建的，再嘻嘻onCreate方法，并且把此时的生命周期状态ON_CREATE存储在ActivityClientRecord里面
3. 事务处理器TranstionExect计算起始生命周期状态和结束生命周期状态，发现中间还有一个ON_START的生命周期状态需要执行，于是执行ON_START生命周期
4. 最后执行ResumeActivityItem的exect方法，调入到handlerResumeActivity里面，执行完activityB的onResume方法，然后把DecorView添加到Window上面
5. 在handlerResumeActivity尾部，通过一个IdleHandler，在messagequeue没有message执行或者休眠的时候通过binder和AMS通信，调回到ActivityStackSupervior，找到ActivityA对应的ActivityRecord，在ActivityRecord把onStop方法封装成一个事务ClientTranstion，在通过AMS和App进程跨进程通信，把事务传送给App进程，最后通过事务处理器TranstionExect执行ActivityA的相关生命周期