美文网首页源码分析
Android 源码分析--onConfigurationCha

Android 源码分析--onConfigurationCha

作者: NeWolf | 来源:发表于2022-06-28 15:58 被阅读0次

    前言

    在手机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的官方文档有下面一句话:

    Activity官方文档.jpg

    也就是说,在设备配置发生变化的时候,会回调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

    相关文章

      网友评论

        本文标题:Android 源码分析--onConfigurationCha

        本文链接:https://www.haomeiwen.com/subject/vdnavrtx.html