Android 源码分析--onConfigurationChanged

前言

在手机APP开发的时候，一般默认会适配竖屏，游戏开发除外。但是在Android平板电脑开发中，屏幕旋转的问题比较突出，可以这样说，平板电脑的最初用意就是横屏使用的，比较方便，用户会经常旋转我们设备的屏幕。

今天主要分析一下onConfigurationChanged调用的不确定性因素。

关于这个问题，笔者在网上搜索了一下关于为什么onConfigurationChanged的方法不会被调用，基本都是说清单文件里面没有正确配置，因为在Android2.3以后需要增加screenSize这个配置，完整的配置如下：

<activity    android:name=".MainActivity"    
android:configChanges="orientation|screenSize">   
   <intent-filter>        
          <action android:name="android.intent.action.MAIN"/>         
         <category android:name="android.intent.category.LAUNCHER"/>
    </intent-filter>
</activity>

但是完全搜索不到关于我的问题的搜索结果，毕竟做Android平板的并不多，因此写下来记录自己的学习过程。

关于官方文档

我们知道，在Activity、View（ViewGroup）、Fragment、Service、Content Provider等等在设备的配置发生变化的时候，会回调onConfigurationChanged的方法。实质上主要是Activity中收到AMS的通知，回调，然后把事件分发到Window、Fragment、ActionBar等。

下面我们可以通过Activity的 onConfigurationChanged方法源码可以看到：

public void onConfigurationChanged(Configuration newConfig) {
    mCalled = true;

    //分发到Activity中的所有Fragment
    mFragments.dispatchConfigurationChanged(newConfig);

    //分发到Activity的Window对象
    if (mWindow != null) {
        // Pass the configuration changed event to the window
        mWindow.onConfigurationChanged(newConfig);
    }

    //分发到Activity的ActionBar
    if (mActionBar != null) {
        mActionBar.onConfigurationChanged(newConfig);
    }
}

这里我们讨论的是为什么当我们的界面在设备配置发生变化的时候（屏幕旋转），有时候并不会回调onConfigurationChanged呢？

关于Activity的官方文档有下面一句话：

image

也就是说，在设备配置发生变化的时候，会回调onConfigurationChanged，但是前提条件是当你的Activity（组件）还在运行的时候。

这就很明显了，说明一旦你的界面暂停以后就不会回调这个方法了。但是这样会导致一个问题，就是你的界面跳转到其他界面的时候（当前界面暂停），然后发生了一次屏幕旋转，再返回的时候，你的界面虽然旋转了，但是并没有回调onConfigurationChanged方法，并没有执行你的UI适配代码。

源码分析

想到四大组件，我们第一时间应该会想到AMS(ActivityManagerService)，没错，今天我们的始发站就是AMS。

在AMS里面搜索了一下关键字Configuration，发现了updateConfigurationLocked这个方法（没有说明的情况下，都是只给出省略版）：
相信眼尖的朋友一定会看出来，在这里由AMS创建了Configuration对象，然后通过进程间通信，通知我们的app进程。

private boolean updateConfigurationLocked(Configuration values, ActivityRecord starting,
        boolean initLocale, boolean persistent, int userId, boolean deferResume) {
    int changes = 0;

    if (mWindowManager != null) {
        mWindowManager.deferSurfaceLayout();
    }
    if (values != null) {
        //创建Configuration对象
        Configuration newConfig = new Configuration(mConfiguration);
        changes = newConfig.updateFrom(values);
        if (changes != 0) {
            for (int i=mLruProcesses.size()-1; i>=0; i--) {
                ProcessRecord app = mLruProcesses.get(i);
                try {
                    if (app.thread != null) {
                        //通过进程间通信，通知我们的app进程
                        app.thread.scheduleConfigurationChanged(configCopy);
                    }
                } catch (Exception e) {
                }
            }
        }
    }
}

thread是一个IApplicationThread对象，继承了IInterface接口，也就是说是一个AIDL对象，实际上这个接口的实现类是ActivityThread里面的内部类ApplicationThread。

public interface IApplicationThread extends IInterface {
}

那么就是说这时候AMS通过IApplicationThread进行了进程间通信，实际上调用了我们APP所在的进程的ActivityThread里面的内部类ApplicationThread的scheduleConfigurationChanged方法：

public void scheduleConfigurationChanged(Configuration config) {
    updatePendingConfiguration(config);
    sendMessage(H.CONFIGURATION_CHANGED, config);
}

这个方法很简单，就是发送消息给我们应用程序的系统Handler，然后由它来处理消息，下面继续分析处理消息的过程：

case CONFIGURATION_CHANGED:
    mCurDefaultDisplayDpi = ((Configuration)msg.obj).densityDpi;
    mUpdatingSystemConfig = true;
    handleConfigurationChanged((Configuration)msg.obj, null);
    mUpdatingSystemConfig = false;
    break;

这里继续调用了handleConfigurationChanged方法：

final void handleConfigurationChanged(Configuration config, CompatibilityInfo compat) {

    //收集需要回调onConfigurationChanged的组件信息
    ArrayList<ComponentCallbacks2> callbacks = collectComponentCallbacks(false, config);

    if (callbacks != null) {
        final int N = callbacks.size();
        for (int i=0; i<N; i++) {
            ComponentCallbacks2 cb = callbacks.get(i);
            if (cb instanceof Activity) {
                //如果当前循环的组件是Activity，那么回调Activity的onConfigurationChanged
                Activity a = (Activity) cb;
                performConfigurationChangedForActivity(mActivities.get(a.getActivityToken()),
                        config, REPORT_TO_ACTIVITY);
            } else {
                //如果当前循环不是Activity，比如说是Service等，也需要回调
                performConfigurationChanged(cb, null, config, null, REPORT_TO_ACTIVITY);
            }
        }
    }
}

这个方法首先收集需要回调onConfigurationChanged的组件信息，如果当前循环的组件是Activity，那么通过调用performConfigurationChangedForActivity方法回调Activity的onConfigurationChanged。
如果当前循环不是Activity，比如说是Service等，也需要performConfigurationChanged进行相应回调。

下面我们先看performConfigurationChangedForActivity这个方法：

private void performConfigurationChangedForActivity(ActivityClientRecord r,
                                                    Configuration newBaseConfig,
                                                    boolean reportToActivity) {
    r.tmpConfig.setTo(newBaseConfig);
    if (r.overrideConfig != null) {
        r.tmpConfig.updateFrom(r.overrideConfig);
    }
    performConfigurationChanged(r.activity, r.token, r.tmpConfig, r.overrideConfig,
            reportToActivity);
    freeTextLayoutCachesIfNeeded(r.activity.mCurrentConfig.diff(r.tmpConfig));
}

实际上也会调用performConfigurationChanged方法，这里最终会回调Activity的onConfigurationChanged方法：

private void performConfigurationChanged(ComponentCallbacks2 cb,
                                         IBinder activityToken,
                                         Configuration newConfig,
                                         Configuration amOverrideConfig,
                                         boolean reportToActivity) {
    Activity activity = (cb instanceof Activity) ? (Activity) cb : null;

    if (shouldChangeConfig) {

        if (reportToActivity) {
            final Configuration configToReport = createNewConfigAndUpdateIfNotNull(
                    newConfig, contextThemeWrapperOverrideConfig);

            //回调Activity的onConfigurationChanged方法
            cb.onConfigurationChanged(configToReport);
        }

        //这里有个注意点，就是我们需要先调用super的onConfigurationChanged方法，父类的方法中会把mCalled置为true。
        //因为上文提到，父类的方法需要进行一次分发。否则就会抛出SuperNotCalledException。
        if (activity != null) {
            if (reportToActivity && !activity.mCalled) {
                throw new SuperNotCalledException(
                        "Activity " + activity.getLocalClassName() +
                        " did not call through to super.onConfigurationChanged()");
            }
            activity.mConfigChangeFlags = 0;
            activity.mCurrentConfig = new Configuration(newConfig);
        }
    }
}

这里有个注意点，就是我们需要先调用super的onConfigurationChanged方法，父类的方法中会把mCalled置为true。
因为上文提到，父类的方法需要进行一次分发。否则就会抛出SuperNotCalledException。

我们的问题还没有解决，就是为什么我们的组件在暂停以后并不会回调呢？问题的核心代码就出在收集组件信息的时候，我们回到ActivityThread的系统Handler的handleConfigurationChanged方法中：

 callbacks = collectComponentCallbacks(false, config);

这里收集了组件的信息，下面我们点进去collectComponentCallbacks这个方法缪一眼：

ArrayList<ComponentCallbacks2> collectComponentCallbacks(
        boolean allActivities, Configuration newConfig) {

    //初始化一个ArrayList用于存储需要回调的组件信息
    ArrayList<ComponentCallbacks2> callbacks
            = new ArrayList<ComponentCallbacks2>();

    synchronized (mResourcesManager) {
        //拿到所有Application对象
        final int NAPP = mAllApplications.size();
        for (int i=0; i<NAPP; i++) {
            callbacks.add(mAllApplications.get(i));
        }
        final int NACT = mActivities.size();
        for (int i=0; i<NACT; i++) {
            //拿到所有Activity
            ActivityClientRecord ar = mActivities.valueAt(i);
            Activity a = ar.activity;
            if (a != null) {
                Configuration thisConfig = applyConfigCompatMainThread(
                        mCurDefaultDisplayDpi, newConfig,
                        ar.packageInfo.getCompatibilityInfo());
                if (!ar.activity.mFinished && (allActivities || !ar.paused)) {
                    // If the activity is currently resumed, its configuration
                    // needs to change right now.
                    //如果当前的Activity是resumed状态的时候，需要马上回调
                    callbacks.add(a);
                } else if (thisConfig != null) {
                    ar.newConfig = thisConfig;
                }
            }
        }
        //收集所有的Service信息
        final int NSVC = mServices.size();
        for (int i=0; i<NSVC; i++) {
            callbacks.add(mServices.valueAt(i));
        }
    }
    //收集所有Content Provider
    synchronized (mProviderMap) {
        final int NPRV = mLocalProviders.size();
        for (int i=0; i<NPRV; i++) {
            callbacks.add(mLocalProviders.valueAt(i).mLocalProvider);
        }
    }

    return callbacks;
}

这个方法初始化一个ArrayList用于存储需要回调的组件信息，然后收集了当前应用的所有Application对象（多进程的时候可能就会有多个），Activity，Service，Content Provider信息，然后进行下一步回调。

关键是在收集Activity的时候，进行了一次判断：

if (!ar.activity.mFinished && (allActivities || !ar.paused)) {
    // If the activity is currently resumed, its configuration
    // needs to change right now.
    //如果当前的Activity是resumed状态的时候，需要马上回调
    callbacks.add(a);

经过源码的分析，已经可以得出这个结论就是：
当Activity已经Finish掉或者已经暂停的时候，并不会把这个Activity添加进来，这样做是为了保证系统的效率，只去处理那些活跃（resume）的Activity，其他的不处理。

解决办法

• 办法一：

通过自定义广播的方式去接收android.intent.action.CONFIGURATION_CHANGED这个广播。

注意这个广播只能够在Java代码中注册才会有效果。

• 办法二：

重写Activity的onRestart代替onConfigurationChanged方法，只不过需要判断一下当前的屏幕方向。

@Override
protected void onRestart() {
    super.onRestart();
    if (isLandOrientation()) {
        //横屏

    } else {
        //竖屏

    }
}

public boolean isLandOrientation() {
    if (getResources().getConfiguration().orientation == Configuration.ORIENTATION_LANDSCAPE) {
        return true;
    } else {
        return false;
    }
}

android:configChangesd 配置

列出 Activity 将自行处理的配置变更。在运行时发生配置变更时，默认情况下会关闭 Activity 并将其重启，但使用该属性声明配置将阻止 Activity 重启。相反，Activity 会保持运行状态，并且系统会调用其 onConfigurationChanged() 方法。

注意：应避免使用该属性，并且只应在万不得已的情况下使用。如需了解有关如何正确处理配置变更所致重启的详细信息，请阅读处理运行时变更。

任何或所有下列字符串均是该属性的有效值。若有多个值，则使用“|”进行分隔，例如“locale|navigation|orientation”。

值	说明
“density”	显示密度发生变更 - 用户可能已指定不同的显示比例，或者有不同的显示现处于活跃状态。
在 API 级别 24 中引入。
“fontScale”	字体缩放系数发生变更 - 用户已选择新的全局字号。
“keyboard”	键盘类型发生变更 - 例如，用户插入外置键盘。
“keyboardHidden”	键盘无障碍功能发生变更 - 例如，用户显示硬键盘。
“layoutDirection”	布局方向发生变更 - 例如，自从左至右 (LTR) 更改为从右至左 (RTL)。
在 API 级别 17 中引入。
“locale”	语言区域发生变更 - 用户已为文本选择新的显示语言。
“mcc”	IMSI 移动设备国家/地区代码 (MCC) 发生变更 - 检测到 SIM 并更新 MCC。
“mnc”	IMSI 移动设备网络代码 (MNC) 发生变更 - 检测到 SIM 并更新 MNC。
“navigation”	导航类型（轨迹球/方向键）发生变更。（这种情况通常不会发生。）
“orientation”	屏幕方向发生变更 - 用户旋转设备。注意：如果应用面向 Android 3.2（API 级别 13）或更高版本的系统，则还应声明 "screenSize" 和 "screenLayout" 配置，因为当设备在纵向模式与横向模式之间切换时，该配置也会发生变更。
“screenLayout”	屏幕布局发生变更 - 现处于活跃状态的可能是其他显示模式。
“screenSize”	当前可用屏幕尺寸发生变更。在 API 级别 13 中引入。该值表示目前可用尺寸相对于当前宽高比的变更，当用户在横向模式与纵向模式之间切换时，它便会发生变更。
“smallestScreenSize”	物理屏幕尺寸发生变更。该值表示与方向无关的尺寸变更，因此它只有在实际物理屏幕尺寸发生变更（如切换到外部显示器）时才会变化。对此配置所作变更对应 smallestWidth 配置的变化。在 API 级别 13 中引入。
“touchscreen”	触摸屏发生变更。（这种情况通常不会发生。）
“uiMode”	界面模式发生变更 - 用户已将设备置于桌面或车载基座，或者夜间模式发生变更。如需了解有关不同界面模式的更多信息，请参阅 [UiModeManager]https://developer.android.google.cn/reference/android/app/UiModeManager)。在 API 级别 8 中引入。

所有这些配置变更都可能影响应用所看到的资源值。因此，调用 onConfigurationChanged() 时，通常有必要再次检索所有资源（包括视图布局、可绘制对象等），以正确处理变更。

注意：如要处理所有多窗口模式相关的配置变更，请使用 "screenLayout" 和 "smallestScreenSize"。Android 7.0（API 级别 24）或更高版本的系统支持多窗口模式。

详细请参考：https://developer.android.google.cn/guide/topics/manifest/activity-element