我的Android学习和总结：Android系统启动一个APP（Activity）的流程

                                                                        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