Configuration 变动时Activity的生命周期探究

当设备配置发生变动时，系统会调用AMS的updateConfiguration()方法，来通知AMS处理configuration changed事件，updateConfiguration()源码以下：

public boolean updateConfiguration(Configuration values) {
    // ... 省略一段代码
    synchronized(this) {
        // ... 省略一段代码
        try {
            if (values != null) {
                Settings.System.clearConfiguration(values);
            }
            updateConfigurationLocked(values, null, false, false /* persistent */,
                    UserHandle.USER_NULL, false /* deferResume */,
                    mTmpUpdateConfigurationResult);
            return mTmpUpdateConfigurationResult.changes != 0;
        } finally {
            Binder.restoreCallingIdentity(origId);
        }
    }
}	
复制代码

能够看到updateConfiguration()内部调用了private boolean updateConfigurationLocked()，在其代码注释中咱们能够看到，该方法一共作了两件事： 1.调用updateGlobalConfigurationLocked()更新当前配置信息 2.调用ensureConfigAndVisibilityAfterUpdate()确保给定的activity使用的是当前配置 若是返回true表示activity未被重启，不然让该activity destroyed以适配当前配置。 ensureConfigAndVisibilityAfterUpdate()的源码以下：

private boolean ensureConfigAndVisibilityAfterUpdate(ActivityRecord starting, int changes) {
        boolean kept = true;
        // 获取当前拥有焦点的activity
        final ActivityStack mainStack = mStackSupervisor.getFocusedStack();
        // mainStack is null during startup.
        if (mainStack != null) {
            if (changes != 0 && starting == null) {
                // If the configuration changed, and the caller is not already
                // in the process of starting an activity, then find the top
                // activity to check if its configuration needs to change.
                starting = mainStack.topRunningActivityLocked();
            }

            if (starting != null) {
                // 关键代码
                kept = starting.ensureActivityConfiguration(changes,
                        false /* preserveWindow */);
                // And we need to make sure at this point that all other activities
                // are made visible with the correct configuration.
                mStackSupervisor.ensureActivitiesVisibleLocked(starting, changes,
                        !PRESERVE_WINDOWS);
            }
        }

        return kept;
    }
复制代码

能够看到，决定返回值的是ActivityRecord的ensureActivityConfiguration()方法，并在内部调用了该方法的重载方法，其源码以下：

boolean ensureActivityConfiguration(int globalChanges, boolean preserveWindow, boolean ignoreStopState) {
        final ActivityStack stack = getStack();
        // 若是立刻就会再次调用updateConfiguration()，则忽略本次修改，交由下次处理，节省时间
        if (stack.mConfigWillChange) {
            if (DEBUG_SWITCH || DEBUG_CONFIGURATION) Slog.v(TAG_CONFIGURATION,
                    "Skipping config check (will change): " + this);
            return true;
        }

        // We don't worry about activities that are finishing.
        // 若是当前activity已经finish则忽略
        if (finishing) {
            if (DEBUG_SWITCH || DEBUG_CONFIGURATION) Slog.v(TAG_CONFIGURATION,
                    "Configuration doesn't matter in finishing " + this);
            stopFreezingScreenLocked(false);
            return true;
        }
        // ...省略一段代码
        if (mState == INITIALIZING) {
            // No need to relaunch or schedule new config for activity that hasn't been launched
            // yet. We do, however, return after applying the config to activity record, so that
            // it will use it for launch transaction.
            if (DEBUG_SWITCH || DEBUG_CONFIGURATION) Slog.v(TAG_CONFIGURATION,
                    "Skipping config check for initializing activity: " + this);
            return true;
        }

        if (shouldRelaunchLocked(changes, mTmpConfig) || forceNewConfig) {
            // Aha, the activity isn't handling the change, so DIE DIE DIE.
            configChangeFlags |= changes;
            startFreezingScreenLocked(app, globalChanges);
            forceNewConfig = false;
            preserveWindow &= isResizeOnlyChange(changes);
            if (app == null || app.thread == null) {
                // ...省略log代码
                // 若是app不在托管状态，则仅销毁当前activity
                stack.destroyActivityLocked(this, true, "config");
            } else if (mState == PAUSING) {
                // ...省略log代码
                // 若是当前activity处于PAUSING状态，则标记其须要重启，等到PAUSING后reLaunch
                deferRelaunchUntilPaused = true;
                preserveWindowOnDeferredRelaunch = preserveWindow;
                return true;
            } else if (mState == RESUMED) {
                // ...省略一段代码
                // 若是当前activity处于RESUMED状态，则重启后须要恢复到RESUMED状态
                relaunchActivityLocked(true /* andResume */, preserveWindow);
            } else {
                // ...省略log代码
                relaunchActivityLocked(false /* andResume */, preserveWindow);
            }
            // activity自行处理了configuration changed，无需重启
            return false;
        }
        // Activity能够本身处理配置变动则走这里
        if (displayChanged) {
            scheduleActivityMovedToDisplay(newDisplayId, newMergedOverrideConfig);
        } else {
            scheduleConfigurationChanged(newMergedOverrideConfig);
        }
        return true;
    }
复制代码

能够看到决定是否重启的关键代码是shouldRelaunchLocked(changes, mTmpConfig)。另一个值得关注的点是forceNewConfig变量，其值仅在ActivityStack.restartPackage()时为true,此时会忽略activity的configChanges配置，强制重启activity。shouldRelaunchLocked的源码以下：

private boolean shouldRelaunchLocked(int changes, Configuration changesConfig) {
        // 获取manifest中配置的configChanges属性
        int configChanged = info.getRealConfigChanged();
        boolean onlyVrUiModeChanged = onlyVrUiModeChanged(changes, changesConfig);

        // Override for apps targeting pre-O sdks
        // If a device is in VR mode, and we're transitioning into VR ui mode, add ignore ui mode
        // to the config change.
        // For O and later, apps will be required to add configChanges="uimode" to their manifest.
        if (appInfo.targetSdkVersion < O
                && requestedVrComponent != null
                && onlyVrUiModeChanged) {
            configChanged |= CONFIG_UI_MODE;
        }
        // 关键代码 
        return (changes&(~configChanged)) != 0;
    }
复制代码

(changes&(~configChanged)) != 0决定了是否ReLaunch当前activity，若是变动的配置在activity自处理的配置列表中，则不会重启。而configChanged正是咱们在manifest中配置的configChanges属性。

void relaunchActivityLocked(boolean andResume, boolean preserveWindow) {
        // ...省略一段代码
        try {
            // ...省略log代码
            // 关键代码1
            final ClientTransactionItem callbackItem = ActivityRelaunchItem.obtain(pendingResults,
                    pendingNewIntents, configChangeFlags,
                    new MergedConfiguration(service.getGlobalConfiguration(),
                            getMergedOverrideConfiguration()),
                    preserveWindow);
            final ActivityLifecycleItem lifecycleItem;
            if (andResume) {
                lifecycleItem = ResumeActivityItem.obtain(service.isNextTransitionForward());
            } else {
                lifecycleItem = PauseActivityItem.obtain();
            }
            final ClientTransaction transaction = ClientTransaction.obtain(app.thread, appToken);
            transaction.addCallback(callbackItem);
            transaction.setLifecycleStateRequest(lifecycleItem);
            // 关键代码2
            service.getLifecycleManager().scheduleTransaction(transaction);
        } catch (RemoteException e) {
            if (DEBUG_SWITCH || DEBUG_STATES) Slog.i(TAG_SWITCH, "Relaunch failed", e);
        }
        // ...省略一段代码
    }
复制代码

首先咱们看关键代码1：ActivityRelaunchItem.obtain()。ActivityRelaunchItem继承自``，其中在execute()中调用了client.handleRelaunchActivity(mActivityClientRecord, pendingActions)。 最终ClientTransaction的callback的execute(ClientTransactionHandler client, IBinder token,PendingTransactionActions pendingActions)都会被调用，而添加的callback：ActivityRelaunchItem的execute以下：

public void execute(ClientTransactionHandler client, IBinder token,PendingTransactionActions pendingActions) {
    if (mActivityClientRecord == null) {
        if (DEBUG_ORDER) Slog.d(TAG, "Activity relaunch cancelled");
        return;
    }
    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityRestart");
    client.handleRelaunchActivity(mActivityClientRecord, pendingActions);
    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
}
复制代码

ClientTransactionHandler是一个抽象类，这里实际是经过ClientTransaction.obtain(app.thread, appToken)传入的IApplicationThread对象，app.thread是在attachApplication()方法中设置的，其实现类是ApplicationThread,而其内部调用的是ActivityThread.handleRelaunchActivity()，该方法在其父类中实现：

void scheduleTransaction(ClientTransaction transaction) {
    transaction.preExecute(this);
    sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
}
复制代码

其中sendMessage()由ActivityThread实现，最终交由H处理：

case EXECUTE_TRANSACTION:
    final ClientTransaction transaction = (ClientTransaction) msg.obj;
    mTransactionExecutor.execute(transaction);
    if (isSystem()) {
       transaction.recycle();
    }
    break;
复制代码

mTransactionExecutor是TransactionExecutor的实例，其execute()方法最终会调用executeCallbacks(transaction)调用经过ClientTransaction#addCallback()方法添加的全部ClientTransactionItem实例的execute()。最终会调用ActivityThread.handleRelaunchActivity()：

public void handleRelaunchActivity(ActivityClientRecord tmp,PendingTransactionActions pendingActions) {
        // ...省略一段代码
        if (changedConfig != null) {
            mCurDefaultDisplayDpi = changedConfig.densityDpi;
            updateDefaultDensity();
            handleConfigurationChanged(changedConfig, null);
        }
        ActivityClientRecord r = mActivities.get(tmp.token);
        // ...省略一段代码
        handleRelaunchActivityInner(r, configChanges, tmp.pendingResults, tmp.pendingIntents,
                pendingActions, tmp.startsNotResumed, tmp.overrideConfig, "handleRelaunchActivity");
         // ...省略一段代码
    }
复制代码

在handleRelaunchActivityInner()中，先调用ActivityThread.handleDestroyActivity()销毁当前activity，随便调用ActivityThread.handleLaunchActivity()重启了activity。咱们都知道，Activity有一个回调方法onRetainNonConfigurationInstance()，当设备信息变动时，会保存该方法返回的Object，以后能够在重启的Activity中经过getLastNonConfigurationInstance()获取该Object。onRetainNonConfigurationInstance()并不是仅会在发生reLaunchActivity时回调，而是在Activity destoryed时，在ActivityThread.performDestroyActivity()中调用Activity.retainNonConfigurationInstances()获取的。该方法返回的是NonConfigurationInstances,其activity属性即是调用Activity.onRetainNonConfigurationInstance()获取的。而之因此getLastNonConfigurationInstance()能获取到值，是由于在reLaunchActivity中将同一ActivityRecord做为参数，传递给了新Activity。该方法是在ComponentActivity，已经被重写为final方法，子类若是想保存数据，能够经过onRetainCustomNonConfigurationInstance替代，可是官方推荐使用ViewModel组件来替代它，而ViewModel之因此会在设备旋转后恢复，即是经过这种方式保存的。 如今要解决的疑惑是，当变动的配置在activity自处理的配置列表时，activity仅会回调onConfigurationChanged(Configuration),这又是在哪里调用的呢？答案就在ActivityRecord的ensureActivityConfiguration()方法中。

// Activity能够本身处理配置变动则走这里
    if (displayChanged) {
        scheduleActivityMovedToDisplay(newDisplayId, newMergedOverrideConfig);
    } else {
        scheduleConfigurationChanged(newMergedOverrideConfig);
    }
复制代码

这两个分支，最终都会调用ClientTransactionHandler.handleActivityConfigurationChanged()方法，该方法由ActivityThread实现:

public void handleActivityConfigurationChanged(IBinder activityToken,Configuration overrideConfig, int displayId) {
        // ...省略一段代码
        final boolean movedToDifferentDisplay = displayId != INVALID_DISPLAY
                && displayId != r.activity.getDisplay().getDisplayId();
        // ...省略一段代码
        if (movedToDifferentDisplay) {
            // ...省略一段代码
            final Configuration reportedConfig = performConfigurationChangedForActivity(r,
                    mCompatConfiguration, displayId, true /* movedToDifferentDisplay */);
            // ...省略一段代码
        } else {
            if (DEBUG_CONFIGURATION) Slog.v(TAG, "Handle activity config changed: "
                    + r.activityInfo.name + ", config=" + overrideConfig);
            performConfigurationChangedForActivity(r, mCompatConfiguration);
        }
        // ...省略一段代码
    }
复制代码

performConfigurationChangedForActivity()最终会调用performActivityConfigurationChanged()方法，该方法以下：

private Configuration performActivityConfigurationChanged(Activity activity,Configuration newConfig, Configuration amOverrideConfig, int displayId,boolean movedToDifferentDisplay) {
        // ...省略一段代码
        boolean shouldChangeConfig = false;
        if (activity.mCurrentConfig == null) {
            shouldChangeConfig = true;
        } else {
            // If the new config is the same as the config this Activity is already running with and
            // the override config also didn't change, then don't bother calling
            // onConfigurationChanged.
            final int diff = activity.mCurrentConfig.diffPublicOnly(newConfig);

            if (diff != 0 || !mResourcesManager.isSameResourcesOverrideConfig(activityToken,
                    amOverrideConfig)) {
                // Always send the task-level config changes. For system-level configuration, if
                // this activity doesn't handle any of the config changes, then don't bother
                // calling onConfigurationChanged as we're going to destroy it.
                // 若是共用配置发生变动
                // mUpdatingSystemConfig这里为false因此shouldChangeConfig=true
                if (!mUpdatingSystemConfig
                        || (~activity.mActivityInfo.getRealConfigChanged() & diff) == 0
                        || !REPORT_TO_ACTIVITY) {
                    shouldChangeConfig = true;
                }
            }
        }
        if (!shouldChangeConfig && !movedToDifferentDisplay) {
            // Nothing significant, don't proceed with updating and reporting.
            return null;
        }
        // ...省略一段代码
        if (shouldChangeConfig) {
            activity.mCalled = false;
            activity.onConfigurationChanged(configToReport);
            if (!activity.mCalled) {
                throw new SuperNotCalledException("Activity " + activity.getLocalClassName() +
                                " did not call through to super.onConfigurationChanged()");
            }
        }

        return configToReport;
    }
复制代码

最终咱们找到了activity.onConfigurationChanged(configToReport)调用位置。至此，设备变动是，activity的生命周期调用流程分析完毕。 #Fragment#setRetainInstance 众所周知，经过调用Fragment#setRetainInstance(true),咱们能够在因设配配置发生变动而重建时保留Fragment而不是销毁重建。那么这一效果又是如何实现的呢？ 咱们先来看看Fragment#setRetainInstance()：

public void setRetainInstance(boolean retain) {
        mRetainInstance = retain;
        if (mFragmentManager != null) {
            if (retain) {
                mFragmentManager.addRetainedFragment(this);
            } else {
                mFragmentManager.removeRetainedFragment(this);
            }
        } else {
            mRetainInstanceChangedWhileDetached = true;
        }
    }
复制代码

继续追踪发现，Fragment实例被添加到了FragmentManagerViewModel.mRetainedFragments,这是一个HashSet类型的变量，觉得这同一仅容许被添加一次。那么这些Fragment是在什么时候保存的呢？想一想以前ViewModel的保存，没错就是Activity#retainNonConfigurationInstances()：

NonConfigurationInstances retainNonConfigurationInstances() {
        Object activity = onRetainNonConfigurationInstance();
        HashMap<String, Object> children = onRetainNonConfigurationChildInstances();
        // 保存 FragmentManagerNonConfig
        FragmentManagerNonConfig fragments = mFragments.retainNestedNonConfig();

        mFragments.doLoaderStart();
        mFragments.doLoaderStop(true);
        ArrayMap<String, LoaderManager> loaders = mFragments.retainLoaderNonConfig();

        if (activity == null && children == null && fragments == null && loaders == null
                && mVoiceInteractor == null) {
            return null;
        }

        NonConfigurationInstances nci = new NonConfigurationInstances();
        nci.activity = activity;
        nci.children = children;
        // 赋值给封装变量
        nci.fragments = fragments;
        nci.loaders = loaders;
        if (mVoiceInteractor != null) {
            mVoiceInteractor.retainInstance();
            nci.voiceInteractor = mVoiceInteractor;
        }
        return nci;
    }
复制代码

咱们追踪mFragments.retainNestedNonConfig()看下去，发现调用流程以下： FragmentController#retainNestedNonConfig() -> FragmentManagerImpl#retainNonConfig() ->FragmentManagerViewModel#getSnapshot(), FragmentManagerViewModel#getSnapshot()方法以下：

FragmentManagerNonConfig getSnapshot() {
        if (mRetainedFragments.isEmpty() && mChildNonConfigs.isEmpty()
                && mViewModelStores.isEmpty()) {
            return null;
        }
        HashMap<String, FragmentManagerNonConfig> childNonConfigs = new HashMap<>();
        for (Map.Entry<String, FragmentManagerViewModel> entry : mChildNonConfigs.entrySet()) {
            FragmentManagerNonConfig childNonConfig = entry.getValue().getSnapshot();
            if (childNonConfig != null) {
                childNonConfigs.put(entry.getKey(), childNonConfig);
            }
        }

        mHasSavedSnapshot = true;
        if (mRetainedFragments.isEmpty() && childNonConfigs.isEmpty()
                && mViewModelStores.isEmpty()) {
            return null;
        }
        return new FragmentManagerNonConfig(
                new ArrayList<>(mRetainedFragments),
                childNonConfigs,
                new HashMap<>(mViewModelStores));
    }
复制代码

能够看到，若是咱们设置了保留Fragment，那么被保留的Fragment最终都会保存在FragmentManagerNonConfig变量中，从而被Activity#retainNonConfigurationInstances()所保存，以后做为参数传给reluanch的Activity，至此Fragment保存完毕。 下面咱们来看看保留的Fragment是如何被恢复的。 经过阅读Activity#onCreate()方法咱们发现，若是Activity.mLastNonConfigurationInstances不为null，即设备配置发生变动保存了相关数据，那么将会对Fragment进行状态恢复。Fragment的状态恢复的关键代码是mFragments.restoreAllState(),这里的mFragments是FragmentController的实例，该方法的内部最终调用了FragmentManagerImpl#restoreSaveState()，咱们来看看该方法的实现：

void restoreSaveState(Parcelable state) {
        // ...省略一段代码
        // First re-attach any non-config instances we are retaining back
        // to their saved state, so we don't try to instantiate them again.
        // 遍历保留的Fragments
        for (Fragment f : mNonConfig.getRetainedFragments()) {
            if (DEBUG) Log.v(TAG, "restoreSaveState: re-attaching retained " + f);
            FragmentState fs = null;
            // 获取以前处于Active状态的Fragments状态
            for (FragmentState fragmentState : fms.mActive) {
                if (fragmentState.mWho.equals(f.mWho)) {
                    fs = fragmentState;
                    break;
                }
            }
            // 未获取到状态直接变动生命周期
            if (fs == null) {
                if (DEBUG) {
                    Log.v(TAG, "Discarding retained Fragment " + f
                            + " that was not found in the set of active Fragments " + fms.mActive);
                }
                // We need to ensure that onDestroy and any other clean up is done
                // so move the Fragment up to CREATED, then mark it as being removed, then
                // destroy it.
                moveToState(f, Fragment.CREATED, 0, 0, false);
                f.mRemoving = true;
                moveToState(f, Fragment.INITIALIZING, 0, 0, false);
                continue;
            }
            // 恢复Fragment的状态
            fs.mInstance = f;
            f.mSavedViewState = null;
            f.mBackStackNesting = 0;
            f.mInLayout = false;
            f.mAdded = false;
            f.mTargetWho = f.mTarget != null ? f.mTarget.mWho : null;
            f.mTarget = null;
            if (fs.mSavedFragmentState != null) {
                fs.mSavedFragmentState.setClassLoader(mHost.getContext().getClassLoader());
                f.mSavedViewState = fs.mSavedFragmentState.getSparseParcelableArray(
                        FragmentManagerImpl.VIEW_STATE_TAG);
                f.mSavedFragmentState = fs.mSavedFragmentState;
            }
        }
        // ...省略一段代码
    }
复制代码

至此保留的Fragments在的状态恢复完成。