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方法。
