Application启动流程分析
启动方式一:通过Launcher启动app
启动方式二:在某一个app里启动第二个app的Activity.
以上两种方式均可触发app进程的启动。但无论哪种方式,最终通过通过调用AMS的startActivity()来启动application的。
根据上图分析, 要启动一个Application,需要涉及五个进程,Launcher进程,SystemServer进程,Zygote进程,和要启动的目标Application进程,最后还有一个ServiceManager进程。通过Launcher进程是无法直接启动app的,因为启动是通过AMS或ATMS完成的。
所以第一步,Launcher必须要拿到AMS的Binder,而AMS的Binder(如上图左侧)在Launcher中的代理则是ActivityManagerProxy,它是Launcher从ServiceManager中查询获取而得到的,然后基于这个代理,向SystemServer进程中的AMS去请求startActivity().
这个过程是通过ActivityManagerProxy这个Binder远程调用了AMS的服务,让AMS去startActivity. 但是AMS在启动之前肯定要先判断一下这个Activity对应的Application进程是否已经存在。如果进程存在, 直接走上面的第五步,这一步的处理过程也是跨进程通信的,通过获取APP进程在AMS中的客户端代理即ApplicationThreadProxy, 通过这个代理Binder远程调用app进程的scheduleLauncherActivity()方法直接启动进程中的Activity,这个流程是基于APP进程已经存在了,所以走的是第5和6步分支。
但是现在要讨论的是APP进程不存在的时候,这个APP的启动流程,这种启动方式会覆盖所有app的启动流程。所以AMS当发现进程不存在时,它首先会走第2步,向Zygote进程发送创建进程的请求,这一步采用的是socket通信方式来操作的,zygote收到socket指令后,是通过调用fork()的方式来启动复制创建一个application进程的,这个就是第三步。一旦这个Application被创建,它不会立刻运行,因为它是由AMS来负责的,所以它会先将自身的Binder代理对象发给AMS,这个是第四步,它是利用ActivityManager在Application的Binder对象ActivityManagerProxy来远程调用其attach_application()方法来传递自身Binder。这样AMS也就保存了这个Application的Binder对象,
然后才是走第5步,在第5步中如上面的分析(app进程已经存在的情况下),利用Application在AMS的Binder代理即ApplicationThreadProxy进行启动,最后执行到第8步,调用Activity.onCreate方法。