原文链接：Supporting Multiple Screens

3：为Android 3.2声明平板布局

在运行着Android 3.0的第一代平板上，声明平板布局的合适方式是把它们放到xlarge配置限定符目录下(比如,res/layout-xlarge/)。为了向其他类型的平板类型和屏幕尺寸提供，特别是7"的平板，Android 3.2提出了一种新的方式去为各种大小的屏幕去指定资源。这种新的技术是基于你的布局所需要的空间(比如 600dp 的宽度)，而不是试图让你的布局去适应某个泛化的尺寸(比如large 或者 xlarge)。

为7"平板设计的原因是比较微妙的，当我们使用泛化尺寸去划分时，7"的平板和5"的技术上处于同一个组别(the large group)。这两种设备似乎在尺寸上非常接近，然而在UI设计风格上，显然它们的可用空间大小是不一样的。因此，7"和5"的屏幕不应该使用全部相同的布局。为了让你可以为这两种不同类型的屏幕提供不同的布局，Android现在允许你去基于真实有效的宽度或者高度去定义应用程序的布局，单位是dp。

比如，当你已经已经设计好平板风格的布局，你可能会发现当屏幕小于600dp的时候布局工作的不是很好。这个界限就成为了你的平板布局需要的最小尺寸。因此，你应该在至少在600dp以上的宽度去为你的应用程序指定这些布局文件。

你应该挑选一个宽度作为你的最小设计尺寸，或者测试你的布局支持的最小宽度。

注意：记住所有使用这些新的尺寸API的图形都是使用密度独立像素(dp)值的，你的布局维度也应该总是使用dp单位，因为你关心的是系统为屏幕密度计算之后的有效屏幕空间(而不是使用原始像素分辨率)。获取更多关于密度独立像素信息，请阅读前面的小节Terms and concepts

3.1：使用新的尺寸限定符

你可以基于有效空间布局指定的不同资源配置在表2中总结。这些新的限定符让你的应用程序可以支持特定的屏幕尺寸，而不止是原来的屏幕尺寸归类(small,normal,large,and xlarge)。

注意：你指定的这些限定词尺寸不是真正的屏幕尺寸，而是你的有效活动窗口(activity's window)使用dp单位的宽度和高度尺寸。Android系统会使用部分屏幕作为系统UI(比如在屏幕底部的系统工具栏和在顶部的状态栏)，所以部分屏幕不在你的布局有效范围内。这样，你声明的尺寸应该是你的activity所需要的尺寸--系统会把系统UI(system ui)占用的空间也算上你声明的布局空间大小。还要注意的是工具栏(Action Bar)也要考虑入你的程序窗口空间的一部分，尽管你的布局不会声明它，因此它也会减少有效地空间，在你的设计上一定要考虑到这点。

表格2 屏幕尺寸的新配置限定符(Android 3.2引入)

使用这些限定符似乎比使用屏幕尺寸类别更复杂，实际上当你决定了UI的需要的时候，这种方式会更简单。当你设计UI时，你可能主要关心的问题是应用程序在手机风格UI和使用多面板的平板风格UI上切换时的实际大小。切换的关键点是取决于你的具体设计的，可能你需要720dp宽的平板布局，可能600dp就够了，或者480dp,或者位于这些值之间。使用表2这些限定词，你可以控制布局变化的具体尺寸。

更多关于这些尺寸配置限定符的讨论，请阅读这篇文档:Providing Resources

3.2：配置例子

为了帮助你定位对不同类型设备的设计，下面是一些典型的屏幕宽度：

• 320dp:一个典型的手机屏幕(240x320 ldpi, 320x480 mdpi, 480x800 hdpi, etc).

• 480dp:一个像Streak一样中等大小的平板 (480x800 mdpi).

• 600dp:一个7寸大小的平板 (600x1024 mdpi).

• 720dp:一个10寸大小的平板(720x1280 mdpi, 800x1280 mdpi, etc).

使用表2的尺寸限定符，你的程序可以通过使用不同的宽度或者高度限定符去切换为不同的设备准备的不同的布局资源。比如，如果600dp是你的平板布局支持的最小有效宽度，那么你可以提供这两组布局:

res/layout/main_activity.xml               # For handsets
res/layout-sw600dp/main_activity.xml       # For tablets

用这种方式，平板使用的布局的有效屏幕空间的最小宽度必须是600dp。
对于你想更进一步为7寸和10寸的平板定制UI的情形，你可以定义额外的最小宽度布局：

res/layout/main_activity.xml           # For handsets (smaller than 600dp available width)
res/layout-sw600dp/main_activity.xml   # For 7” tablets (600dp wide and bigger)
res/layout-sw720dp/main_activity.xml   # For 10” tablets (720dp wide and bigger)

注意上面的两个例子是使用"smallest width"限定符: sw<N>dp，这是指定了屏幕两个维度的最小的那个，而不管屏幕现在的方向如何。因此，使用sw<N>dp是通过忽略屏幕方向来为布局指定整个有效屏幕大小的一种简单的方式。

然而，在某些情况下，对于你的布局的具体要使用多少的有效宽度和高度是很重要的。比如，如果你有带有两个并排的fragment的双面板布局，你可能会想在600dp以上的宽度屏幕上使用，不论设备是处于横屏还是竖屏状态。如此，你的资源可能看起来像这样子:

res/layout/main_activity.xml         # For handsets (smaller than 600dp available width)
res/layout-w600dp/main_activity.xml  # Multi-pane (any screen with 600dp available width or more)

注意第二个集合是使用"available width"限定符的：w<N>dp.通过这种方式，同一台设备实际上把两种布局方式都用上，这取决于屏幕当时的方向(如果其中一个方向的有效宽度至少是600dp而另外一个少于600dp).
如果你关心的是有效高度，那么同样地你也可以使用h<N>dp 限定符。或者,组合使用w<N>dp and h<N>dp 限定符如果你需要这么精确的话。

3.3：声明屏幕尺寸支持

当你已经为多种屏幕尺寸实现了布局，在manifest文件中声明你程序支持哪些屏幕也是同等重要的。
和为屏幕尺寸准备的新的配置限定符一起，Android 3.2 为manifest元素<supports-screens>提出了新的属性：

android:requiresSmallestWidthDp

该属性指定了需要的最小smallestWidth,smallestWidth是应用程序UI有效的屏幕空间中最小的那个维度，单位是dp。即，有效屏幕的两个维度的最小值。因此，为了让设备能兼容程序，设备的smallestWidth必须要等于或者大于这个值。(通常，你为这个属性提供的那个值是你的布局支持的smallestWidth,不管屏幕当时的方向如何)。
例如，如果你的程序只为最小有效宽度为600dp的平板设备设计，那么可以这样声明:
<manifest ... >
    <supports-screens android:requiresSmallestWidthDp="600" />
    ...
</manifest>
然而，如果你的你的程序要支持所有的屏幕尺寸(比如最小的是426dp x 320dp),那么你没有必要徐声明这个属性，因为应程序需要的最小宽度是任何设备中的可能出现的最小值。
注意：Android系统不会注意到这个属性，所以它不会影响你程序的运行。然而，它会在一些如Google Play这样的服务平台上用来过滤应用程序。值得一提的是，Google Play目前还不支持这个属性过滤(在 Android 3.2上)，所以你应该继续使用其他的尺寸属性如果你的程序不支持小屏幕。

android:compatibleWidthLimitDp

该属性让你可以开启screen compatibility mode(屏幕兼容模式)作为用户可选的特性，该模式指定了你应用程序支持的最大"smallest width"。如果设备的有效屏幕最小的那边比这个值大，用户还是可以安装你的程序，但是会运行在屏幕兼容模式下。默认地，屏幕兼容模式是禁止的，你的布局会调整为充满屏幕，但是在系统栏的按钮是可以让用户去切换屏幕兼容模式的开和关。

注意：如果你的程序布局可以合适地在大屏幕上调整，你就没有必要去使用这个属性了。我们推荐你应该避免使用这个属性，而应该根据这篇文档的建议和确保你布局的调整。

android:largestWidthLimitDp

该属性让你强制开启screen compatibility mode,该模式指定了你应用程序支持的最大"smallest width"。如果设备的有效屏幕最小的那边比这个值大，程序会运行在屏幕兼容模式下，并且用户没有任何方式去禁用它。

注意：如果你的程序布局可以合适地在大屏幕上调整，你就没有必要去使用这个属性了。我们推荐你应该避免使用这个属性，而应该根据这篇文档的建议和确保你布局的调整。

提醒：当在Android3.2或者更高版本上开发时，你不应该使用老的屏幕尺寸属性和上面列出的属性组合，使用这些新的属性和就的属性可能会导致意想不到的情况。

获取更多的这些属性的信息，可以点击上面相应的链接。

4：最佳实践

支持多屏的目标是创建一个程序能运行良好和在Android支持的多数屏幕配置下好看。这篇文档的前面几个小节提供了有关Android如何使你的程序适配屏幕的信息，和怎么在不同的屏幕配置下定义程序的UI。这一姐将提供一些额外的小技巧和总结有关帮助你确保程序能在不同屏幕配置合适缩放的技术。

下面是有关如何保证你的程序合适显示在不同的设备上的一个快速清单:
1: 使用wrap_content, fill_parent, 或者 dp 单位当在XML布局文件中定义维度时。
2: 不要再程序代码中使用硬编码的像素值。
3: 不要使用AbsoluteLayout (它已经过时)
4: 为不同屏幕密度提供可选择bitmap drawables

1.为布局维度使用wrap_content, fill_parent, 或者 dp 单位

当在XML布局文件中为view定义android:layout_width 和 android:layout_height 时，使用wrap_content, fill_parent, 或者 dp 单位能保证在当前设备屏幕上为view赋予一个合适的值。
举个例子，在一个medium-density屏幕上的一个宽度定义为layout_width="100dp"的View测量为100像素，在high-density屏幕上这回放大为150像素，因此这个View占用了大致相等的物理屏幕空间。
相似的，你应该为字体大小使用sp(scale-independent pixel)。sp缩放因素取决于用户设置，系统会对dp进行相同的尺寸缩放。

2.不要再程序代码中使用硬编码的像素值

由于性能的原因和为了让代码更简洁，Android系统使用像素作为坐标或者维度的标准单位。这意味着View的维度总是会使用像素去表达，但是基于当前屏幕密度下的。例如，如果 myView.getWidth()返回10，那么该view在当前屏幕中是10个像素，但是在一个有更高密度的屏幕的设备上，这个值可能会返回15。如果你在程序代码中使用像素作为不会在当前屏幕密度下预缩放图片的单位，你可能需要在代码中缩放像素值去匹配没有缩放的图片资源。如果你需要在程序运行时处理图片或者像素值，可以参考这个小节：Additional Density Considerations

3.不要使用AbsoluteLayout
不像其他的布局组件， AbsoluteLayout强制使用固定位置去布局它的子view，这会很容易导致UI不能在不同的屏幕上很好地工作。因此，AbsoluteLayout在Android1.5(API Level 3)之后就过时了。
你应该用RelativeLayout代替它，它可以使用相对的位置去布局它的子View。例如，你可以指定一个Button应该在一个TextView的右边。

4.使用特定的尺寸和密度资源 

尽管系统会根据当前屏幕配置去缩放你的布局或者drawable resources,但你可能想在不同的屏幕尺寸下为UI做不同的调整，提供为不同密度屏幕优化过的bitmap drawables。这些内容已经文档前面提到了。如果你需要在繁多的屏幕配置下严格控制程序的界面，可以通过在特定配置的资源目录下调整你的布局和bitmap drawables。比如，考虑在中等密度和高密度屏幕下显示的一个图标。简单地创建两张不同尺寸的图标(如100x100给中等密度，150x150给高密度)，然后把它们分别放到合适限定符的目录下。
res/drawable-mdpi/icon.png   //for medium-density screens
res/drawable-hdpi/icon.png   //for high-density screens
注意：如果没有在资源目录下定义密度限定符目录，系统会假定在该目录下的资源师为基准终端密度设计的，而会其他密度下作适当的缩放。
更多有关有效配置限定符的信息，看文档前面的小节：使用配置限定符。

5：额外的密度考虑

这个小节描述更多关于Android如何在不同屏幕密度下对bitmap drawables进行缩放，你可以进一步控制在不同密度屏幕上绘制。这部分内容对于大部分程序都不是很重要，除非你的程序在不同屏幕密度下运行时碰到问题或者在处理图形时。
为了更好地理解在处理图片时你能够如何支持多种密度，你应该理解系统如何通过下面的方式去帮助保证适当地缩放图片的。

1.资源的预缩放(比如bitmap drawables)

基于当前屏幕的密度，系统会为程序使用任何size- 或者density- 特定的资源和无缩放地显示它们。如果在当前密度下没有有效地资源，系统会加载默认的资源和缩放它们去适配当前的屏幕密度。系统假定默认的资源(没有配置限定符的那个目录)是为基准屏幕密度(mdpi)而设计的,除非它们是从特定密度的资源目录下加载过来的。因此，预缩放就是系统为当前屏幕密度对图片重新调整到一个合适的尺寸。
如果你请求一个没有预缩放资源的维度，系统会返回维度缩放后的值。例如，一个设计为mdpi屏幕设计的50x50像素的图片，在hdpi屏幕下放大到75x75像素(如果hdpi没有可选的资源),系统会报告这样的值。
有些情形下你可能不想Android去预缩放资源。去避免预缩放最简单的方式是把资源放到nodpi限定符的目录下。例如：
res/drawable-nodpi/icon.png
当系统从这个目录下使用icon.png这张图片时，它不会基于当前设备密度做任何缩放。

2.像素维度和坐标的自动缩放

应用程序可以通过在manifest中设置android:anyDensity 为"false"或者在程序中设置Bitmap的inScaled为"false"去禁用预缩放。在这种情况下，系统会在绘制的时候自动缩放任何绝对像素坐标和像素维度值。它通过这些去保证像素确定的屏幕依然可以在同样物理尺寸的屏幕上显示差不多的结果正如在基准屏幕密度(mdpi)下一样。系统处理这个缩放过程对于程序是透明的，对程序会报告缩放的像素维度，而不是物理像素维度。
例如，假设一个设备有WVGA的高密度屏幕，它的尺寸是480x800,和传统的HVGA屏幕有相同的尺寸，但是它运行的程序禁用了预缩放。在这种情况下，系统会在查询屏幕尺寸的时候"欺骗"程序，报告为320x533(近似mdpi的屏幕密度)。然后，当程序执行绘制操作的时候，比如invalidating一个从(10,10)到(100,100)的矩形，系统通过缩放它们到一个合适的值来转换坐标，实际上就是invalidate一个(15,15)到(150,150)的区域了。这个矛盾这能会导致意想不到的情形如果你的程序直接控制缩放的图片，但这可以认为是个合理的平衡点去尽可能保持程序的性能。如果你碰到这种情况，阅读接下来的有关小节:把dp单位转换为像素单位。通常，你不应该禁用预缩放。支持多屏幕的最好方式是去遵循在上面讨论到的如何支持多屏幕的基本技术。

如果你的程序要在屏幕上通过其他方式控制图片或者直接和像素直接交互，你可能需要去采取额外的步骤去支持不同的屏幕密度。 例如，如果你通过计算手指经过的像素数来响应触碰手势，你需要使用合适的密度独立像素值，而不是实际像素值。

5.1：缩放在运行时创建的Bitmap对象

如果你的程序创建了一个驻内存的位图(一个Bitmap对象)，系统会假设默认这个bitmap是为基准中等密度屏幕设计的，在绘制的时候会自动缩放这个bitmap。系统为Bitmap采用了"自动缩放(auto-scaling)"当bitmap没有特定的密度属性。如果你不为当前设备的屏幕密度进行适当计算和指定bitmap的密度属性，自动缩放会导致你不提供可选的资源时一样的缩放。

去控制在运行时创建的bitmap是否应该缩放，你可以通过setDensity()来设定bitmap的密度，传递一个来自的DisplayMetrics密度常数，比如DENSITY_HIGH 或者 DENSITY_LOW。

如果你设置inScaled属性为false, 然后你禁用任何系统可能对bitmap应用的预缩放，系统就会在绘制的时候自动缩放它了。使用自动缩放而不是预缩放会使用更多CPU资源，但使用更少的内存。

 图-5

图5 示范了在高密度屏幕上加载低(120),中等(160),高(240)密度位图时的预缩放和自动缩放机制带来的结果。这种差别是细微的，因为所有的bitmap会同时缩放去匹配当前的屏幕密度，然而缩放后的bitmap会有细微的外观上的差别，这取决于它们在绘制时是预缩放还是自动缩放的。你可以在这个例子的程序源代码中找到使用了预缩放和自动缩放的bitmap,在ApiDemos里面。

5.2：转化dp单位为像素单位

在某些情况下，你会需要用dp来表示维度，然后把它们转化成像素。想象一个程序里的一个在用户手指已经移动至少16个像素的辨识为滚动或者滑动手势。在基准屏幕上，在手势被辨识之前，用户必须至少移动16 px /160 dpi，等于一英寸的1/10(或者2.5 mm)。在一个高密度屏幕(240dpi)的设备上，用户必须要移动16 px / 240 dpi, 等于1/15英寸(1.7mm)。这距离就更加短了，因此程序对于用户来说就显得更加敏感了。
去修复这个问题，手势的阈值必须在代码中使用dp来表示，然后转化成实际的像素，例如：

// The gesture threshold expressed in dp
private static final float GESTURE_THRESHOLD_DP = 16.0f;
// Get the screen's density scale
final float scale = getResources().getDisplayMetrics().density;
// Convert the dps to pixels, based on density scale
mGestureThreshold = (int) (GESTURE_THRESHOLD_DP * scale + 0.5f);
// Use mGestureThreshold as a distance in pixels...

DisplayMetrics.density属性根据当前的屏幕密度指定了你必须使用的把dp单位转化为像素的缩放因子。在一个中等密度(medium-density)屏幕上，它等于1.0; 在高密度(high-density)屏幕上它等于1.5; 在特别高密度(extra high-density)的屏幕上，它等于2.0; 在一个低密度(low-density)屏幕上，它等于0.75。这个图形是你应该用dp单位和因子相乘后得到的实际像素值在当前屏幕显示的结果(然后加上0.5，在转化成整数时取最接近的整个结果)。获取更多的信息，请参考DisplayMetrics这个类
然而，你应该在预配置中使用ViewConfiguration中有效的配置值，而不是为这种事件定义一个任意的阈值。

5.3：使用预缩放配置值

你可以使用ViewConfiguration这个类来访问常见的距离，速度和Android系统使用的时间。例如，框架使用的滚动条阈值的距离可以通过getScaledTouchSlop()来获取，单位是像素。

private static final int GESTURE_THRESHOLD_DP = ViewConfiguration.get(myContext).getScaledTouchSlop();

ViewConfiguration里面的方法以getScaled前缀开头的返回的结果确保了是在当前屏幕密度下合理显示之后的像素值。

6：如何在多种屏幕下测试你的程序

在你发布程序之前，你应该在所有支持的屏幕尺寸和密度上测试它。Android SDK包括了可以使用的各种皮肤，它们复制了你的程序可能运行的一般的尺寸和密度屏幕配置。你也可以去修改默认的模拟器皮肤的尺寸，密度和分辨率，去复制任何特定的屏幕特征。使用模拟器皮肤和额外的自定义配置允许你去测试任何可能的屏幕配置，所以你不需要去购买各种不同的设备如果只是测试程序的屏幕支持。

去建立一个程序屏幕支持的测试环境，你应该创建一系列的AVD(Android Virtual Devices)，使用模拟器皮肤和屏幕配置去模拟你程序想要支持的屏幕尺寸和密度。这么做，你可以使用AVD管理器去创建AVD和在图形界面上启动它们。

去启动Android SDK管理器，从你的Android SDK目录下(只是Windows)启动SDK Manager.exe或者从<sdk>/tools/目录下面(所有平台)执行android,图6展示了AVD管理器和可选择的AVD，用于测试不同的屏幕配置。

表3展示了在Android SDK中各种不同的模拟器皮肤，你可以使用它们去模拟一些最常见的屏幕配置。

更多关于如何创建和使用AVD去测试你的程序，请阅读Managing AVDs with AVD Manager。

看支持给出的屏幕配置的活动设备的相关数量，可以看Screen Sizes and Densities面板。

我们同样推荐你在和实际设备非常匹配的物理尺寸的模拟器上测试你的程序。这会让它在和不同的尺寸和密度上比较结果变得简单许多。去做到这个，你需要知道你电脑屏幕监视器的近似的密度，单位是dpi(例如，一个30寸的Dell监视器有大概96dpi的密度)。当你从AVD管理器启动一个AVD时，你可以为模拟器指定屏幕大小，监视器的dpi，如图7所示。

如果你打算使用内置不支持的分辨率或者密度的皮肤去测试你的程序，你可以创建一个自定义分辨率或者密度的AVD。当从AVD管理器创建一个AVD时，指定它的分辨率，而不是选择内置的皮肤。
如果你在命令行中启动你的AVD,你可以通过-scale来指定模拟器的缩放，例如：

emulator -avd <avd_name> -scale 96dpi

去精确模拟器的尺寸，你可以传递 -scale选项一个 0.1到3的数值，这代表了你希望得到的缩放因子。 更多关于用命令行去创建AVD的信息爱，阅读Managing AVDs from the Command Line

翻译原文：http://www.darcye.com/article/15499952