前言
我们想一想几个问题，Android是如何启动一个Activity的呢？我们调用Context.startActivity()，一个Activity就展现了出来，这个Activity的onCreate()和onResume()等方法会被系统调用，其内部到底经历了怎样的过程呢？当前展示的Activity的onPause()和onStop()方法是怎么被调用的？
首先，要明白一件事，就是startActivity()是一个跨进程的操作，相当于给另一个进程发送一个消息，然后该方法就马上返回了，背后系统会进行一系列复杂的操作，之后这个Activity才会展示出来，我们不能认为startActivity之后这个Activity就启动展示出来了，包括Activity的finish()也一样，它们只负责给系统进程发送信息而已。
那么，我们马上会想到两个问题：
1. startActivity()是发消息给谁呢？
答案是ActivityManagerService这个服务，而这个服务驻留在系统进程SystemServer中，之前的文章谈过，一个进程可以驻留多个服务，比如SystemServer这个进程包含了ActivityManagerService、PackageManagerService、WindowManagerService、PowerManagerService等很多个系统服务。因此，startActivity()是发消息给SystemServer进程，而进程间通信的方法正是安卓世界强大的Binder机制。
2. startActivity()发送的是什么消息呢？
这里的消息是通过Intent参数携带的，比如客户端可以通过PackageManager的getLaunchIntentForPackage()方法获取特定包名下特定Activity的Intent，这个Intent便指定了要启动的Activity，AMS进程则通过解析这个Intent创建对应的ActivityRecord，继续后续启动Activity的过程。
Activity在AMS中的数据表示 —— ActivityRecord
Android中的Activity是通过Task来组织的，系统只支持一个Task处于前台，即用户当前看到的Activity所属的Task，其余的Task均处于后台，这些后台Task内部的Activity保持顺序不变。用户可以一次将整个Task挪到后台或者置为前台。在一些安卓手机中，按Menu键，系统会弹出近期Task列表，用户能快速在多个Task间切换。与Task概念相关的还有Activity启动的模式，比如可以通过在Manifest指定launchMode为singleTask或在Intent中指定Flag为FLAG_ACTIVITY_NEW_TASK来控制Activity独占一个Task，或者通过taskAffinity属性来指定Activity所属的Task，这块不是本文的重点，详细可以看这里：https://developer.android.google.cn/guide/components/activities/tasks-and-back-stack。
注意：Task并不是进程的意思，它只是一个虚拟的概念，由AMS中的TaskRecord表示。
AMS内部是通过ActivityStack来组织Activity和Task，Activity用ActivityRecord来表示，Task用TaskRecord来表示，需要注意的是，ActivityStack并不是从Task的维度来保存ActivityRecord的，而是直接扁平化地使用一个数组来保存ActivityRecord，用mHistory变量指向这个数组，表示历史的Activity。由于系统只有一个ActivityStack实例，因此mMainStack一直为true。ActivityStack有一系列方法来搜索和操作ActivityRecord，其主要结构如图：
在ActivityStack中，startActivityXXX的一系列流程是为了创建ActivityRecord和TaskRecord，然后将TaskRecord设置到ActivityRecord中，进而通过该ActivityRecord来启动Activity。
启动Activity
ActivityRecord就绪之后，AMS会判断ActivityRecord中的ProcessRecord中pid指向的进程是否存在，如果存在则直接向该进程发送启动Activity的消息，否则会启动进程。与应用进程通信的方式同样是Binder，接口是IApplicationThread，AMS通过IApplicationThread将APK相关的信息传递给应用进程。
当需要启动应用进程时，AMS向zygote进程发送信息，使得zygote分裂出一个新的进程，AMS随即得到该进程的pid，并把该pid与ActivityRecord的ProcessRecord关联起来。zygote分裂出来的是一个通用的进程，它并不知道自己的使命，也不知道自己运行的是哪个apk包，只是个空白的进程。但该进程在启动Java虚拟机和进行必要的初始化后会进入Java世界，然后会执行ActivityThread的main()方法，在该main()方法中，会调用ActivityThread的attach方法，attach方法将会调用AMS服务的attachApplication方法，并传入自己的IApplicationThread对象，从而开始应用进程和AMS进程间的通信。
因此，应用进程在被创建之后会主动与AMS进程建立通信，而AMS在创建一个应用进程后，会设置一个超时时间（一般是10秒）。如果超过这个时间，应用进程还没有和AMS交互，则断定该进程创建失败。
建立完通信链路后，AMS内部便可以使用IApplicationThread接口，通过bindApplication方法，将APK相关的信息传给应用进程，此时应用进程也就活起来了。应用进程在收到bindApplication消息后，将会根据AndroidManifest中声明的Application标签创建一个Application。
而真正启动Activity是通过ActivityStack的realStartActivityLocked方法，其大体的流程是向应用进程发送信息，使得应用进程调用ActivityThread的handleLaunchActivity以及PerformLaunchActivity方法。
其实启动一个Activity的关键流程是：
- startActivity所在的进程向AMS发送Intent
- AMS根据Intent寻找ActivityRecord
- 如果进程不存在，则：
a. 通知Zygote分裂启动新的应用
b. 应用进程与AMS建立Binder通信
c. AMS告诉应用进程APK包的信息 - AMS通知应用进程启动Activity
- 应用进程会通过ActivityThread执行performLaunchActivity，callOnCreate等方法
这只是主要的流程，其实里边的细节还有很多，比如当下Activity的onPause和onStop等方法的调用，但原理其实很好理解，当AMS启动一个新的Activity以及该Activity的onCreate方法在被调用之前，AMS会发信息给当前展示的Activity的应用进程，通知其ActivityThread调用performPauseActivityIfNeeded方法，进而调用当前Activity的onPause方法。
至此，启动Activity的原理介绍完毕，AMS极其复杂，要完全理解需要花费很长时间，但我认为只需要把关键的节点理清楚就好，具体细节等需要用到再仔细研究。
完毕。
其它文章可以学习：
理解Application创建过程：http://gityuan.com/2017/04/02/android-application/