首先我们看看根activity的启动流程，也就是点击桌面图标时启动的activity。 为了方便起见我们先大致看一下启动的时序图
public boolean startActivitySafely(View v, Intent intent, ItemInfo item) {
boolean success = super.startActivitySafely(v, intent, item);
...
return success;
}
其实就是调用父类的这个方法，它的父类为BaseDraggingActivity，我们接着看这个类中的startActivitySafely方法
public boolean startActivitySafely(View v, Intent intent, ItemInfo item) {
// Prepare intent
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
if (v != null) {
intent.setSourceBounds(getViewBounds(v));
}
try {
...
// Could be launching some bookkeeping activity
startActivity(intent, optsBundle);
getUserEventDispatcher().logAppLaunch(v, intent);
return true;
}
...
return false;
}
可以看到这里其实就是调用了Activity中的startActivity，并且将这个Activity的启动模式标记为NEW_TASK，这样新启动的Activity就会在一个新的任务栈中。那就接着看Activity中的这个方法，在Activity中最终会调用startActivityForResult
public void startActivityForResult(@RequiresPermission Intent intent, int requestCode,
@Nullable Bundle options) {
if (mParent == null) {
options = transferSpringboardActivityOptions(options);
Instrumentation.ActivityResult ar =
mInstrumentation.execStartActivity(
this, mMainThread.getApplicationThread(), mToken, this,
intent, requestCode, options);
...
}}}
可以看到这里调用了Instrumentation中的execStartActivity方法
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode, Bundle options) {
...
int result = ActivityManager.getService()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
...
return null;
}
这里真正起作用的就是上面这段，就是调用ActivityManager.getService中的startActivity方法，我们先来看看这个getService
public static IActivityManager getService() {
return IActivityManagerSingleton.get();
}
private static final Singleton<IActivityManager> IActivityManagerSingleton =
new Singleton<IActivityManager>() {
@Override
protected IActivityManager create() {
final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
final IActivityManager am = IActivityManager.Stub.asInterface(b);
return am;
}
};
其实就是为了与ActivityManagerService通信，这里相当于客户端，通过getService获取名为“activity”的IBinder类型的AMS引用，而为什么说它是ActivityManagerService通信呢，看他的定义就知道了
@Override
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());
}
它调用了本身的startActivityAsUser方法
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,
boolean validateIncomingUser) {
enforceNotIsolatedCaller("startActivity");
userId = mActivityStartController.checkTargetUser(userId, validateIncomingUser,
Binder.getCallingPid(), Binder.getCallingUid(), "startActivityAsUser");
// TODO: Switch to user app stacks here.
return mActivityStartController.obtainStarter(intent, "startActivityAsUser")
.setCaller(caller)
.setCallingPackage(callingPackage)
.setResolvedType(resolvedType)
.setResultTo(resultTo)
.setResultWho(resultWho)
.setRequestCode(requestCode)
.setStartFlags(startFlags)
.setProfilerInfo(profilerInfo)
.setActivityOptions(bOptions)
.setMayWait(userId)
.execute();
}
这里的重点其实就是return中的方法，首先通过mActivityStartController.obtain获取一个ActivityStarter并且通过set方法来构造这个starter，最终执行它的execute方法。
int execute() {
try {
// TODO(b/64750076): Look into passing request directly to these methods to allow
// for transactional diffs and preprocessing.
if (mRequest.mayWait) {
return startActivityMayWait(mRequest.caller, mRequest.callingUid,
mRequest.callingPackage, mRequest.intent, mRequest.resolvedType,
mRequest.voiceSession, mRequest.voiceInteractor, mRequest.resultTo,
mRequest.resultWho, mRequest.requestCode, mRequest.startFlags,
mRequest.profilerInfo, mRequest.waitResult, mRequest.globalConfig,
mRequest.activityOptions, mRequest.ignoreTargetSecurity, mRequest.userId,
mRequest.inTask, mRequest.reason,
mRequest.allowPendingRemoteAnimationRegistryLookup);
} else {
return startActivity(mRequest.caller, mRequest.intent, mRequest.ephemeralIntent,
mRequest.resolvedType, mRequest.activityInfo, mRequest.resolveInfo,
mRequest.voiceSession, mRequest.voiceInteractor, mRequest.resultTo,
mRequest.resultWho, mRequest.requestCode, mRequest.callingPid,
mRequest.callingUid, mRequest.callingPackage, mRequest.realCallingPid,
mRequest.realCallingUid, mRequest.startFlags, mRequest.activityOptions,
mRequest.ignoreTargetSecurity, mRequest.componentSpecified,
mRequest.outActivity, mRequest.inTask, mRequest.reason,
mRequest.allowPendingRemoteAnimationRegistryLookup);
}
} finally {
onExecutionComplete();
}
}
接着看这个startActivityMayWait方法 private int startActivityMayWait(IApplicationThread caller, int callingUid,
final ActivityRecord[] outRecord = new ActivityRecord[1];
int res = startActivity(caller, intent, ephemeralIntent, resolvedType, aInfo, rInfo,
voiceSession, voiceInteractor, resultTo, resultWho, requestCode, callingPid,
callingUid, callingPackage, realCallingPid, realCallingUid, startFlags, options,
ignoreTargetSecurity, componentSpecified, outRecord, inTask, reason,
allowPendingRemoteAnimationRegistryLookup);
...
mSupervisor.getActivityMetricsLogger().notifyActivityLaunched(res, outRecord[0]);
return res;
}
}
这个方法中实际起作用的的就是调用了该类（ActivityStarter）中的startActivity方法，不过最终都会调用下面形式的startActivity方法
private int startActivity(final ActivityRecord r, ActivityRecord sourceRecord,
IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
int startFlags, boolean doResume, ActivityOptions options, TaskRecord inTask,
ActivityRecord[] outActivity) {
int result = START_CANCELED;
try {
mService.mWindowManager.deferSurfaceLayout();
result = startActivityUnchecked(r, sourceRecord, voiceSession, voiceInteractor,
startFlags, doResume, options, inTask, outActivity);
} ...
return result;
}
可以看到真正起作用的就是这个startActivityUnchecked方法
private int startActivityUnchecked(final ActivityRecord r, ActivityRecord sourceRecord,
IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
int startFlags, boolean doResume, ActivityOptions options, TaskRecord inTask,
ActivityRecord[] outActivity) {
...
// Should this be considered a new task?
int result = START_SUCCESS;
if (mStartActivity.resultTo == null && mInTask == null && !mAddingToTask
&& (mLaunchFlags & FLAG_ACTIVITY_NEW_TASK) != 0) {
newTask = true;
result = setTaskFromReuseOrCreateNewTask(taskToAffiliate, topStack);
...
else {
...
mSupervisor.resumeFocusedStackTopActivityLocked(mTargetStack, mStartActivity,
mOptions);
}
} ...
}
这个方法首先会判断是否需要建立新的任务栈，因为之前已经设置了NEW_TASK所以这里会调用setTaskFromReuseOrCreateNewTask方法，最终调用resumeFocusedStackTopActivityLocked方法，这个方法是在ActivityStackSuperVisor这个类中
boolean resumeFocusedStackTopActivityLocked(
ActivityStack targetStack, ActivityRecord target, ActivityOptions targetOptions) {
if (!readyToResume()) {
return false;
}
if (targetStack != null && isFocusedStack(targetStack)) {
return targetStack.resumeTopActivityUncheckedLocked(target, targetOptions);
}
final ActivityRecord r = mFocusedStack.topRunningActivityLocked();
if (r == null || !r.isState(RESUMED)) {
mFocusedStack.resumeTopActivityUncheckedLocked(null, null);
} else if (r.isState(RESUMED)) {
// Kick off any lingering app transitions form the MoveTaskToFront operation.
mFocusedStack.executeAppTransition(targetOptions);
}
return false;
}
在这里首先是根据topRunningActivityLocked来判断想要启动的这个Activity的任务栈的栈顶的不是处于停止状态的ActivityRecord，如果这个record为null则会执行resumeTopActivityUncheckedLocked方法，显然对于根Activity来说这个是值为null，所以接着看这个方法，这个方法是在ActivityStack中
/**
* Ensure that the top activity in the stack is resumed.
*/
@GuardedBy("mService")
boolean resumeTopActivityUncheckedLocked(ActivityRecord prev, ActivityOptions options) {
if (mStackSupervisor.inResumeTopActivity) {
return false;
}
boolean result = false;
try {
// Protect against recursion.
mStackSupervisor.inResumeTopActivity = true;
result = resumeTopActivityInnerLocked(prev, options);
...
}
} ...
return result;
}
根据注释可以看出这个方法是确保任务栈栈顶的Activity已恢复，这个方法的核心则是调用了这个类中的resumeTopActivityInnerLocked
private boolean resumeTopActivityInnerLocked(ActivityRecord prev, ActivityOptions options) {
// If the top activity is the resumed one, nothing to do.
if (mResumedActivity == next && next.isState(RESUMED)
&& mStackSupervisor.allResumedActivitiesComplete()) {
// Make sure we have executed any pending transitions, since there
// should be nothing left to do at this point.
executeAppTransition(options);
if (DEBUG_STATES) Slog.d(TAG_STATES,
"resumeTopActivityLocked: Top activity resumed " + next);
if (DEBUG_STACK) mStackSupervisor.validateTopActivitiesLocked();
return false;
}
...
// If the flag RESUME_WHILE_PAUSING is set, then continue to schedule the previous activity
// to be paused, while at the same time resuming the new resume activity only if the
final boolean resumeWhilePausing = (next.info.flags & FLAG_RESUME_WHILE_PAUSING) != 0
&& !lastResumedCanPip;
boolean pausing = mStackSupervisor.pauseBackStacks(userLeaving, next, false);
if (mResumedActivity != null) {
if (DEBUG_STATES) Slog.d(TAG_STATES,
"resumeTopActivityLocked: Pausing " + mResumedActivity);
pausing |= startPausingLocked(userLeaving, false, next, false);
}
...
mStackSupervisor.startSpecificActivityLocked(next, true, true);
...
return true;
}
从注释中也可以看出来，这个方法是先判断栈顶已经resume的Activity是不是要启动的，是的话就return，不是的话会将栈顶的Activity schedule to be paused，这也说明了Activity A启动另一个Activity B时，A先pause然后才走B的创建周期，这里的startPausingLocked则是真正的执行将栈顶activity生命周期置为pause的，至于这个我们稍后再说。这里真正启动Activity的是startSpecificActivityLocked方法，这个类在ActivityStackSuperVisor中
void startSpecificActivityLocked(ActivityRecord r,
boolean andResume, boolean checkConfig) {
ProcessRecord app = mService.getProcessRecordLocked(r.processName,
r.info.applicationInfo.uid, true);
getLaunchTimeTracker().setLaunchTime(r);
if (app != null && app.thread != null) {
try {
if ((r.info.flags&ActivityInfo.FLAG_MULTIPROCESS) == 0
|| !"android".equals(r.info.packageName)) {
// Don't add this if it is a platform component that is marked
// to run in multiple processes, because this is actually
// part of the framework so doesn't make sense to track as a
// separate apk in the process.
app.addPackage(r.info.packageName, r.info.applicationInfo.longVersionCode,
mService.mProcessStats);
}
realStartActivityLocked(r, app, andResume, checkConfig);
return;
} catch (RemoteException e) {
Slog.w(TAG, "Exception when starting activity "
+ r.intent.getComponent().flattenToShortString(), e);
}
// If a dead object exception was thrown -- fall through to
// restart the application.
}
mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0,
"activity", r.intent.getComponent(), false, false, true);
}
他首选是获取了一个ProcessRecord，也就是即将启动activity所在的应用进程，如果进程已运行的话会调动realStartActivityLocked方法，这个方法也在ActivityStackSuperVisor中
final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app,
boolean andResume, boolean checkConfig) throws RemoteException {
if (!allPausedActivitiesComplete()) {
// While there are activities pausing we skipping starting any new activities until
// pauses are complete. NOTE: that we also do this for activities that are starting in
// the paused state because they will first be resumed then paused on the client side.
if (DEBUG_SWITCH || DEBUG_PAUSE || DEBUG_STATES) Slog.v(TAG_PAUSE,
"realStartActivityLocked: Skipping start of r=" + r
+ " some activities pausing...");
return false;
}
...
// Create activity launch transaction.
final ClientTransaction clientTransaction = ClientTransaction.obtain(app.thread,
r.appToken);
clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
System.identityHashCode(r), r.info,
// TODO: Have this take the merged configuration instead of separate global
// and override configs.
mergedConfiguration.getGlobalConfiguration(),
mergedConfiguration.getOverrideConfiguration(), r.compat,
r.launchedFromPackage, task.voiceInteractor, app.repProcState, r.icicle,
r.persistentState, results, newIntents, mService.isNextTransitionForward(),
profilerInfo));
// Set desired final state.
final ActivityLifecycleItem lifecycleItem;
if (andResume) {
lifecycleItem = ResumeActivityItem.obtain(mService.isNextTransitionForward());
} else {
lifecycleItem = PauseActivityItem.obtain();
}
clientTransaction.setLifecycleStateRequest(lifecycleItem);
// Schedule transaction.
mService.getLifecycleManager().scheduleTransaction(clientTransaction);
...
return true;
}
这个方法首先确定了栈顶Activity必须pause以后才进行接下来的创建。最关键的地方则是他构建了一个ClientTransaction，这个类包含一系列消息的容器，可以将消息发送给客户端。 这包括回调列表和最终生命周期状态。 我们可以看到在给这个类添加回调的时候构造了一个LaunchActivityItem,，而且它的lifecycleItem为ResumActivityItem,这两个个我们稍后会用到。构造完之后我们就用到了这里的mService.getLifecycleManager().scheduleTransaction。这里其实就是调用了ClientLifecycleManager中的scheduleTransaction方法
void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
final IApplicationThread client = transaction.getClient();
transaction.schedule();
...
}
这里其实就是调用了ClientTransaction中的schedule方法
/**
* Schedule the transaction after it was initialized. It will be send to client and all its
* individual parts will be applied in the following sequence:
* 1. The client calls {@link #preExecute(ClientTransactionHandler)}, which triggers all work
* that needs to be done before actually scheduling the transaction for callbacks and
* lifecycle state request.
* 2. The transaction message is scheduled.
* 3. The client calls {@link TransactionExecutor#execute(ClientTransaction)}, which executes
* all callbacks and necessary lifecycle transitions.
*/
public void schedule() throws RemoteException {
mClient.scheduleTransaction(this);
}
其实就是调用了mClient中的scheduleTransaction方法，这里的mClient是IApplicationThread，也就是ApplicationThread这个类中的这个方法，它是ActivityThread中的内部类
@Override
public void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
ActivityThread.this.scheduleTransaction(transaction);
}
可以看到ApplicationThread中的这个方法直接调用ActivityThread中的这个方法，而ActivityThread中并没有这个方法，但是它继承了ClientTransactionHandler，那么就去这个类中看看
void scheduleTransaction(ClientTransaction transaction) {
transaction.preExecute(this);
sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
}
可以看到他先执行了transaction.preExecute方法，也就是做一些准备工作，这个在上面schedule的注释上已经写了调用步骤。然后向消息队列中添加了一条消息，消息的what值为ActivityThread.H.EXECUTE_TRANSACTION，我们知道消息的处理是在主线程上也就是ActivityThread上，那么我们就看看它接到这条消息后做了什么
case EXECUTE_TRANSACTION:
final ClientTransaction transaction = (ClientTransaction) msg.obj;
mTransactionExecutor.execute(transaction);
if (isSystem()) {
// Client transactions inside system process are recycled on the client side
// instead of ClientLifecycleManager to avoid being cleared before this
// message is handled.
transaction.recycle();
}
// TODO(lifecycler): Recycle locally scheduled transactions.
break;
在handleMessage这个方法其中一个分支如上，也就是拿到了这个Transaction后调用了mTransactionExecutor.execute方法，也就是TransactionExecutor中的execute方法
public void execute(ClientTransaction transaction) {
final IBinder token = transaction.getActivityToken();
log("Start resolving transaction for client: " + mTransactionHandler + ", token: " + token);
executeCallbacks(transaction);
executeLifecycleState(transaction);
mPendingActions.clear();
log("End resolving transaction");
}
这里首先执行了executeCallbacks，然后执行executeLifecycleState。我们分别看一下这两个方法。
public void executeCallbacks(ClientTransaction transaction) {
final List<ClientTransactionItem> callbacks = transaction.getCallbacks();
...
final int size = callbacks.size();
for (int i = 0; i < size; ++i) {
final ClientTransactionItem item = callbacks.get(i);
log("Resolving callback: " + item);
...
item.execute(mTransactionHandler, token, mPendingActions);
item.postExecute(mTransactionHandler, token, mPendingActions);
...
}
}
这里最关键的其实就是这个item.execute和item.postExecute。之前我们在构造Transaction的callback时我们传入的是LaunchActivityItem，所以这里的这两个方法其实就是LaunchActivityItem中的这两个方法，
@Override
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
ActivityClientRecord r = new ActivityClientRecord(token, mIntent, mIdent, mInfo,
mOverrideConfig, mCompatInfo, mReferrer, mVoiceInteractor, mState, mPersistentState,
mPendingResults, mPendingNewIntents, mIsForward,
mProfilerInfo, client);
client.handleLaunchActivity(r, pendingActions, null /* customIntent */);
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
其实就是执行了handleLaunchActivity，而这个方法是在ClientTransactionHandler中，这个类是个抽象类，而前面提到过ActivityThread继承了这个类，所以这个handleLaunchActivity其实是ActivityThread中的方法
public Activity handleLaunchActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions, Intent customIntent) {
...
final Activity a = performLaunchActivity(r, customIntent);
...
return a;
}
这个方法中需要关注的就这一个方法，也在ActivityThread中
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
...
ContextImpl appContext = createBaseContextForActivity(r);
...
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
...
appContext.setOuterContext(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, r.configCallback);
...
activity.mCalled = false;
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
r.activity = activity;
}
r.setState(ON_CREATE);
mActivities.put(r.token, r);
...
return activity;
}
这里首先会调用createBaseContextForActivity来创建一个ContextImpl对象，然后会调用makeApplication来创建一个Application，接着调用setOuterContext方法将这个activity赋值给ContextImpl中的mOuterContext变量，这样ContextImpl也可以访问activity中的变量和方法。在而调用activity的attach方法做了一些初始化工作。
final void attach(Context context, ActivityThread aThread,
Instrumentation instr, IBinder token, int ident,
Application application, Intent intent, ActivityInfo info,
CharSequence title, Activity parent, String id,
NonConfigurationInstances lastNonConfigurationInstances,
Configuration config, String referrer, IVoiceInteractor voiceInteractor,
Window window, ActivityConfigCallback activityConfigCallback) {
attachBaseContext(context);
mFragments.attachHost(null /*parent*/);
mWindow = new PhoneWindow(this, window, activityConfigCallback);
mWindow.setWindowControllerCallback(this);
mWindow.setCallback(this);
mWindow.setOnWindowDismissedCallback(this);
mWindow.getLayoutInflater().setPrivateFactory(this);
if (info.softInputMode != WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) {
mWindow.setSoftInputMode(info.softInputMode);
}
if (info.uiOptions != 0) {
mWindow.setUiOptions(info.uiOptions);
}
mUiThread = Thread.currentThread();
mMainThread = aThread;
mInstrumentation = instr;
mToken = token;
mIdent = ident;
mApplication = application;
mIntent = intent;
mReferrer = referrer;
mComponent = intent.getComponent();
mActivityInfo = info;
mTitle = title;
mParent = parent;
mEmbeddedID = id;
mLastNonConfigurationInstances = lastNonConfigurationInstances;
if (voiceInteractor != null) {
if (lastNonConfigurationInstances != null) {
mVoiceInteractor = lastNonConfigurationInstances.voiceInteractor;
} else {
mVoiceInteractor = new VoiceInteractor(voiceInteractor, this, this,
Looper.myLooper());
}
}
mWindow.setWindowManager(
(WindowManager)context.getSystemService(Context.WINDOW_SERVICE),
mToken, mComponent.flattenToString(),
(info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);
if (mParent != null) {
mWindow.setContainer(mParent.getWindow());
}
mWindowManager = mWindow.getWindowManager();
mCurrentConfig = config;
mWindow.setColorMode(info.colorMode);
setAutofillCompatibilityEnabled(application.isAutofillCompatibilityEnabled());
enableAutofillCompatibilityIfNeeded();
}
可以看到这里创建了PhoneWindow并为其添加了callback，windowManager等，比如常用的onAttachToWindow等方法都是这个callback中的，而view的事件分发也是通过phoneWindow转发给activity的。而一开始的attachBaseContext，其实就是将ContextWrapper中的mBase变量赋值为刚刚创建的这个ContextImpl。上面我们还提到，在创建完activity的context之后，又创建了Application。他是调用的LoadedApk中的makeApplication方法
public Application makeApplication(boolean forceDefaultAppClass,
Instrumentation instrumentation) {
if (mApplication != null) {
return mApplication;
}
...
Application app = null;
String appClass = mApplicationInfo.className;
if (forceDefaultAppClass || (appClass == null)) {
appClass = "android.app.Application";
}
try {
...
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);
appContext.setOuterContext(app);
} ...
mApplication = app;
if (instrumentation != null) {
try {
instrumentation.callApplicationOnCreate(app);
}
...
return app;
}
可以看到这里首先会判断本地变量Application是否为空，不为空直接返回，为空则创建，所以一个APP的Application只有一个。为空的话就调用Instrumentation中的newApplication方法创建一个Application，在这个newApplication中会调用它的attach方法
public Application newApplication(ClassLoader cl, String className, Context context)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
Application app = getFactory(context.getPackageName())
.instantiateApplication(cl, className);
app.attach(context);
return app;
}
紧接着利用创建好的Application调用它的onCreate，当然是利用callApplicationOnCreate方法，下面我们依次看看它的attach方法和callApplicationOnCreate方法
final void attach(Context context) {
attachBaseContext(context);
mLoadedApk = ContextImpl.getImpl(context).mPackageInfo;
其实就是把ContextWrapper中的Context类型的mBase赋值为这个Application。
public void callApplicationOnCreate(Application app) {
app.onCreate();
}
至此Application的创建也完成了。 最后则是调用了Instrumentation中的callActivityOnCreate方法，当然是两个参数的
public void callActivityOnCreate(Activity activity, Bundle icicle) {
prePerformCreate(activity);
activity.performCreate(icicle);
postPerformCreate(activity);
}
这里执行创建操作的则是activity.performCreate，它位于Activity中
final void performCreate(Bundle icicle, PersistableBundle persistentState) {
mCanEnterPictureInPicture = true;
restoreHasCurrentPermissionRequest(icicle);
if (persistentState != null) {
onCreate(icicle, persistentState);
} else {
onCreate(icicle);
}
writeEventLog(LOG_AM_ON_CREATE_CALLED, "performCreate");
mActivityTransitionState.readState(icicle);
mVisibleFromClient = !mWindow.getWindowStyle().getBoolean(
com.android.internal.R.styleable.Window_windowNoDisplay, false);
mFragments.dispatchActivityCreated();
mActivityTransitionState.setEnterActivityOptions(this, getActivityOptions());
}
可以看到它调用了Activity的onCreate方法并且调用了mFragments.dispatchActivityCreated()其实就是fragmentManager中的这个方法
public void dispatchActivityCreated() {
mStateSaved = false;
dispatchMoveToState(Fragment.ACTIVITY_CREATED);
}
所以添加在Activity上的fragment最先执行的是onActivityCreated，至此整个根Activity启动流程就结束了。还有一个方法我们没有看，那就是 executeLifecycleState(transaction);
private void executeLifecycleState(ClientTransaction transaction) {
final ActivityLifecycleItem lifecycleItem = transaction.getLifecycleStateRequest();
if (lifecycleItem == null) {
// No lifecycle request, return early.
return;
}
log("Resolving lifecycle state: " + lifecycleItem);
final IBinder token = transaction.getActivityToken();
final ActivityClientRecord r = mTransactionHandler.getActivityClient(token);
if (r == null) {
// Ignore requests for non-existent client records for now.
return;
}
// Cycle to the state right before the final requested state.
cycleToPath(r, lifecycleItem.getTargetState(), true /* excludeLastState */);
// Execute the final transition with proper parameters.
lifecycleItem.execute(mTransactionHandler, token, mPendingActions);
lifecycleItem.postExecute(mTransactionHandler, token, mPendingActions);
}
在上面构造Transaction的时候，这个lifecycleItem我们传入的是ResumeActivityItem，所以它执行的是这里的execute和postExecute方法，那就看看这个类中的这两个方法 先来看它的execute方法
@Override
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityResume");
client.handleResumeActivity(token, true /* finalStateRequest */, mIsForward,
"RESUME_ACTIVITY");
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
通过上面我们介绍了解到这里的client其实就是ActivityThread
public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,
String reason) {
// If we are getting ready to gc after going to the background, well
// we are back active so skip it.
unscheduleGcIdler();
mSomeActivitiesChanged = true;
// TODO Push resumeArgs into the activity for consideration
final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
...
}
它又调用了本身的performResumeActivity
public ActivityClientRecord performResumeActivity(IBinder token, boolean finalStateRequest,
String reason) {
final ActivityClientRecord r = mActivities.get(token);
...
r.activity.performResume(r.startsNotResumed, reason);
...
}
return r;
}
这里最重要的其实是调用了Activity中的performResume方法
final void performResume(boolean followedByPause, String reason) {
performRestart(true /* start */, reason);
...
mInstrumentation.callActivityOnResume(this);
...
}
其实这里面最重要的就这两行，根据字面意思也能看出来，就是调用Restart和Resume，到低是不是则继续看看，首先是第一行
final void performRestart(boolean start, String reason) {
...
if (start) {
performStart(reason);
}
}
}
由于我们刚才传入的是true，所以会执行performStart方法
final void performStart(String reason) {
...
mInstrumentation.callActivityOnStart(this);
...
}
可以看到这里调用了Instrumentation中的callActivityOnStart方法
public void callActivityOnStart(Activity activity) {
activity.onStart();
}
它直接调用了activity的onStart方法。所以上面第一个方法就完事了。那么再看看上面说的第二个方法，也就是Instrumentation中的callActivityOnResume
public void callActivityOnResume(Activity activity) {
activity.mResumed = true;
activity.onResume();
...
}
可以看到这里调用了activity的resume方法。至此根activity的启动流程就分析完毕了。对于普通activity的启动，那么根据之前的了解，如果从跟activity启动一个新的activity名为A，那么这个根activity首先会进入pause状态，然后才是A的onCreate、onStart、onResume等，那么这个根activity又是什么时候进入的pause呢。上面我们提到过，启动Activity时会调用ActivityStack中的resumeTopActivityInnerLocked方法，之前的分析中说过执行pause所使用的就是这方法中的startPausingLocked，那我们就从这个方法继续往下看
final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping,
ActivityRecord resuming, boolean pauseImmediately) {
...
try {
EventLogTags.writeAmPauseActivity(prev.userId, System.identityHashCode(prev),
prev.shortComponentName, "userLeaving=" + userLeaving);
mService.updateUsageStats(prev, false);
mService.getLifecycleManager().scheduleTransaction(prev.app.thread, prev.appToken,
PauseActivityItem.obtain(prev.finishing, userLeaving,
prev.configChangeFlags, pauseImmediately));
}
...
}
可以看到，这里是直接调用了ClientLifecycleManager中的scheduleTransaction方法，只不过传入的为PauseActivityItem，到这里剩下的就同之前的创建流程是一样的，最终会调用ExecutionHandler中的execute方法，我们再看一下这个方法
public void execute(ClientTransaction transaction) {
final IBinder token = transaction.getActivityToken();
log("Start resolving transaction for client: " + mTransactionHandler + ", token: " + token);
executeCallbacks(transaction);
executeLifecycleState(transaction);
mPendingActions.clear();
log("End resolving transaction");
}
其实就是两个execute方法，前面我们已经分析过了，第一个会执行ClientTransactionItem的execute方法，这里我们传入的是PauseActivityItem，那我们就来看看它的execute方法
@Override
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityPause");
client.handlePauseActivity(token, mFinished, mUserLeaving, mConfigChanges, pendingActions,
"PAUSE_ACTIVITY_ITEM");
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
也就是执行ActivityThread中的handlePauseActivity
@Override
public void handlePauseActivity(IBinder token, boolean finished, boolean userLeaving,
int configChanges, PendingTransactionActions pendingActions, String reason) {
...
performPauseActivity(r, finished, reason, pendingActions);
...
}
这里直接调用了该类中的performPauseActivity方法
private Bundle performPauseActivity(ActivityClientRecord r, boolean finished, String reason,
PendingTransactionActions pendingActions) {
...
// Pre-Honeycomb apps always save their state before pausing
final boolean shouldSaveState = !r.activity.mFinished && r.isPreHoneycomb();
if (shouldSaveState) {
callActivityOnSaveInstanceState(r);
}
performPauseActivityIfNeeded(r, reason);
...
return shouldSaveState ? r.state : null;
}
这里的callActivityOnSaveInstanceState其实就是调用onSaveInstance来存储需要保存的内容，然后才会让Activity进入pause状态，也就是performPauseActivityIfNeeded
private void performPauseActivityIfNeeded(ActivityClientRecord r, String reason) {
...
try {
r.activity.mCalled = false;
mInstrumentation.callActivityOnPause(r.activity);
...
}
...
r.setState(ON_PAUSE);
}
这里直接调用了Instrumentation中的callActivityOnPause方法
public void callActivityOnPause(Activity activity) {
activity.performPause();
}
他执行了Activity中的performPause方法
final void performPause() {
...
mFragments.dispatchPause();
mCalled = false;
onPause();
mResumed = false;
...
}
}
可以看到这里调用了Activity的onPause方法，到这里executeCallback流程就结束了，而下一个方法executeLifecycleState方法
private void executeLifecycleState(ClientTransaction transaction) {
final ActivityLifecycleItem lifecycleItem = transaction.getLifecycleStateRequest();
if (lifecycleItem == null) {
// No lifecycle request, return early.
return;
}
...
// Execute the final transition with proper parameters.
lifecycleItem.execute(mTransactionHandler, token, mPendingActions);
lifecycleItem.postExecute(mTransactionHandler, token, mPendingActions);
}
由于我们之前构造这个Transaction时候并没有传入ActivityLifeCycleItem，所以直接就return了，而不会执行下面的execute方法。至此根activity启动Aactivity时，根activity进入onPause状态的流程就分析完了。除此之外我们还知道在Activity A resumed之后根Activity还会调用onStop，这又是在什么地方开始调用的呢。 这里其实是在ActivityStackSuperVisor类中的realStartActivityLocked（前面已经提到过）
final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app,
boolean andResume, boolean checkConfig) throws RemoteException {
...
beginDeferResume();
...
// Create activity launch transaction.
final ClientTransaction clientTransaction = ClientTransaction.obtain(app.thread,
r.appToken);
clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
System.identityHashCode(r), r.info,
// TODO: Have this take the merged configuration instead of separate global
// and override configs.
mergedConfiguration.getGlobalConfiguration(),
mergedConfiguration.getOverrideConfiguration(), r.compat,
r.launchedFromPackage, task.voiceInteractor, app.repProcState, r.icicle,
r.persistentState, results, newIntents, mService.isNextTransitionForward(),
profilerInfo));
// Set desired final state.
final ActivityLifecycleItem lifecycleItem;
if (andResume) {
lifecycleItem = ResumeActivityItem.obtain(mService.isNextTransitionForward());
} else {
lifecycleItem = PauseActivityItem.obtain();
}
clientTransaction.setLifecycleStateRequest(lifecycleItem);
// Schedule transaction.
mService.getLifecycleManager().scheduleTransaction(clientTransaction);
...
} finally {
endDeferResume();
}
...
// TODO(lifecycler): Resume or pause requests are done as part of launch transaction,
// so updating the state should be done accordingly.
if (andResume && readyToResume()) {
// As part of the process of launching, ActivityThread also performs
// a resume.
stack.minimalResumeActivityLocked(r);
}
...
return true;
}
我们再重新梳理一下，首先看beginDeferResume
private void beginDeferResume() {
mDeferResumeCount++;
}
其实就是对一个初始值为0的int类型变量进行++操作， 然后构造一个Transaction，接着就是调用scheduleTransaction方法发送这个Transaction，这里与上面介绍的是一样的。接着看在finally中调用了endDeferResume
private void endDeferResume() {
mDeferResumeCount--;
}
其实就是将刚才自增的1再减回去，紧接着就调用了readyToResume方法
private boolean readyToResume() {
return mDeferResumeCount == 0;
}
就是判断是否回0了，其实就是判断上面的Transaction是否执行完毕，而另一个变量andResume传进来的时候就是true，所以会执行ActivityStack中的minimalResumeActivityLocked
void minimalResumeActivityLocked(ActivityRecord r) {
...
r.setState(RESUMED, "minimalResumeActivityLocked");
r.completeResumeLocked();
mStackSupervisor.getLaunchTimeTracker().setLaunchTime(r);
...
}
可以看到这里调用了ActivityRecord中的completeResumeLocked方法
void completeResumeLocked() {
...
// Schedule an idle timeout in case the app doesn't do it for us.
mStackSupervisor.scheduleIdleTimeoutLocked(this);
...
}
我们点进去看看这个方法是干什么的
void scheduleIdleTimeoutLocked(ActivityRecord next) {
if (DEBUG_IDLE) Slog.d(TAG_IDLE,
"scheduleIdleTimeoutLocked: Callers=" + Debug.getCallers(4));
Message msg = mHandler.obtainMessage(IDLE_TIMEOUT_MSG, next);
mHandler.sendMessageDelayed(msg, IDLE_TIMEOUT);
}
其实就是发送一条消息，它的what为IDLE_TIMEOUT_MSG，那我们看看在handleMessage中是怎么处理的
case IDLE_TIMEOUT_MSG: {
activityIdleInternal((ActivityRecord) msg.obj,
true /* processPausingActivities */);
} break;
继续跟踪
void activityIdleInternal(ActivityRecord r, boolean processPausingActivities) {
synchronized (mService) {
activityIdleInternalLocked(r != null ? r.appToken : null, true /* fromTimeout */,
processPausingActivities, null);
}
}
这里又调用了activityIdleInternal方法
final ActivityRecord activityIdleInternalLocked(final IBinder token, boolean fromTimeout,
boolean processPausingActivities, Configuration config) {
...
// Atomically retrieve all of the other things to do.
final ArrayList<ActivityRecord> stops = processStoppingActivitiesLocked(r,
true /* remove */, processPausingActivities);
NS = stops != null ? stops.size() : 0;
if ((NF = mFinishingActivities.size()) > 0) {
finishes = new ArrayList<>(mFinishingActivities);
mFinishingActivities.clear();
}
...
// Stop any activities that are scheduled to do so but have been
// waiting for the next one to start.
for (int i = 0; i < NS; i++) {
r = stops.get(i);
final ActivityStack stack = r.getStack();
if (stack != null) {
if (r.finishing) {
stack.finishCurrentActivityLocked(r, ActivityStack.FINISH_IMMEDIATELY, false,
"activityIdleInternalLocked");
} else {
stack.stopActivityLocked(r);
}
}
}
// Finish any activities that are scheduled to do so but have been
// waiting for the next one to start.
for (int i = 0; i < NF; i++) {
r = finishes.get(i);
final ActivityStack stack = r.getStack();
if (stack != null) {
activityRemoved |= stack.destroyActivityLocked(r, true, "finish-idle");
}
}
}
}
.....
return r;
}
从这个方法中我们可以看出，它首先找出需要stop的activity ，然后在for循环中逐个取出，如果activity为正在finish则调用finish方法，否则的话调用stopActivityLocked，我们这里并没有将根activity关闭，所以会调用stopActivityLocked方法
final void stopActivityLocked(ActivityRecord r) {
if (r.app != null && r.app.thread != null) {
...
mService.getLifecycleManager().scheduleTransaction(r.app.thread, r.appToken,
StopActivityItem.obtain(r.visible, r.configChangeFlags));
if (shouldSleepOrShutDownActivities()) {
r.setSleeping(true);
}
Message msg = mHandler.obtainMessage(STOP_TIMEOUT_MSG, r);
mHandler.sendMessageDelayed(msg, STOP_TIMEOUT);
...
}
可以看到这里也构建了一个Transaction，并且参数为StopActivityItem，并没有构建ActivityLifecycleItem。接下来就跟pause时候的调用一样，最终会调用StopActivityItem中的execute方法
@Override
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityStop");
client.handleStopActivity(token, mShowWindow, mConfigChanges, pendingActions,
true /* finalStateRequest */, "STOP_ACTIVITY_ITEM");
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
他会调用ActivityThread中的handleStopActivity方法
public void handleStopActivity(IBinder token, boolean show, int configChanges,
PendingTransactionActions pendingActions, boolean finalStateRequest, String reason) {
final ActivityClientRecord r = mActivities.get(token);
r.activity.mConfigChangeFlags |= configChanges;
final StopInfo stopInfo = new StopInfo();
performStopActivityInner(r, stopInfo, show, true /* saveState */, finalStateRequest,
reason);
...
mSomeActivitiesChanged = true;
}
他会调用performStopActivityInner
private void performStopActivityInner(ActivityClientRecord r, StopInfo info, boolean keepShown,
boolean saveState, boolean finalStateRequest, String reason) {
...
if (!keepShown) {
callActivityOnStop(r, saveState, reason);
}
}
}
在上一步我们传入的keepShown为true，所以会执行callActivityOnStop
private void callActivityOnStop(ActivityClientRecord r, boolean saveState, String reason) {
r.state == null
&& !r.isPreHoneycomb();
final boolean isPreP = r.isPreP();
if (shouldSaveState && isPreP) {
callActivityOnSaveInstanceState(r);
}
try {
r.activity.performStop(false /*preserveWindow*/, reason);
}
r.setState(ON_STOP);
if (shouldSaveState && !isPreP) {
callActivityOnSaveInstanceState(r);
}
}
可以看到在Android11之前如果需要保存状态的话那么会在onPause之前直接调用OnSavedInstance，而在28之后则在onStop之前，从28开始则在onStop之后
final void performStop(boolean preserveWindow, String reason) {
...
mFragments.dispatchStop();
mCalled = false;
mInstrumentation.callActivityOnStop(this);
...
}
其实就是调用Instrumentation中的callActivityOnStop方法
public void callActivityOnStop(Activity activity) {
activity.onStop();
}
这里就回调了Activity中的onStop方法，至此整个Activity的启动流程就分析完了。
