Android Activity启动三部曲（一）

背景

　　本章作为Activity启动流程的第一篇，将对调用过程到ActivityManagerService（以下简称AMS）之前的工作做以说明，并对下一篇执行过程做铺垫。
　　计划在第二篇讲解到启动新进程中，为启动Activity做准备(已完成)。
　　在第三篇，主要讲解如何在新进程中启动Activity，以及Activity各种声明周期的回调(已完成)。
　　使用源码：Nougat - 7.0.0_r1

Activity启动（一）

首先来通过一张大图，看看Activity的启动过程，在这一部分中，将调用过程先截止到AMS。

Activity启动过程（一）

说明：

• 其实，不管是根 Activity（ 在Intent Filter中标记为Launcher和Main）或者子 Activity（除了根Activity的其他Activity），它们的 start 过程，都将会由上图中的 Instrumentation 执行 execStartActivity。
• 通过 Instrumentation 的 execStartActivity 方法，得到一个单例，即上图中的 gDefault ，这个单例实际上是 AMS 提供给客户端的代理。顺便说一句，这种单例方式为一种插件化方式提供了良好的基础，可以Hook掉这个 gDefault，搞事情。具体可参考
• 最终执行到了 AMS代理类中的 startActivity 方法。这里将进行Binder通信。如果对Binder机制不清楚，可以参看这里，startActivity请求最终由AMS代理类通过Binder机制发送到 AMS 服务端，交给AMS处理，这是标准的CS架构。
• 为啥要交给 AMS 处理呢？startActivity将会启动一个非常重要的组件，这么大的事，必须要交给系统集中处理、管理。正如在十字路口，如果没有红绿灯，用不了多久，交通就会瘫痪。AMS 通过数据结构集中对所有的Activity进行管理，为如丝般顺滑地用户体验提供基础的基础的基础。

小结

　　本节体现了Binder通信机制，以及建立在该机制之上的服务提供方和客户端的CS架构。
　　AMS是大家的AMS，只有一个，但是却有很多的App，每个App都可以通过AMS提供的代理类和AMS进行通信。请求AMS处理数据，比如打开一个新的Activity。AMS是所有Activity的处理中心，记录保存追踪着所有的Activity。
　　下一节，我们来看看 AMS 如何处理 startActiviy的请求。