Android适配——采用Values-dpi-wSize X hSize 模式，并分析原理

可以查看最新的文章《Android屏幕适配》：http://blog.csdn.net/wolinxuebin/article/details/54288798

9月27号，更新，从源码的中找到了关于分辨率写法以及android如何查找dpi资源的代码，见第3章。

这篇文章主要讲两点：

一、xxxhdpi、560dpi、xxhdpi、xhdpi、hdpi、mdpi、ldpi (还有tvdpi 主要用于电视，不去讨论) 在某个dpi缺失的情况下，如果去找寻。

二、values-xxhdpi-1920X1080 这种以dpi加屏幕分辨率的适配方案是什么规律。

一、各种dpi之间的关系

【1】：由于网上以及存在一篇很好的文章，所以就不细讲了，这里给出链接地址：http://blog.csdn.net/a220315410/article/details/11896189 【文章1】

【2】：其次还看可以去查看官方文档：https://developer.android.com/guide/topics/resources/providing-resources.html 【文章2】

       为了方便查阅，在文章的末尾列出了google的“配置限定符名称”表格。 所有res/下的文件都必须遵守，否则会报错，具体命名规则请参考【文章1】或者Google 官方文档【文章2】。

这里我们将讨论下如果我们在res下存在 values-xxhdpi 以及values-hdpi，values-mdpi，values-ldpi 以及默认的values文件夹。【注，假设每个文件都有我们需要的资源】

【情景一】，设备为：xxhdpi（或hdpi, 或 mdpi, 或 ldpi）的情况下， 因为res/下存在相应的目录，所以讲匹配各自相应的目录便可，这叫“最佳匹配”。

【情景二】，设备为xhdpi,发现上述目录中没有相应的资源，那该如何？将会到哪个目录下寻找？

会去最近的比自己高的dpi，也就是xxhdpi，如果没有xxhdpi，那么会找560dpi，最后找xxxhdpi，也就是 xxhdpi>560dpi>xxxhdpi

如果没有自己高的呢？ 找里自己最近的小dpi（values一般称为default，会比ldpi高） mdpi > default>ldpi

总结，来一个总的顺序 xxxhdpi->560dpi->xxhdpi->xhdpi->hdpi->mdpi->default->ldpi。

如果缺少hdpi，先往上找xhdpi > xxhdpi> 560dpi > xxxhdpi，如果都没有则 mdpi > default > ldpi

1） 如果资源是dimen或Integer等,以取到的值为准

2） 如果是图片资源，按照相应的比例进行压缩或放大。 如hdpi为240 xxdpi为 480 ，所以hdpi的设备到xxhdpi中拿到的图片将会压缩至原来的1/2。反之放大2倍。

二、在资源后面带上分辨率 如（xxhdpi-1920X1080）

命名规范，google官方没有这种规定，所以根据文章末尾的“配置限定符名称”表中的命名规则进行测试，发现1920X1080方这一名称和表格最后的“平台版本”为同一等级（谁先谁后都行）

匹配规律：

1）1920X1080 与 1080X1920 是完全一样的，如果都写上将报 ：Error: Duplicate resources (最后取其较长的为屏幕的高度)

2）如果长或宽，有一个超过机子的分辨率，将不会被匹配 （如 1920X1080 的手机， 如果长度为1921，或其中一个较小的值超过了1080，都不会被匹配）

3）如果宽度和高度两个数值的和相等的情况下，高度（较大的数）越接近实际手机高度的将会被匹配。 （1920X80 与 1000X1000 将会匹配1920X80）

4）如果两个数之和不相等，那么取和较大的进行匹配。 （也就是 1920X80 与 1001X1000 将会匹配1001X1000）

注：以上这几条规律，由于google没有做相应的官方文档，全都是通过实验得到，如果有错误，请在评论中留言，大家共同进步。 看第三章

三、从源码的角度，分析以上的几个论点

在Android的源码中的ResourceTypes的getEntry中有如下两个关键的函数，一个是match，另一个是isBatterThan。具体见下面：

3.1 match函数

从上述函数中可以看到，的确有screenSize的定义，节选代码如下：

bool ResTable_config::match(const ResTable_config& settings) const {
    //....
    if (screenSize != 0) {
        if (screenWidth != 0 && screenWidth > settings.screenWidth) {
            return false;
        }
        if (screenHeight != 0 && screenHeight > settings.screenHeight) {
            return false;
        }
    }
    if (version != 0) {
        if (sdkVersion != 0 && sdkVersion > settings.sdkVersion) {
            return false;
        }
        if (minorVersion != 0 && minorVersion != settings.minorVersion) {
            return false;
        }
    }
    return true;
}

3.2 isBatterThan函数

这个函数的主要作用是选择最合适的资源，节选代码如下：

bool ResTable_config::isBetterThan(const ResTable_config& o,
        const ResTable_config* requested) const {
    if (requested) {
        //...

        if (screenType || o.screenType) {
            if (density != o.density) {
                // Use the system default density (DENSITY_MEDIUM, 160dpi) if none specified.
                const int thisDensity = density ? density : int(ResTable_config::DENSITY_MEDIUM);
                const int otherDensity = o.density ? o.density : int(ResTable_config::DENSITY_MEDIUM);

                // We always prefer DENSITY_ANY over scaling a density bucket.
                if (thisDensity == ResTable_config::DENSITY_ANY) {
                    return true;
                } else if (otherDensity == ResTable_config::DENSITY_ANY) {
                    return false;
                }

                int requestedDensity = requested->density;
                if (requested->density == 0 ||
                        requested->density == ResTable_config::DENSITY_ANY) {
                    requestedDensity = ResTable_config::DENSITY_MEDIUM;
                }

                // DENSITY_ANY is now dealt with. We should look to
                // pick a density bucket and potentially scale it.
                // Any density is potentially useful
                // because the system will scale it.  Scaling down
                // is generally better than scaling up.
                int h = thisDensity;
                int l = otherDensity;
                bool bImBigger = true;
                if (l > h) {
                    int t = h;
                    h = l;
                    l = t;
                    bImBigger = false;
                }

                if (requestedDensity >= h) {
                    // requested value higher than both l and h, give h
                    return bImBigger;
                }
                if (l >= requestedDensity) {
                    // requested value lower than both l and h, give l
                    return !bImBigger;
                }
                // saying that scaling down is 2x better than up
                if (((2 * l) - requestedDensity) * h > requestedDensity * requestedDensity) {
                    return !bImBigger;
                } else {
                    return bImBigger;
                }
            }

            if ((touchscreen != o.touchscreen) && requested->touchscreen) {
                return (touchscreen);
            }
        }

        //......

        if (screenSize || o.screenSize) {
            // "Better" is based on the sum of the difference between both
            // width and height from the requested dimensions.  We are
            // assuming the invalid configs (with smaller sizes) have
            // already been filtered.  Note that if a particular dimension
            // is unspecified, we will end up with a large value (the
            // difference between 0 and the requested dimension), which is
            // good since we will prefer a config that has specified a
            // size value.
            int myDelta = 0, otherDelta = 0;
            if (requested->screenWidth) {
                myDelta += requested->screenWidth - screenWidth;
                otherDelta += requested->screenWidth - o.screenWidth;
            }
            if (requested->screenHeight) {
                myDelta += requested->screenHeight - screenHeight;
                otherDelta += requested->screenHeight - o.screenHeight;
            }
            if (myDelta != otherDelta) {
                return myDelta < otherDelta;
            }
        }

        //...
    }
    return isMoreSpecificThan(o);
}

3.2.1 屏幕密度资源

上述代码中，地一段是关于如何选取最优的屏幕密度资源，注释有有一句话，大致意思是，从高密度到到低密度的效率会高过从低密度到高密度转化。这段代码总结来是如下几条：

1、系统默认屏幕密码==mdpi

2、如果request 密度 < 当前遍历的密度 和 best密度（之前最佳项） 那么就讲他们取他们两者间小的

3、如果request 密度 < 当前遍历的密度 和 best密度（之前最佳项） 那么就讲他们取他们两者间大的

4、如果request 密度（r） 在 当前遍历的密度(l) 和 best密度（之前最佳项）(h) 之间 (l 和 h的位置可以变化，代表其中小的) 那么遵循 (2*l - r) * h > r * r 这个条件，也就是说寻找更靠近 request 密度的资源

3.2.2 像素资源

第二段是关于屏幕分辨率的，可以将上述代码进行化简（前提是当前屏幕满足） wSize + hSize 的和越接近 requestWSize + requestHSize，作为最佳资源。

参考文献：

【1】Android应用程序资源的编译和打包过程分析

【2】Android应用程序资源的查找过程分析

【3】 google 6.0源码

google官方表格：配置限定符名称表

配置	限定符值	描述
MCC 和 MNC	示例： mcc310 mcc310-mnc004 mcc208-mnc00 等等	移动国家代码 (MCC)，（可选）后跟设备 SIM 卡中的移动网络代码 (MNC)。例如，mcc310是指美国的任一运营商，mcc310-mnc004 是指美国的 Verizon 公司，mcc208-mnc00 是指法国的 Orange 公司。 如果设备使用无线电连接（GSM 手机），则 MCC 和 MNC 值来自 SIM 卡。 也可以单独使用 MCC（例如，将国家/地区特定的合法资源包括在应用中）。如果只需根据语言指定，则改用“语言和区域”限定符（稍后进行介绍）。 如果决定使用 MCC 和 MNC 限定符，请谨慎执行此操作并测试限定符是否按预期工作。 另请参阅配置字段 mcc 和 mnc，这两个字段分别表示当前的移动国家代码和移动网络代码。
语言和区域	示例： en fr en-rUS fr-rFR fr-rCA 等等	语言通过由两个字母组成的 ISO 639-1 语言代码定义，（可选）后跟两个字母组成的 ISO 3166-1-alpha-2 区域码（前带小写字母“r”）。 这些代码不区分大小写；r 前缀用于区分区域码。 不能单独指定区域。 如果用户更改系统设置中的语言，它有可能在应用生命周期中发生改变。 如需了解这会在运行期间给应用带来哪些影响，请参阅处理运行时变更。 有关针对其他语言本地化应用的完整指南，请参阅本地化。 另请参阅 locale 配置字段，该字段表示当前的区域设置。
布局方向	ldrtl ldltr	应用的布局方向。ldrtl 是指“布局方向从右到左”。ldltr 是指“布局方向从左到右”，这是默认的隐式值。 它适用于布局、图片或值等任何资源。 例如，若要针对阿拉伯语提供某种特定布局，并针对任何其他“从右到左”语言（如波斯语或希伯来语）提供某种通用布局，则可编码如下： 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.) 注：要为应用启用从右到左的布局功能，必须将 supportsRtl 设置为 "true"，并将targetSdkVersion 设置为 17 或更高。 此项为API 级别 17 中新增配置。
smallestWidth	sw<N>dp 示例： sw320dp sw600dp sw720dp 等等	屏幕的基本尺寸，由可用屏幕区域的最小尺寸指定。 具体来说，设备的 smallestWidth 是屏幕可用高度和宽度的最小尺寸（您也可以将其视为屏幕的“最小可能宽度”）。无论屏幕的当前方向如何，您均可使用此限定符确保应用 UI 的可用宽度至少为 &lt;N&gt;dp。 例如，如果布局要求屏幕区域的最小尺寸始终至少为 600dp，则可使用此限定符创建布局资源 res/layout-sw600dp/。仅当可用屏幕的最小尺寸至少为 600dp 时，系统才会使用这些资源，而不考虑 600dp 所代表的边是用户所认为的高度还是宽度。smallestWidth 是设备的固定屏幕尺寸特性；设备的 smallestWidth 不会随屏幕方向的变化而改变。 设备的 smallestWidth 将屏幕装饰元素和系统 UI 考虑在内。例如，如果设备的屏幕上有一些永久性 UI 元素占据沿 smallestWidth 轴的空间，则系统会声明 smallestWidth 小于实际屏幕尺寸，因为这些屏幕像素不适用于您的 UI。因此，使用的值应该是布局所需要的实际最小尺寸（通常，无论屏幕的当前方向如何，此值都是布局支持的“最小宽度”）。 以下是一些可用于普通屏幕尺寸的值： 320，适用于屏幕配置如下的设备： 240x320 ldpi（QVGA 手机） 320x480 mdpi（手机） 480x800 hdpi（高密度手机） 480，适用于 480x800 mdpi 之类的屏幕（平板电脑/手机）。 600，适用于 600x1024 mdpi 之类的屏幕（7 英寸平板电脑）。 720，适用于 720x1280 mdpi 之类的屏幕（10 英寸平板电脑）。 应用为多个资源目录提供不同的 smallestWidth 限定符值时，系统会使用最接近（但未超出）设备 smallestWidth 的值。 此项为 API 级别 13 中新增配置。 另请参阅 android:requiresSmallestWidthDp 属性和 smallestScreenWidthDp 配置字段，前者声明与应用兼容的最小 smallestWidth；后者存放设备的 smallestWidth 值。 如需了解有关设计不同屏幕和使用此限定符的详细信息，请参阅支持多个屏幕开发者指南。
可用宽度	w<N>dp 示例： w720dp w1024dp 等等	指定资源应该使用的最小可用屏幕宽度，以 dp 为单位，由 <N> 值定义。在横向和纵向之间切换时，为了匹配当前实际宽度，此配置值也会随之发生变化。 应用为多个资源目录提供不同的此配置值时，系统会使用最接近（但未超出）设备当前屏幕宽度的值。 此处的值考虑到了屏幕装饰元素，因此如果设备显示屏的左边缘或右边缘上有一些永久性 UI 元素，考虑到这些 UI 元素，它会使用小于实际屏幕尺寸的宽度值，这样会减少应用的可用空间。 此项为 API 级别 13 中新增配置。 另请参阅 screenWidthDp 配置字段，该字段存放当前屏幕宽度。 如需了解有关设计不同屏幕和使用此限定符的详细信息，请参阅支持多个屏幕开发者指南。
可用高度	h<N>dp 示例： h720dp h1024dp 等等	指定资源应该使用的最小可用屏幕高度，以“dp”为单位，由 <N> 值定义。 在横向和纵向之间切换时，为了匹配当前实际高度，此配置值也会随之发生变化。 应用为多个资源目录提供不同的此配置值时，系统会使用最接近（但未超出）设备当前屏幕高度的值。 此处的值考虑到了屏幕装饰元素，因此如果设备显示屏的上边缘或下边缘有一些永久性 UI 元素，考虑到这些 UI 元素，同时为减少应用的可用空间，它会使用小于实际屏幕尺寸的高度值。 非固定的屏幕装饰元素（例如，全屏时可隐藏的手机状态栏）并不在考虑范围内，标题栏或操作栏等窗口装饰也不在考虑范围内，因此应用必须准备好处理稍小于其所指定值的空间。 此项为 API 级别 13 中新增配置。 另请参阅 screenHeightDp 配置字段，该字段存放当前屏幕宽度。 如需了解有关设计不同屏幕和使用此限定符的详细信息，请参阅支持多个屏幕开发者指南。
屏幕尺寸	small normal large xlarge	small：尺寸类似于低密度 QVGA 屏幕的屏幕。小屏幕的最小布局尺寸约为 320x426 dp 单位。例如，QVGA 低密度屏幕和 VGA 高密度屏幕。 normal：尺寸类似于中等密度 HVGA 屏幕的屏幕。标准屏幕的最小布局尺寸约为 320x470 dp 单位。例如，WQVGA 低密度屏幕、HVGA 中等密度屏幕、WVGA 高密度屏幕。 large：尺寸类似于中等密度 VGA 屏幕的屏幕。 大屏幕的最小布局尺寸约为 480x640 dp 单位。 例如，VGA 和 WVGA 中等密度屏幕。 xlarge：明显大于传统中等密度 HVGA 屏幕的屏幕。超大屏幕的最小布局尺寸约为 720x960 dp 单位。在大多数情况下，屏幕超大的设备体积过大，不能放进口袋，最常见的是平板式设备。 此项为 API 级别 9 中新增配置。 注：使用尺寸限定符并不表示资源仅适用于该尺寸的屏幕。 如果没有为备用资源提供最符合当前设备配置的限定符，则系统可能使用其中最匹配的资源。 注意：如果所有资源均使用大于当前屏幕的尺寸限定符，则系统不会使用这些资源，并且应用在运行时将会崩溃（例如，如果所有布局资源均用 xlarge 限定符标记，但设备是标准尺寸的屏幕）。 此项为 API 级别 4 中新增配置。 如需了解详细信息，请参阅支持多个屏幕。 另请参阅 screenLayout 配置字段，该字段表示屏幕是小尺寸、标准尺寸还是大尺寸。
屏幕纵横比	long notlong	long：宽屏，如 WQVGA、WVGA、FWVGA notlong：非宽屏，如 QVGA、HVGA 和 VGA 此项为 API 级别 4 中新增配置。 它完全基于屏幕的纵横比（宽屏较宽），而与屏幕方向无关。 另请参阅 screenLayout 配置字段，该字段指示屏幕是否为宽屏。
屏幕方向	port land	port：设备处于纵向（垂直） land：设备处于横向（水平） 如果用户旋转屏幕，它有可能在应用生命周期中发生改变。 如需了解这会在运行期间给应用带来哪些影响，请参阅处理运行时变更。 另请参阅 orientation 配置字段，该字段指示当前的设备方向。
UI 模式	car desk television appliancewatch	car：设备正在车载手机座上显示 desk：设备正在桌面手机座上显示 television：设备正在电视上显示，为用户提供“十英尺”体验，其 UI 位于远离用户的大屏幕上，主要面向方向键或其他非指针式交互 appliance：设备用作不带显示屏的装置 watch：设备配有显示屏，戴在手腕上 此项为 API 级别 8 中新增配置，API 13 中新增电视配置，API 20 中新增手表配置。 如需了解应用在设备插入手机座或从中移除时的响应方式，请阅读确定并监控插接状态和类型。 如果用户将设备放入手机座中，它有可能在应用生命周期中发生改变。 可以使用UiModeManager 启用或禁用其中某些模式。如需了解这会在运行期间给应用带来哪些影响，请参阅处理运行时变更。
夜间模式	night notnight	night：夜间 notnight：白天 此项为 API 级别 8 中新增配置。 如果夜间模式停留在自动模式（默认），它有可能在应用生命周期中发生改变。在这种情况下，该模式会根据当天的时间进行调整。 可以使用 UiModeManager 启用或禁用此模式。如需了解这会在运行期间给应用带来哪些影响，请参阅处理运行时变更。
屏幕像素密度 (dpi)	ldpi mdpi hdpi xhdpi xxhdpi xxxhdpi nodpi tvdpi	ldpi：低密度屏幕；约为 120dpi。 mdpi：中等密度（传统 HVGA）屏幕；约为 160dpi。 hdpi：高密度屏幕；约为 240dpi。 xhdpi：超高密度屏幕；约为 320dpi。API 级别 8 中新增配置 xxhdpi：超超高密度屏幕；约为 480dpi。API 级别 16 中新增配置 xxxhdpi：超超超高密度屏幕使用（仅限启动器图标，请参阅“支持多个屏幕”中的注释）；约为 640dpi。 API 级别 18 中新增配置 nodpi：它可用于您不希望缩放以匹配设备密度的位图资源。 tvdpi：密度介于 mdpi 和 hdpi 之间的屏幕；约为 213dpi。它并不是“主要”密度组， 主要用于电视，而大多数应用都不需要它。对于大多数应用而言，提供 mdpi 和 hdpi 资源便已足够，系统将根据需要对其进行缩放。API 级别 13 中引入了此限定符。 六个主要密度之间的缩放比为 3:4:6:8:12:16（忽略 tvdpi 密度）。因此，9x9 (ldpi) 位图相当于 12x12 (mdpi)、18x18 (hdpi)、24x24 (xhdpi) 位图，依此类推。 如果您认为图像资源在电视或其他某些设备上呈现的效果不够好，而想尝试使用 tvdpi 资源，则缩放比例为 1.33*mdpi。例如，mdpi 屏幕的 100px x 100px 图像应该相当于 tvdpi 的133px x 133px。 注：使用密度限定符并不表示资源仅适用于该密度的屏幕。 如果没有为备用资源提供最符合当前设备配置的限定符，则系统可能使用其中最匹配的资源。 如需了解有关如何处理不同屏幕密度以及 Android 如何缩放位图以适应当前密度的详细信息，请参阅支持多个屏幕。
触摸屏类型	notouch finger	notouch：设备没有触摸屏。 finger：设备有一个专供用户通过手指直接与其交互的触摸屏。 另请参阅 touchscreen 配置字段，该字段指示设备上的触摸屏类型。
键盘可用性	keysexposed keyshidden keyssoft	keysexposed：设备具有可用的键盘。如果设备启用了软键盘（不无可能），那么即使硬键盘没有展示给用户，哪怕设备没有硬键盘，也可以使用此限定符。 如果没有提供或已经禁用软键盘，则只有在显示硬键盘时才会使用此限定符。 keyshidden：设备具有可用的硬键盘，但它处于隐藏状态，且设备没有启用软键盘。 keyssoft：设备已经启用软键盘（无论是否可见）。 如果提供了 keysexposed 资源，但未提供 keyssoft 资源，那么只要系统已经启用软键盘，就会使用 keysexposed 资源，而不考虑键盘是否可见。 如果用户打开硬键盘，它有可能在应用生命周期中发生改变。 如需了解这会在运行期间给应用带来哪些影响，请参阅处理运行时变更。 另请参阅配置字段 hardKeyboardHidden 和 keyboardHidden，这两个字段分别指示硬键盘的可见性和任何一种键盘（包括软键盘）的可见性。
主要文本输入法	nokeys qwerty 12key	nokeys：设备没有用于文本输入的硬按键。 qwerty：设备具有标准硬键盘（无论是否对用户可见）。 12key：设备具有 12 键硬键盘（无论是否对用户可见）。 另请参阅 keyboard 配置字段，该字段指示可用的主要文本输入法。
导航键可用性	navexposed navhidden	navexposed：导航键可供用户使用。 navhidden：导航键不可用（例如，位于密封盖子后面）。 如果用户显示导航键，它有可能在应用生命周期中发生改变。 如需了解这会在运行期间给应用带来哪些影响，请参阅处理运行时变更。 另请参阅 navigationHidden 配置字段，该字段指示导航键是否处于隐藏状态。
主要非触摸导航方法	nonav dpad trackball wheel	nonav：除了使用触摸屏以外，设备没有其他导航设施。 dpad：设备具有用于导航的方向键。 trackball：设备具有用于导航的轨迹球。 wheel：设备具有用于导航的方向盘（不常见）。 另请参阅 navigation 配置字段，该字段指示可用的导航方法类型。
平台版本（API 级别）	示例： v3 v4 v7 等等	设备支持的 API 级别。例如，v1 对应于 API 级别 1（带有 Android 1.0 或更高版本系统的设备），v4 对应于 API 级别 4（带有 Android 1.6 或更高版本系统的设备）。如需了解有关这些值的详细信息，请参阅 Android API 级别文档。