当前位置：首页 > news >正文

【Android 13源码分析】Activity生命周期之onCreate,onStart,onResume-2

news 2025/7/7 1:39:00

忽然有一天，我想要做一件事：去代码中去验证那些曾经被“灌输”的理论。

– 服装学院的IT男

本篇已收录于Activity短暂的一生系列
欢迎一起学习讨论Android应用开发或者WMS
V：WJB6995
Q：707409815

正文

在这里插入图片描述

生命周期系列：

Activity生命周期之onPause
onCreate,onStart,onResume-1
onCreate,onStart,onResume-2
Activity生命周期之onStop-1
Activity生命周期之onStop-2
Activity生命周期之onDestory

本篇为"onCreate,onStart,onResume"的第二篇，介绍应用端 onCreate，onStart,onResume 的处理

1. onCreate

onCreate 是一个新 Activity 启动的第一个生命周期。而且根据前面的铺垫，也知道了他是在 onStart 和 onResume 执行的。
对应的事务为 LaunchActivityItem

# LaunchActivityItem@Overridepublic void execute(ClientTransactionHandler client, IBinder token,PendingTransactionActions pendingActions) {// traceTrace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityStart");ActivityClientRecord r = new ActivityClientRecord(token, mIntent, mIdent, mInfo,mOverrideConfig, mCompatInfo, mReferrer, mVoiceInteractor, mState, mPersistentState,mPendingResults, mPendingNewIntents, mActivityOptions, mIsForward, mProfilerInfo,client, mAssistToken, mShareableActivityToken, mLaunchedFromBubble,mTaskFragmentToken);// 应用段处理client.handleLaunchActivity(r, pendingActions, null /* customIntent */);Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);}@Overridepublic void postExecute(ClientTransactionHandler client, IBinder token,PendingTransactionActions pendingActions) {client.countLaunchingActivities(-1);}

完整的调用链如下：

LaunchActivityItem::executeActivityThread::handleLaunchActivityActivityThread::performLaunchActivityInstrumentation::newActivity      --- 创建ActivityActivity::attach                  --- 创建WindowWindow::initWindow::setWindowManagerInstrumentation::callActivityOnCreate  Activity::performCreateActivity::onCreate        --- onCreateActivityClientRecord::setState    --- 设置状态为 ON_CREATE（1）

这部分的代码其实在【Activity启动流程-3】的末尾有解释，单独拎出来再看一遍。

# ActivityThreadpublic Activity handleLaunchActivity(ActivityClientRecord r,PendingTransactionActions pendingActions, Intent customIntent) {......final Activity a = performLaunchActivity(r, customIntent);......}private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {......Activity activity = null;try {// 重点* 1. 通过Instrumentation 反射创建Activityjava.lang.ClassLoader cl = appContext.getClassLoader();activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);......}try {......// 重点* 2. 执行 attach 流程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.activityConfigCallback,r.assistToken, r.shareableActivityToken);if (r.isPersistable()) {mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);} else {重点* 3. OnCreate流程mInstrumentation.callActivityOnCreate(activity, r.state);}// 设置状态为 ON_CREATE（1）r.setState(ON_CREATE);} ............}# Instrumentationpublic void callActivityOnCreate(Activity activity, Bundle icicle) {prePerformCreate(activity);// onCreate流程activity.performCreate(icicle);postPerformCreate(activity);}
# Activityfinal void performCreate(Bundle icicle) {performCreate(icicle, null);}final void performCreate(Bundle icicle, PersistableBundle persistentState) {......if (persistentState != null) {onCreate(icicle, persistentState);} else {// 执行onCreateonCreate(icicle);}// wm_on_create_calledEventLogTags.writeWmOnCreateCalled(mIdent, getComponentName().getClassName(),"performCreate");......}

onCreate 的流程还是比较简单的，在 ActivityThread::performLaunchActivity 做了四件事：

1. 反射创建 Activity 对象
1. 执行 activity.attach，这里会创建Window
1. 执行到 onCreate 生命周期
1. 设置 ActivityClientRecord 中的状态为 ON_CREATE（1）

这里需要留意下会先执行 Activity::attach 来创建Window，然后才是后面的 Activity的onCreate。
创建 Window 的时候会创建 DecorView，有了这个 DecorView 我们在 onCreate 的时候才可以把对应的XML布局设置进去。

2. onStart

onStart 也有其对应的一个事务： StartActivityItem ，我一度以为启动 Activity 的时候也是通过这个事务来触发 onStart 的，但是实际情况我有点意外，它不是通过事务触发的，而是在执行 ResumeActivityItem 前，通过 TransactionExecutor::cycleToPath 触发的。

按下 recent 键再回到 Activity，这个时候onStart 是通过 StartActivityItem 触发的

当前分析 TransactionExecutor::cycleToPath 方法

# TransactionExecutor// 工具类private TransactionExecutorHelper mHelper = new TransactionExecutorHelper();    private void cycleToPath(ActivityClientRecord r, int finish, boolean excludeLastState,ClientTransaction transaction) {// 1. 获取当前ActivityClientRecord的生命周期状态值final int start = r.getLifecycleState();// log if (DEBUG_RESOLVER) {Slog.d(TAG, tId(transaction) + "Cycle activity: "+ getShortActivityName(r.token, mTransactionHandler)+ " from: " + getStateName(start) + " to: " + getStateName(finish)+ " excludeLastState: " + excludeLastState);}// 2. 根据起始状态、结束状态以及是否排除最后一个状态，计算出生命周期状态变化的路径final IntArray path = mHelper.getLifecyclePath(start, finish, excludeLastState);// 3. 按照计算出的生命周期状态路径顺序执行相关操作performLifecycleSequence(r, path, transaction);}

1. 获取到当前 Activity 的生命周期状态，目前是 ON_CREATE 也就是 1
1. 通过工具类计算出生命周期变化的路径，这个路径是啥呢，比如说当前是 ON_CREATE（1），需要到 ON_RESUME（3），那路径就是 [2]
1. 根据第二步计算的路径开始执行各个生命周期

2.1 getLifecyclePath 计算生命周期切换路径

TransactionExecutor::getLifecyclePath 方法完整代码和解释都在下面了，但是我个人建议了解一下即可，大概浏览一下，留意我代码加了1，2，3 这3个重点的地方即可。

# TransactionExecutorHelper// 定义需要经过的生命周期路径，长度为6（毕竟一共也才7个生命周期）@ActivityLifecycleItem.LifecycleStateprivate IntArray mLifecycleSequence = new IntArray(6);// start   ：开始的生命周期状态// finish  ：结束的生命周期状态// excludeLastState ：是否移除最后一个状态public IntArray getLifecyclePath(int start, int finish, boolean excludeLastState) {// 如果开始状态或结束状态未定义，则抛出异常if (start == UNDEFINED || finish == UNDEFINED) {throw new IllegalArgumentException("Can't resolve lifecycle path for undefined state");}// 如果开始状态或结束状态是ON_RESTART，则抛出异常，因为在生命周期中不能以此状态开始或结束if (start == ON_RESTART || finish == ON_RESTART) {throw new IllegalArgumentException("Can't start or finish in intermittent RESTART state");}// 如果结束状态为PRE_ON_CREATE且开始状态不等于结束状态，则抛出异常，只能从预创建状态开始if (finish == PRE_ON_CREATE && start != finish) {throw new IllegalArgumentException("Can only start in pre-onCreate state");}// 重点* 1. 清空用于存储生命周期状态变更序列的集合mLifecycleSequence.clear();// 重点* 2. 分情况计算生命周期状态变更路径 （正常场景）if (finish >= start) {// 如果结束状态大于等于开始状态if (start == ON_START && finish == ON_STOP) {// 特殊情况：从开始到停止状态，无需经过暂停和恢复状态mLifecycleSequence.add(ON_STOP);} else {// 重点* 3. 普通情况：直接将中间的所有状态加入序列 （正常场景）for (int i = start + 1; i <= finish; i++) {mLifecycleSequence.add(i);}}} else { // 结束状态小于开始状态，不能简单地向下循环if (start == ON_PAUSE && finish == ON_RESUME) {// 特殊情况：从暂停直接到恢复状态mLifecycleSequence.add(ON_RESUME);} else if (start <= ON_STOP && finish >= ON_START) {// 开始状态在ON_STOP之前且结束状态在ON_START之后的情况// 先转为停止状态for (int i = start + 1; i <= ON_STOP; i++) {// 添加mLifecycleSequence.add(i);}// 添加mLifecycleSequence.add(ON_RESTART);// 再转到指定结束状态for (int i = ON_START; i <= finish; i++) {mLifecycleSequence.add(i);}} else {// 其他情况：需要重新启动并转到指定状态// 先转到销毁状态for (int i = start + 1; i <= ON_DESTROY; i++) {// 添加mLifecycleSequence.add(i);}// 再转到指定结束状态for (int i = ON_CREATE; i <= finish; i++) {// 添加mLifecycleSequence.add(i);}}}// 如果要求排除最后一个状态并且生命周期序列不为空，则移除最后一个状态if (excludeLastState && mLifecycleSequence.size() != 0) {mLifecycleSequence.remove(mLifecycleSequence.size() - 1);}// 返回计算好的生命周期状态变更序列return mLifecycleSequence;}

根据当前分析的场景，这个方法执行以下3步:

1. 清除集合的数据，避免有脏数据影响结果
1. 当前第一个参数是 ON_CREATE（1）, 第二个参数定义在 ResumeActivityItem 下，返回值是 ON_RESUME（3），满足finish >= start的条件，所以进if语句
1. 走 else 逻辑，最终 mLifecycleSequence 下也就一个元素： 2 ，返回返回

2.2 performLifecycleSequence 切换Activity的生命周期

上一小节计算出需要执行的生命周期路径后，现在就要开始应用了。

# TransactionExecutor// 实际执行在 ActiviThreadprivate ClientTransactionHandler mTransactionHandler;// 构造方法赋值public TransactionExecutor(ClientTransactionHandler clientTransactionHandler) {mTransactionHandler = clientTransactionHandler;}private void performLifecycleSequence(ActivityClientRecord r, IntArray path,ClientTransaction transaction) {// 当前场景就1个元素final int size = path.size();// 开始遍历for (int i = 0, state; i < size; i++) {// 获取到状态，当前就1个元素：ON_START（ 2）state = path.get(i);// 打印logif (DEBUG_RESOLVER) {Slog.d(TAG, tId(transaction) + "Transitioning activity: "+ getShortActivityName(r.token, mTransactionHandler)+ " to state: " + getStateName(state));}switch (state) {......case ON_START:mTransactionHandler.handleStartActivity(r, mPendingActions,null /* activityOptions */);break;......}         }}

mTransactionHandler 在构造 TransactionExecutor 的构造方法赋值，创建对象的地方在 ActivityThread 中，传递的参数是 this，而 ActivityThread 是 ClientTransactionHandler 的子类，也就是说 mTransactionHandler 真正的实现还是在 ActivityThread。

# ActivityThread@Overridepublic void handleStartActivity(ActivityClientRecord r,PendingTransactionActions pendingActions, ActivityOptions activityOptions) {// 拿到 Activityfinal Activity activity = r.activity;......// Start// 重点* 1. 执行onStartactivity.performStart("handleStartActivity");// 2. 更新对应的状态r.setState(ON_START);......// 重点* 3. 更新可见性，参数为trueupdateVisibility(r, true /* show */);mSomeActivitiesChanged = true;......}

一共处理了3件事，其中设置状态的逻辑之前看过了，看看另外2个重点流程。

2.3 onStart 流程

# Activityfinal void performStart(String reason) {......// 执行onStartmInstrumentation.callActivityOnStart(this);// wm_on_start_calledEventLogTags.writeWmOnStartCalled(mIdent, getComponentName().getClassName(), reason);......// Fragment 处理mFragments.dispatchStart();......}# Instrumentationpublic void callActivityOnStart(Activity activity) {activity.onStart();}

到这里 Activity 的 onStart 就执行了。

2.4 设置 View 可见

上一小节先执行到 onStart ，然后会设置 View 的可见性，看一下具体代码

# ActivityThreadprivate void updateVisibility(ActivityClientRecord r, boolean show) {// 拿到DecorViewView v = r.activity.mDecor;if (v != null) {if (show) {if (!r.activity.mVisibleFromServer) {r.activity.mVisibleFromServer = true;mNumVisibleActivities++;if (r.activity.mVisibleFromClient) {// 设置 View 可见 (当前逻辑)r.activity.makeVisible();}}} else {if (r.activity.mVisibleFromServer) {r.activity.mVisibleFromServer = false;mNumVisibleActivities--;// 隐藏Viewv.setVisibility(View.INVISIBLE);}}}}

当前是 onStart 逻辑，也看到了方法传递的参数是 true，说明要设置可见，所以会执行 Activity::makeVisible 逻辑。

# Activityvoid makeVisible() {if (!mWindowAdded) { // 之前setView时已置位trueViewManager wm = getWindowManager();wm.addView(mDecor, getWindow().getAttributes());mWindowAdded = true;}// 设置可见mDecor.setVisibility(View.VISIBLE);}

2.5 onStart 小结

启动一个Activity 执行到 onStart 流程的分析就结束了，完整调用链如下：

TransactionExecutor::cycleToPathTransactionExecutorHelper::getLifecyclePathTransactionExecutor::performLifecycleSequenceClientTransactionHandler::handleStartActivityActivityThread::handleStartActivityActivity::performStart           -- onStartInstrumentation::callActivityOnStartActivity::onStartActivityClientRecord::setState   -- 状态设置为 ON_STARTActivityThread::updateVisibility -- 更新View可见性Activity::makeVisibleView::setVisibility      -- VISIBLE

如果是按多任务键（Recent）再回到 Activity 是会执行 ActivityRecord::makeActiveIfNeeded 来构建 StartActivityItem 事务处理 onStart 流程，但是后续的逻辑还是一样的

我们知道 onStart 和 onStop 是成对的，那 onStart 会执行 View::setVisibility 设置 View 可见，那相对的在 onStop 流程是不是就会设置 View 不可见呢？

这个疑问留到下一篇 onStop 流程解答。

当前还是继续看 onResume 的执行

3. onResume

onResume 对应事务为 ResumeActivityItem

# ResumeActivityItem@Overridepublic void execute(ClientTransactionHandler client, ActivityClientRecord r,PendingTransactionActions pendingActions) {// TraceTrace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityResume");// 应用端处理client.handleResumeActivity(r, true /* finalStateRequest */, mIsForward,"RESUME_ACTIVITY");Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);}@Overridepublic void postExecute(ClientTransactionHandler client, IBinder token,PendingTransactionActions pendingActions) {// TODO(lifecycler): Use interface callback instead of actual implementation.ActivityClient.getInstance().activityResumed(token, client.isHandleSplashScreenExit(token));}@Overridepublic int getTargetState() {return ON_RESUME;}

调用链如下：

ResumeActivityItem::executeActivityThread::handleResumeActivityActivityThread::performResumeActivity   Activity::performResume     Instrumentation::callActivityOnResumeActivity::onResume           -- onResumeActivityClientRecord::setState   -- ON_RESUMEWindowManagerImpl::addView               -- 创建ViewRootImplWindowManagerGlobal::addView   ViewRootImpl::setView            -- 与WMS通信与WMS通信触发窗口的显示逻辑

开始撸代码。

# ActivityThreadpublic void handleResumeActivity(ActivityClientRecord r, boolean finalStateRequest,boolean isForward, String reason) {......// 触发onResumeif (!performResumeActivity(r, finalStateRequest, reason)) {return;}......// 拿到activityfinal Activity a = r.activity;......if (r.window == null && !a.mFinished && willBeVisible) {// 将本地的window设置到activityRecord中r.window = r.activity.getWindow();// 获取DecorViewView decor = r.window.getDecorView();// 设置不可见  在后面调用Activity::makeVisible会设为可见decor.setVisibility(View.INVISIBLE);ViewManager wm = a.getWindowManager();// 获取参数WindowManager.LayoutParams l = r.window.getAttributes();// DecorView设置给Activitya.mDecor = decor;// 设置Activity的windowType,注意这个type，才是应用的窗口类型l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;......if (a.mVisibleFromClient) {if (!a.mWindowAdded) {// 重点：执行addView，并设置mWindowAdded=truea.mWindowAdded = true;wm.addView(decor, l);} else {a.onWindowAttributesChanged(l);}}} else if (!willBeVisible) {if (localLOGV) Slog.v(TAG, "Launch " + r + " mStartedActivity set");r.hideForNow = true;}......r.nextIdle = mNewActivities;mNewActivities = r;// stop 逻辑的触发if (localLOGV) Slog.v(TAG, "Scheduling idle handler for " + r);Looper.myQueue().addIdleHandler(new Idler());}

当前分析 onResume 生命周期，所以只看 performResumeActivity 方法就好。

# ActivityThread@VisibleForTestingpublic boolean performResumeActivity(ActivityClientRecord r, boolean finalStateRequest,String reason) {// logif (localLOGV) {Slog.v(TAG, "Performing resume of " + r + " finished=" + r.activity.mFinished);}......// 触发 onResumer.activity.performResume(r.startsNotResumed, reason);// 设置状态r.setState(ON_RESUME);......}
# Activityfinal void performResume(boolean followedByPause, String reason) {// traceif (Trace.isTagEnabled(Trace.TRACE_TAG_WINDOW_MANAGER)) {Trace.traceBegin(Trace.TRACE_TAG_WINDOW_MANAGER, "performResume:"+ mComponent.getClassName());}......// 主流程mInstrumentation.callActivityOnResume(this);// wm_on_resume_calledEventLogTags.writeWmOnResumeCalled(mIdent, getComponentName().getClassName(), reason);......// Fragments 处理mFragments.dispatchResume();......}

流程和其他的一样，也是先通过 Instrumentation 然后又回到 Activity 处理，然后打印另一个 events 日志。

# Instrumentationpublic void callActivityOnResume(Activity activity) {activity.mResumed = true;activity.onResume();}

4. 总结

SourceActivity 在启动过程中会执行的3个生命周期已经分析完了，当前分析的场景下有以下几个点：

1. 这3个生命周期的执行的连续的，
1. onStart 原来这个场景下不是通过事务执行的
1. 知道了 Activity 生命周期事务跨进程处理方式
1. DecorView 的可见性是在 onStart 设置的
1. 执行 onResume 的时候会触发窗口的添加显示，从严格意义上说，执行 onResume 的时候并不意味着手机屏幕上就有UI数据了。（但是不那么严谨思考的话，正常情况下，onResume 执行了差不多窗口也就显示了）

关于 events 日志的整理如下：

1. wm_restart_activity 的触发在 ActivityTaskSupervisor::realStartActivityLocked 方法构建2个事务的时候，表示 SystemService 端要真正触发 TargetActivity 启动
1. wm_on_create_called 的触发在 Activity::performCreate 方法，表示TargetActivity端执行 onCreate
1. wm_on_start_called 的触发在 Activity::performStart 方法，表示TargetActivity端执行 onStart
1. wm_on_resume_called 的触发在 Activity::performResume 方法，表示TargetActivity端执行 onResume

查看全文

http://www.lryc.cn/news/453665.html