关于Android Settings中的八个题目

最新推荐文章于 2024-08-01 23:04:44 发布

winson_jason

最新推荐文章于 2024-08-01 23:04:44 发布

阅读量2.9k

点赞数

分类专栏： android

android 专栏收录该内容

125 篇文章 0 订阅

订阅专栏

原文地址：http://www.byywee.com/page/M0/S862/862201.html

本问将答复以下八个题目，如有错误，敬请批驳斧正，不堪感激感动！（注：本文中的Settings解析基于android4.0+）

题目一、Settings的主界面是怎么实现的？

题目二、为什么应用hierarchyviewer 时Settings中的很多界面显示的都是SubSettings？

题目三、hierarchyviewer 中显示SubSetting时如何断定我进入的是哪个fragment？

题目四、点击设置界面的某一个header时，设置界面是如何切换的？

题目五、Settings.java中getMetaData与getStartingFragmentClass这两个函数是否有点抵触？

题目六、Settings的shortcut是如何创建的？从shortcut进入Settings的流程是什么？

题目七、为什么我从Settings的shortcut进入时，hierarchyviewer显示的就不是SubSettings（如Data usage）？

题目八、Settings.java中很多持续自它的内部类都是空实现，为什么要写这些类？

-----------------------------------------------------------------------------------------------------------------------------------------

因为项目须要，本人就对Android中的Settings进行懂得析，能帮到对Settings有爱好的同道们～

-----------------------------------------------------------------------------------------------------------------------------------------

题目一、Settings的主界面是怎么实现的？

为了能适应平板和，Settings采取了PreferenceActivity和PreferenceFragment连络的实现体式格式。

Settings.java持续自PreferenceActivity，是Settings的主界面，它经由过程loadHeadersFromResource函数（api level 11）加载res/xml/settings_headers.xml来机关界面。在settings_headers.xml中声了然要在Settings主界面显示的各个header（如Sound、Display等）。Settings.HeaderAdapter将此中的header分为三类。在Settings.HeaderAdapter中的getView办法中按照header的类型应用不合的布局文件。

为header划分类型的函数

        static int getHeaderType（Header header） {



            if （header.fragment == null && header.intent == null） {



                return HEADER_TYPE_CATEGORY; // 因为没有指明fragment和intent



            } else if （header.id == R.id.wifi_settings || header.id == R.id.bluetooth_settings || header.id == R.id.mobiledata_settings） {



                return HEADER_TYPE_SWITCH; // 针对特定的三个header，分别为Wi-Fi、Bluetooth和Mobile data



            } else {



                return HEADER_TYPE_NORMAL;



            }



        }

点击主界面的header后会显示与该header相干的设置界面。大项目组（如Display的具体设置界面）都是经由过程持续PreferenceFragment来实现的；有一项目组是在settings_headers.xml中声明<intent>，当被点击时（触发PreferenceActivity的onHeaderClick（））将会经由过程startActivity来启动在<intent>节点中声明的targetClass（如设置中的Add account）。

题目二、为什么应用hierarchyviewer 时Settings中的很多界面显示的都是SubSettings？

要解决这个题目我们先要清楚为什么会写一个SubSettings.java持续自Settings.java？

SubSettings.java中的注释很清楚的告诉了我们原因：

Stub class for showing sub-settings; we can""t use the main Settings class since for our app it is a special singleTask class。

本来是因为Settings.java在声明时指定了android:launchMode="singleTask"。

我们知道，要显示Fragment的内容，我们就须要为其指定一个Activity。而Settings中的很多设置界面是由PreferenceFragment来完成的，当然也须要我们指定Activity.

onBuildStartFragmentIntent函数会为我们机关一个显示Fragment的Intent对象（该函数的注释写的很是熟悉打听）.Settings.java重写了这个函数（注，重写时它调用了super的该办法），在为intent对象setClass时都应用SubSettings.java.（注：在settings_headers.xml指定了intent的header是不会触发onBuildStartFragmentIntent的）

成果就是，Settings中大项目组fragment都是应用的SubSettings这个Activity来显示。因为hierarchyviewer只是显示当前界面应用的Activity（不克不及显示这个界面是由哪个Fragment机关的），所以我们应用hierarchyviewer 对Settings进行调查时很多设置界面显示的是SubSettings。

题目三、hierarchyviewer 中显示SubSetting时如何断定我进入的是哪个fragment？

在res/xml/settings_headers.xml中声了然各个header被点击后应用的fragment。我们可以按照这个文件断定我们进入的fragment。

例如，点击Display时hierarchyviewer 中显示SubSetting。我们经由过程查找settings_headers就可知道应用的是哪个fragment。

Display这个header在settings_headers.xml中的声明：

    <!-- Display -->



    <header



        android:id="＠+id/display_settings"



        android:icon="＠drawable/ic_settings_display"



        android:fragment="com.android.settings.DisplaySettings"



        android:title="＠string/display_settings" />

header中应用 android:fragment指明应用的fragment。由此可知，Display应用的是com.android.settings.DisplaySettings这个fragment

题目四、点击设置界面的某一个header时，设置界面是如何切换的？

点击设置界面的header时，会触发Settings中onHeaderClick函数，首要的处理惩罚都在其父类PreferenceActivity的onHeaderClick中实现的。若是这个header指定了fragment，在mSinglePane（标识是否为小屏幕设备。如，区分别机还是平板）为true时，会调用startWithFragment办法，在startWithFragment办法中将调用onBuildStartFragmentIntent办法来机关intent对象（首要），最后应用该intent对象启动一个activity来显示fragment。

以点击Settings中的Display为例.

（Bluetooth同理，只不过启动的Activity变为BluetoothSettingsActivity（持续自Settings，然则没有实现重写任何办法，所以与SubSettings是一样的处理惩罚），fragment变为 com.android.settings.bluetooth.BluetoothSettings）

fragment是com.android.settings.DisplaySettings，activity是com.android.settings.SubSettings.（fragment是由onHeaderClick函数传入的，activity是由onBuildStartFragmentIntent（）指定的）

履行startActivity后将启动SubSettings.java。即我们将会再一次履行SubSettings和PreferenceActivity的onCreate办法（因为Settings.java的onCreate办法调用了super.onCreate（）），然则此次并不会进入Settings的主界面，因为我们的应用的intent对象是有很大不合的。这一次onCreate函数（PreferenceActivity）中的initialFragment 将被初始化为com.android.settings.DisplaySettings，然后我们将进入switchToHeader（），最后switchToHeaderInner会取得FragmentTransaction对象，然后履行了transaction.replace（com.android.internal.R.id.prefs， f）.就如许把我们的fragment显示出来了。在onCreate中会对其他view的visibility进行设置，以包管只显示prefs。如，将com.android.internal.R.id.headers的visibility设置为VIEW.GONE.

注：PreferenceActivity的布局文件为preference_list_content.xml

题目五、Settings.java中getMetaData与getStartingFragmentClass这两个函数是否有点抵触？

这两个函数可以说是相辅相成的（好官方，^_^）。getMetaData会从AndroidManifest.xml中读取Activity的<meta-data>节点的数据；getStartingFragmentClass则从启动Activity的intent中读取数据。这两个函数会对读取到的数据进行整合，getStartingFragmentClass依附于getMetaData读取到的数据，然则它也可能对数据作出批改（为了兼容性，如对原有manage apps类进行特别处理惩罚）。

题目六、Settings的shortcut是如何创建的？从shortcut进入Settings的流程是什么？

创建Settings的shortcut时Luancher将会启动CreateShortcut，创建shortcut所需的intent对象将会由CreateShortcut和其父类LuancherActivity共同构建（详见 CreateShortcut的onListItemClick），这时创建的Intent对象应用的就不是SubSettings了（LuancherActivity中intentForPosition函数履行setClassName（）时应用的参数并不是SubSettings）.

CreateShortcut中列出了可以创建shortcut的设置项，这些设置项如何检索出来的？

本来，在创建LuancherActivity的ActivityAdapter对象时，其机关函数中履行了makeListItems函数，该函数将应用PackageManager的queryIntentActivities来按照intent对象查询合适前提的activity。应用的intent是从getTargetIntent函数返回的。不难发明，要想在CreateShortcut中显示，Activity在必必要有

<category android:name="com.android.settings.SHORTCUT" />

若是我们想将Security设置项添加到shortcut列表，我们只须要在androidmanifest.xml中声明Settings￥SecuritySettingsActivity项目组加上

<category android:name="com.android.settings.SHORTCUT" />

即可。

回到正题，点击shortcut进入Settings时，传入的Intent对象中包含了目标fragment和目标activity以及其他信息。PreferenceActivity获得了足够多的信息，是以在onCreate中将依次履行switchToHeader（）->setSelectedHeader（null）->switchToHeaderInner（）->transaction.replace（com.android.internal.R.id.prefs， f）;

如许就完成了fragment的显示（应用的activity是从intent解析出来的.在switchToHeaderInner中履行Fragment.instantiate时应用的Context是this!!）。不像履行onHeaderClick那样会履行函数onBuildStartFragmentIntent（Settings中重写了该函数）来从头指定我们应用的Activity。

题目七、为什么我从Settings的shortcut进入时，hierarchyviewer显示的就不是SubSettings（如Data usage）？

hierarchyviewer中显示SubSettings是因为我们在onBuildStartFragmentIntent办法中做了特别处理惩罚（详见题目二）。从shortcut进入Settings时不显示SubSettings是因为没有走这个函数，是以就不会显示为SubSettings了（详见题目六）。

题目八、Settings.java中很多持续自它的内部类都是空实现，为什么要写这些类？

我们从这些内部类的名字可以看出它们的首要感化，如BluetoothSettingsActivity是针对蓝牙设置的。空实现申明他们都将应用Settings.java中的函数（重视private的属性和办法的接见权限题目）。声明这些Activity的原因我认为主如果为了进步各个设置项、全部Settings的灵活性，便利开辟者进行扩大。除此之外的一些原因：可以让我们为零丁的设置项添加 shortcut（如data usage），因为创建shortcut应用queryIntentActivities查询应用的activity;容许其它法度接见零丁的设置项;布局设计须要，启动Activity会读取meta-data信息;某些设置项不想应用SubSettings的属性。如，在Settings中点击Bluetooth时应用BluetoothSettingsActivity，启动Bluetooth时将应用BluetoothSettingsActivity的属性，如 android:clearTaskOnLaunch="true"。