原创 九渝 淘系技术 5月19日
背景
手淘 9.13.0 版本上线后，突然出现了一个首现 crash，废话不多说上堆栈
看起来很普通的一个 crash，报在手淘首页启动的瞬间，但是后续引发了一个很奇怪的问题，这篇文章就对这个问题的记录做一个详细记录。
第一次排查
发现问题后，找到日志做了初步分析，想看到到底是什么场景下会引发这个 crash，先看日志。
上面日志中打印出来了出问题之前的手淘生命周期日志和最后一行发生 crash 时候的堆栈，其中 Welcome 是手淘的欢迎页面，TBMainActivity 是手淘首页（其他的 activity 不是重点，暂时不关注），发现了一个非常奇怪的事情，TBMainActivity 执行了两次 onCreate 生命周期，但是两次生命周期之间却没有执行 onDestory，而 TBMainActivity 的启动模式是 singleTask 的。作为 Android 开发同学来说，Activity 的启动模式再熟悉不过了，当启动一个 Activity 是 singleTask 模式的时候，如果这个 Activity 已经存在栈中，那么行为应该是把该 Activity 之上所有 Activity 都直接清除掉，然后直接复用 Activity，借用网上一张图说明：
看到这个日志的第一反应是线上存在一种特殊情况，手淘会在栈中同时存在两个首页！！
但是抛出结论的时候让否了，因为首页的启动模式很清楚，不可能在一个栈里面存在两个实例，大家都说这里的两个实例应该是在两个栈里面，我也觉得应该是这样，就暂时放弃了这个方向的排查，把排查的重心放在拉起两个首页 crash，而不是为什么拉起了两个首页。
以为自己破案了
连续拉取好几份日志观察之后发现一个共同点，每次发生 crash 之前都是在首页的时候拉起了 welcome 页面，判断是在首页点击 back 按键的时候快速 finish 自己，瞬间用户又点击了 icon 打开了手淘，导致第一个首页还没有 finish 然后又拉起了一个新的，于是在首页 finish 的时候做了保护逻辑，进行了第一次灰度。
过几天观察效果，发现 crash 数量大幅减少，从占比 20% 多降到 6%，终于松了一口气，以为自己破案了。
但是一个周六突然接到了告警电话，这个 crash 疯长，过几分钟之后又回落到正常水位，看来还没有完全破案。事情还得查。
这次真的破案了
上次灰度失败，我反思了一下，还是要回到 crash 本身。
回到 crash 本身，堆栈中我们自己的代码出现在图中红框中的代码：
FragmentTabHost 是手淘首页中的 Fragment 管理器，但是这块代码确实好几个版本都没有变动了。代码中看到 TabHost 在 onAttachedToWindow 函数中，最终调用了FragmentManager 类中的 executePendingTransactions 方法提交了 Fragment 的切换请求。中间代码就是一路按照堆栈调用，调用到 FragmentManagerImpl 的 moveToState 方法。系统源码如下：
void moveToState(Fragment f, int newState, int transit, int transitionStyle, boolean keepActive) { ...... case Fragment.CREATED: if (newState > Fragment.CREATED) { if (DEBUG) Log.v(TAG, "moveto ACTIVITY_CREATED: " + f); if (!f.mFromLayout) { ViewGroup container = null; if (f.mContainerId != 0) { container = (ViewGroup)mContainer.onFindViewById(f.mContainerId); if (container == null && !f.mRestored) { throwException(new IllegalArgumentException( "No view found for id 0x" + Integer.toHexString(f.mContainerId) + " (" + f.getResources().getResourceName(f.mContainerId) + ") for fragment " + f)); } } f.mContainer = container; f.mView = f.performCreateView(f.getLayoutInflater( f.mSavedFragmentState), container, f.mSavedFragmentState); if (f.mView != null) { f.mInnerView = f.mView; if (Build.VERSION.SDK_INT >= 11) { ViewCompat.setSaveFromParentEnabled(f.mView, false); } else { f.mView = NoSaveStateFrameLayout.wrap(f.mView); } if (container != null) { Animation anim = loadAnimation(f, transit, true, transitionStyle); if (anim != null) { setHWLayerAnimListenerIfAlpha(f.mView, anim); f.mView.startAnimation(anim); } //在这里调用了 addView container.addView(f.mView); } if (f.mHidden) f.mView.setVisibility(View.GONE); f.onViewCreated(f.mView, f.mSavedFragmentState); } else { f.mInnerView = null; } } f.performActivityCreated(f.mSavedFragmentState); if (f.mView != null) { f.restoreViewState(f.mSavedFragmentState); } f.mSavedFragmentState = null; } ...... } f.mView = f.performCreateView(f.getLayoutInflater( f.mSavedFragmentState), container, f.mSavedFragmentState); if (f.mView != null) { f.mInnerView = f.mView; if (Build.VERSION.SDK_INT >= 11) { ViewCompat.setSaveFromParentEnabled(f.mView, false); } else { f.mView = NoSaveStateFrameLayout.wrap(f.mView); } if (container != null) { Animation anim = loadAnimation(f, transit, true, transitionStyle); if (anim != null) { setHWLayerAnimListenerIfAlpha(f.mView, anim); f.mView.startAnimation(anim); } //在这里调用了 addView container.addView(f.mView); } if (f.mHidden) f.mView.setVisibility(View.GONE); f.onViewCreated(f.mView, f.mSavedFragmentState); } else { f.mInnerView = null; } } f.performActivityCreated(f.mSavedFragmentState); if (f.mView != null) { f.restoreViewState(f.mSavedFragmentState); } f.mSavedFragmentState = null; } ...... }
在上面代码中，调用了 container 的 addView 方法，container 是一个个ViewGroup，而这个 addView 的参数 f.View 是在 performCreateView 中进行赋值的，系统源码如下：
View performCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { if (mChildFragmentManager != null) { mChildFragmentManager.noteStateNotSaved(); } return onCreateView(inflater, container, savedInstanceState); }
而 performCreateView 函数最终调用到 Fragment 的 onCreateView 中，这个函数是首页 Fragment 自己实现的，找负责同学要来代码继续看。
public View onCreateView(LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) { ...... if (mRootView == null) { View view = workflow.onCreateView(inflater, container, savedInstanceState); return view; } ...... return mRootView; }
看起来逻辑是首页 Fragment 做了自己的缓存处理，如果 mRootView 为 null，则从 coldStartUpWorkflow 中调用 onCreateView 创建一个 view 并返回，如果 mRootView 不为 null，则去掉 view 的父节点，一点毛病没有。那问题只能出现在 coldStartUpWorkflow 中创建的 view 可能有问题。
@Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { super.onCreateView(inflater, container, savedInstanceState); return create(inflater,container); } private View create(LayoutInflater inflater, ViewGroup container){ View rootView = null; ...... rootView = RevisionReuseViewController.getInstance().getHomePageView(inflater, container); ...... return rootView; }
发现这个函数名字虽然叫 onCreateView，但是其中的 view 对象却是通过一个 get 开头的函数获取来的，不出意外问题肯定是在这里了。
public class RevisionReuseViewController { private WeakReference<View> homePageViewWR; private RevisionReuseViewController(){} private static class SingleHandler { private static RevisionReuseViewController instance = new RevisionReuseViewController(); } public static RevisionReuseViewController getInstance() { return RevisionReuseViewController.SingleHandler.instance; } public View getHomePageView(LayoutInflater inflater, ViewGroup container) { View view = homePageViewWR == null ? null : homePageViewWR.get(); if (view == null) { homePageViewWR = new WeakReference<>(inflater.inflate(R.layout.activity_homepage, container, false)); } return homePageViewWR.get(); } }
RevisionReuseViewController 这个单例里面竟然自己做了缓存逻辑，而触发这个逻辑的时候并没有把缓存的 view 的父节点 remove 掉。
确定了问题所在，马上第二次灰度，果不其然 crash 不再出现了。
但是还遗留下来一个问题， 为什么会有两个首页呢？
两个首页
crash 解决了，但是更棘手的问题还在后面，crash 只是把这个问题暴露出来了，也就是说两个首页有可能引起这个 crash，但是不是所有两个首页都引发这个 crash，我们还不知道这个问题在线上到底有多么严重，会不会出现很多意想不到的问题。
可能很多同学会说，出现两个 singleTask 的 activity ，他们有可能在两个栈里面。但是第一次灰度的时候我们已经确定了，他们是在一个栈里面，这回线索彻底断了。
天无绝人之路，在首页同学把修复代码集成进手淘的前一天，突然接到了一个钉钉消息，一个同学告诉我，他们有个 crash，要我确认，我看到堆栈之后发现跟前面解决的问题堆栈一致，就告诉他，这个版本修复，低概率的话暂时不用管。
但是他告诉我，我这边必现这个 crash。
按耐住激动的心，让他告诉我复现路径，果然必现。要来代码看到了一个崩快的原因：原来有同学在代码里面调用 startActivtyForResult 启动了首页。
想了一下也没有什么问题，因为 startActivity 内部调用就是 startActivityForResult 来实现的，但是直觉告诉我就是这里有问题，于是写个 demo 验证一下我的想法。
demo 很简单，两个 activity ，第一个 activity 是 singleTask 模式，其中一个按钮，点击正常调用到第二个 activity，第二个 activity 是标准模式，其中两个按钮，第一个按钮调用 startActivity 拉起第一个 activity，第二个按钮通过 startActivityForResult 拉起第一个 activity，启动 requsetCode 传递的是1。具体代码就不贴了，很简单一个 demo。当我点击第二个 activity 的第一个按钮的时候，看到栈里面只剩下一个 activity，符合预期。但是当我点击第二个按钮的时候，神奇的一幕出现了。很明显一个 TaskRecord 里面有两个 MainActivity，而且我确认这个 MainActivity 是 singleTask 的。奇怪的是 startActivity 里面调用的也是 startActivityForResult，只是传递的值是 -1 ，难道真的是这个值决定了这个行为么？
真相大白
看源码吧（以下代码来自 Android 9.0）
public void startActivity(Intent intent) { this.startActivity(intent, null); } @Override public void startActivity(Intent intent, @Nullable Bundle options) { if (options != null) { startActivityForResult(intent, -1, options); } else { // Note we want to go through this call for compatibility with // applications that may have overridden the method. startActivityForResult(intent, -1); } } public void startActivityForResult(@RequiresPermission Intent intent, int requestCode) { startActivityForResult(intent, requestCode, null); } 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); if (ar != null) { mMainThread.sendActivityResult( mToken, mEmbeddedID, requestCode, ar.getResultCode(), ar.getResultData()); } if (requestCode >= 0) { // If this start is requesting a result, we can avoid making // the activity visible until the result is received. Setting // this code during onCreate(Bundle savedInstanceState) or onResume() will keep the // activity hidden during this time, to avoid flickering. // This can only be done when a result is requested because // that guarantees we will get information back when the // activity is finished, no matter what happens to it. mStartedActivity = true; } cancelInputsAndStartExitTransition(options); // TODO Consider clearing/flushing other event sources and events for child windows. } else { if (options != null) { mParent.startActivityFromChild(this, intent, requestCode, options); } else { // Note we want to go through this method for compatibility with // existing applications that may have overridden it. mParent.startActivityFromChild(this, intent, requestCode); } } } 可以看到 startActivity 调用到 startActivityForResult，startActivityForResult 调用了 Instrumentation 中的 execStartActivity 执行后续流程（下面 else 中的 mParent.startActivityFromChild 的流程最终也调用到了此处）。 public ActivityResult execStartActivity( Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options) { ...... try { intent.migrateExtraStreamToClipData(); intent.prepareToLeaveProcess(who); int result = ActivityTaskManager.getService() .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; }
可以看到startActivity 调用到 startActivityForResult，startActivityForResult 调用了 Instrumentation 中的 execStartActivity 执行后续流程（下面 else 中的 mParent.startActivityFromChild 的流程最终也调用到了此处）。
public ActivityResult execStartActivity( Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options) { ...... try { intent.migrateExtraStreamToClipData(); intent.prepareToLeaveProcess(who); int result = ActivityTaskManager.getService() .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; }
里面删除一些无关逻辑，最终调用到 ActivityTaskManagerService 中的 startActivity 函数继续流程。
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("startActivityAsUser"); userId = getActivityStartController().checkTargetUser(userId, validateIncomingUser, Binder.getCallingPid(), Binder.getCallingUid(), "startActivityAsUser"); // TODO: Switch to user app stacks here. return getActivityStartController().obtainStarter(intent, "startActivityAsUser") .setCaller(caller) .setCallingPackage(callingPackage) .setResolvedType(resolvedType) .setResultTo(resultTo) .setResultWho(resultWho) .setRequestCode(requestCode) .setStartFlags(startFlags) .setProfilerInfo(profilerInfo) .setActivityOptions(bOptions) .setMayWait(userId) .execute(); }
ActivityTaskManagerService 的 startActivity 方法只是转换了一下控制权，最终调用到 startActivityAsUser中，把控制权交给 ActivityStarter，传递参数，并最终执行 execute 函数执行后续流程。
int execute() { try { if (mRequest.mayWait) { return startActivityMayWait(mRequest.caller, mRequest.callingUid, mRequest.callingPackage, mRequest.realCallingPid, mRequest.realCallingUid, 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, mRequest.originatingPendingIntent, mRequest.allowBackgroundActivityStart); } 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, mRequest.originatingPendingIntent, mRequest.allowBackgroundActivityStart); } } finally { onExecutionComplete(); } }
由于参数重mRequest.mayWait的值为true，所以调用到startActivityMayWait。
private int startActivityMayWait(IApplicationThread caller, int callingUid, String callingPackage, int requestRealCallingPid, int requestRealCallingUid, Intent intent, String resolvedType, IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor, IBinder resultTo, String resultWho, int requestCode, int startFlags, ProfilerInfo profilerInfo, WaitResult outResult, Configuration globalConfig, SafeActivityOptions options, boolean ignoreTargetSecurity, int userId, TaskRecord inTask, String reason, boolean allowPendingRemoteAnimationRegistryLookup, PendingIntentRecord originatingPendingIntent, boolean allowBackgroundActivityStart) { ...... 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, originatingPendingIntent, allowBackgroundActivityStart); ...... return res; }
去掉一些多余逻辑，留下关键路径，看到转移到 startActivity 继续执行，
private int startActivity(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, SafeActivityOptions options, boolean ignoreTargetSecurity, boolean componentSpecified, ActivityRecord[] outActivity, TaskRecord inTask, String reason, boolean allowPendingRemoteAnimationRegistryLookup, PendingIntentRecord originatingPendingIntent, boolean allowBackgroundActivityStart) { ...... mLastStartActivityResult = startActivity(caller, intent, ephemeralIntent, resolvedType, aInfo, rInfo, voiceSession, voiceInteractor, resultTo, resultWho, requestCode, callingPid, callingUid, callingPackage, realCallingPid, realCallingUid, startFlags, options, ignoreTargetSecurity, componentSpecified, mLastStartActivityRecord, inTask, allowPendingRemoteAnimationRegistryLookup, originatingPendingIntent, allowBackgroundActivityStart); ...... return getExternalResult(mLastStartActivityResult); }
中间一顿操作，最终调用到下面
private int startActivity(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, SafeActivityOptions options, boolean ignoreTargetSecurity, boolean componentSpecified, ActivityRecord[] outActivity, TaskRecord inTask, boolean allowPendingRemoteAnimationRegistryLookup, PendingIntentRecord originatingPendingIntent, boolean allowBackgroundActivityStart) { int result = START_CANCELED; final ActivityStack startedActivityStack; try { mService.mWindowManager.deferSurfaceLayout(); result = startActivityUnchecked(r, sourceRecord, voiceSession, voiceInteractor, startFlags, doResume, options, inTask, outActivity, restrictedBgActivity); } finally { } postStartActivityProcessing(r, result, startedActivityStack); 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, boolean restrictedBgActivity) { setInitialState(r, options, inTask, doResume, startFlags, sourceRecord, voiceSession, voiceInteractor, restrictedBgActivity); ...... // 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. final ActivityStack topStack = mRootActivityContainer.getTopDisplayFocusedStack(); final ActivityRecord topFocused = topStack.getTopActivity(); final ActivityRecord top = topStack.topRunningNonDelayedActivityLocked(mNotTop); final boolean dontStart = top != null && mStartActivity.resultTo == null && top.mActivityComponent.equals(mStartActivity.mActivityComponent) && top.mUserId == mStartActivity.mUserId && top.attachedToProcess() && ((mLaunchFlags & FLAG_ACTIVITY_SINGLE_TOP) != 0 || isLaunchModeOneOf(LAUNCH_SINGLE_TOP, LAUNCH_SINGLE_TASK)) // This allows home activity to automatically launch on secondary display when // display added, if home was the top activity on default display, instead of // sending new intent to the home activity on default display. && (!top.isActivityTypeHome() || top.getDisplayId() == mPreferredDisplayId); if (dontStart) { // For paranoia, make sure we have correctly resumed the top activity. topStack.mLastPausedActivity = null; if (mDoResume) { mRootActivityContainer.resumeFocusedStacksTopActivities(); } ActivityOptions.abort(mOptions); if ((mStartFlags & START_FLAG_ONLY_IF_NEEDED) != 0) { // We don't need to start a new activity, and the client said not to do // anything if that is the case, so this is it! return START_RETURN_INTENT_TO_CALLER; } deliverNewIntent(top); // Don't use mStartActivity.task to show the toast. We're not starting a new activity // but reusing 'top'. Fields in mStartActivity may not be fully initialized. mSupervisor.handleNonResizableTaskIfNeeded(top.getTaskRecord(), preferredWindowingMode, mPreferredDisplayId, topStack); return START_DELIVERED_TO_TOP; } ...... }
把一些乱七八糟的逻辑去除掉，抽丝剥茧，看到了dontStart 这个变量，下面这个变量的值控制了activity 启动过程中的复用流程，当它是true 的时候，则通过 resumeFocusedStacksTopActivities直接从栈中拉起一个已经存在的activity ，当他是 false 的时候新拉起一个 activity 接收这次请求。
boolean resumeFocusedStacksTopActivities( ActivityStack targetStack, ActivityRecord target, ActivityOptions targetOptions) { if (!mStackSupervisor.readyToResume()) { return false; } boolean result = false; if (targetStack != null && (targetStack.isTopStackOnDisplay() || getTopDisplayFocusedStack() == targetStack)) { result = targetStack.resumeTopActivityUncheckedLocked(target, targetOptions); } for (int displayNdx = mActivityDisplays.size() - 1; displayNdx >= 0; --displayNdx) { boolean resumedOnDisplay = false; final ActivityDisplay display = mActivityDisplays.get(displayNdx); for (int stackNdx = display.getChildCount() - 1; stackNdx >= 0; --stackNdx) { final ActivityStack stack = display.getChildAt(stackNdx); final ActivityRecord topRunningActivity = stack.topRunningActivityLocked(); if (!stack.isFocusableAndVisible() || topRunningActivity == null) { continue; } if (stack == targetStack) { // Simply update the result for targetStack because the targetStack had // already resumed in above. We don't want to resume it again, especially in // some cases, it would cause a second launch failure if app process was dead. resumedOnDisplay |= result; continue; } if (display.isTopStack(stack) && topRunningActivity.isState(RESUMED)) { // Kick off any lingering app transitions form the MoveTaskToFront operation, // but only consider the top task and stack on that display. stack.executeAppTransition(targetOptions); } else { resumedOnDisplay |= topRunningActivity.makeActiveIfNeeded(target); } } if (!resumedOnDisplay) { // In cases when there are no valid activities (e.g. device just booted or launcher // crashed) it's possible that nothing was resumed on a display. Requesting resume // of top activity in focused stack explicitly will make sure that at least home // activity is started and resumed, and no recursion occurs. final ActivityStack focusedStack = display.getFocusedStack(); if (focusedStack != null) { focusedStack.resumeTopActivityUncheckedLocked(target, targetOptions); } } } return result; }
resumeFocusedStacksTopActivities 函数中首先找到了目标栈，定位到目标栈中需要拉起的 activity，最终通过 resumeTopActivityUncheckedLocked 函数直接 resume activity，具体流程这里不做展开，有兴趣的同学可以自己阅读源码。
回到 dontStart 这个变量，名字看起来就是是否需要启动一个新的 activity，而且他的赋值逻辑里面有一个
mStartActivity.resultTo == null这个逻辑，而这个resultTo是在什么时候赋值的呢,看到进入startActivityUnchecked的时候调用了setInitialState函数来初始化一些状态。
private void setInitialState(ActivityRecord r, ActivityOptions options, TaskRecord inTask, boolean doResume, int startFlags, ActivityRecord sourceRecord, IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor, boolean restrictedBgActivity) { reset(false /* clearRequest */); mStartActivity = r; mIntent = r.intent; mOptions = options; ...... }
在这个函数里面用传入的 ActivityRecord 初始化了 mStartActivity 这个全局变量，继续往回回溯这个 ActivityRecord 是在那里构建的。
final class ActivityRecord extends ConfigurationContainer { ActivityRecord(ActivityTaskManagerService _service, WindowProcessController _caller, int _launchedFromPid, int _launchedFromUid, String _launchedFromPackage, Intent _intent, String _resolvedType, ActivityInfo aInfo, Configuration _configuration, ActivityRecord _resultTo, String _resultWho, int _reqCode, boolean _componentSpecified, boolean _rootVoiceInteraction, ActivityStackSupervisor supervisor, ActivityOptions options, ActivityRecord sourceRecord) { mAtmService = _service; mRootActivityContainer = _service.mRootActivityContainer; appToken = new Token(this, _intent); info = aInfo; launchedFromPid = _launchedFromPid; launchedFromUid = _launchedFromUid; launchedFromPackage = _launchedFromPackage; mUserId = UserHandle.getUserId(aInfo.applicationInfo.uid); intent = _intent; shortComponentName = _intent.getComponent().flattenToShortString(); resolvedType = _resolvedType; componentSpecified = _componentSpecified; rootVoiceInteraction = _rootVoiceInteraction; mLastReportedConfiguration = new MergedConfiguration(_configuration); resultTo = _resultTo; resultWho = _resultWho; requestCode = _reqCode; setState(INITIALIZING, "ActivityRecord ctor"); frontOfTask = false; launchFailed = false; stopped = false; delayedResume = false; finishing = false; deferRelaunchUntilPaused = false; keysPaused = false; inHistory = false; visible = false; nowVisible = false; mDrawn = false; idle = false; hasBeenLaunched = false; mStackSupervisor = supervisor; } } private int startActivity(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, SafeActivityOptions options, boolean ignoreTargetSecurity, boolean componentSpecified, ActivityRecord[] outActivity, TaskRecord inTask, boolean allowPendingRemoteAnimationRegistryLookup, PendingIntentRecord originatingPendingIntent, boolean allowBackgroundActivityStart) { ...... ActivityRecord resultRecord = null; if (resultTo != null) { sourceRecord = mRootActivityContainer.isInAnyStack(resultTo); if (DEBUG_RESULTS) Slog.v(TAG_RESULTS, "Will send result to " + resultTo + " " + sourceRecord); if (sourceRecord != null) { if (requestCode >= 0 && !sourceRecord.finishing) { resultRecord = sourceRecord; } } } ...... ActivityRecord r = new ActivityRecord(mService, callerApp, callingPid, callingUid, callingPackage, intent, resolvedType, aInfo, mService.getGlobalConfiguration(), resultRecord, resultWho, requestCode, componentSpecified, voiceSession != null, mSupervisor, checkedOptions, sourceRecord); ...... }
发现在 startActivity 函数中构建了 ActivityRecord，而 ActivityRecord 里面的 resultTo 变量是通过 resultRecord 进行赋值的，这个变量会根据传入的 requestCode 是否大于 0 来判断是否赋值。
那就很明白了，我们直接调用 startActivity 的时候 requestCode 是 -1 ，而调用传入 startActivityForResult 的时候传入的值大于 0 导致在这个位置错过了启动过程中 activity 复用的逻辑。最终导致了虽然是一个 singleTask 的 activity 但是却在同一个栈中同时存在两个实例。
总结
其实这个现象也是可以理解的，当我们调用 startActivityForResult 的时候，当然是希望拉起来的 Activity 生命周期结束退出后还能回到当前的 Activity，但是如果直接走 singleTask 的复用逻辑，就会把原 Activity 清掉，则无法返回了，可以说这是一个 bug，也可以说 Android 为开发同学做了这一层兜底。
但是 singleTask 的 Activity 只能在栈内存在一个实例的面试题是不是需要改改了。