Ams分析之activity启动

ams负责管理activity，对外提供startactivity接口用于启动activity，调用的方式比较灵活，应用侧通常通过context实现类调用。下面先给出一个启动的主干流程：

                                                                                    

从调用者发出请求，ams将请求转发给内部对象acitivityStack的startActivityMayWait，在这个方法中，先根据请求的intent从包管理器获取相应的activity信息，然后调用startactivitylocked。

在startactivitylocked中，会new出一个activityrecord，这个activityrecord是activity的ams端对应物。

在startactivityuncheckedlocked方法中，会有flag相关的处理，这个我们暂时不跟，继续。

在startactivitylocked中，注意这个和上面的那个方法同名，区别就是它的参数少些^_^.它会进行一个重要操作，就是把前面new出来的activityrecoed添加到变量mhistoty的顶端，mhistory其实就是ams管理activity的Z轴线。

Resumetopactivitylocked方法，这个比较重要，它其实是启动的起始者。这里有两个变量mResumedactivity和mpausingactivity，前者指向现在已经启动完成，且状态是resumed的activityrecord，后者指向正在pause的activityrecord。为分析方便，我们暂时假设两者都为null。

在startspecificactivity中，查看当前要启动的activity对应的app是否已经存在，如果没有就先fork出一个进程，然后再执行启动，如果进程已经存在，则执行realstartactivitylocked。在ams中维护着一个map表mprocessnames，以app的name为键值，判断就是依据它实现。

在Realstartactivitylocked中，会通过app.thread.scheduleactivity给要启动的activity对应进程发送lunch消息，thread对应实现是在activitythread中，对应进程对lunch消息的处理，一般是加载activity类，调用其oncreate，onresume方法。activitystack发送消息后，等于启动已经完成，需要把相应activityrecord的状态置为resumed，并将mResumedactivity指向它，还记得这个变量吧。

一个activity启动完成了。

不过这个只是一个雏形，我们考虑一种情况，假如这时用户又发出一个启动activity请求，这时代码会一直跑到resumetopactivitylocked中，因为现在mresumedactivity非null，所以启动转为对startpausinglocked的调用，为描述方便，我暂且把mresumedactivity现在指向的activityrecord称为当前activityrecord，在startpausinglocked中，会把mresumedactivity置null，让mpausingactivity指向当前activityrecord，然后把当前activityrecord状态置成pausing。做完状态调整后，会通过app.thread.sheduleactivity向当前activityrecord对应进程发送pause消息，对应进程对消息的处理就是调用activity的onpause方法，应用侧完成onpause后，会回调ams端的activitypaused。在发送pause消息后，activitystack自己也会补一个超时消息，在这个超时处理中调用activitypaused。

Activitypaused中，会将当前activityrecord状态置成paused，然后调用completepausedlocked，在它里面，会将当前activityrecord加入到mstoppingactivities中，然后把mpausingactivity置为null，并调用resumetopactivity，重新回到启动主干流程上，因为现在mReumedactivity和mpausingactivity都是null，所以启动跟上面一样。我们整理一下：

                         

再看一种情况，如果要启动的intent，已经有对应的activity被启动了，或者说，在ams中有可复用的activity，这时候会将新的intent设置到对应activityrecord的newintents属性中，然后跳到resumetopactivity，在这个方法里执行next.app.thread.shedulenewintent，然后调用next.app.thread.sheduleresumactivity。

另一个问题，我们知道启动一个activity时，可以要求返回一个结果值，这个结果会在resumetopactivity中，即要求返回结果的activity重新被启动起来的时候，调用next.app.thread.shedulesendresult通知给它。

上面这些都是一些比较简单的场景，不过却覆盖了activity的大多数行为。

让我们换个思路，activity到底充当一种什么角色，想想以前的桌面程序，生命周期，加一个消息泵，activity不也是如此吗，如果可以忽略进程概念的话？！

这就是google想要的结果。

忽略系统上的复杂概念，让程序员专注于用户需求，activity，service不用考虑进程的问题，只考虑需求与响应，发出你的需求，发出你的intent，让ams来处理进程边界的问题，应用侧只看到从一个activity切换到另一个activity，而看不到进程间的切换，就像好多人把拨号盘和通话界面混为一谈一样。说白了，ams就是一个调度器。对应用的请求作出响应，根据系统的状态，调整activity的执行，考虑一下锁屏和灭屏的情况，这时候没有activity能别被启动起来，实际上，这时ams是处于睡眠状态的，切换完成后调用checkreadforsleeplocked就是处理这种情况，如果ams处休眠，这时被启动的activity都会被强制pause，当ams被唤醒时，再调用resumetopactivity将其启动起来。