在开始分析app启动流程之前，我们先回想下平时是怎么启动一款App的：打开Android系统桌面->点击应用图标->启动App。从用户角度来看，这个过程看起来很简单，但是app的背后又隐藏着哪些流程呢？做安卓开发这么多年，觉得还是有必要认真分析一下，下文就借助友盟 u-apm，针对安卓app启动流程进行简要分析！
Android中每一个App都在一个独立的空间，运行在一个单独的进程中，拥有一个vm，系统会分配一个唯一的user ID。init进程会启动一个"Zygote"进程。这个进程初始化了第一个VM，并且预加载了framework和众多app所需要的通用资源。然后它开启一个Socket接口来监听请求，根据请求孵化出新的VM来管理新的app进程。一旦收到新的请求，Zygote会基于自身预先加载的VM来孵化出一个新的VM创建一个新的进程。Zygote还会孵化出一个超级管理进程---System Server。SystemServer会启动所有系统核心服务: 引导服务(7个)：ActivityManagerService、PowerManagerService、LightsService、DisplayManagerService、PackageManagerService、UserManagerService、SensorService; 核心服务(3个)：BatteryService、UsageStatsService、WebViewUpdateService; 其他服务(70个 )：AlarmManagerService、VibratorService等。
启动App流程
启动一个App的方式
启动一个应用时：都会调用startActivity(Intent)
Activity.startActivity
这里mMainThread也是Activity类的成员变量，它的类型是ActivityThread，mMainThread.getApplicationThread获得它里面的ApplicationThread成员变量，这个ApplicationThread实际上是一个Binder对象，是App所在的进程与AMS所在进程system_server通信的桥梁。1、AMS会对Activity生命周期的管理以及任务栈的管理，通过Binder通信，这时AMS是Server端，App进程持有AMS的client端IActivityManagerSingleton进行通信。2、AMS在完成任务栈和生命周期管理后，回调App方法，这时AMS是client持有App的ApplicationThread进行通信。
mToken是Activity中一个成员变量，AMS和Activity交互中并没有把Activity实例传入，而是使用mToken，可以唯一标示Activity。
Instrumentation.execStartActivity
这里把App中Binder的Server端的ApplicationThread的句柄传给AMS，用于生命周期的回调等，如onPause。通过Binder驱动，就进入AMS的startActivity方法。
ActivityManagerService 通知当前进程进入pause状态
AMS在system_server进程中，由于AMS中代码太多了，我们这里就不全部展开讲了，大概的说一下。有兴趣的可以去看一下老罗的文章。在AMS会新创建一个栈Task，并通过ApplicationThread的句柄通知当前Activity进入paused状态。
回到ActivityThread中
