本文用于记录Android四大组件启动流程的相关知识总结。主要梳理思路，源码比较少......

一. Activity

Activity有两种：根Activity和普通Activity。根Activity的启动等价于应用程序的启动过程。

根Activity的启动分成3个步骤：

• Launcher请求AMS过程
• AMS到ApplicationThread的调用过程
• ActivityThread启动Activity的过程

① Launcher请求AMS过程

当我们点击APP图标时，就会通过Launcher请求AMS来启动应用程序。
大概的流程如下：

Launcher（```startActivitySafely```）
👇
Activity（```startActivity```）
👇
Instrumentation（```execStartActivity```）
👇
IActivityManager（```startActivity```）
👇
AMS（```startActivity```）

Launcher和Activity部分，主要是对Intent等参数的处理和判断。Instrumentation主要用来监控应用程序和系统的交互，算是一个抽离出来的负责该交互功能的类。
IActivityManager是AMS在本地的代理，通过Binder机制与AMS建立联系。也就是说Instrumentation的本质就是调用AMS的startActivity。

② AMS到ApplicationThread的调用过程

Launcher请求AMS后，代码逻辑已经进入AMS中。
接下来的流程如下：

AMS（```startActivity``` → ```startActivityAsUser```）
👇
ActivityStart（```startActivityMayWait```→ ... ）
👇
ActivityStackSupervisor（```resumeFocusedStackTopActivityLocked```）
👇
ActivityStack（```startActivity```）
👇
ActivityStackSupervisor（```realStartActivityLocked```）
👇
ApplicationThread（```scheduleLaunchActivity```）

AMS判断调用者进程是否被隔离，检查调用者权限，然后调用ActivityStart。ActivityStart是加载Activity的控制类，会收集所有的逻辑来决定如何将Intent和Flags转换为Activity，并将Activity和Task以及Stack相关联。
ActivityStart的startActivity逻辑也比较多，主要做的事情是判断处理参数，其中IApplicationThread（Launcher的ApplicationThread对象）、ActivityRecord（Activity信息模型）、ProcessRecord（进程信息模型）这些对象的处理需要再梳理一下。
进入ActivityStackSupervisor中，栈管理的相关逻辑也会在ActivityStack中执行，最终会回到ActivityStackSupervisor，调用其的startSpecificActivityLocked，这是最重要的一步，让APP自己去做事情。
获取即将启动的Activity所在的应用程序进程，当做参数，通过Binder通信，让APP自己去做事，也就是代码逻辑进入APP。

这边需要注意的是：
AMS是在SystemServer进程，APP是单独的进程。它们之间的通信是通过Binder。要想让APP去启动Activity，是通过AMS与ApplicationThread的Binder通信。ApplicationThread是ActivityThread的内部类，继承了IApplicationThread.sub。ActivityThread是应用程序主线程，主线程存在于应用程序进程。

AMS与应用程序进程通信.jpeg

③ ActivityThread启动Activity的过程

目前代码逻辑运行在应用程序进程中。
流程如下：

ApplicationThread（```scheduleLaunchActivity```）
👇
ActivityThread（```sendMessage```）
👇
H（```handleMessage```）
👇
ActivityThread（```handleLaunchActivity```）
👇
Instrumentation（```callActivityOnCreate```）
👇
Activity（```performCreate```）

scheduleLaunchActivity将启动Activity的参数封装成ActivityClientRecord，通过ActivityThread（管理当前应用程序进程的主线程）的mH（Handler）发送消息。mH是ActivityThread的内部类并继承自Handler，是应用程序进程中主线程的消息管理类。因为ApplicationThread是一个Binder，调用逻辑运行在Binder线程池中，所以需要用H将代码逻辑切换到主线程。
应用程序进程要启动Activity时需要将该Activity所属的APK加载进来，LoadedApk就是用来描述已加载的APK文件的。获取的ActivityInfo和LoadedApk，创建启动Activity的上下文环境，用类加载器来创建Activity的实例，初始化Activity实例（通过attach，创建Window对象（PhoneWindow）与Activity自身进行关联），然后Instrumentation调用callActivityOnCreate，从而调用Activity的onCreate，根Activity就启动了，应用程序就启动了。

总结:
简单记，Launcher进程告诉AMS要启动Activity（处理权限，栈信息），如果没有APP进程，AMS还要让Zygote进程去创建。AMS处理完通过Binder回调到APP（请求创建Activity），从ApplicationThread到ActivityThread主线程，APP启动Activity。启动过程包括类信息加载，创建，创建Application，创建PhoneWindow并关联。

根Activity启动过程中涉及到4个进程：
Launcher进程请求AMS启动根Activity，AMS请求Zygote进程创建应用程序进程，Zygote进程创建并启动应用程序进程，应用程序进程告诉AMS已经准备就绪了，AMS告诉应用程序进程启动根Activity，应用程序进程自己启动根Activity。

普通Activity启动过程中涉及到2个进程：
AMS进程和应用程序进程。AMS告诉应用程序进程启动根Activity，应用程序进程自己启动根Activity。

二. Service

Service的启动过程分成两部分：

• ContextImpl到AMS的调用过程
• ActivityThread启动Service

① ContextImpl到AMS的调用过程

要启动Service，我们会调用startService，它在ContextWrapper中实现。
流程如下：

ContextWrapper（```startService```）
👇
ContextImpl（```startService```）
👇
IActivityManager（```startService```）
👇
AMS（```startService```）

ContextWrapper是ContextImpl的包装类，本质是调用ContextImpl的方法。之前在Activity的启动的最后步骤里，创建启动Activity的上下文环境appContext（ContextImpl），并传入Activity的attach，将Activity与上下文对象appContext关联起来，实际上就是将ContextImpl赋值给ContextWrapper的成员变量mBase。在ContextImpl中，会调用AMS的代理IActivityManager的startService，最终将逻辑转移到AMS中。

② ActivityThread启动Service

AMS（```startService```）
👇
ActivityServices（```startServiceLocked``` → ...）
👇
ApplicationThread（```scheduleCreateService```）
👇
ActivityThread（```sendMessage```）
👇
H（```handleCreateService```）
👇
Service（```onCreate```）

AMS和ActivityServices逻辑都是在AMS中（ActivityServices是AMS的mServices成员变量）。在ActivityServices中，会对Services信息进行处理，比如retrieveServiceLocked会查找与参数service对应的ServiceRecord，如果没找到会调用PMS去获取service对应的Service信息，并封装在ServiceRecord（Service模型类，类似ActivityRecord）。
另外，会根据record中processName（processName描述Service想在哪个进程运行，默认当前线程，在AndroidMainfest文件中的android:process设置），将processName和Service的uid传入到AMS的getProcessRecordLocked，查询是否存在一个与Service对应的ProcessRecord类型的对象app，如果为空则通过AMS的startProcessLocked来创建对应的应用程序进程。然后接着调用realStartServiceLocked。这一部分的逻辑类似上面介绍Activity的启动，通过与ApplicationThread的通信，将创建Service的逻辑转移到应用程序进程。启动Service的参数会被封装成CreateServiceData，ActivityThread通过Handler机制，将逻辑转到主线程执行，即handleCreateService，这块内容大概就是获取启动Service的应用程序的LoadedApk，获取类加载器，通过类加载器来创建Service实例，同样通过Service的attch来初始化Service，并将启动的Service加入到ActivityThread的成员变量mServices（ArrayMap类型）。

三. BroadcastReceiver

① 广播的注册过程

广播分为静态注册和动态注册，静态注册在应用安装时由PMS完成注册过程，所以以下介绍的是动态注册。
流程如下：

ContextWrapper（```registerReceiver```）
👇
ContextImpl（```registerReceiver``` → ```registerReceiverInternal```）
👇
IActivityManager（```registerReceiver```）
👇
AMS（```registerReceiver```）

流程跟Service差不多，不一样的是

② 广播的发送和接收过程

广播的发送和接收过程又分成ContextImpl到AMS的调用过程和AMS到BroadcastReceiver的调用过程

ContextImpl到AMS的调用过程

ContextWrapper（```sendBroadcast```）
👇
ContextImpl（```sendBroadcast```）
👇
IActivityManager（```broadcastIntent```）
👇
AMS（```broadcastIntent```）

AMS到BroadcastReceiver的调用过程

流程如下：

BroadcastQueue（```scheduleBroadcastsLocked```）
👇
BroadcastHandler（```sendBroadcast```）
👇
ApplicationThread（```broadcastIntent```）
👇
InnerReceiver（```broadcastIntent```）
👇
ReceiverDispatcher（```broadcastIntent```）
👇
Args（```broadcastIntent```）
👇
BroadcastReceiver（```broadcastIntent```）

四. ContentProvider

未完待续....