Configuration changed事件传递流程

当设备配置发生变更时，系统会调用AMS的updateConfiguration()方法，来通知AMS处理configuration changed事件，ActivityManagerService#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);
        }
    }
}	

可以看到ActivityManagerService#updateConfiguration()内部调用了ActivityManagerService#updateConfigurationLocked()，该方法一共做了两件事：

1. 调用ActivityManagerService#updateGlobalConfigurationLocked()更新当前配置信息
2. 调用ActivityManagerService#ensureConfigAndVisibilityAfterUpdate()确保给定的activity使用的是当前配置。如果返回true表示activity未被重启，否则让该activity destroyed以适配当前配置。

ActivityManagerService#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;
    }

这里可以看到，真正完成Activity配置更新的是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;
    }

可以看到决定是否需要reLaunch的关键代码是ActivityRecord#shouldRelaunchLocked(changes, mTmpConfig)。另外一个值得关注的点是forceNewConfig变量，如果改值为true，则会忽略activity的configChanges配置，强制重启activity。其值仅在调用ActivityStack#restartPackage()时为true。ActivityRecord#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通过比对变更事件是否在Activity自己可以处理的范围内来决定是否reLaunch，而configChanged正是我们在Manifest.xml中配置的android:configChanges属性。

reLunch的调用流程

我们接着往下看，可以发现真正执行reLuanch逻辑的是ActivityRecord#relaunchActivityLocked()方法：

void relaunchActivityLocked(boolean andResume, boolean preserveWindow) {
        // ...省略一段代码
        try {
            // ...省略log代码
            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);
            // 关键代码1
            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);
        }
        // ...省略一段代码
    }

首先我们看关键代码2。 service.getLifecycleManager()返回的是一个ClientLifecycleManager的实例，其scheduleTransaction(ClientTransaction)方法最终会调用ClientTransaction#schedule():

    public void schedule() throws RemoteException {
        // mClient为ApplicationThead类型变量
        mClient.scheduleTransaction(this);
    }

最终消息通过ApplicationThead转发到了ActivityThread,并调用ActivityThread#sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction)交由H处理。

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

H会通过TransactionExecutor执行该ransaction，内部会遍历通过addCallback()传递给transaction的callbacks，callbacks的execute(ClientTransactionHandler, IBinder,PendingTransactionActions)都会被调用，而此时callback接收到的ClientTransactionHandler对象是类型正是ActivityThread。 让我们回到关键代码1.这里添加了一个ActivityRelaunchItem类型的callback。它继承自ClientTransactionItem，在它execute()中调用了ClientTransactionHandler#handleRelaunchActivity(mActivityClientRecord, pendingActions)来执行reluanch真正逻辑：

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);
}

通过对关键代码2的分析，我们知道这里实际会调用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#onConfigurationChanged(Configuration)调用时机

现在要解决的疑惑是，当变更的配置在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在的状态恢复完成。