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 的启动