Android启动过程深入解析

AMS主要功能：

AMS是Android中最核心的服务，主要负责系统中四大组件的启动、切换、调度及应用进程的管理和调度等工作。还负责启动或杀死应用程序的进程。

WMS主要功能：

为所有窗口分配Surface。

管理Surface的显示顺序、尺寸、位置。

管理窗口动画。

输入系统相关：WMS是派发系统按键和触摸消息的最佳人选，当接收到一个触摸事件，它需要寻找一个最合适的窗口来处理消息。

PWS主要功能：

PMS 用来管理跟踪所有应用APK，包括安装，卸载，解析，控制权限等。

SystemServer也是一个进程，包括AMS、PMS、WMS等等。

zygote意为“受精卵“。Android是基于Linux系统的，而在Linux中，所有的进程都是由init进程直接或者是间接fork出来的，zygote进程也不例外。

App进程是用户点击桌面icon时，通过Launcher进程请求SystemServer，再调用Zygote孵化的。

①点击启动一个App，Launcher进程采用Binder IPC向ActivityManagerService发起startActivity请求；

②ActivityManagerService接收到请求后，向zygote进程发送创建进程的请求；

③Zygote进程fork出新的子进程，即App进程；

④App进程通过Binder IPC向sytem_server进程发起绑定Application请求；

⑤system_server进程在收到请求后，进行一系列准备工作后，再通过binder IPC向App进程发送scheduleLaunchActivity请求；

⑥App进程的binder线程（ApplicationThread）在收到请求后，通过handler向主线程发送LAUNCH_ACTIVITY消息；

⑦主线程在收到Message后，通过发射机制创建目标Activity，并回调Activity.onCreate()等方法。

⑧到此，App便正式启动，开始进入Activity生命周期，执行完onCreate/onStart/onResume方法，UI渲染结束后便可以看到App的主界面。

备注：

Launcher，PMS，Zygote，App进程是三个独立的进程，相互通信就需要使用进程间通信机制。与Zygote通信是使用的socket通信，Launcher，PMS，App进程间使用的是Binder机制。

本文主要学习记录，基于Android 10的源码，有错误欢迎指正，主要目的是梳理流程图。

以进程为单位的调用栈图如下：

1.activity中的startActivity方法最终都会通过拿到ATSM的代理IActivityTaskManager调用的startActivity；

2.之后进入system server进程中的ATMS startActivity，ATMS 经过收集Intent信息，然后使用ActivityStackSupervisor.startSpecificActivityLocked，如果进程已经存在，则直接使用realStartActivityLocked，通过App的binder客户端的代理ApplicationThread调用回到bindApplication，走入Activity的启动流程；如果进程不存在则通过socket链接Zygote，请求fork新的进程；

3.App进程创建完成后，进程启动会调用ActivityThread.main方法，初始化主线程Handler,接着走入attach方法，然后通过AMS的代理调用AMS的attachApplication方法，并将App进程的通信代理ApplicationThread传入AMS；

4.AMS获取到ATMS调用ApplicationThread的bindApplication回到App进程的ActivityThread.ApplicationThread.bindApplication方法中，然后使用Handler切换到主线程执行handleBindApplication，这里初始化了App的进程名字、时间，用户的硬件配置，包括App的文件系统，创建了App的Context实例，Instrumentation实例，调用App的onCreate回调方法，同时告诉AMS APP初始化工作完毕；

5.AMS接着会调用ATMS的attachApplication，最后调用ClientLifecycleManager的scheduleTransaction方法，通过App的Binder代理ApplicationThread回到ActivityThread；

6.进入ActivityThread.ApplicationThread.scheduleTransaction方法之后就进入了Activity的onStart、onResume回调

创建进程之前的过程主要是AMS的内部信息收集的判断的过程，下面主要看一下App进程启动的源码流程

从应用进程被创建开始，ActivityThread.main被执行

调用ActivityThread的attach方法，然后将activity和AMS通信的Binder代理IApplicationThread实例传入AMS

接着进入AMS进程，ActivityManagerService.attachApplicationLocked

1.thread.bindApplication ：该方法主要讲App进程的配置信息通过IApplicationThread Binder通信回传到ActivityThread中

2.mAtmInternal.attachApplication ：mAtmInternal实际就是ActivityTaskManager的实例，通过LocalServices加载

那么这里相当于走到了ActivityTaskManagerServer的attachApplication中

先看第一条：

注意：ActivityThread中存在于Binder通信的代理--》ApplicationThread extends IApplicationThread.Stub

ActivityThread--》ApplicationThread--》bindApplication

这里的bindApplication主要初始化了AppBindData，然后发送BIND_APPLICATION给APP的主线程BIND_APPLICATION，最后执行了handleBindApplication

handleBindApplication如下：

ActivityThread--》class H extends Handler

该方法主要在App进程中对App的一些硬件资源配置申请的属性、App的文件夹等完成App基本信息的初始化

接着看第二条：mAtmInternal.attachApplication

mAtmInternal.attachApplication最终会调用mRootActivityContainer.attachApplication(wpc)

RootActivityContainer.attachApplication

接着调用ActivityStackSupervisor.realStartActivityLocked开始创建Activity

ActivityStackSupervisor.realStartActivityLocked

创建ClientLifecycleManager和ClientTransactionHandler来辅助管理Activity的生命周期

注意

clientTransaction.addCallback是LaunchActivityItem

lifecycleItem是ResumeActivityItem

ClientLifecycleManager.scheduleTransaction最终会调用ClientTransaction的schedule方法

那么这个mClient是IApplicationThread的实例，那么此时也就回到了ActivityThread的ApplicationThread中

ActivityThread的ApplicationThread中

因为ActivityThread继承ClientTransactionHandler，所以到了ClientTransactionHandler中

通过Handler发送消息EXECUTE_TRANSACTION到H中

接着TransactionExecutor的execute方法

LaunchActivityItem.execute方法

client其实是在ActivityThread的实例，那么就回到了ActivityThread的handleLaunchActivity

接着调用performLaunchActivity

在performLaunchActivity中，主要是加载App的资源包，然后创建了Activity的context实例，并创建了Activity的实例，接着调用activity.attach方法，attach执行完之后调用了onCreate方法。

activity.attach

activity.attach中主要

1.创建了PhoneWindow实例

2.设置了Window接口的监听

3.初始化了成员变量，包括线程和WindowManager

到此Oncreate已经完成，那么OnStart和OnResume去哪了？

TransactionExecutor的execute方法

之前们只分析了executeCallbacks，接着executeLifecycleState方法

TransactionExecutor的executeLifecycleState方法

cycleToPath：lifecycleItem即为ResumeActivityItem

第一点：

int finish = lifecycleItem.getTargetState()

lifecycleItem对应ResumeActivityItem，如下：

ResumeActivityItem的getTargetState方法

对应ActivityLifecycleItem中的枚举类型：

第二点：ActivityClientRecord中的mLifecycleState，由于在前面已经执行了handleLaunchActivity所以mLifecycleState=1

对应ActivityLifecycleItem中的枚举类型：

PRE_ON_CREATE = 0

所以final int star = 1

接着看getLifecyclePath，此时start=1，finish=3

那么返回的IntArray就是2

接着看performLifecycleSequence

最终执行的是handleStartActivity所以最终走到了ActivityThread的handleResumeActivity

两点：

调用activity.performStart

调用Instrumetation.callActivityOnPostCreate

performStart方法：

调用了Instrumentation.callActivityOnStart方法：

最终到了activity的onStart方法

第二点：Instrumentation.callActivityOnPostCreate

上面主要走了cycleToPath，接着ResumeActivityItem.execute

调用了handleResumeActivity方法

handleResumeActivity最终调用performResumeActivity

调用了Instrumentation.callActivityOnResume，

到了activity.onResume()方法

参考文章： https://blog.csdn.net/u011386173/article/details/87802765

---