AMS
Activity管理模块、Service管理模块、BroadcastReceiver管理模块、ContentProvider管理模块、进程管理模块、App错误管理模块、App性能分析模块
App端框架
上图先简单介绍下App端框架的运行过程：
- 凡是从ActivityManagerService过来的数据，都需要经过ApplicationThread类，这本身是一个binder通信的过程。而大部分数据会通过Handler post到UI线程去执行，ActivityThread会把各种数据进行分发，比如是启动Activity的还是启动Service的等等。
- 当App进程被创建后，ActivityManagerService会把当前App的各种重要信息比如包名、Apk版本信息、Apk文件路径、so库文件路径、共享库文件路径等等这些数据传递给App进程，LoadedApk会把Apk文件路径、so库文件路径、共享库文件路径这些数据交给类加载器，类加载器就可以加载当前Apk中的各种类了。
- 在启动一个Activity的时候，ActivityManagerService会把Activity的信息如Activity的类名通过binder通信传递给ActivityThread，而ActivityThread会根据要启动的Activity的类名通过反射，初始化一个对应Activity的实例，进而会调用相应Activity的onCreate、onResume这些生命周期方法。
凡是与Service、ContentProvider、BroadcastReceiver三大组件有关系的事情都归我ActivityManagerService负责，而Activity相关的事情都归ActivityTaskManagerService负责
启动
SystemServer把所有的服务分类为bootstrap service、core service、other service、apex service这四种类型。先在startBootstrapServices方法中启动bootstrap类型的服务，其次在startCoreServices方法中启动core类型的服务，再次在startOtherServices方法中启动other类型的服务，最后在startApexServices启动apex类型的服务。因此SystemServer启动过程就是依照上面的顺序启动各种服务，而我ActivityManagerService很荣幸属于bootstrap类型的服务，因此是最早被初始化
SystemServer的启动过程中会分发不同的阶段值，不同的阶段值所代表的含义各不相同，服务收到这些阶段值就可以知道当前是到了哪个启动阶段了，同时根据自己的需求来做不同的事情。
PHASE_WAIT_FOR_DEFAULT_DISPLAY代表当前阶段正在等待获取显示屏幕的硬件信息，这时候SystemServer的启动过程就暂时处于暂停状态，若屏幕硬件信息获取失败则停止启动；否则继续启动。
PHASE_ACTIVITY_MANAGER_READY代表ActivityManagerService已经准备好了，其他的服务可以使用ActivityManagerService提供的服务了，比如发送广播。
PHASE_BOOT_COMPLETED代表SystemServer启动完成了，所有的服务都已经准备好“进入工作状态”了，Android设备可以被用户使用了 (当然这只是解释几个常用的阶段值)。
启动可以分为出生、设置系统进程、准备、等待boot anim完成这四个步骤，出生这个步骤发生于startBootstrapServices方法的最前面，而设置系统进程这个步骤发生于startBootstrapServices方法的中间部分，准备这个步骤发生于startOtherServices方法的结尾部分，而等待boot anim则是最后一个步骤。可以看到ActivityManagerService的启动贯穿了Systemserver启动流程的全过程
启动发生后，添加到ServiceManager服务，这样我的使用方比如各种App就可以使用我的功能了。我所在的systemserver进程被ProcessRecord对象记录下来，并且它不再“无名无姓”了，它的包名就是android。这样进程管理就可以对systemserver进程进行管理了。同时systemserver进程的pid和oom_score:-900信息也传递给lmkd进程，便于lmkd更好的查杀进程。
经过此步骤后，SystemServer后面的启动流程中各种服务就可以从进程管理根据包名android拿到systemserver进程对应的ProcessRecord对象，进而做相应的处理了。
Systemserver启动贯穿了SystemServer启动的整个流程，如下是启动过程所做的事情：
- 在SystemServer最先启动的时候，会创建ActivityManagerService的实例，并且初始化它包含的各种属性
- 我还承担了设置系统进程的任务，我会创建ProcessRecord对象把systemserver进程信息记录下来，并且为systemserver进程提供android这样的包名，这样systemserver进程就可以被记录并且被进程管理进行管理了，同时我还会把systemserver进程的pid和oom_score:-900的信息传递给lmkd进程
- 在准备阶段我会把PHASE_ACTIVITY_MANAGER_READY这个阶段值发送给所有服务，并且还会启动launcher，启动launcher可是一个系统能不能被使用的一个重要环节
- 当收到launcher启动完成的消息后，boot anim会消失，这时候我会发送PHASE_BOOT_COMPLETED阶段值，该值可是代表Android设备可以被用户使用了。
APP的启动
App进程的启动分为准备、告知和初始化三部分
准备作为启动的第一阶段，它发生于main方法，因为ActivityThread还没有实例化，因此会实例化一个ActivityThread对象。如果要想保证一个App进程一直运行的话，一般的做法是在一个线程里面不断的循环执行某些操作。而Android中创造了Looper、Handler、Message、MessageQueue，在main方法中会开启Looper，这个Looper会保证当前线程不断的“循环”下去，这里的循环并不是傻傻的循环，而是Looper的MessageQueue中有Message的话去执行，没有Message的话则会处于等待状态。而Looper所处的线程就是UI主线程了，也就是Looper会在UI主线程里面不断的“循环”下去。
告知用简单明了的话说就是App进程告知ActivityManagerService我这边准备好了，为啥要有这一阶段呢？
首先systemserver进程中的ProcessList类虽然是fork App进程的发起方，但是App进程被fork成功以及准备好这些好消息是非常有必要告知ActivityManagerService的。经过此阶段后，App进程处于等待ActivityManagerService的回复结果中。
初始化主要做了初始化PathClassLoader、创建Application、安装ContentProvider、调用Application的onCreate方法
ATMS会通过binder通信把启动Activity的数据发送给ApplicationThread，ApplicationThread同样把这一消息通过Handler post到UI线程中。最终会在ActivityThread的handleLaunchActivity方法中开始启动Activity
Task的容器--TaskDisplayArea
启动Activity的过程分为查询Activity信息、检查、记录Activity信息、启动App进程、App进程准备好、发送初始化数据、发送Activity启动信息这几步，当然这几步中会需要zygote进程及进程管理模块帮忙
