我们应该总是从我们的代码分离应用资源，比如图片和字符串，这样我们就可以单独维护他们。我们也应该为特定的设备配置提供替代的资源，通过在特殊命名的资源目录分组。在运行的时候，安卓以当前配置为基础使用合适的资源。举例，我们可能想提供一个不同UI布局取决于屏幕大小或者不同的字符取决于语言设置。
一旦我们分离我们的应用资源，我们可以使用在工程R类生成的资源ID访问他们。如果在程序使用资源在Accessing Resource讨论。这个文档讨论如何在安卓工程分组我们的资源并且为特定设备配置提供替代的资源。
Grouping Resource Types
________________________________________
应该放置每种类型的资源在工程的res/ 目录的一个特定的子目录下。举例，下面是一个简单工程的层级：
MyProject/
src/
MyActivity.java
res/
drawable/
graphic.png
layout/
main.xml
info.xml
mipmap/
icon.png
values/
strings.xml
正如我们在这个例子看到的，res/ 目录，包含所有资源（在子目录中）：一个图片资源，两个布局资源，mipmap/ 目录为启动图标， 和一个string资源文件。资源目录的命名很重要，在下表描述。
Table 1. Resource directories supported inside project res/ directory.
Directory Resource Type
animator/ XML files that define property animations.
anim/ XML files that define tween animations. (Property animations can also be saved in this directory, but the animator/ directory is preferred for property animations to distinguish between the two types.)
color/ XML files that define a state list of colors. See Color State List Resource
drawable/ Bitmap files (.png, .9.png, .jpg, .gif) or XML files that are compiled into the following drawable resource subtypes:
? Bitmap files
? Nine-Patches (re-sizable bitmaps)
? State lists
? Shapes
? Animation drawables
? Other drawables
See Drawable Resources.
mipmap/ Drawable files for different launcher icon densities. For more information on managing launcher icons with mipmap/ folders, see Managing Projects Overview.
layout/ XML files that define a user interface layout. See Layout Resource.
menu/ XML files that define application menus, such as an Options Menu, Context Menu, or Sub Menu. See Menu Resource.
raw/ Arbitrary files to save in their raw form. To open these resources with a raw InputStream, call Resources.openRawResource() with the resource ID, which is R.raw.filename.
However, if you need access to original file names and file hierarchy, you might consider saving some resources in the assets/ directory (instead of res/raw/). Files in assets/ are not given a resource ID, so you can read them only using AssetManager.
values/ XML files that contain simple values, such as strings, integers, and colors.
Whereas XML resource files in other res/ subdirectories define a single resource based on the XML filename, files in the values/ directory describe multiple resources. For a file in this directory, each child of the <resources> element defines a single resource.
For example, a <string> element creates an R.string resource and a <color> element creates an R.color resource.
Because each resource is defined with its own XML element, you can name the file whatever you want and place different resource types in one file. However, for clarity, you might want to place unique resource types in different files. For example, here are
some filename conventions for resources you can create in this directory:
? arrays.xml for resource arrays (typed arrays).
? colors.xml for color values
? dimens.xml for dimension values.
? strings.xml for string values.
? styles.xml for styles.
See String Resources, Style Resource, and More Resource Types.
xml/ Arbitrary XML files that can be read at runtime by calling Resources.getXML(). Various XML configuration files must be saved here, such as a searchable configuration.
Caution:永远不要直接在res/ 目录下保存资源，会导致编译错误。
上面这些还不够，要提供可替代的资源。
Providing Alternative Resources
________________________________________
几乎每一个应用应该提供替代的资源支持特定的设备设置。例如，我们应该包含可替代的drawable资源为不同的屏幕密度和替代字符资源为不同的语言。在运行的时候，安卓检测当前设备配置，并且为我们的应用加载合适的资源。
为了指定特殊配置选择为一些资源：
Table 2. Configuration qualifier names.
Configuration Qualifier Values
Description
MCC and MNC Examples:
mcc310
mcc310-mnc004
mcc208-mnc00
etc. The mobile country code (MCC), optionally followed by mobile network code (MNC) from the SIM card in the device. For example, mcc310 is U.S. on any carrier, mcc310-mnc004 is U.S. on Verizon, and mcc208-mnc00 is France
on Orange.
If the device uses a radio connection (GSM phone), the MCC and MNC values come from the SIM card.
You can also use the MCC alone (for example, to include country-specific legal resources in your application). If you need to specify based on the language only, then use the language and region qualifier instead (discussed next). If you decide to use the MCC
and MNC qualifier, you should do so with care and test that it works as expected.
Also see the configuration fields mcc, and mnc, which indicate the current mobile country code and mobile network code, respectively.
Language and region Examples:
en
fr
en-rUS
fr-rFR
fr-rCA
etc. The language is defined by a two-letter ISO 639-1 language code, optionally followed by a two letter ISO 3166-1-alpha-2 region code (preceded by lowercase "r").
The codes are not case-sensitive; the r prefix is used to distinguish the region portion. You cannot specify a region alone.
This can change during the life of your application if the user changes his or her language in the system settings. See Handling Runtime Changes for information about how this can affect your application during runtime.
See Localization for a complete guide to localizing your application for other languages.
Also see the locale configuration field, which indicates the current locale.
Layout Direction ldrtl
ldltr The layout direction of your application. ldrtl means "layout-direction-right-to-left". ldltr means "layout-direction-left-to-right" and is the default implicit value.
This can apply to any resource such as layouts, drawables, or values.
For example, if you want to provide some specific layout for the Arabic language and some generic layout for any other "right-to-left" language (like Persian or Hebrew) then you would have:
res/
layout/
main.xml (Default layout)
layout-ar/
main.xml (Specific layout for Arabic)
layout-ldrtl/
main.xml (Any "right-to-left" language, except
for Arabic, because the "ar" language qualifier
has a higher precedence.)
Note: To enable right-to-left layout features for your app, you must set supportsRtl to "true" and set targetSdkVersion to 17 or higher.
Added in API level 17.
smallestWidth sw<N>dp
Examples:
sw320dp
sw600dp
sw720dp
etc. The fundamental size of a screen, as indicated by the shortest dimension of the available screen area. Specifically, the device‘s smallestWidth is the shortest of the screen‘s available height and width (you may also
think of it as the "smallest possible width" for the screen). You can use this qualifier to ensure that, regardless of the screen‘s current orientation, your application has at least <N> dps of width available for its UI.
For example, if your layout requires that its smallest dimension of screen area be at least 600 dp at all times, then you can use this qualifer to create the layout resources, res/layout-sw600dp/. The system will use these resources only when the smallest dimension
of available screen is at least 600dp, regardless of whether the 600dp side is the user-perceived height or width. The smallestWidth is a fixed screen size characteristic of the device; the device‘s smallestWidth does not change when the screen‘s orientation
changes.
The smallestWidth of a device takes into account screen decorations and system UI. For example, if the device has some persistent UI elements on the screen that account for space along the axis of the smallestWidth, the system declares the smallestWidth to
be smaller than the actual screen size, because those are screen pixels not available for your UI. Thus, the value you use should be the actual smallest dimension required by your layout (usually, this value is the "smallest width" that your layout supports,
regardless of the screen‘s current orientation).
Some values you might use here for common screen sizes:
? 320, for devices with screen configurations such as:
o 240x320 ldpi (QVGA handset)
o 320x480 mdpi (handset)
o 480x800 hdpi (high-density handset)
? 480, for screens such as 480x800 mdpi (tablet/handset).
? 600, for screens such as 600x1024 mdpi (7" tablet).
? 720, for screens such as 720x1280 mdpi (10" tablet).
When your application provides multiple resource directories with different values for the smallestWidth qualifier, the system uses the one closest to (without exceeding) the device‘s smallestWidth.
Added in API level 13.
Also see the android:requiresSmallestWidthDp attribute, which declares the minimum smallestWidth with which your application is compatible, and the smallestScreenWidthDp configuration field, which holds the device‘s smallestWidth value.
For more information about designing for different screens and using this qualifier, see the Supporting Multiple Screens developer guide.
Available width w<N>dp
Examples:
w720dp
w1024dp
etc. Specifies a minimum available screen width, in dp units at which the resource should be used—defined by the <N> value. This configuration value will change when the orientation changes between landscape and portrait
to match the current actual width.
When your application provides multiple resource directories with different values for this configuration, the system uses the one closest to (without exceeding) the device‘s current screen width. The value here takes into account screen decorations, so if
the device has some persistent UI elements on the left or right edge of the display, it uses a value for the width that is smaller than the real screen size, accounting for these UI elements and reducing the application‘s available space.
Added in API level 13.
Also see the screenWidthDp configuration field, which holds the current screen width.
For more information about designing for different screens and using this qualifier, see the Supporting Multiple Screens developer guide.
Available height h<N>dp
Examples:
h720dp
h1024dp
etc. Specifies a minimum available screen height, in "dp" units at which the resource should be used—defined by the <N> value. This configuration value will change when the orientation changes between landscape and portrait
to match the current actual height.
When your application provides multiple resource directories with different values for this configuration, the system uses the one closest to (without exceeding) the device‘s current screen height. The value here takes into account screen decorations, so if
the device has some persistent UI elements on the top or bottom edge of the display, it uses a value for the height that is smaller than the real screen size, accounting for these UI elements and reducing the application‘s available space. Screen decorations
that are not fixed (such as a phone status bar that can be hidden when full screen) are not accounted for here, nor are window decorations like the title bar or action bar, so applications must be prepared to deal with a somewhat smaller space than they specify.
Added in API level 13.
Also see the screenHeightDp configuration field, which holds the current screen width.
For more information about designing for different screens and using this qualifier, see the Supporting Multiple Screens developer guide.
Screen size small
normal
large
xlarge ?
small: Screens that are of similar size to a low-density QVGA screen. The minimum layout size for a small screen is approximately 320x426 dp units. Examples are QVGA low-density and VGA high density.
? normal: Screens that are of similar size to a medium-density HVGA screen. The minimum layout size for a normal screen is approximately 320x470 dp units. Examples of such screens a WQVGA low-density, HVGA medium-density,
WVGA high-density.
? large: Screens that are of similar size to a medium-density VGA screen. The minimum layout size for a large screen is approximately 480x640 dp units. Examples are VGA and WVGA medium-density screens.
? xlarge: Screens that are considerably larger than the traditional medium-density HVGA screen. The minimum layout size for an xlarge screen is approximately 720x960 dp units. In most cases, devices with extra-large screens
would be too large to carry in a pocket and would most likely be tablet-style devices. Added in API level 9.
Note: Using a size qualifier does not imply that the resources are only for screens of that size. If you do not provide alternative resources with qualifiers that better match the current device configuration, the system may use whichever resources are the
best match.
Caution: If all your resources use a size qualifier that is larger than the current screen, the system will not use them and your application will crash at runtime (for example, if all layout resources are tagged with the xlarge qualifier, but the device is
a normal-size screen).
Added in API level 4.
See Supporting Multiple Screens for more information.
Also see the screenLayout configuration field, which indicates whether the screen is small, normal, or large.
Screen aspect long
notlong ?
long: Long screens, such as WQVGA, WVGA, FWVGA
? notlong: Not long screens, such as QVGA, HVGA, and VGA
Added in API level 4.
This is based purely on the aspect ratio of the screen (a "long" screen is wider). This is not related to the screen orientation.
Also see the screenLayout configuration field, which indicates whether the screen is long.
Round screen round
notround ?
round: Round screens, such as a round wearable device
? notround: Rectangular screens, such as phones or tablets
Added in API level 23.
Also see the isScreenRound() configuration method, which indicates whether the screen is round.
Screen orientation port
land ?
port: Device is in portrait orientation (vertical)
? land: Device is in landscape orientation (horizontal)
This can change during the life of your application if the user rotates the screen. See Handling Runtime Changes for information about how this affects your application during runtime.
Also see the orientation configuration field, which indicates the current device orientation.
UI mode car
desk
television
appliance watch ?
car: Device is displaying in a car dock
? desk: Device is displaying in a desk dock
? television: Device is displaying on a television, providing a "ten foot" experience where its UI is on a large screen that the user is far away from, primarily oriented around DPAD or other non-pointer interaction
? appliance: Device is serving as an appliance, with no display
? watch: Device has a display and is worn on the wrist
Added in API level 8, television added in API 13, watch added in API 20.
For information about how your app can respond when the device is inserted into or removed from a dock, read Determining and Monitoring the Docking State and Type.
This can change during the life of your application if the user places the device in a dock. You can enable or disable some of these modes using UiModeManager. See Handling Runtime Changes for information about how this affects your application during runtime.
Night mode night
notnight ?
night: Night time
? notnight: Day time
Added in API level 8.
This can change during the life of your application if night mode is left in auto mode (default), in which case the mode changes based on the time of day. You can enable or disable this mode using UiModeManager. See Handling Runtime Changes for information
about how this affects your application during runtime.
Screen pixel density (dpi) ldpi
mdpi
hdpi
xhdpi
xxhdpi
xxxhdpi
nodpi
tvdpi ?
ldpi: Low-density screens; approximately 120dpi.
? mdpi: Medium-density (on traditional HVGA) screens; approximately 160dpi.
? hdpi: High-density screens; approximately 240dpi.
? xhdpi: Extra-high-density screens; approximately 320dpi. Added in API Level 8
? xxhdpi: Extra-extra-high-density screens; approximately 480dpi. Added in API Level 16
? xxxhdpi: Extra-extra-extra-high-density uses (launcher icon only, see the note in Supporting Multiple Screens); approximately 640dpi. Added in API Level 18
? nodpi: This can be used for bitmap resources that you do not want to be scaled to match the device density.
? tvdpi: Screens somewhere between mdpi and hdpi; approximately 213dpi. This is not considered a "primary" density group. It is mostly intended for televisions and most apps shouldn‘t need it—providing mdpi and hdpi resources
is sufficient for most apps and the system will scale them as appropriate. This qualifier was introduced with API level 13.
There is a 3:4:6:8:12:16 scaling ratio between the six primary densities (ignoring the tvdpi density). So, a 9x9 bitmap in ldpi is 12x12 in mdpi, 18x18 in hdpi, 24x24 in xhdpi and so on.
If you decide that your image resources don‘t look good enough on a television or other certain devices and want to try tvdpi resources, the scaling factor is 1.33*mdpi. For example, a 100px x 100px image for mdpi screens should be 133px x 133px for tvdpi.
Note: Using a density qualifier does not imply that the resources are only for screens of that density. If you do not provide alternative resources with qualifiers that better match the current device configuration, the system may use whichever resources are
the best match.
See Supporting Multiple Screens for more information about how to handle different screen densities and how Android might scale your bitmaps to fit the current density.
Touchscreen type notouch
finger ?
notouch: Device does not have a touchscreen.
? finger: Device has a touchscreen that is intended to be used through direction interaction of the user‘s finger.
Also see the touchscreen configuration field, which indicates the type of touchscreen on the device.
Keyboard availability keysexposed
keyshidden
keyssoft ?
keysexposed: Device has a keyboard available. If the device has a software keyboard enabled (which is likely), this may be used even when the hardware keyboard is not exposed to the user, even if the device has no hardware keyboard. If no software keyboard
is provided or it‘s disabled, then this is only used when a hardware keyboard is exposed.
? keyshidden: Device has a hardware keyboard available but it is hidden and the device does not have a software keyboard enabled.
? keyssoft: Device has a software keyboard enabled, whether it‘s visible or not.
If you provide keysexposed resources, but not keyssoft resources, the system uses the keysexposed resources regardless of whether a keyboard is visible, as long as the system has a software keyboard enabled.
This can change during the life of your application if the user opens a hardware keyboard. See Handling Runtime Changes for information about how this affects your application during runtime.
Also see the configuration fields hardKeyboardHidden and keyboardHidden, which indicate the visibility of a hardware keyboard and and the visibility of any kind of keyboard (including software), respectively.
Primary text input method nokeys
qwerty
12key ?
nokeys: Device has no hardware keys for text input.
? qwerty: Device has a hardware qwerty keyboard, whether it‘s visible to the user or not.
? 12key: Device has a hardware 12-key keyboard, whether it‘s visible to the user or not.
Also see the keyboard configuration field, which indicates the primary text input method available.
Navigation key availability navexposed
navhidden ?
navexposed: Navigation keys are available to the user.
? navhidden: Navigation keys are not available (such as behind a closed lid).
This can change during the life of your application if the user reveals the navigation keys. See Handling Runtime Changes for information about how this affects your application during runtime.
Also see the navigationHidden configuration field, which indicates whether navigation keys are hidden.
Primary non-touch navigation method nonav
dpad
trackball
wheel ?
nonav: Device has no navigation facility other than using the touchscreen.
? dpad: Device has a directional-pad (d-pad) for navigation.
? trackball: Device has a trackball for navigation.
? wheel: Device has a directional wheel(s) for navigation (uncommon).
Also see the navigation configuration field, which indicates the type of navigation method available.
Platform Version (API level) Examples:
v3
v4
v7
etc. The API level supported by the device. For example, v1 for API level 1 (devices with Android 1.0 or higher) and v4 for API level 4 (devices with Android 1.6 or higher). See the Android API levels document for more information
about these values.
1. 在 res/创建一个新的目录，命名为格式： <resources_name>-<config_qualifier>.
o <resources_name> 是目录名对应默认的资源（在表1）
o <qualifier> 一个名称指定一个独立的这些资源要使用的配置（上表2）
遇到的有layout-land, values-w820dp, drawable-hdpi等，建立这些文件夹好像不显示，但是放资源的时候会有提示。
可以指定不只一个<qualifier>，使用破折号（dash）
Caution: 当添加多个<qualifiers>,必须把他们放置在表2列出的同样的顺序。如果这些qualifier被排错序，资源被忽略（这个顺序是怎么回事）。
2. 保存各个替代的资源在新目录。资源文件必须和默认资源文件命名一致。例如，下面是一些默认的和可替代的资源：
res/
drawable/
icon.png
background.png
drawable-hdpi/
icon.png
background.png
这个hdpi qualifier暗示这个那个目录的资源是为有high-densiy屏幕设备。这些drawable目录下的图片为特定屏幕密度制定大小，但是文件名称是一模一样的。这样，我们用来指向icon.png或者background.png的资源ID总是一样的。但是，安卓选择匹配当前设备最好的资源版本，通过对比设备配置信息和Resource目录名的qualifier。
安卓支持几个配置qualifier，并且我们可以添加多个qualifier到一个目录名，通过分离每个qualifier使用一个破折号。表2列出可用的配置qualifier，在程序中，如果使用多个qualifier为资源目录，必须按照他们在表2列出的顺序添加。
Note:一些配置qualifier从1.0就添加了，所有不是所有版本的安卓支持所有的qualifier。
使用一个新的qualifier隐式添加平台版本qualifier这样旧版本确保忽略他。举例，使用一个w600dp qualifier会自动包含v13qualifier，因为这个available-width qualifier在API13的新的。为了避免任何问题，总是包含一些默认的资源（没有qualifier的资源）。阅读Providing the Best Device Compatibility with Resources.
Qualifier name rules
下面是是用过配置qualifier name的一些规则：
? 可以为单一资源集指定多个qualifier，通过破折号分离。比如，drawable-en-rUS-land应用于US-English设备在横向
? Qualifier的排序必须和表2列出的一致
? 替代资源目录不能嵌套，平级的吧，比如，不能这样res/drawable/drawable-en/.
? 值是不区分大小写的。资源编译器把目录名转化为小写在处理之前，避免在大小写敏感文件系统出现问题。任何名字中的大写字母仅仅是为了便于阅读
? 每个qualifier类型只有一个值是支持的。例如，如果想使用为Spain和France使用同样的drawable文件，我们不能使用一个目录命名drawable-rES-rFR/.相反，需要两个资源目录，比如drawable-rES/ 和 drawable-rFR/，每个包含合适的文件。然而，实际上，我们不被要求复制相同的文件在两个位置。相反，我们应该创建一个别名为资源。看看Create alias resoures.
在我们保存替代资源到以这些qualifier命名的目录之后，安卓系统自动在我们程序应用这些资源，以当前设备配置为基础。每次一个资源被请求，安卓检查包含请求资源的替代资源目录，然后finds the best-matching resource。如果没有替代资源匹配一个特殊设备配置，然后安卓使用相应的默认资源（没有配置qualifier的资源类型）。
Creating alias resources
当我们有一个资源，我们想为不只一个设备配置使用（但是不想提供作为一个默认的资源），我们不需要把同样的资源放在多个替代资源目录。相反，我们可以（在某些情况下），创建一个替代资源为保存在我们默认资源目录的资源作为一个别名。
Note:不是所有的资源提供一个机制，我们可以创建一个别名到另一个资源。尤其是 animation, menu, raw, and other unspecified resources in the xml/ directory do not offer this feature.
例如，假设我们有一个应用图标，icon.png，并且需要为不同的场所提供唯一的版本。然后，两个场所，English-Canadian and French-Canadian需要使用同样的版本。我们可能假设需要为English-Canadian and French-Canadian复制同样的图片到资源目录，但是不是这样的。相反，我们可以保存为他们俩的图片为icon_ca.png（任何名字而不是icon.png）,把它放在默认的res/drawable/ 目录。然后创建一个icon.xml文件在res/drawable-en-rCA/
和 res/drawable-fr-rCA/，使用<bitmap>元素指向这个icon_ca.png.这允许我们保存PNG文件的一个版本，和两个小的XML文件指向他。下面是例子：
Drawable
为一个存在的drawable创建一个别名，使用<bitmap>元素，例如：
<?xml version="1.0" encoding="utf-8"?>
<bitmap xmlns:android="http://schemas.android.com/apk/res/android"
android:src="@drawable/icon_ca" />
如果保存这个文件为icon.xml(在一个可替代的资源目录，比如res/drawable-en-rCA/),他被编译进一个资源可以指向R.drawable.icon，但是实际是R.drawable.icon_ca资源（保存在res/drawable/）的别名。
Layout
为存在的一个布局创建别名，使用<include>元素，包装在<merge>中。
<?xml version="1.0" encoding="utf-8"?>
<merge>
<include layout="@layout/main_ltr"/>
</merge>
编译和实际指向并不一样？
If you save this file as main.xml, it is compiled into a resource you can reference as R.layout.main, but is actually an alias for the R.layout.main_ltr resource.
Strings and other simple values
To create an alias to an existing string, simply use the resource ID of the desired string as the value for the new string. For example:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="hello">Hello</string>
<string name="hi">@string/hello</string>
</resources>
The R.string.hi resource is now an alias for the R.string.hello.
Other simple values work the same way. For example, a color:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<color name="yellow">#f00</color>
<color name="highlight">@color/red</color>
</resources>
Providing the Best Device Compatibility with Resources
________________________________________
为了让我们的应用支持多个设备配置，我们总是提供默认资源是很重要的。例如，如果我们的应用支持几个语言，总是包含一个 没有language and region qualifier 的values/ 目录（string保存位置）。如果我们相反，把所有string文件放到一个有一个language and region qualifier的目录，然后我们的应用会崩溃当运行在一个设备在设置的语音不支持。但是，只要提供默认的 values/ 资源，我们的应用可以合适的运行（即使用户不理解这个语言，比崩溃强）。
类似的，如果提供不同的布局资源以屏幕方向为基础，应该选择一个方向作为默认的。例如，不是提供布局资源在layout-land 为横向，layout-port为纵向，让一个作为默认的，比如layout/ 为横屏， layout-port为纵向。
提供一个默认的资源是很重要的，不仅仅是因为我们的应用可能运行这我们没有预料的的配置，而且因为新版本的安卓有时添加配置qualifier，但是维护代码兼容和老的版本，然后当一个老版本安卓运行我们的程序，他会崩溃如果我们不提供默认资源，因为它不能使用新qualifier命名的资源。例如，如果我们minSDKVersion设置为4，并且我们的所有drawable资源的qualifier使用night mode（night or notnight, which were added in API Level 8），然后一个API4设备不能访问我们的drawable资源，并且会崩溃。在这种情况下，我们可能想让notnight是默认的资源，所有我们应该排除哪个qualifier，这样我们的资源要么在drawable/
要么在drawable-night/.
所以，为了提供最好的设备兼容，总是提供默认资源。然后创建可替代资源为特殊设备配置，使用配置qualifier。
有一个例外，吐过我们的应用minSdkVersion是4或者更大，不需要，安卓会自动找到。不过还是为所以三种类型密度提供替代drawable吧。
There is one exception to this rule: If your application‘s minSdkVersion is 4 or greater, you do not need default drawable resources when you provide alternative drawable resources with the screen density qualifier. Even without default drawable resources,
Android can find the best match among the alternative screen densities and scale the bitmaps as necessary. However, for the best experience on all types of devices, you should provide alternative drawables for all three types of density.
How Android Finds the Best-matching Resource
________________________________________
当我们请求一个提供替代的资源，安卓选择哪个替代资源在运行时使用，取决于当前设备配置。为了演示安卓如何选择一个替代资源，假设下面drawable目录每个包含不同版本的同样图片：
drawable/
drawable-en/
drawable-fr-rCA/
drawable-en-port/
drawable-en-notouch-12key/
drawable-port-ldpi/
drawable-port-notouch-12key/
假设下面是设备配置：（根据下面这些配置在表2 的顺序，一个个来，只要任何一个匹配某个，排除不匹配的，然后继续走，知道最后只剩下一个，下图）
Locale = en-GB
Screen orientation = port
Screen pixel density = hdpi
Touchscreen type = notouch
Primary text input method = 12key
通过比对设备配置和可用的替代资源，安卓选择drawable-en-port中的drawable。
系统到达他的决定使用哪个资源，在下面的逻辑：
1.排除和设备设置矛盾的资源文件。Eliminate resource files that contradict the device configuration.
The drawable-fr-rCA/ directory is eliminated, because it contradicts the en-GB locale.
drawable/
drawable-en/
drawable-fr-rCA/
drawable-en-port/
drawable-en-notouch-12key/
drawable-port-ldpi/
drawable-port-notouch-12key/
Exception: Screen pixel density is the one qualifier that is not eliminated due to a contradiction. Even though the screen density of the device is hdpi, drawable-port-ldpi/ is not eliminated because every screen density is considered to be a match at this
point. More information is available in the Supporting Multiple Screens document.
2 Pick the (next) highest-precedence qualifier in the list (table 2). (Start with MCC, then move down.) 从表2第一个开始，优先级最高一个个来到第三步是否有一个目录包含这个qualifier，如果不，返回2，继续找下一个，如果是，到第四步
3 Do any of the resource directories include this qualifier?
? If No, return to step 2 and look at the next qualifier. (In the example, the answer is "no" until the language qualifier is reached.)这里是no,直到language到达
? If Yes, continue to step 4.
4 排除资源目录不包含这个这个qualifier。这个例子中，排除不包含一个language的qualifier。
drawable/
drawable-en/
drawable-en-port/
drawable-en-notouch-12key/
drawable-port-ldpi/
drawable-port-notouch-12key/
Exception: If the qualifier in question is screen pixel density, Android selects the option that most closely matches the device screen density. In general, Android prefers scaling down a larger original image to scaling up a smaller original image. See Supporting
Multiple Screens.
5.重复2和3，直到只剩下一个。这个例子，屏幕方向是下一个，所以没有指定屏幕方法排除：
drawable-en/
drawable-en-port/
drawable-en-notouch-12key/
剩下的目录是 drawable-en-port.
虽然这个程序为一个请求资源执行，系统会优化。一个优化就是一旦设备配置已知，可能忽略永远不会匹配的替代资源。例如，如果配置语言是English（en）,然后任何资源目录有资源qualifier设置为不是英语的永远不会再这个检查池（随意一个没有语言qualifier的资源目录仍然包含）。
当选择资源以屏幕大小qualifier为基础，系统会使用比当前屏幕小的如果没有更好的适配（例如，一个 large-size屏幕会使用normal-size屏幕资源如果需要）。然后如果唯一可用的资源比当前屏幕大，那么系统不会使用，我们的程序会崩溃，（例如，如果所有的布局资源标记为xlarge qualifier，但是设备是normal-size 屏幕）。
Note:对比程序的是有优先级的，虽然上面的drawable-port-notouch-12key匹配三个，但是不匹配语言，而语言比这三个(orientation, touchscreen type, and input method)都优先，所以drawable-port-notouch-12key先被排除了。
The precedence of the qualifier (in table 2) is more important than the number of qualifiers that exactly match the device. For example, in step 4 above, the last choice on the list includes three qualifiers that exactly match the device (orientation, touchscreen
type, and input method), while drawable-en has only one parameter that matches (language). However, language has a higher precedence than these other qualifiers, so drawable-port-notouch-12key is out.