Android系统启动一个APP(Activity)的流程
一,先简单介绍一下系统的启动过程
在学习APP的启动之前先简单了解下系统的启动,有助于我们更好的学习APP的启动。系统的启动过程很复杂,这里简单化,只关心大致流程和涉及到的一些名词以及相关类的作用
APP的启动可以简单总结为一下几个流程:
加载BootLoader --> 初始化内核和驱动–> 启动init进程 --> 解析inir.rc脚本–> init进程fork出Zygote进程 --> Zygote进程fork出SystemServer进程
二,启动一个APP的过程
(1),重要进程以及类和函数的说明:
1,Zygote进程:系统中的所有经常进程都是由Zygote进程fork出来的,
2,SystemServer进程是系统进程,很多系统服务,例如ActivityManagerService、PackageManagerService、WindowManagerService…都是存在该进程被创建后启动
3,ActivityManagerServices(AMS):是一个服务端对象,负责所有的Activity的生命周期,AMS通过Binder与Activity通信,而AMS与Zygote之间是通过Socket通信
4,ActivityThread:UI线程/主线程,它的main()方法是APP的真正入口
5,ApplicationThreadNative:继承了Binder,Binder实现了IBinder接口
5,ApplicationThread:是ApplicationThreadNative的子类,一个实现了IBinder接口的ActivityThread内部类,用于ActivityThread和AMS的所在进程间通信
6,ApplicationThreadProxy:ApplicationThread在AMS端的代理
7,Instrumentation:可以理解为ActivityThread的一个工具类,在ActivityThread中初始化,一个进程只存在一个Instrumentation对象,在每个Activity初始化时,会通过Activity的Attach方法,将该引用传递给Activity。Activity所有生命周期的方法都有该类来执行
8,ActivityManagerNative:是一个抽象的类,继承Binder类,实现IActivityManager接口
9, ActivityManagerProxy:也实现了IActivityManager接口,是AMS在客户端代理,获取方式ActivityManagerNative.getDefault() 返回的就是ActivityManagerNative的内部类ActivityManagerProxy,ActivityManagerProxy的构造方法需要传入一个服务端的IBinder,然后就可以和AMS通信,调用AMS的函数了。
(2),流程图(不是很完整)
(3)代码执行过程分析:
1,点击桌面APP图标时,Launcher调用startActivity()方法,通过Binder通信最终调用system_server进程中AMS服务的startActivity方法,发起启动请求。
2 ,system_server进程的AMS服务收到启动请求后,执行初始化操作解析启动模式保存请求信息等一系列操作,然后AMS会先将系统当前栈顶的Activity执行onPause操作,具体就是利用Binder机制通过AMS端的ApplicationThreadProxy,告诉前台APP执行当前栈顶Activity的onPause方法,前台APP的ActivityThread的内部类ApplicationThread(ApplicationThreadNative子类继承Binder)收到这个消息后,通过Handle发消息给ActivityThread,ActivityThread又通知(调用)Activity对象去执行onPause方法。当执行完onPause方法之后,又通过ActivityManagerNative.getDefault()函数获取到ActivityManagerNative的内部类ActivityManagerProxy(AMS在客户端的代理)和AMS通信,告诉AMS栈顶Activity已经执行完onPause方法,AMS接下来会继续执行启动Activity的操作。
2,AMS首先判断需要先判断Activity所在的进程是否已经启动,如果没有启动的话会先启动这个进程,AMS通过socket通信向Zygote进程发送创建进程的请求。如果已经启动就不用创建进程了,直接通知这个APP的ActivityThread去创建Activity对象(已经创建了,根据不同的启动模式可能不需要重新创建Activity对象,有的启动模式需要重新创建Activity对象),并执行它的生命周期。
3,Zygote进程fork出App进程,并执行ActivityThread的main方法,这也是APP的入口方法,创建ActivityThread线程,初始化MainLooper,主线程Handler,同时初始化ApplicationThread用于和AMS通信交互。
4, App进程,通过Binder向sytem_server进程发起attachApplication请求,这里实际上就是APP进程通过Binder调用sytem_server进程中AMS的attachApplication方法,上面我们已经分析过,AMS的attachApplication方法的作用是将ApplicationThread对象与AMS绑定。
5 ,system_server进程在收到attachApplication的请求,进行一些准备工作后,再通过binder IPC向App进程发送handleBindApplication请求(初始化Application并调用onCreate方法)和scheduleLaunchActivity请求(创建启动Activity)
6, App进程的binder线程(ApplicationThread)在收到请求后,通过handler向主线程发送BIND_APPLICATION和LAUNCH_ACTIVITY消息,这里注意的是AMS和主线程并不直接通信,而是AMS和主线程的内部类ApplicationThread通过Binder通信,ApplicationThread再和主线程通过Handler消息交互。 ( 这里猜测这样的设计意图可能是为了统一管理主线程与AMS的通信,并且不向AMS暴露主线程中的其他公开方法,大神可以来解析下)
7, 主线程在收到Message后,创建Application并调用onCreate方法,再通过反射机制创建目标Activity,并回调Activity.onCreate()等方法
8, 到此,App便正式启动,开始进入Activity生命周期,执行完onCreate/onStart/onResume方法,UI渲染后显示APP主界面
9,前面执行完之后,AMS开始执行之前栈顶Activity的onStop方法,具体就是通过Binder通信通知Activity所在进程的ActivityThread执行。
参考链接:
https://blog.csdn.net/hzwailll/article/details/85339714
https://blog.csdn.net/weitangzhu_2008/article/details/86680715