AMS治下的Activity启动运行

Activity的启动情况有多种，一种是应用程序还未启动MainActivity，一种是在已启动的应用程序中启动Activity，这两者存在不一样的情况，如果是应用程序未启动，那么和Service在新进程中启动一样，需要先创建新进程，创建Application、绑定Application、启动ActivityThread线程、创建ApplicationThread Binder对象。分析Activity启动之前，首先先分析几个和应用启动，ActivityManagerService关于Activity管理相关的类：

ProcessRecord：进程相关的记录类，每一个ProcessRecord对象实例保存在SparseArray数组mPidsSelfLocked中；

Token:  一个stub类，binder对象，主要两个属性，一个ActivityRecord的弱引用对象，一个Activity类名属性。通过这个Token可以查找对应的ActivityRecord；

ActivityRecord：包含一个TaskRecord实例;

TaskRecord: 记录一组ActivityRecord的mActivities数组；

ActivityStack：主要在于保存着一组TaskRecord历史列表mTaskHistory，通过该属性可以查出对应Token属于哪个TaskRecord，继而可以得到ActivityRecord的栈列表。

上面几个类就是在创建Activity的时候要用到的，和启动模式相关，和页面之间的Activity跳转相关。我们使用adb shell dumpsys activity就会打印出如下信息。

接下来分析下应用程序的启动流程（MainActivity的启动），我们分析的时候尽量以白话的形式、极其简单的表达。如下图，App1启动App2，它向ActivityManagerService发出请求，喂，我想要启动App2的MainActivity，AMS收到请求之后，就让辅助ActivityStack分析要创建的MainActivity没有对应的task任务在，更别说stack的栈顶就是MainActivity，于是，反正都要创建的，就先创建好task任务、堆栈情况，然后返回响应给App1，携带的信息就是赶紧停止你的活动XXXActivity，于是App1 Pasuse自己的Activity之后，还得告知AMS停止好了，AMS再让辅助ActivityStack根据任务所在的stack栈顶MainActivity，准备启动MainActivity，可是发现要让活动跑起来，总得事先得确定好空间吧，于是AMS就帮忙创建了App2的进程，接着在App2的进程中建立好活动Activity要在哪跑的线程(这就是所谓的主线程)，App2的进程就绪之后，跟AMS说，老哥，进程已创建，主线程也在跑，现在可以开始干活了,还向AMS传递了一个ApplicationThread的stub（binder对象），实际上，运用程序创建的时候就启动了一个线程用于server组件和binder驱动程序之间的交互，而ApplicationThread正是充当这个stub（binder机制见上文，关于应用程序进程创建我们后面再来分析），用于和AMS的进程间通信，AMS收到之后，发出走起命令，启动MainActivity，启动过程完成。

这个过程中涉及三个进程间的通信，App1、App2以及AMS。而AMS充当中间人，管理者活动的信息，活动所在的任务，任务历史等。正是因为AMS充当中间人，才使得这一流程能按部就班的完成。至于同一个app在不同的进程启动另一个Activity，大体上都和上面的过程类似，而在同一个app同一个进程中从一个Activity启动另一个Activity，有一点不同，就是少了启动另一个进程的步骤，剩下的还是步骤也是大体相同。