Android应用程序的Activity启动过程、Android应用程序启动过程源代码分析、Android应用程序内部启动Activity过程（startActivity）的源代码分析
2014-08-19 16:42
711 查看
本文来自：
http://blog.csdn.net/luoshengyang/article/details/6685853
http://blog.csdn.net/luoshengyang/article/details/6689748
http://blog.csdn.net/luoshengyang/article/details/6703247
1.Android应用程序的Activity启动过程简要介绍和学习计划
下面简要介绍一下启动的过程：
Step 1. 无论是通过Launcher来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，都通过Binder进程间通信进入到ActivityManagerService进程中，并且调用ActivityManagerService.startActivity接口；
Step 2. ActivityManagerService调用ActivityStack.startActivityMayWait来做准备要启动的Activity的相关信息；
Step 3. ActivityStack通知ApplicationThread要进行Activity启动调度了，这里的ApplicationThread代表的是调用ActivityManagerService.startActivity接口的进程，对于通过点击应用程序图标的情景来说，这个进程就是Launcher了，而对于通过在Activity内部调用startActivity的情景来说，这个进程就是这个Activity所在的进程了；
Step 4. ApplicationThread不执行真正的启动操作，它通过调用ActivityManagerService.activityPaused接口进入到ActivityManagerService进程中，看看是否需要创建新的进程来启动Activity；
Step 5. 对于通过点击应用程序图标来启动Activity的情景来说，ActivityManagerService在这一步中，会调用startProcessLocked来创建一个新的进程，而对于通过在Activity内部调用startActivity来启动新的Activity来说，这一步是不需要执行的，因为新的Activity就在原来的Activity所在的进程中进行启动；
Step 6. ActivityManagerServic调用ApplicationThread.scheduleLaunchActivity接口，通知相应的进程执行启动Activity的操作；
Step 7. ApplicationThread把这个启动Activity的操作转发给ActivityThread，ActivityThread通过ClassLoader导入相应的Activity类，然后把它启动起来。
时序图：
2.Android应用程序启动过程源代码分析
在手机屏幕中点击应用程序图标的情景就会引发Android应用程序中的默认Activity的启动，从而把应用程序启动起来。这种启动方式的特点是会启动一个新的进程来加载相应的Activity。这里，我们继续以这个例子为例来说明Android应用程序的启动过程，即MainActivity的启动过程。
Step
1. Launcher.startActivitySafely；在Android系统中，应用程序是由Launcher启动起来的，其实，Launcher本身也是一个应用程序，其它的应用程序安装后，就会Launcher的界面上出现一个相应的图标，点击这个图标时，Launcher就会对应的应用程序启动起来。
它的默认Activity是MainActivity，这里是AndroidManifest.xml文件中配置的，因此，这里的intent包含的信息为：action
= "android.intent.action.Main"，category="android.intent.category.LAUNCHER", cmp="shy.luo.activity/.MainActivity"，表示它要启动的Activity为shy.luo.activity.MainActivity。Intent.FLAG_ACTIVITY_NEW_TASK表示要在一个新的Task中启动这个Activity，注意，Task是Android系统中的概念，它不同于进程Process的概念。简单地说，一个Task是一系列Activity的集合，这个集合是以堆栈的形式来组织的，遵循后进先出的原则。事实上，Task是一个非常复杂的概念，有兴趣的读者可以到官网http://developer.android.com/guide/topics/manifest/activity-element.html查看相关的资料。这里，我们只要知道，这个MainActivity要在一个新的Task中启动就可以了
Step
2. Activity.startActivity； 在Step 1中，我们看到，Launcher继承于Activity类，而Activity类实现了startActivity函数，因此，这里就调用了Activity.startActivity函数，这个函数实现很简单，它调用startActivityForResult来进一步处理，第二个参数传入-1表示不需要这个Actvity结束后的返回结果
Step
3. Activity.startActivityForResult；这里的mInstrumentation是Activity类的成员变量，它的类型是Intrumentation，它用来监控应用程序和系统的交互，这里的mMainThread也是Activity类的成员变量，它的类型是ActivityThread，它代表的是应用程序的主线程，我们在Android系统在新进程中启动自定义服务过程（startService）的原理分析一文中已经介绍过了。这里通过mMainThread.getApplicationThread获得它里面的ApplicationThread成员变量，它是一个Binder对象，后面我们会看到，ActivityManagerService会使用它来和ActivityThread来进行进程间通信。这里我们需注意的是，这里的mMainThread代表的是Launcher应用程序运行的进程，这里的mToken也是Activity类的成员变量，它是一个Binder对象的远程接口。
Step 4. Instrumentation.execStartActivity； 这里的ActivityManagerNative.getDefault返回ActivityManagerService的远程接口，即ActivityManagerProxy接口。
Step
5. ActivityManagerProxy.startActivity；这里的参数resolvedType、grantedUriPermissions和resultWho均为null；参数caller为ApplicationThread类型的Binder实体；参数resultTo为一个Binder实体的远程接口，我们先不关注它；参数grantedMode为0，我们也先不关注它；参数requestCode为-1；参数onlyIfNeeded和debug均空false。
Step
6. ActivityManagerService.startActivity；上一步Step 5通过Binder驱动程序就进入到ActivityManagerService的startActivity函数来了，这里只是简单地将操作转发给成员变量mMainStack的startActivityMayWait函数，这里的mMainStack的类型为ActivityStack。
Step
7. ActivityStack.startActivityMayWait；对参数intent的内容进行解析，得到MainActivity的相关信息，保存在aInfo变量中，解析之后，得到的aInfo.applicationInfo.packageName的值为"shy.luo.activity"，aInfo.name的值为"shy.luo.activity.MainActivity"，这是在这个实例的配置文件AndroidManifest.xml里面配置的。此外，函数开始的地方调用intent.getComponent()函数的返回值不为null，因此，这里的componentSpecified变量为true。 接下去就调用startActivityLocked进一步处理了。
Step
8. ActivityStack.startActivityLocked； 从传进来的参数caller得到调用者的进程信息，并保存在callerApp变量中，这里就是Launcher应用程序的进程信息了。前面说过，参数resultTo是Launcher这个Activity里面的一个Binder对象，通过它可以获得Launcher这个Activity的相关信息，保存在sourceRecord变量中。再接下来，创建即将要启动的Activity的相关信息，并保存在r变量中， 接着调用startActivityUncheckedLocked函数进行下一步操作。
Step
9. ActivityStack.startActivityUncheckedLocked；由于在这个例子的AndroidManifest.xml文件中，MainActivity没有配置launchMode属值，因此，这里的r.launchMode为默认值0，表示以标准（Standard，或者称为ActivityInfo.LAUNCH_MULTIPLE）的方式来启动这个Activity。Activity的启动方式有四种，其余三种分别是ActivityInfo.LAUNCH_SINGLE_INSTANCE、ActivityInfo.LAUNCH_SINGLE_TASK和ActivityInfo.LAUNCH_SINGLE_TOP，传进来的参数r.resultTo为null，表示Launcher不需要等这个即将要启动的MainActivity的执行结果，由于这个intent的标志值的位Intent.FLAG_ACTIVITY_NEW_TASK被置位，而且Intent.FLAG_ACTIVITY_MULTIPLE_TASK没有置位，因此，下面的if语句会被执行
if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 &&
(launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0)
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
// If bring to front is requested, and no result is requested, and
// we can find a task that was started with this same
// component, then instead of launching bring that one to the front.
if (r.resultTo == null) {
// See if there is a task to bring to the front. If this is
// a SINGLE_INSTANCE activity, there can be one and only one
// instance of it in the history, and it is always in its own
// unique task, so we do a special search.
ActivityRecord taskTop = r.launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE
? findTaskLocked(intent, r.info)
: findActivityLocked(intent, r.info);
if (taskTop != null) {
......
}
}
这段代码的逻辑是查看一下当前有没有Task可以用来执行这个Activity。由于r.launchMode的值不为ActivityInfo.LAUNCH_SINGLE_INSTANCE，因此，它通过findTaskLocked函数来查找存不存这样的Task，这里返回的结果是null，即taskTop为null，因此，需要创建一个新的Task来启动这个Activity。
接着往下看：
if (r.packageName != null) {
// If the activity being launched is the same as the one currently
// at the top, then we need to check if it should only be launched
// once.
ActivityRecord top = topRunningNonDelayedActivityLocked(notTop);
if (top != null && r.resultTo == null) {
if (top.realActivity.equals(r.realActivity)) {
......
}
}
} 这段代码的逻辑是看一下，当前在堆栈顶端的Activity是否就是即将要启动的Activity，有些情况下，如果即将要启动的Activity就在堆栈的顶端，那么，就不会重新启动这个Activity的别一个实例了，具体可以参考官方网站http://developer.android.com/reference/android/content/pm/ActivityInfo.html。现在处理堆栈顶端的Activity是Launcher，与我们即将要启动的MainActivity不是同一个Activity，因此，这里不用进一步处理上述介绍的情况。
执行到这里，我们知道，要在一个新的Task里面来启动这个Activity了，于是新创建一个Task，
新建的Task保存在r.task域中，同时，添加到mService中去，这里的mService就是ActivityManagerService了。
最后就进入startActivityLocked(r,
newTask, doResume)进一步处理了，调用resumeTopActivityLocked进一步操作。
Step
10. Activity.resumeTopActivityLocked；函数先通过调用topRunningActivityLocked函数获得堆栈顶端的Activity，这里就是MainActivity了，这是在上面的Step 9设置好的，保存在next变量中， 当我们处理休眠状态时，mLastPausedActivity保存堆栈顶端的Activity，因为当前不是休眠状态，所以mLastPausedActivity为null。
有了这些信息之后，下面的语句就容易理解了：
// If the top activity is the resumed one, nothing to do.
if (mResumedActivity == next && next.state == ActivityState.RESUMED) {
......
}
// If we are sleeping, and there is no resumed activity, and the top
// activity is paused, well that is the state we want.
if ((mService.mSleeping || mService.mShuttingDown)
&& mLastPausedActivity == next && next.state == ActivityState.PAUSED) {
......
}
它首先看要启动的Activity是否就是当前处理Resumed状态的Activity，如果是的话，那就什么都不用做，直接返回就可以了；否则再看一下系统当前是否休眠状态，如果是的话，再看看要启动的Activity是否就是当前处于堆栈顶端的Activity，如果是的话，也是什么都不用做。
上面两个条件都不满足，因此，在继续往下执行之前，首先要把当处于Resumed状态的Activity推入Paused状态，然后才可以启动新的Activity。但是在将当前这个Resumed状态的Activity推入Paused状态之前，首先要看一下当前是否有Activity正在进入Pausing状态，如果有的话，当前这个Resumed状态的Activity就要稍后才能进入Paused状态了，这样就保证了所有需要进入Paused状态的Activity串行处理。
这里没有处于Pausing状态的Activity，即mPausingActivity为null，而且mResumedActivity也不为null，于是就调用startPausingLocked函数把Launcher推入Paused状态去了。
Step
11. ActivityStack.startPausingLocked；函数首先把mResumedActivity保存在本地变量prev中。在上一步Step 10中，说到mResumedActivity就是Launcher，因此，这里把Launcher进程中的ApplicationThread对象取出来，通过它来通知Launcher这个Activity它要进入Paused状态了。当然，这里的prev.app.thread是一个ApplicationThread对象的远程接口，通过调用这个远程接口的schedulePauseActivity来通知Launcher进入Paused状态。
Step
12. ApplicationThreadProxy.schedulePauseActivity；通过Binder进程间通信机制进入到ApplicationThread.schedulePauseActivity函数中。
Step
13. ApplicationThread.schedulePauseActivity；这里调用的函数queueOrSendMessage是ActivityThread类的成员函数，因此，queueOrSendMessage的第一个参数值为H.PAUSE_ACTIVITY，表示要暂停token所代表的Activity，即Launcher。
Step
14. ActivityThread.queueOrSendMessage；这里首先将相关信息组装成一个msg，然后通过mH成员变量发送出去，mH的类型是H，继承于Handler类，是ActivityThread的内部类，因此，这个消息最后由H.handleMessage来处理。
Step
15. H.handleMessage；这里调用ActivityThread.handlePauseActivity进一步操作，msg.obj是一个ActivityRecord对象的引用，它代表的是Launcher这个Activity。
Step
16. ActivityThread.handlePauseActivity；函数首先将Binder引用token转换成ActivityRecord的远程接口ActivityClientRecord，然后做了三个事情：1. 如果userLeaving为true，则通过调用performUserLeavingActivity函数来调用Activity.onUserLeaveHint通知Activity，用户要离开它了；2.
调用performPauseActivity函数来调用Activity.onPause函数，我们知道，在Activity的生命周期中，当它要让位于其它的Activity时，系统就会调用它的onPause函数；3. 它通知ActivityManagerService，这个Activity已经进入Paused状态了，ActivityManagerService现在可以完成未竟的事情，即启动MainActivity了。
Step
17. ActivityManagerProxy.activityPaused；这里通过Binder进程间通信机制就进入到ActivityManagerService.activityPaused函数中去了。
Step
18. ActivityManagerService.activityPaused； 这里，又再次进入到ActivityStack类中，执行activityPaused函数。
Step
19. ActivityStack.activityPaused；这里通过参数token在mHistory列表中得到ActivityRecord，从上面我们知道，这个ActivityRecord代表的是Launcher这个Activity，而我们在Step
11中，把Launcher这个Activity的信息保存在mPausingActivity中，因此，这里mPausingActivity等于r，于是，执行completePauseLocked操作。
Step
20. ActivityStack.completePauseLocked； 函数首先把mPausingActivity变量清空，因为现在不需要它了，然后调用resumeTopActivityLokced进一步操作，它传入的参数即为代表Launcher这个Activity的ActivityRecord。
Step 21. ActivityStack.resumeTopActivityLokced； 通过上面的Step
9，我们知道，当前在堆栈顶端的Activity为我们即将要启动的MainActivity，这里通过调用topRunningActivityLocked将它取回来，保存在next变量中。之前最后一个Resumed状态的Activity，即Launcher，到了这里已经处于Paused状态了，因此，mResumedActivity为null。最后一个处于Paused状态的Activity为Launcher，因此，这里的mLastPausedActivity就为Launcher。前面我们为MainActivity创建了ActivityRecord后，它的app域一直保持为null。有了这些信息后，上面这段代码就容易理解了，它最终调用startSpecificActivityLocked进行下一步操作。
Step
22. ActivityStack.startSpecificActivityLocked；注意，这里由于是第一次启动应用程序的Activity，所以下面语句：
ProcessRecord app = mService.getProcessRecordLocked(r.processName,
r.info.applicationInfo.uid);
取回来的app为null。在Activity应用程序中的AndroidManifest.xml配置文件中，我们没有指定Application标签的process属性，系统就会默认使用package的名称，这里就是"shy.luo.activity"了。每一个应用程序都有自己的uid，因此，这里uid + process的组合就可以为每一个应用程序创建一个ProcessRecord。当然，我们可以配置两个应用程序具有相同的uid和package，或者在AndroidManifest.xml配置文件的application标签或者activity标签中显式指定相同的process属性值，这样，不同的应用程序也可以在同一个进程中启动。函数最终执行ActivityManagerService.startProcessLocked函数进行下一步操作
Step
23. ActivityManagerService.startProcessLocked；这里再次检查是否已经有以process + uid命名的进程存在，在我们这个情景中，返回值app为null，因此，后面会创建一个ProcessRecord，并存保存在成员变量mProcessNames中，最后，调用另一个startProcessLocked函数进一步操作。
该函数这里主要是调用Process.start接口来创建一个新的进程，新的进程会导入android.app.ActivityThread类，并且执行它的main函数，这就是为什么我们前面说每一个应用程序都有一个ActivityThread实例来对应的原因。
Step
24. ActivityThread.main； 这个函数在进程中创建一个ActivityThread实例，然后调用它的attach函数，接着就进入消息循环了，直到最后进程退出。函数attach最终调用了ActivityManagerService的远程接口ActivityManagerProxy的attachApplication函数，传入的参数是mAppThread，这是一个ApplicationThread类型的Binder对象，它的作用是用来进行进程间通信的。
Step
25. ActivityManagerProxy.attachApplication；这里通过Binder驱动程序，最后进入ActivityManagerService的attachApplication函数中。
Step
26. ActivityManagerService.attachApplication； 这里将操作转发给attachApplicationLocked函数。
Step
27. ActivityManagerService.attachApplicationLocked；在前面的Step 23中，已经创建了一个ProcessRecord，这里首先通过pid将它取回来，放在app变量中，然后对app的其它成员进行初始化，最后调用mMainStack.realStartActivityLocked执行真正的Activity启动操作。这里要启动的Activity通过调用mMainStack.topRunningActivityLocked(null)从堆栈顶端取回来，这时候在堆栈顶端的Activity就是MainActivity了。
Step
28. ActivityStack.realStartActivityLocked；这里最终通过app.thread进入到ApplicationThreadProxy的scheduleLaunchActivity函数中，注意，这里的第二个参数r，是一个ActivityRecord类型的Binder对象，用来作来这个Activity的token值。
Step
29. ApplicationThreadProxy.scheduleLaunchActivity；这个函数最终通过Binder驱动程序进入到ApplicationThread的scheduleLaunchActivity函数中。
Step
30. ApplicationThread.scheduleLaunchActivity；函数首先创建一个ActivityClientRecord实例，并且初始化它的成员变量，然后调用ActivityThread类的queueOrSendMessage函数进一步处理。
Step
31. ActivityThread.queueOrSendMessage；函数把消息内容放在msg中，然后通过mH把消息分发出去，这里的成员变量mH我们在前面已经见过，消息分发出去后，最后会调用H类的handleMessage函数。
Step
32. H.handleMessage； 这里最后调用ActivityThread类的handleLaunchActivity函数进一步处理。
Step
33. ActivityThread.handleLaunchActivity。 这里首先调用performLaunchActivity函数来加载这个Activity类，即shy.luo.activity.MainActivity，然后调用它的onCreate函数，最后回到handleLaunchActivity函数时，再调用handleResumeActivity函数来使这个Activity进入Resumed状态，即会调用这个Activity的onResume函数，这是遵循Activity的生命周期的。
Step
34. ActivityThread.performLaunchActivity；函数前面是收集要启动的Activity的相关信息，主要package和component信息，然后通过ClassLoader将shy.luo.activity.MainActivity类加载进来，创建Application对象，这是根据AndroidManifest.xml配置文件中的Application标签的信息来创建的，后面的代码主要创建Activity的上下文信息，并通过attach方法将这些上下文信息设置到MainActivity中去，最后还要调用MainActivity的onCreate函数，这里不是直接调用MainActivity的onCreate函数，而是通过mInstrumentation的callActivityOnCreate函数来间接调用，前面我们说过，mInstrumentation在这里的作用是监控Activity与系统的交互操作，相当于是系统运行日志。
Step
35. MainActivity.onCreate；这样，MainActivity就启动起来了，整个应用程序也启动起来了。
整个应用程序的启动过程要执行很多步骤，但是整体来看，主要分为以下五个阶段：
一. Step1 - Step 11：Launcher通过Binder进程间通信机制通知ActivityManagerService，它要启动一个Activity；
二. Step 12 - Step 16：ActivityManagerService通过Binder进程间通信机制通知Launcher进入Paused状态；
三. Step 17 - Step 24：Launcher通过Binder进程间通信机制通知ActivityManagerService，它已经准备就绪进入Paused状态，于是ActivityManagerService就创建一个新的进程，用来启动一个ActivityThread实例，即将要启动的Activity就是在这个ActivityThread实例中运行；
四. Step 25 - Step 27：ActivityThread通过Binder进程间通信机制将一个ApplicationThread类型的Binder对象传递给ActivityManagerService，以便以后ActivityManagerService能够通过这个Binder对象和它进行通信；
五. Step 28 - Step 35：ActivityManagerService通过Binder进程间通信机制通知ActivityThread，现在一切准备就绪，它可以真正执行Activity的启动操作了。
3.Android应用程序内部启动Activity过程（startActivity）的源代码分析
上文介绍了Android应用程序的启动过程，即应用程序默认Activity的启动过程，一般来说，这种默认Activity是在新的进程和任务中启动的；本文将继续分析在应用程序内部启动非默认Activity的过程的源代码，这种非默认Activity一般是在原来的进程和任务中启动的。
Step
1. Activity.startActivity；这一步与上一篇文章Android应用程序启动过程源代码分析的Step
2大体一致，通过指定名称“shy.luo.activity.subactivity”来告诉应用程序框架层，它要隐式地启动SubActivity。所不同的是传入的参数intent没有Intent.FLAG_ACTIVITY_NEW_TASK标志，表示这个SubActivity和启动它的MainActivity运行在同一个Task中
Step
2. Activity.startActivityForResult；这一步与上一篇文章Android应用程序启动过程源代码分析的Step
3一致。
Step 3. Instrumentation.execStartActivity；这一步与上一篇文章Android应用程序启动过程源代码分析的Step
4一致。
Step 4. ActivityManagerProxy.startActivity；这一步与上一篇文章Android应用程序启动过程源代码分析的Step
5一致。
Step 5. ActivityManagerService.startActivity；这一步与上一篇文章Android应用程序启动过程源代码分析的Step
6一致。
Step 6. ActivityStack.startActivityMayWait； 这一步与上一篇文章Android应用程序启动过程源代码分析的Step
7一致。
Step 7. ActivityStack.startActivityLocked；这一步与上一篇文章Android应用程序启动过程源代码分析的Step
8一致。
Step 8. ActivityStack.startActivityUncheckedLocked； 这一步与上一篇文章Android应用程序启动过程源代码分析的Step
9有所不同，主要是当前要启动的Activity与启动它的Activity是在同一个Task中运行的，我们来详细看一下。
public class ActivityStack {
......
final int startActivityUncheckedLocked(ActivityRecord r,
ActivityRecord sourceRecord, Uri[] grantedUriPermissions,
int grantedMode, boolean onlyIfNeeded, boolean doResume) {
final Intent intent = r.intent;
final int callingUid = r.launchedFromUid;
int launchFlags = intent.getFlags();
......
if (sourceRecord == null) {
......
} else if (sourceRecord.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
......
} else if (r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE
......
}
if (r.resultTo != null && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
......
}
boolean addingToTask = false;
if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 &&
(launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0)
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
......
}
if (r.packageName != null) {
// If the activity being launched is the same as the one currently
// at the top, then we need to check if it should only be launched
// once.
ActivityRecord top = topRunningNonDelayedActivityLocked(notTop);
if (top != null && r.resultTo == null) {
if (top.realActivity.equals(r.realActivity)) {
......
}
}
} else {
......
}
boolean newTask = false;
// Should this be considered a new task?
if (r.resultTo == null && !addingToTask
&& (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
......
} else if (sourceRecord != null) {
......
// An existing activity is starting this new activity, so we want
// to keep the new one in the same task as the one that is starting
// it.
r.task = sourceRecord.task;
......
} else {
......
}
......
startActivityLocked(r, newTask, doResume);
return START_SUCCESS;
}
......
}
这里，参数intent的标志位Intent.FLAG_ACTIVITY_NEW_TASK没有设置，在配置文件AndriodManifest.xml中，SubActivity也没有配置启动模式launchMode，于是它就默认标准模式，即ActivityInfo.LAUNCH_MULTIPLE
这里看一下当前要启动的Activity是否就是当前堆栈顶端的Activity，如果是的话，在某些情况下，就不用再重新启动了。函数topRunningNonDelayedActivityLocked返回当前堆栈顶端的Activity，这里即为MainActivity，而当前要启动的Activity为SubActivity，因此，这二者不相等，于是跳过里面的if语句。
接着，前面说过参数intent的标志位Intent.FLAG_ACTIVITY_NEW_TASK没有设置，而这里的sourceRecord即为当前执行启动Activity操作的Activity，这里即为MainActivity，因此，它不为null，于是于MainActivity所属的Task设置到r.task中去，这里的r即为SubActivity。看到这里，我们就知道SubActivity要和MainActivity运行在同一个Task中了，同时，变量newTask的值为false。最后，函数进 入step
7中startActivityLocked(r, newTask, doResume)进一步处理了。
这里传进来的参数newTask为false，doResume为true。当newTask为false，表示即将要启动的Activity是在原有的Task运行时，如果这个原有的Task当前对用户不可见时，这时候就不需要继续执行下去了，因为即使把这个Activity启动起来，用户也看不到，还不如先把它保存起来，等到下次这个Task对用户可见的时候，再启动不迟。这里，这个原有的Task，即运行MainActivity的Task当前对用户是可见的，因此，会继续往下执行。
接下去执行就会把这个SubActivity通过mHistroy.add(addPos,
r)添加到堆栈顶端去，然后调用resumeTopActivityLocked进一步操作。
Step
9. ActivityStack.resumeTopActivityLocked； 这一步与上一篇文章Android应用程序启动过程源代码分析的Step
10一致。但是要注意的是，执行到这个函数的时候，当前处于堆栈顶端的Activity为SubActivity，ActivityStack的成员变量mResumedActivity指向MainActivity。
Step
10. ActivityStack.startPausingLocked
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 11一致。
从这里开始，ActivityManagerService通知MainActivity进入Paused状态。
Step 11. ApplicationThreadProxy.schedulePauseActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 12一致。
Step 12. ApplicationThread.schedulePauseActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 13一致。
Step 13. ActivityThread.queueOrSendMessage
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 14一致。
Step 14. H.handleMessage
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 15一致。
Step 15. ActivityThread.handlePauseActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 16一致。
Step 16. ActivityManagerProxy.activityPaused
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 17一致。
Step 17. ActivityManagerService.activityPaused
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 18一致。
Step 18. ActivityStack.activityPaused
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 19一致。
Step 19. ActivityStack.completePauseLocked
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 20一致。
执行到这里的时候，MainActivity就进入Paused状态了，下面就开始要启动SubActivity了。
Step 20. ActivityStack.resumeTopActivityLokced
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 21一致。
Step 21. ActivityStack.startSpecificActivityLocked； 这一步与上一篇文章Android应用程序启动过程源代码分析的Step
22就有所不同了，这里，它不会调用mService.startProcessLocked来创建一个新的进程来启动新的Activity； 这里由于不是第一次启动应用程序的Activity（MainActivity是这个应用程序第一个启动的Activity），所以下面语句：
ProcessRecord app = mService.getProcessRecordLocked(r.processName,
r.info.applicationInfo.uid);
取回来的app不为null。在上一篇文章Android应用程序启动过程源代码分析中，我们介绍过，在Activity应用程序中的AndroidManifest.xml配置文件中，我们没有指定application标签的process属性，于是系统就会默认使用package的名称，这里就是"shy.luo.activity"了。每一个应用程序都有自己的uid，因此，这里uid
+ process的组合就可以创建一个全局唯一的ProcessRecord。这个ProcessRecord是在前面启动MainActivity时创建的，因此，这里将它取回来，并保存在变量app中。注意，我们也可以在AndroidManifest.xml配置文件中指定SubActivity的process属性值，这样SubActivity就可以在另外一个进程中启动，不过很少有应用程序会这样做，我们不考虑这种情况。
这个app的thread也是在前面启动MainActivity时创建好的，于是，这里就直接调用realStartActivityLocked函数来启动新的Activity了，新的Activity的相关信息都保存在参数ActivityRecord 中了。
Step 22. ActivityStack.realStartActivityLocked
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 28一致。
Step 23. ApplicationThreadProxy.scheduleLaunchActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 29一致。
Step 24. ApplicationThread.scheduleLaunchActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 30一致。
Step 25. ActivityThread.queueOrSendMessage
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 31一致。
Step 26. H.handleMessage
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 32一致。
Step 27. ActivityThread.handleLaunchActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 33一致。
Step 28. ActivityThread.performLaunchActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 34一致，不过，这里要从ClassLoader里面加载的类就是shy.luo.activity.SubActivity了。
Step 29. SubAcitiviy.onCreate；
在应用程序内部启动新的Activity的过程要执行很多步骤，但是整体来看，主要分为以下四个阶段：
一. Step 1 - Step 10：应用程序的MainActivity通过Binder进程间通信机制通知ActivityManagerService，它要启动一个新的Activity；
二. Step 11 - Step 15：ActivityManagerService通过Binder进程间通信机制通知MainActivity进入Paused状态；
三. Step 16 - Step 22：MainActivity通过Binder进程间通信机制通知ActivityManagerService，它已经准备就绪进入Paused状态，于是ActivityManagerService就准备要在MainActivity所在的进程和任务中启动新的Activity了；
四. Step 23 - Step 29：ActivityManagerService通过Binder进程间通信机制通知MainActivity所在的ActivityThread，现在一切准备就绪，它可以真正执行Activity的启动操作了。
http://blog.csdn.net/luoshengyang/article/details/6685853
http://blog.csdn.net/luoshengyang/article/details/6689748
http://blog.csdn.net/luoshengyang/article/details/6703247
1.Android应用程序的Activity启动过程简要介绍和学习计划
下面简要介绍一下启动的过程：
Step 1. 无论是通过Launcher来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，都通过Binder进程间通信进入到ActivityManagerService进程中，并且调用ActivityManagerService.startActivity接口；
Step 2. ActivityManagerService调用ActivityStack.startActivityMayWait来做准备要启动的Activity的相关信息；
Step 3. ActivityStack通知ApplicationThread要进行Activity启动调度了，这里的ApplicationThread代表的是调用ActivityManagerService.startActivity接口的进程，对于通过点击应用程序图标的情景来说，这个进程就是Launcher了，而对于通过在Activity内部调用startActivity的情景来说，这个进程就是这个Activity所在的进程了；
Step 4. ApplicationThread不执行真正的启动操作，它通过调用ActivityManagerService.activityPaused接口进入到ActivityManagerService进程中，看看是否需要创建新的进程来启动Activity；
Step 5. 对于通过点击应用程序图标来启动Activity的情景来说，ActivityManagerService在这一步中，会调用startProcessLocked来创建一个新的进程，而对于通过在Activity内部调用startActivity来启动新的Activity来说，这一步是不需要执行的，因为新的Activity就在原来的Activity所在的进程中进行启动；
Step 6. ActivityManagerServic调用ApplicationThread.scheduleLaunchActivity接口，通知相应的进程执行启动Activity的操作；
Step 7. ApplicationThread把这个启动Activity的操作转发给ActivityThread，ActivityThread通过ClassLoader导入相应的Activity类，然后把它启动起来。
时序图：
2.Android应用程序启动过程源代码分析
在手机屏幕中点击应用程序图标的情景就会引发Android应用程序中的默认Activity的启动，从而把应用程序启动起来。这种启动方式的特点是会启动一个新的进程来加载相应的Activity。这里，我们继续以这个例子为例来说明Android应用程序的启动过程，即MainActivity的启动过程。
Step
1. Launcher.startActivitySafely；在Android系统中，应用程序是由Launcher启动起来的，其实，Launcher本身也是一个应用程序，其它的应用程序安装后，就会Launcher的界面上出现一个相应的图标，点击这个图标时，Launcher就会对应的应用程序启动起来。
它的默认Activity是MainActivity，这里是AndroidManifest.xml文件中配置的，因此，这里的intent包含的信息为：action
= "android.intent.action.Main"，category="android.intent.category.LAUNCHER", cmp="shy.luo.activity/.MainActivity"，表示它要启动的Activity为shy.luo.activity.MainActivity。Intent.FLAG_ACTIVITY_NEW_TASK表示要在一个新的Task中启动这个Activity，注意，Task是Android系统中的概念，它不同于进程Process的概念。简单地说，一个Task是一系列Activity的集合，这个集合是以堆栈的形式来组织的，遵循后进先出的原则。事实上，Task是一个非常复杂的概念，有兴趣的读者可以到官网http://developer.android.com/guide/topics/manifest/activity-element.html查看相关的资料。这里，我们只要知道，这个MainActivity要在一个新的Task中启动就可以了
Step
2. Activity.startActivity； 在Step 1中，我们看到，Launcher继承于Activity类，而Activity类实现了startActivity函数，因此，这里就调用了Activity.startActivity函数，这个函数实现很简单，它调用startActivityForResult来进一步处理，第二个参数传入-1表示不需要这个Actvity结束后的返回结果
Step
3. Activity.startActivityForResult；这里的mInstrumentation是Activity类的成员变量，它的类型是Intrumentation，它用来监控应用程序和系统的交互，这里的mMainThread也是Activity类的成员变量，它的类型是ActivityThread，它代表的是应用程序的主线程，我们在Android系统在新进程中启动自定义服务过程（startService）的原理分析一文中已经介绍过了。这里通过mMainThread.getApplicationThread获得它里面的ApplicationThread成员变量，它是一个Binder对象，后面我们会看到，ActivityManagerService会使用它来和ActivityThread来进行进程间通信。这里我们需注意的是，这里的mMainThread代表的是Launcher应用程序运行的进程，这里的mToken也是Activity类的成员变量，它是一个Binder对象的远程接口。
Step 4. Instrumentation.execStartActivity； 这里的ActivityManagerNative.getDefault返回ActivityManagerService的远程接口，即ActivityManagerProxy接口。
Step
5. ActivityManagerProxy.startActivity；这里的参数resolvedType、grantedUriPermissions和resultWho均为null；参数caller为ApplicationThread类型的Binder实体；参数resultTo为一个Binder实体的远程接口，我们先不关注它；参数grantedMode为0，我们也先不关注它；参数requestCode为-1；参数onlyIfNeeded和debug均空false。
Step
6. ActivityManagerService.startActivity；上一步Step 5通过Binder驱动程序就进入到ActivityManagerService的startActivity函数来了，这里只是简单地将操作转发给成员变量mMainStack的startActivityMayWait函数，这里的mMainStack的类型为ActivityStack。
Step
7. ActivityStack.startActivityMayWait；对参数intent的内容进行解析，得到MainActivity的相关信息，保存在aInfo变量中，解析之后，得到的aInfo.applicationInfo.packageName的值为"shy.luo.activity"，aInfo.name的值为"shy.luo.activity.MainActivity"，这是在这个实例的配置文件AndroidManifest.xml里面配置的。此外，函数开始的地方调用intent.getComponent()函数的返回值不为null，因此，这里的componentSpecified变量为true。 接下去就调用startActivityLocked进一步处理了。
Step
8. ActivityStack.startActivityLocked； 从传进来的参数caller得到调用者的进程信息，并保存在callerApp变量中，这里就是Launcher应用程序的进程信息了。前面说过，参数resultTo是Launcher这个Activity里面的一个Binder对象，通过它可以获得Launcher这个Activity的相关信息，保存在sourceRecord变量中。再接下来，创建即将要启动的Activity的相关信息，并保存在r变量中， 接着调用startActivityUncheckedLocked函数进行下一步操作。
Step
9. ActivityStack.startActivityUncheckedLocked；由于在这个例子的AndroidManifest.xml文件中，MainActivity没有配置launchMode属值，因此，这里的r.launchMode为默认值0，表示以标准（Standard，或者称为ActivityInfo.LAUNCH_MULTIPLE）的方式来启动这个Activity。Activity的启动方式有四种，其余三种分别是ActivityInfo.LAUNCH_SINGLE_INSTANCE、ActivityInfo.LAUNCH_SINGLE_TASK和ActivityInfo.LAUNCH_SINGLE_TOP，传进来的参数r.resultTo为null，表示Launcher不需要等这个即将要启动的MainActivity的执行结果，由于这个intent的标志值的位Intent.FLAG_ACTIVITY_NEW_TASK被置位，而且Intent.FLAG_ACTIVITY_MULTIPLE_TASK没有置位，因此，下面的if语句会被执行
if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 &&
(launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0)
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
// If bring to front is requested, and no result is requested, and
// we can find a task that was started with this same
// component, then instead of launching bring that one to the front.
if (r.resultTo == null) {
// See if there is a task to bring to the front. If this is
// a SINGLE_INSTANCE activity, there can be one and only one
// instance of it in the history, and it is always in its own
// unique task, so we do a special search.
ActivityRecord taskTop = r.launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE
? findTaskLocked(intent, r.info)
: findActivityLocked(intent, r.info);
if (taskTop != null) {
......
}
}
这段代码的逻辑是查看一下当前有没有Task可以用来执行这个Activity。由于r.launchMode的值不为ActivityInfo.LAUNCH_SINGLE_INSTANCE，因此，它通过findTaskLocked函数来查找存不存这样的Task，这里返回的结果是null，即taskTop为null，因此，需要创建一个新的Task来启动这个Activity。
接着往下看：
if (r.packageName != null) {
// If the activity being launched is the same as the one currently
// at the top, then we need to check if it should only be launched
// once.
ActivityRecord top = topRunningNonDelayedActivityLocked(notTop);
if (top != null && r.resultTo == null) {
if (top.realActivity.equals(r.realActivity)) {
......
}
}
} 这段代码的逻辑是看一下，当前在堆栈顶端的Activity是否就是即将要启动的Activity，有些情况下，如果即将要启动的Activity就在堆栈的顶端，那么，就不会重新启动这个Activity的别一个实例了，具体可以参考官方网站http://developer.android.com/reference/android/content/pm/ActivityInfo.html。现在处理堆栈顶端的Activity是Launcher，与我们即将要启动的MainActivity不是同一个Activity，因此，这里不用进一步处理上述介绍的情况。
执行到这里，我们知道，要在一个新的Task里面来启动这个Activity了，于是新创建一个Task，
新建的Task保存在r.task域中，同时，添加到mService中去，这里的mService就是ActivityManagerService了。
最后就进入startActivityLocked(r,
newTask, doResume)进一步处理了，调用resumeTopActivityLocked进一步操作。
Step
10. Activity.resumeTopActivityLocked；函数先通过调用topRunningActivityLocked函数获得堆栈顶端的Activity，这里就是MainActivity了，这是在上面的Step 9设置好的，保存在next变量中， 当我们处理休眠状态时，mLastPausedActivity保存堆栈顶端的Activity，因为当前不是休眠状态，所以mLastPausedActivity为null。
有了这些信息之后，下面的语句就容易理解了：
// If the top activity is the resumed one, nothing to do.
if (mResumedActivity == next && next.state == ActivityState.RESUMED) {
......
}
// If we are sleeping, and there is no resumed activity, and the top
// activity is paused, well that is the state we want.
if ((mService.mSleeping || mService.mShuttingDown)
&& mLastPausedActivity == next && next.state == ActivityState.PAUSED) {
......
}
它首先看要启动的Activity是否就是当前处理Resumed状态的Activity，如果是的话，那就什么都不用做，直接返回就可以了；否则再看一下系统当前是否休眠状态，如果是的话，再看看要启动的Activity是否就是当前处于堆栈顶端的Activity，如果是的话，也是什么都不用做。
上面两个条件都不满足，因此，在继续往下执行之前，首先要把当处于Resumed状态的Activity推入Paused状态，然后才可以启动新的Activity。但是在将当前这个Resumed状态的Activity推入Paused状态之前，首先要看一下当前是否有Activity正在进入Pausing状态，如果有的话，当前这个Resumed状态的Activity就要稍后才能进入Paused状态了，这样就保证了所有需要进入Paused状态的Activity串行处理。
这里没有处于Pausing状态的Activity，即mPausingActivity为null，而且mResumedActivity也不为null，于是就调用startPausingLocked函数把Launcher推入Paused状态去了。
Step
11. ActivityStack.startPausingLocked；函数首先把mResumedActivity保存在本地变量prev中。在上一步Step 10中，说到mResumedActivity就是Launcher，因此，这里把Launcher进程中的ApplicationThread对象取出来，通过它来通知Launcher这个Activity它要进入Paused状态了。当然，这里的prev.app.thread是一个ApplicationThread对象的远程接口，通过调用这个远程接口的schedulePauseActivity来通知Launcher进入Paused状态。
Step
12. ApplicationThreadProxy.schedulePauseActivity；通过Binder进程间通信机制进入到ApplicationThread.schedulePauseActivity函数中。
Step
13. ApplicationThread.schedulePauseActivity；这里调用的函数queueOrSendMessage是ActivityThread类的成员函数，因此，queueOrSendMessage的第一个参数值为H.PAUSE_ACTIVITY，表示要暂停token所代表的Activity，即Launcher。
Step
14. ActivityThread.queueOrSendMessage；这里首先将相关信息组装成一个msg，然后通过mH成员变量发送出去，mH的类型是H，继承于Handler类，是ActivityThread的内部类，因此，这个消息最后由H.handleMessage来处理。
Step
15. H.handleMessage；这里调用ActivityThread.handlePauseActivity进一步操作，msg.obj是一个ActivityRecord对象的引用，它代表的是Launcher这个Activity。
Step
16. ActivityThread.handlePauseActivity；函数首先将Binder引用token转换成ActivityRecord的远程接口ActivityClientRecord，然后做了三个事情：1. 如果userLeaving为true，则通过调用performUserLeavingActivity函数来调用Activity.onUserLeaveHint通知Activity，用户要离开它了；2.
调用performPauseActivity函数来调用Activity.onPause函数，我们知道，在Activity的生命周期中，当它要让位于其它的Activity时，系统就会调用它的onPause函数；3. 它通知ActivityManagerService，这个Activity已经进入Paused状态了，ActivityManagerService现在可以完成未竟的事情，即启动MainActivity了。
Step
17. ActivityManagerProxy.activityPaused；这里通过Binder进程间通信机制就进入到ActivityManagerService.activityPaused函数中去了。
Step
18. ActivityManagerService.activityPaused； 这里，又再次进入到ActivityStack类中，执行activityPaused函数。
Step
19. ActivityStack.activityPaused；这里通过参数token在mHistory列表中得到ActivityRecord，从上面我们知道，这个ActivityRecord代表的是Launcher这个Activity，而我们在Step
11中，把Launcher这个Activity的信息保存在mPausingActivity中，因此，这里mPausingActivity等于r，于是，执行completePauseLocked操作。
Step
20. ActivityStack.completePauseLocked； 函数首先把mPausingActivity变量清空，因为现在不需要它了，然后调用resumeTopActivityLokced进一步操作，它传入的参数即为代表Launcher这个Activity的ActivityRecord。
Step 21. ActivityStack.resumeTopActivityLokced； 通过上面的Step
9，我们知道，当前在堆栈顶端的Activity为我们即将要启动的MainActivity，这里通过调用topRunningActivityLocked将它取回来，保存在next变量中。之前最后一个Resumed状态的Activity，即Launcher，到了这里已经处于Paused状态了，因此，mResumedActivity为null。最后一个处于Paused状态的Activity为Launcher，因此，这里的mLastPausedActivity就为Launcher。前面我们为MainActivity创建了ActivityRecord后，它的app域一直保持为null。有了这些信息后，上面这段代码就容易理解了，它最终调用startSpecificActivityLocked进行下一步操作。
Step
22. ActivityStack.startSpecificActivityLocked；注意，这里由于是第一次启动应用程序的Activity，所以下面语句：
ProcessRecord app = mService.getProcessRecordLocked(r.processName,
r.info.applicationInfo.uid);
取回来的app为null。在Activity应用程序中的AndroidManifest.xml配置文件中，我们没有指定Application标签的process属性，系统就会默认使用package的名称，这里就是"shy.luo.activity"了。每一个应用程序都有自己的uid，因此，这里uid + process的组合就可以为每一个应用程序创建一个ProcessRecord。当然，我们可以配置两个应用程序具有相同的uid和package，或者在AndroidManifest.xml配置文件的application标签或者activity标签中显式指定相同的process属性值，这样，不同的应用程序也可以在同一个进程中启动。函数最终执行ActivityManagerService.startProcessLocked函数进行下一步操作
Step
23. ActivityManagerService.startProcessLocked；这里再次检查是否已经有以process + uid命名的进程存在，在我们这个情景中，返回值app为null，因此，后面会创建一个ProcessRecord，并存保存在成员变量mProcessNames中，最后，调用另一个startProcessLocked函数进一步操作。
该函数这里主要是调用Process.start接口来创建一个新的进程，新的进程会导入android.app.ActivityThread类，并且执行它的main函数，这就是为什么我们前面说每一个应用程序都有一个ActivityThread实例来对应的原因。
Step
24. ActivityThread.main； 这个函数在进程中创建一个ActivityThread实例，然后调用它的attach函数，接着就进入消息循环了，直到最后进程退出。函数attach最终调用了ActivityManagerService的远程接口ActivityManagerProxy的attachApplication函数，传入的参数是mAppThread，这是一个ApplicationThread类型的Binder对象，它的作用是用来进行进程间通信的。
Step
25. ActivityManagerProxy.attachApplication；这里通过Binder驱动程序，最后进入ActivityManagerService的attachApplication函数中。
Step
26. ActivityManagerService.attachApplication； 这里将操作转发给attachApplicationLocked函数。
Step
27. ActivityManagerService.attachApplicationLocked；在前面的Step 23中，已经创建了一个ProcessRecord，这里首先通过pid将它取回来，放在app变量中，然后对app的其它成员进行初始化，最后调用mMainStack.realStartActivityLocked执行真正的Activity启动操作。这里要启动的Activity通过调用mMainStack.topRunningActivityLocked(null)从堆栈顶端取回来，这时候在堆栈顶端的Activity就是MainActivity了。
Step
28. ActivityStack.realStartActivityLocked；这里最终通过app.thread进入到ApplicationThreadProxy的scheduleLaunchActivity函数中，注意，这里的第二个参数r，是一个ActivityRecord类型的Binder对象，用来作来这个Activity的token值。
Step
29. ApplicationThreadProxy.scheduleLaunchActivity；这个函数最终通过Binder驱动程序进入到ApplicationThread的scheduleLaunchActivity函数中。
Step
30. ApplicationThread.scheduleLaunchActivity；函数首先创建一个ActivityClientRecord实例，并且初始化它的成员变量，然后调用ActivityThread类的queueOrSendMessage函数进一步处理。
Step
31. ActivityThread.queueOrSendMessage；函数把消息内容放在msg中，然后通过mH把消息分发出去，这里的成员变量mH我们在前面已经见过，消息分发出去后，最后会调用H类的handleMessage函数。
Step
32. H.handleMessage； 这里最后调用ActivityThread类的handleLaunchActivity函数进一步处理。
Step
33. ActivityThread.handleLaunchActivity。 这里首先调用performLaunchActivity函数来加载这个Activity类，即shy.luo.activity.MainActivity，然后调用它的onCreate函数，最后回到handleLaunchActivity函数时，再调用handleResumeActivity函数来使这个Activity进入Resumed状态，即会调用这个Activity的onResume函数，这是遵循Activity的生命周期的。
Step
34. ActivityThread.performLaunchActivity；函数前面是收集要启动的Activity的相关信息，主要package和component信息，然后通过ClassLoader将shy.luo.activity.MainActivity类加载进来，创建Application对象，这是根据AndroidManifest.xml配置文件中的Application标签的信息来创建的，后面的代码主要创建Activity的上下文信息，并通过attach方法将这些上下文信息设置到MainActivity中去，最后还要调用MainActivity的onCreate函数，这里不是直接调用MainActivity的onCreate函数，而是通过mInstrumentation的callActivityOnCreate函数来间接调用，前面我们说过，mInstrumentation在这里的作用是监控Activity与系统的交互操作，相当于是系统运行日志。
Step
35. MainActivity.onCreate；这样，MainActivity就启动起来了，整个应用程序也启动起来了。
整个应用程序的启动过程要执行很多步骤，但是整体来看，主要分为以下五个阶段：
一. Step1 - Step 11：Launcher通过Binder进程间通信机制通知ActivityManagerService，它要启动一个Activity；
二. Step 12 - Step 16：ActivityManagerService通过Binder进程间通信机制通知Launcher进入Paused状态；
三. Step 17 - Step 24：Launcher通过Binder进程间通信机制通知ActivityManagerService，它已经准备就绪进入Paused状态，于是ActivityManagerService就创建一个新的进程，用来启动一个ActivityThread实例，即将要启动的Activity就是在这个ActivityThread实例中运行；
四. Step 25 - Step 27：ActivityThread通过Binder进程间通信机制将一个ApplicationThread类型的Binder对象传递给ActivityManagerService，以便以后ActivityManagerService能够通过这个Binder对象和它进行通信；
五. Step 28 - Step 35：ActivityManagerService通过Binder进程间通信机制通知ActivityThread，现在一切准备就绪，它可以真正执行Activity的启动操作了。
3.Android应用程序内部启动Activity过程（startActivity）的源代码分析
上文介绍了Android应用程序的启动过程，即应用程序默认Activity的启动过程，一般来说，这种默认Activity是在新的进程和任务中启动的；本文将继续分析在应用程序内部启动非默认Activity的过程的源代码，这种非默认Activity一般是在原来的进程和任务中启动的。
Step
1. Activity.startActivity；这一步与上一篇文章Android应用程序启动过程源代码分析的Step
2大体一致，通过指定名称“shy.luo.activity.subactivity”来告诉应用程序框架层，它要隐式地启动SubActivity。所不同的是传入的参数intent没有Intent.FLAG_ACTIVITY_NEW_TASK标志，表示这个SubActivity和启动它的MainActivity运行在同一个Task中
Step
2. Activity.startActivityForResult；这一步与上一篇文章Android应用程序启动过程源代码分析的Step
3一致。
Step 3. Instrumentation.execStartActivity；这一步与上一篇文章Android应用程序启动过程源代码分析的Step
4一致。
Step 4. ActivityManagerProxy.startActivity；这一步与上一篇文章Android应用程序启动过程源代码分析的Step
5一致。
Step 5. ActivityManagerService.startActivity；这一步与上一篇文章Android应用程序启动过程源代码分析的Step
6一致。
Step 6. ActivityStack.startActivityMayWait； 这一步与上一篇文章Android应用程序启动过程源代码分析的Step
7一致。
Step 7. ActivityStack.startActivityLocked；这一步与上一篇文章Android应用程序启动过程源代码分析的Step
8一致。
Step 8. ActivityStack.startActivityUncheckedLocked； 这一步与上一篇文章Android应用程序启动过程源代码分析的Step
9有所不同，主要是当前要启动的Activity与启动它的Activity是在同一个Task中运行的，我们来详细看一下。
public class ActivityStack {
......
final int startActivityUncheckedLocked(ActivityRecord r,
ActivityRecord sourceRecord, Uri[] grantedUriPermissions,
int grantedMode, boolean onlyIfNeeded, boolean doResume) {
final Intent intent = r.intent;
final int callingUid = r.launchedFromUid;
int launchFlags = intent.getFlags();
......
if (sourceRecord == null) {
......
} else if (sourceRecord.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
......
} else if (r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE
......
}
if (r.resultTo != null && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
......
}
boolean addingToTask = false;
if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 &&
(launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0)
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
......
}
if (r.packageName != null) {
// If the activity being launched is the same as the one currently
// at the top, then we need to check if it should only be launched
// once.
ActivityRecord top = topRunningNonDelayedActivityLocked(notTop);
if (top != null && r.resultTo == null) {
if (top.realActivity.equals(r.realActivity)) {
......
}
}
} else {
......
}
boolean newTask = false;
// Should this be considered a new task?
if (r.resultTo == null && !addingToTask
&& (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
......
} else if (sourceRecord != null) {
......
// An existing activity is starting this new activity, so we want
// to keep the new one in the same task as the one that is starting
// it.
r.task = sourceRecord.task;
......
} else {
......
}
......
startActivityLocked(r, newTask, doResume);
return START_SUCCESS;
}
......
}
这里，参数intent的标志位Intent.FLAG_ACTIVITY_NEW_TASK没有设置，在配置文件AndriodManifest.xml中，SubActivity也没有配置启动模式launchMode，于是它就默认标准模式，即ActivityInfo.LAUNCH_MULTIPLE
这里看一下当前要启动的Activity是否就是当前堆栈顶端的Activity，如果是的话，在某些情况下，就不用再重新启动了。函数topRunningNonDelayedActivityLocked返回当前堆栈顶端的Activity，这里即为MainActivity，而当前要启动的Activity为SubActivity，因此，这二者不相等，于是跳过里面的if语句。
接着，前面说过参数intent的标志位Intent.FLAG_ACTIVITY_NEW_TASK没有设置，而这里的sourceRecord即为当前执行启动Activity操作的Activity，这里即为MainActivity，因此，它不为null，于是于MainActivity所属的Task设置到r.task中去，这里的r即为SubActivity。看到这里，我们就知道SubActivity要和MainActivity运行在同一个Task中了，同时，变量newTask的值为false。最后，函数进 入step
7中startActivityLocked(r, newTask, doResume)进一步处理了。
这里传进来的参数newTask为false，doResume为true。当newTask为false，表示即将要启动的Activity是在原有的Task运行时，如果这个原有的Task当前对用户不可见时，这时候就不需要继续执行下去了，因为即使把这个Activity启动起来，用户也看不到，还不如先把它保存起来，等到下次这个Task对用户可见的时候，再启动不迟。这里，这个原有的Task，即运行MainActivity的Task当前对用户是可见的，因此，会继续往下执行。
接下去执行就会把这个SubActivity通过mHistroy.add(addPos,
r)添加到堆栈顶端去，然后调用resumeTopActivityLocked进一步操作。
Step
9. ActivityStack.resumeTopActivityLocked； 这一步与上一篇文章Android应用程序启动过程源代码分析的Step
10一致。但是要注意的是，执行到这个函数的时候，当前处于堆栈顶端的Activity为SubActivity，ActivityStack的成员变量mResumedActivity指向MainActivity。
Step
10. ActivityStack.startPausingLocked
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 11一致。
从这里开始，ActivityManagerService通知MainActivity进入Paused状态。
Step 11. ApplicationThreadProxy.schedulePauseActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 12一致。
Step 12. ApplicationThread.schedulePauseActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 13一致。
Step 13. ActivityThread.queueOrSendMessage
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 14一致。
Step 14. H.handleMessage
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 15一致。
Step 15. ActivityThread.handlePauseActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 16一致。
Step 16. ActivityManagerProxy.activityPaused
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 17一致。
Step 17. ActivityManagerService.activityPaused
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 18一致。
Step 18. ActivityStack.activityPaused
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 19一致。
Step 19. ActivityStack.completePauseLocked
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 20一致。
执行到这里的时候，MainActivity就进入Paused状态了，下面就开始要启动SubActivity了。
Step 20. ActivityStack.resumeTopActivityLokced
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 21一致。
Step 21. ActivityStack.startSpecificActivityLocked； 这一步与上一篇文章Android应用程序启动过程源代码分析的Step
22就有所不同了，这里，它不会调用mService.startProcessLocked来创建一个新的进程来启动新的Activity； 这里由于不是第一次启动应用程序的Activity（MainActivity是这个应用程序第一个启动的Activity），所以下面语句：
ProcessRecord app = mService.getProcessRecordLocked(r.processName,
r.info.applicationInfo.uid);
取回来的app不为null。在上一篇文章Android应用程序启动过程源代码分析中，我们介绍过，在Activity应用程序中的AndroidManifest.xml配置文件中，我们没有指定application标签的process属性，于是系统就会默认使用package的名称，这里就是"shy.luo.activity"了。每一个应用程序都有自己的uid，因此，这里uid
+ process的组合就可以创建一个全局唯一的ProcessRecord。这个ProcessRecord是在前面启动MainActivity时创建的，因此，这里将它取回来，并保存在变量app中。注意，我们也可以在AndroidManifest.xml配置文件中指定SubActivity的process属性值，这样SubActivity就可以在另外一个进程中启动，不过很少有应用程序会这样做，我们不考虑这种情况。
这个app的thread也是在前面启动MainActivity时创建好的，于是，这里就直接调用realStartActivityLocked函数来启动新的Activity了，新的Activity的相关信息都保存在参数ActivityRecord 中了。
Step 22. ActivityStack.realStartActivityLocked
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 28一致。
Step 23. ApplicationThreadProxy.scheduleLaunchActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 29一致。
Step 24. ApplicationThread.scheduleLaunchActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 30一致。
Step 25. ActivityThread.queueOrSendMessage
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 31一致。
Step 26. H.handleMessage
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 32一致。
Step 27. ActivityThread.handleLaunchActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 33一致。
Step 28. ActivityThread.performLaunchActivity
这一步与上一篇文章Android应用程序启动过程源代码分析的Step 34一致，不过，这里要从ClassLoader里面加载的类就是shy.luo.activity.SubActivity了。
Step 29. SubAcitiviy.onCreate；
在应用程序内部启动新的Activity的过程要执行很多步骤，但是整体来看，主要分为以下四个阶段：
一. Step 1 - Step 10：应用程序的MainActivity通过Binder进程间通信机制通知ActivityManagerService，它要启动一个新的Activity；
二. Step 11 - Step 15：ActivityManagerService通过Binder进程间通信机制通知MainActivity进入Paused状态；
三. Step 16 - Step 22：MainActivity通过Binder进程间通信机制通知ActivityManagerService，它已经准备就绪进入Paused状态，于是ActivityManagerService就准备要在MainActivity所在的进程和任务中启动新的Activity了；
四. Step 23 - Step 29：ActivityManagerService通过Binder进程间通信机制通知MainActivity所在的ActivityThread，现在一切准备就绪，它可以真正执行Activity的启动操作了。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- Android源码解析之应用程序内部启动Activity过程（startActivity）的源代码分析
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- Android之A面试题④应用程序内部启动Activity过程（startActivity）的源代码分析
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- [转载] Android应用程序内部启动Activity过程（startActivity）的源代码分析
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- Android系统在新进程中启动自定义服务过程（startService）的原理分析、Android应用程序绑定服务（bindService）的过程源代码分析
- Android应用程序启动过程源代码分析
- Android应用程序在新的进程中启动新的Activity的方法和过程分析
- Android应用程序启动过程源代码分析（4）