activity之启动流程
Activity的启动过程
1）Activity启动涉及到的类
首先要简单介绍一下Activity启动过程涉及到的类，以便于更好的理解这个启动过程。
- ActivityManagerService：简称AMS，是service端对象，负责管理系统中所有的Activity
- ActivityManagerProxy：是ActivityManagerService的本地代理
- ActivityStack：Activity在AMS的栈管理，用来记录已经启动的Activity的先后关系，状态信息等。通过ActivityStack决定是否需要启动新的进程。
- ActivityRecord：ActivityStack的管理对象， 每个Activity在AMS对应一个ActivityRecord， 来记录Activity的状态 以及 其他的管理信息。其实就是服务器端的Activity对象的映像。
- TaskRecord：AMS抽象出来的一个“任务”的概念，是记录ActivityRecord的栈，一个“Task”包含若干个ActivityRecord。AMS用TaskRecord确保Activity启动和退出的顺序。
- ActivityThread：App启动的入口
- ApplicationThread：ActivityThread的内部类，继承Binder，可以进程跨进程通信。
- ApplicationThreadProxy：ApplicationThread的一个本地代理，其它的client端通过这个对象调用server端ApplicationThread中方法。
- Instrumentation：负责发起Activity的启动、并具体负责Activity的创建 以及Activity生命周期的回调。一个应用进程只会有一个Instrumentation对象，App内的所有Activity都持有该对象的引用。
2）而从桌面点击应用图标时，由于launcher本身也是一个应用，当点击图标时系统会调用startActivitySately()(一般下启动的activity相关信息都会存在intent中如action，category等等),
当点击应用图标时，就会调用startActivitySately()方法(内部是调用startActivty()),
而startActivity()最终会调用startActivityForResult()这个方法（系统调用startActivityForResult()直接返回-1，表示不需要结果返回了)。
而startActivityForResult()实际通过Instrumentation类中的execStartActivity()方法来启动activity(Instrumentation这类主要作用是监控程序和系统之间的交互)。
而Instrumentation的execStartActivity()中会获取ActivityManagerService的代理对象且通过此代理对象启动activity
(启动时会调用一个checkStartActivityResult()方法，如果说没有在配置清单中配置有这个组件，就会在这个方法中抛出异常了)。
当然最后调用是Application.scheduleLaunchActivity()进行启动activity，而这个方法中通过获取得到一个ActivityClientRecord对象，
而这个ActivityClientRecord通过handler来进行消息的发送，系统内部会将每一个activity组件使用ActivityClientRecord对象来进行描述，
而ActivityClientRecord对象中保存有一个LoaderApk对象，通过这个对象调用handleLaunchActivity来启动activity组件，而页面的生命周期方法也就是在这个方法中进行调用。
说明：
在安装这个应用的时候，系统也会启动一个PackaManagerService的管理服务，这个管理服务会对AndroidManifest.xml文件进行解析，从而得到应用程序中的相关信息，比如service，activity，Broadcast等等，然后获得相关组件的信息。
3）源码分析过程是比较绕，比较烧脑的过程，不要太纠结去API的调用，尽量侧重流程。分析源码，最好带着问题去分析，不要为了分析而分析，尽量在分析过程中寻找自己想要的答案。比如：
- Activity对象是怎么创建的？
- Window对象是什么时候创建的？
- LayoutInflater什么时候创建的？
- 为什么在Activity中的布局中或者Fragment的中View获取的Context都是其所在的Activity对象？
- 为什么自定义View一定要有两个参数的构造函数？
- Activity的生命周期方法是被谁回调的？
- Application是什么时候创建的？
- ClassLoader对象是什么时候创建的？
- 子线程可以启动Activity、Service吗？
- 下拉通知栏，会影响Activity生命周期吗？
Activity启动过程，从Context的startActivity说起，实现是ContextImpl的startActivity，
然后内部会通过Instrumentation来尝试启动Activity，这是一个跨进程过程，它会调用ams的startActivity方法，
当ams校验完activity的合法性后，会通过ApplicationThread回调到我们的进程，这也是一次跨进程过程，
而applicationThread就是一个binder，回调逻辑是在binder线程池中完成的，所以需要通过Handler H将其切换到ui线程，第一个消息是LAUNCH_ACTIVITY，它对应handleLaunchActivity，在这个方法里完成了Activity的创建和启动，接着，在activity的onResume中，activity的内容将开始渲染到window上，然后开始绘制直到我们看见。
在上图中，ActivityManagerService和ActivityStack位于同一个进程中， 而ApplicationThread和ActivityThread位于另一个进程中。
其中，ActivityManagerService是负责管理Activity的生命周期的，ActivityManagerService还借助ActivityStack是来把所有的Activity按照后进先出的顺序放在一个堆栈中；
对于每一个应用程序来说，都有一个ActivityThread来表示应用程序的主进程，而每一个ActivityThread都包含有一个ApplicationThread实例，它是一个Binder对象，负责和其它进程进行通信。
下面简要介绍一下启动的过程：
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类，然后把它启动起来。
一.Activity启动过程分析
总结
源码分析过程是比较绕，比较烧脑的过程，不要太纠结去API的调用，尽量侧重流程。分析源码，最好带着问题去分析，不要为了分析而分析，尽量在分析过程中寻找自己想要的答案。比如：
- Activity对象是怎么创建的？
- Window对象是什么时候创建的？
- LayoutInflater什么时候创建的？
- 为什么在Activity中的布局中或者Fragment的中View获取的Context都是其所在的Activity对象？
- 为什么自定义View一定要有两个参数的构造函数？
- Activity的生命周期方法是被谁回调的？
- Application是什么时候创建的？
- ClassLoader对象是什么时候创建的？
- 子线程可以启动Activity、Service吗？
- 下拉通知栏，会影响Activity生命周期吗？
笔者初入Android开发没多久的时候，有次面试，面试官问我在子线程中启动Activity可以吗？
我回答可以，因为我试过，但是问我为什么我却不知道。如果那时候看了Activity启动过程的源码，看了Binder机制的话，应该很容易的就回答出来了。
通常我们在Activity中启动一个另一个Activity，就是调用Activity的startActivity方法，这个最终会调用到Activity的startActivityForResult方法。那你有没有想过Activity的启动到底经历了哪些过程，我们今天就来分析一下。
在具体分析之前，要先说明一下，Activity的启动流程在细节挺繁琐的，比如启动另一个App的Activity或者启动不同的launchMode的Activity，在细节上都会有不同。这次的源码分析着重分析一下流程，为了简单起见，就以分析一个Activity启动app内部另一个standard模式的Activity为主。
Activity启动另一个Activity之前，当前的Activity先要执行onPause，被启动的Activity才会执行到onResume方法。这中间实际上是会执行4次IPC过程的：
- 当前Activity发起启动另一个Activity的请求——>ActivityManagerService
- ActivityManagerService——> 通知App暂停当前Activity
- 当前App告知已经暂停了当前的Activity——> ActivityManagerService
- ActivityManagerService ——> 通知App启动新的Activity
注：本次源码分析采用Android7.0，不同版本的源码在细节上会有不同，如在Android8.0上ActivityManagerService就改成了以AIDL的方式来写，请不要太纠结API的不同。 注：本文Activity启动过程源码分析过程比较长，代码较繁琐，请做好心理准备。
介绍完这些，我们开始进入正题
Activity的启动过程？
Activity启动最终会调用到startActivityForResult方法。
# android.app.Activity
public void startActivityForResult(@RequiresPermission Intent intent, int requestCode, Bundle options) {
if (mParent == null) {
Instrumentation.ActivityResult ar = mInstrumentation.execStartActivity(this, mMainThread.getApplicationThread(), mToken, this,intent, requestCode, options);
if (ar != null) { mMainThread.sendActivityResult( mToken, mEmbeddedID, requestCode, ar.getResultCode(), ar.getResultData()); } ... }
else { ... } }
调用了Instrumentation的execStartActivity方法，在这里通过ActivityManagerNative.getDefault()方法获取ActivityManagerService的一个本地代理对象ActivityManagerProxy，然后调用了其startActivity方法：
# android.app.Instrumentation
public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target,Intent intent, int requestCode, Bundle options) {
IApplicationThread whoThread = (IApplicationThread) contextThread;
...
try {
...
int result = ActivityManagerNative.getDefault().startActivity(whoThread, who.getBasePackageName(), intent,intent.resolveTypeIfNeeded(who.getContentResolver()),token, target != null ? target.mEmbeddedID : null,requestCode, 0, null, options);
checkStartActivityResult(result, intent);
} catch (RemoteException e) {
throw new RuntimeException("Failure from system", e);
}
return null;
}
看一下ActivityManagerNative，继承Binder并实现IActivityManager接口，ActivityManagerService就是继承了ActivityManagerNative。
public abstract class ActivityManagerNative extends Binder implements IActivityManager
public final class ActivityManagerService extends ActivityManagerNative
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback
class ActivityManagerProxy implements IActivityManager
ActivityManagerNative实际上获取的是其内部类ActivityManagerProxy对象。ActivityManagerProxy只是ActivityManagerService的本地代理对象，
其startActivity方法会调用到AMS的startActivity方法。而且要注意，这个startActivity方法会把ApplicationThread对象传递到AMS所在进程，
当然了AMS拿到的实际上是ApplicationThread的代理对象ApplicationThreadProxy，AMS就要通过这个代理对象与我们的App进程进行通信。
# android.app.ActivityManagerNative
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
protected IActivityManager create() {
IBinder b = ServiceManager.getService("activity");
if (false) {
Log.v("ActivityManager", "default service binder = " + b);
}
IActivityManager am = asInterface(b);
if (false) {
Log.v("ActivityManager", "default service = " + am);
}
return am;
}
};
static public IActivityManager asInterface(IBinder obj) {
if (obj == null) {
return null;
}
IActivityManager in = (IActivityManager)obj.queryLocalInterface(descriptor);
if (in != null) {
return in;
}
return new ActivityManagerProxy(obj);
}
static public IActivityManager getDefault() {
return gDefault.get();
}
注：在Android8.0，由于使用AIDL的方式来写ActivityManagerService，ActivityManagerNative已经过期。
我们接着看一下AMS的startActivity方法：
# com.android.server.am.ActivityManagerService
public final int startActivity(IApplicationThread caller, String callingPackage,
Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
int startFlags, ProfilerInfo profilerInfo, Bundle bOptions) {
return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,
resultWho, requestCode, startFlags, profilerInfo, bOptions, UserHandle.getCallingUserId());
}
startActivity方法紧接着调用了其startActivityAsUser方法。
@Override
public final int startActivityAsUser(IApplicationThread caller, String callingPackage,
Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
int startFlags, ProfilerInfo profilerInfo, Bundle bOptions, int userId) {
enforceNotIsolatedCaller("startActivity");
userId = mUserController.handleIncomingUser(Binder.getCallingPid(), Binder.getCallingUid(),
userId, false, ALLOW_FULL_ONLY, "startActivity", null);
// TODO: Switch to user app stacks here.
return mActivityStarter.startActivityMayWait(caller, -1, callingPackage, intent,
resolvedType, null, null, resultTo, resultWho, requestCode, startFlags,
profilerInfo, null, null, bOptions, false, userId, null, null);
}
接着调用了ActivityStarter的startActivityMayWait方法，由于方法很长，我们只保留关键的流程部分：
# com.android.server.am.ActivityStarter
final int startActivityMayWait(IApplicationThread caller, int callingUid,
String callingPackage, Intent intent, String resolvedType,
IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
IBinder resultTo, String resultWho, int requestCode, int startFlags,
ProfilerInfo profilerInfo, IActivityManager.WaitResult outResult, Configuration config,
Bundle bOptions, boolean ignoreTargetSecurity, int userId,
IActivityContainer iContainer, TaskRecord inTask) {
...
int res = startActivityLocked(caller, intent, ephemeralIntent, resolvedType,
aInfo, rInfo, voiceSession, voiceInteractor,
resultTo, resultWho, requestCode, callingPid,
callingUid, callingPackage, realCallingPid, realCallingUid, startFlags,
options, ignoreTargetSecurity, componentSpecified, outRecord, container, inTask);
...
}
}
ActivityStarter调用了自身的startActivityLocked方法，这又是一个很长的方法，保留关键的流程如下。
# com.android.server.am.ActivityStarter
final int startActivityLocked(IApplicationThread caller, Intent intent, Intent ephemeralIntent,
String resolvedType, ActivityInfo aInfo, ResolveInfo rInfo,
IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
IBinder resultTo, String resultWho, int requestCode, int callingPid, int callingUid,
String callingPackage, int realCallingPid, int realCallingUid, int startFlags,
ActivityOptions options, boolean ignoreTargetSecurity, boolean componentSpecified,
ActivityRecord[] outActivity, ActivityStackSupervisor.ActivityContainer container,
TaskRecord inTask) {
int err = ActivityManager.START_SUCCESS;
...
try {
mService.mWindowManager.deferSurfaceLayout();
err = startActivityUnchecked(r, sourceRecord, voiceSession, voiceInteractor, startFlags,
true, options, inTask);
} finally {
mService.mWindowManager.continueSurfaceLayout();
}
postStartActivityUncheckedProcessing(r, err, stack.mStackId, mSourceRecord, mTargetStack);
return err;
}
ActivityStarter又调用了自身的startActivityUnchecked方法，
# com.android.server.am.ActivityStarter
private int startActivityUnchecked(final ActivityRecord r, ActivityRecord sourceRecord,
IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
int startFlags, boolean doResume, ActivityOptions options, TaskRecord inTask) {
...
if (mDoResume) {
...
if (!mTargetStack.isFocusable()
...
} else {
mSupervisor.resumeFocusedStackTopActivityLocked(mTargetStack, mStartActivity,
mOptions);
}
} else {
...
}
...
return START_SUCCESS;
}
在ActivityStarter中调用了ActivityStackSupervisor的resumeFocusedStackTopActivityLocked方法。
# com.android.server.am.ActivityStackSupervisor
boolean resumeFocusedStackTopActivityLocked(
ActivityStack targetStack, ActivityRecord target, ActivityOptions targetOptions) {
if (targetStack != null && isFocusedStack(targetStack)) {
return targetStack.resumeTopActivityUncheckedLocked(target, targetOptions);
}
...
}
在ActivityStackSupervisor的resumeFocusedStackTopActivityLocked中又调用了ActivityStack的resumeTopActivityUncheckedLocked方法。
# com.android.server.am.ActivityStack
boolean resumeTopActivityUncheckedLocked(ActivityRecord prev, ActivityOptions options) {
...
boolean result = false;
try {
// Protect against recursion.
mStackSupervisor.inResumeTopActivity = true;
...
result = resumeTopActivityInnerLocked(prev, options);
} finally {
mStackSupervisor.inResumeTopActivity = false;
}
return result;
}
ActivityStack在resumeTopActivityUncheckedLocked又调用了其自身的resumeTopActivityInnerLocked方法。
# com.android.server.am.ActivityStack
private boolean resumeTopActivityInnerLocked(ActivityRecord prev, ActivityOptions options) {
..
// We need to start pausing the current activity so the top one can be resumed...
...
if (mResumedActivity != null) {
if (DEBUG_STATES) Slog.d(TAG_STATES,"resumeTopActivityLocked: Pausing " + mResumedActivity);
pausing |= startPausingLocked(userLeaving, false, next, dontWaitForPause);
}
...
}
由于当前的Activity执行了onResume，所以mResumedActivity != null 条件满足，就会调用startPausingLocked方法先暂停当前的Activity。
注意：这个过程必然是一个IPC过程。 我们看一下startPausingLocked方法。
# com.android.server.am.ActivityStack
final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping, ActivityRecord resuming, boolean dontWait) {
ActivityRecord prev = mResumedActivity;
...
if (prev.app != null && prev.app.thread != null) {
if (DEBUG_PAUSE) Slog.v(TAG_PAUSE, "Enqueueing pending pause: " + prev);
try {
...
prev.app.thread.schedulePauseActivity(prev.appToken, prev.finishing,
userLeaving, prev.configChangeFlags, dontWait);
} catch (Exception e) {
...
}
} else {
...
}
...
}
prev.app.thread表示的是IApplicationThread对象，在这里就是指的发起启动的Activity所在进程的ApplicationThread的本地代理ApplicationThreadProxy。
调用它的schedulePauseActivity方法，很明显是一次IPC过程，最终调用到server端，也就是发起启动的Activity所在进程ApplicationThread的schedulePauseActivity方法。
# android.app.ActivityThread$$ApplicationThread
public final void schedulePauseActivity(IBinder token, boolean finished,
boolean userLeaving, int configChanges, boolean dontReport) {
int seq = getLifecycleSeq();
if (DEBUG_ORDER) Slog.d(TAG, "pauseActivity " + ActivityThread.this
+ " operation received seq: " + seq);
sendMessage(
finished ? H.PAUSE_ACTIVITY_FINISHING : H.PAUSE_ACTIVITY,
token,
(userLeaving ? USER_LEAVING : 0) | (dontReport ? DONT_REPORT : 0),
configChanges,
seq);
}
通过Hander的转发，接着会调用到ActivityThread的handlePauseActivity方法。
# android.app.ActivityThread
private void handlePauseActivity(IBinder token, boolean finished,boolean userLeaving, int configChanges, boolean dontReport, int seq) {
ActivityClientRecord r = mActivities.get(token);
...
if (r != null) {
...
performPauseActivity(token, finished, r.isPreHoneycomb(), "handlePauseActivity");
...
// Tell the activity manager we have paused.
if (!dontReport) {
try {
ActivityManagerNative.getDefault().activityPaused(token);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
}
mSomeActivitiesChanged = true;
}
}
在ActivityThread的handlePauseActivity中，首先会调用performPauseActivity来暂停当前的Activity，经过层层调用，会调用到Intrumentation的callActivityOnPause方法，最终调用Activity的onPause方法，这一块的流程比较简单.
暂停之后，会调动ActivityManagerNative.getDefault().activityPaused(token)，这个很明显又是一次IPC过程，就是告诉AMS，已经暂停当前的Activity，可以启动新的Activity 了。
我们来看一下AMS的的activityPaused方法：
# com.android.server.am.ActivityManagerService
@Override
public final void activityPaused(IBinder token) {
final long origId = Binder.clearCallingIdentity();
synchronized(this) {
ActivityStack stack = ActivityRecord.getStackLocked(token);
if (stack != null) {
stack.activityPausedLocked(token, false);
}
}
Binder.restoreCallingIdentity(origId);
}
AMS中的activityPaused又调用了ActivityStack的activityPausedLocked方法。
# com.android.server.am.ActivityStack
final void activityPausedLocked(IBinder token, boolean timeout) {
...
final ActivityRecord r = isInStackLocked(token);
if (r != null) {
mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r);
if (mPausingActivity == r) {
if (DEBUG_STATES) Slog.v(TAG_STATES, "Moving to PAUSED: " + r
+ (timeout ? " (due to timeout)" : " (pause complete)"));
completePauseLocked(true, null);
return;
} else {
...
}
}
...
}
在这个方法中又调用了ActivityStack自身的completePauseLocked方法，
# com.android.server.am.ActivityStack
private void completePauseLocked(boolean resumeNext, ActivityRecord resuming) {
ActivityRecord prev = mPausingActivity;
if (resumeNext) {
final ActivityStack topStack = mStackSupervisor.getFocusedStack();
if (!mService.isSleepingOrShuttingDownLocked()) {
mStackSupervisor.resumeFocusedStackTopActivityLocked(topStack, prev, null);
} else {
...
}
}
...
}
然后又调用了ActivityStackSupervisor的resumeFocusedStackTopActivityLocked方法，这视乎又重新调用了一遍，真复杂啊。
这个流程我们上面讲过了，ActivityStackSupervisor会继续调用ActivityStack的resumeTopActivityUncheckedLocked方法，然后ActivityStack又调用其resumeTopActivityInnerLocked方法，调来调去，又到这个方法里面了，上次在这里是执行了前一个Activity的onPause方法。
这次会调用到ActivityStackSupersivor的startSpecificActivityLocked方法。
# com.android.server.am.ActivityStack
private boolean resumeTopActivityInnerLocked(ActivityRecord prev, ActivityOptions options) {
// We need to start pausing the current activity so the top one can be resumed...
final boolean dontWaitForPause = (next.info.flags & FLAG_RESUME_WHILE_PAUSING) != 0;
boolean pausing = mStackSupervisor.pauseBackStacks(userLeaving, next, dontWaitForPause);
if (mResumedActivity != null) {
if (DEBUG_STATES) Slog.d(TAG_STATES,
"resumeTopActivityLocked: Pausing " + mResumedActivity);
pausing |= startPausingLocked(userLeaving, false, next, dontWaitForPause);
}
...
ActivityStack lastStack = mStackSupervisor.getLastStack();
if (next.app != null && next.app.thread != null) {
...
} else {
...
mStackSupervisor.startSpecificActivityLocked(next, true, true);
}
if (DEBUG_STACK) mStackSupervisor.validateTopActivitiesLocked();
return true;
}
分析到这里，好像我们的就要开始启动我们的目标Activity了，好激动有木有！
在ActivityStackSupersivor的startSpecificActivityLocked 方法中会判断Activity所在进程是否存在，如果不存在的话就要创建一个新的进程。
在这里，我们是Activity启动其App内部的另一个Activity，所以进程肯定是存在的，会走到realStartActivityLocked方法中。
# com.android.server.am.ActivityStackSupervisor
void startSpecificActivityLocked(ActivityRecord r, boolean andResume, boolean checkConfig) {
...
if (app != null && app.thread != null) {
try {
...
realStartActivityLocked(r, app, andResume, checkConfig);
return;
} catch (RemoteException e) {
...
}
}
mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0,
"activity", r.intent.getComponent(), false, false, true);
}
再来看一下ActivityStackSupersivor的realStartActivityLocked方法，这次似乎真的要启动一个Activity了。
# com.android.server.am.ActivityStackSupervisor
final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app,
boolean andResume, boolean checkConfig) throws RemoteException {
...
try {
app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken,
System.identityHashCode(r), r.info, new Configuration(mService.mConfiguration),
new Configuration(task.mOverrideConfig), r.compat, r.launchedFromPackage,
task.voiceInteractor, app.repProcState, r.icicle, r.persistentState, results,
newIntents, !andResume, mService.isNextTransitionForward(), profilerInfo);
...
} catch (RemoteException e) {
...
}
...
return true;
}
看了代码，果然，调用了app.thread.scheduleLaunchActivity方法，app.thread我们前面讲过，就是IApplicationThread对象，实际上就是ApplicationThreadProxy对象，经过IPC过程会调用到ApplicationThread的scheduleLaunchActivity方法，我们来看一下：
# android.app.ActivityThread$$ApplicationThread
@Override
public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
ActivityInfo info, Configuration curConfig, Configuration overrideConfig,
CompatibilityInfo compatInfo, String referrer, IVoiceInteractor voiceInteractor,
int procState, Bundle state, PersistableBundle persistentState,
List<ResultInfo> pendingResults, List<ReferrerIntent> pendingNewIntents,
boolean notResumed, boolean isForward, ProfilerInfo profilerInfo) {
...
sendMessage(H.LAUNCH_ACTIVITY, r);
}
通过Hander的转发，接着会调用到ActivityThread的handlePauseActivity方法。
# android.app.ActivityThread
private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent, String reason) {
...
Activity a = performLaunchActivity(r, customIntent);
if (a != null) {
...
handleResumeActivity(r.token, false, r.isForward,
!r.activity.mFinished && !r.startsNotResumed, r.lastProcessedSeq, reason);
...
} else {
...
}
}
handlePauseActivity内部调用performLaunchActivity方法：
# android.app.ActivityThread
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
...
Activity activity = null;
try {
java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
activity = mInstrumentation.newActivity( cl, component.getClassName(), r.intent);
...
} catch (Exception e) {
...
}
try {
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
...
if (activity != null) {
Context appContext = createBaseContextForActivity(r, activity);
...
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor, window);
...
activity.mCalled = false;
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
...
r.activity = activity;
r.stopped = true;
if (!r.activity.mFinished) {
activity.performStart();
r.stopped = false;
}
if (!r.activity.mFinished) {
if (r.isPersistable()) {
if (r.state != null || r.persistentState != null) {
mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state,
r.persistentState);
}
} else if (r.state != null) {
mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state);
}
}
if (!r.activity.mFinished) {
activity.mCalled = false;
if (r.isPersistable()) {
mInstrumentation.callActivityOnPostCreate(activity, r.state,
r.persistentState);
} else {
mInstrumentation.callActivityOnPostCreate(activity, r.state);
}
if (!activity.mCalled) {
throw new SuperNotCalledException(
"Activity " + r.intent.getComponent().toShortString() +
" did not call through to super.onPostCreate()");
}
}
}
r.paused = true;
mActivities.put(r.token, r);
} catch (SuperNotCalledException e) {
throw e;
} catch (Exception e) {
...
}
return activity;
}
在performLaunchActivity内部，创建了Activity对象，并调用了activity的attach方法，在这个方法中绑定一些属性，并且创建了Activity所属的Window对象。
接着Instrumentation会调用callActivityOnCreate、callActivityOnRestoreInstanceState、callActivityOnPostCreate等来完成Activity生命周期的回调。
不过有一点很有意思，在这个方法中Activity自己调用了其performStart方法，但这个方法内部又调用了Instrumentation的callActivityOnStart方法，进而又调用了Activity的onStart方法。绕过来绕过去，总之，Activity生命周期方法的调用均是通过Instrumentation来控制的。
至此，Activity的启动过程算是分析完了，太费脑筋了。流程太多但是有句话说的好 "一图胜千言"，
下面我们来看一下Activity启动的一个时序图。
