android Activity面试启动流程分析

面试的时候，想要说清楚ams的各个关系不容易，这边记录下：

外部调用startActivity方法，启动一个Activity的时候，都会调用Instrumentation的execStartActivity方法，而这个方法在android7.0以下和以上的处理是不一样的，7.0以下的处理：

通过ActivityManagerNative 的静态方法getDefault，取得ActivityManagerProxy，它子类就是大名鼎鼎的ActivityManagerService，因为涉及到跨进程，所以ActivityManagerNative 和ActivityManagerProxy这两个类的交互，采用binder机制进行通信。

因此这里Instrumentation、ActivityManager等想要和AMS进行通信的地方都需要进过AMP（ActivityManagerProxy），通过binder机制，进而和AMS进行通信。

7.0以上的处理：

ActivityManager.getService()方法，取得AMS对象，直接进行处理，这里内部采用aidl机制，虽然aidl底层也是通过binder机制实现的，但这里源码绕过了AMN和AMP的逻辑，看上去可以直接调用了。

说白了  AMS属于系统进程，系统真正的处理是在这里的，跟你的app并不在同一个进程，你想要调用另一个进程的服务，就是需要通过跨进程的方式。

AMS中包含activitiy业务需要的所有逻辑，startActivity，finishActivity，启动模式，生命周期，数据传递等，Activity的栈管理等

那么系统层的AMS创建流程什么样的？都知道，zygote进程是android系统启动的第一个进程，而其他像AMS，WMS都是基于Zygote进程启动的，这一类属于SystemService，而我们的系统启动的最后一步，是通过PackagerManagerService返回已经安装的应用程序信息，显示在屏幕上，这个叫Launcher。当我们点击Launcher上一个应用程序时，通过AMS给Zygote进程发送一个创建应用进程的socket请求，Zygote收到请求后，确认匹配过程，通过反射方式取到ActivityThread，调用main方法。此时ActivityThread因为是新创建的进程，所以和AMS不在一个进程。

ActivityThread中创建了一个mainHandler对象，不断的在mainLooper中取到这个activity需要处理的handler消息，如生命周期的回调，而我们知道真正的处理都在AMS中，那么ActivityThread又是怎么和AMS通信的呢？其实和上面Instrumentation启动activity是一样的，都是为了解决跨进程通信。