App 启动流程（基于Android8.0）：
- 点击桌面 App图标，Launcher进程采用 BinderIPC（具体为ActivityManager.getService 获取 AMS 实例） 向system_server的AMS发起 startActivity请求
- system_server 进程收到请求后，向 Zygote 进程发送创建进程的请求；
- Zygote 进程 fork 出新的子进程，即 App 进程
- App 进程创建即初始化 ActivityThread，然后通过BinderIPC 向 system_server 进程的 AMS 发起attachApplication 请求
- system_server 进程的 AMS 在收到 attachApplication 请求后，做一系列操作后，通知 ApplicationThread bindApplication，然后发送 H.BIND_APPLICATION 消息
- 主线程收到 H.BIND_APPLICATION 消息，调用handleBindApplication 处理后做一系列的初始化操作，初始化 Application 等
- system_server 进程的 AMS 在 bindApplication 后，会调用 ActivityStackSupervisor.attachApplicationLocked， 之 后经过一系列操作，在 realStartActivityLocked 方法通过Binder IPC 向 App 进程发送scheduleLaunchActivity 请求；
- App进程的 binder 线程（ApplicationThread）在收到请求后，通过 handler 向主线程发送LAUNCH_ACTIVITY 消息；
- 主线程收到 message后经过 handleLaunchActivity，performLaunchActivity 方法，然后通过反射机制创建目标Activity；
- 通过 Activityattach方法创建 window并且和 Activity 关联，然后设置 WindowManager 用来管理 window， 然后通知 Activity 已创建，即调用 onCreate
- 然后调用 handleResumeActivity，Activity可见。
补充：
- ActivityManagerService 是一个注册到 SystemServer进程并实现了 IActivityManager的Binder，可以通过ActivityManager 的 getService 方法获取 AMS 的代理对象，进而调用 AMS 方法
- ApplicationThread 是 ActivityThread 的内部类，是一个实现了 IApplicationThread的 Binder。AMS通过 BinderIPC经ApplicationThread对应用进行控制
- 普通的 Activity 启动和本流程差不多，至少不需要再创建App 进程了ActivityA启动 ActivityB，A先pause然后 B才能resume，因此在 onPause 中不能做耗时操作，不然会影响下一个 Activity 的启动
