使用限定符的方法:

在res目錄下創建資源目錄,命名方式為:resources_name-qualifier
resources_name是資源目錄名,例如drawable或者layout qualifier是限定符名稱,例如hdpi或者xlarge. 將相應的資源保存在上面創建的特定目錄中.注意,例如drawable-hdpi的目錄只能放置hdpi的資源圖片,不要放錯了.

For example, xlarge is a configuration qualifier for extra-large screens. When you append this string to a resource directory name (such as layout-xlarge), it indicates to the system that these resources are to be used on devices that have an extra-large screen.

例如,xlarge限定符是為超大屏幕做的適配標識.當你把xlarge加到相應的目錄後面(例如layout-xlarge),這就意味著當處於超大屏幕時需要會從有xlarge標識的目錄中尋找資源文件.

Table 1. Configuration qualifiers that allow you to provide special resources for different screen configurations.

表格1. 為應用提供的屏幕尺寸限定符和屏幕密度限定符.

For example, the following application resource directories provide different layout designs for different screen sizes and different drawables. Use the mipmap/ folders for launcher icons.

以下是應用程序的資源目錄列表.其中mipmap目錄是用來存放應用圖標的.

However, if your application supports all screen sizes supported by Android (as small as 426dp x 320dp), then you don’t need to declare this attribute, because the smallest width your application requires is the smallest possible on any device.

android:compatibleWidthLimitDp
This attribute allows you to enable screen compatibility mode as a user-optional feature by specifying the maximum “smallest width” that your application supports. If the smallest side of a device’s available screen is greater than your value here, users can still install your application, but are offered to run it in screen compatibility mode. By default, screen compatibility mode is disabled and your layout is resized to fit the screen as usual, but a button is available in the system bar that allows users to toggle screen compatibility mode on and off.

android:largestWidthLimitDp
This attribute allows you to force-enable screen compatibility mode by specifying the maximum “smallest width” that your application supports. If the smallest side of a device’s available screen is greater than your value here, the application runs in screen compatibility mode with no way for the user to disable it.

Android3.2隨著新的限定符也引進了新的manifest元素屬性:

指定應用所需要的最小寬度.
SmallestWidth必須是能被應用程序UI利用的屏幕控件的最小尺寸(單位是dp),也是屏幕高或寬中的最小尺寸.因此,為了讓設備與應用程序兼容,設備的smallestWidth必須大於等於這個值.
例如,如果你的應用只適配最小寬度為600dp的屏幕,那需要在AndroidManifest中添加如下聲明:

然而,如果應用程序支持所有Android支持的屏幕尺寸,那麼沒有必要申明這個屬性了.

android:compatibleWidthLimitDp
這個屬性用來兼容通過指定應用程序支持的最小寬度.如果可用設備的最小值大於這個值,用戶仍然可以安裝應用程序,但是不能再屏幕的兼容模式上運行.默認情況下,屏幕的兼容模式是關閉的.

android:largestWidthLimitDp
這個屬性通過指定你的應用程序支持的最大“最小寬度”強制開啟屏幕的兼容模式,如果設備的可用屏幕最小邊大於這個值,應用程序會運行在屏幕兼容模式上,且用戶沒有辦法去禁用它.

Best Practices(最佳實踐)

The objective of supporting multiple screens is to create an application that can function properly and look good on any of the generalized screen configurations supported by Android. The previous sections of this document provide information about how Android adapts your application to screen configurations and how you can customize the look of your application on different screen configurations. This section provides some additional tips and an overview of techniques that help ensure that your application scales properly for different screen configurations.

支持多個屏幕尺寸的目標是開發一個在任何屏幕尺寸上都能夠很好顯示的Android應用程序.本文前面的章節介紹了Android系統是如何讓應用程序適配不同屏幕的以及如何在不同尺寸的屏幕上自定義自己的UI布局.這一章節提供了更多的適配多種屏幕的開發技巧.

Here is a quick checklist about how you can ensure that your application displays properly on different screens:

The following sections provide more details.

這裡給出適配方案的簡介列表:

在layout布局中聲明寬或高時盡量使用wrap_content, match_parent或者dp等密度無關的度量單位. 不要在應用程序代碼中為布局指定px硬編碼. 不要使用絕對布局,AbsoluteLayout布局已經被廢棄了. 為不同密度的屏幕提供不同的圖片資源.

接下來,是每一條建議的詳細描述.

1. Use wrap_content, match_parent, or the dp unit for layout dimensions(盡量使用wrap_content, match_parent或者dp等密度無關度量標識符)

When defining the android:layout_width and android:layout_height for views in an XML layout file, using “wrap_content”, “match_parent” or dp units guarantees that the view is given an appropriate size on the current device screen.

在layout布局文件中定義寬和高時,使用wrap_content, match_parent, dp等密度無關單位可以在不同的屏幕尺寸上都獲得比較好的顯示效果.

For instance, a view with a layout_width=”100dp” measures 100 pixels wide on medium-density screen and the system scales it up to 150 pixels wide on high-density screen, so that the view occupies approximately the same physical space on the screen.

例如,一個View的寬度聲明為100dp,則意味著在mdpi的屏幕上,這個View占據的寬度為100px,而在hdpi的屏幕上,這個View占據的寬度為150px.因此雖然兩個屏幕的密度不同,但是View控件寬度所占據的屏幕比例幾乎是相同的.

Similarly, you should prefer the sp (scale-independent pixel) to define text sizes. The sp scale factor depends on a user setting and the system scales the size the same as it does for dp.

同樣的,在修飾文字大小時建議使用sp為單位,而不是使用px.sp針對字體大小的效果和dp針對view大小的效果類似.

2. Do not use hard-coded pixel values in your application code(不要在應用代碼中強制寫死px大小)

For performance reasons and to keep the code simpler, the Android system uses pixels as the standard unit for expressing dimension or coordinate values. That means that the dimensions of a view are always expressed in the code using pixels, but always based on the current screen density. For instance, if myView.getWidth() returns 10, the view is 10 pixels wide on the current screen, but on a device with a higher density screen, the value returned might be 15. If you use pixel values in your application code to work with bitmaps that are not pre-scaled for the current screen density, you might need to scale the pixel values that you use in your code to match the un-scaled bitmap source.

為了性能考慮和兼顧代碼簡潔,Android系統使用px作為尺寸和坐標值的標准單位.這意味著,在代碼中去測量一個View的大小總是基於當前屏幕的密度轉換成px來表示.例如,通過myView.getWidth()返回的值為10,說明在當前屏幕密度下myView占據的寬度為10px,但是當換一個更高密度的屏幕時,myView.getWidth()返回的值可能就是15px了.如果你基於當前屏幕密度下,使用px來測試bitmap的大小,你計算時需要考慮到當前的屏幕密度值.

3. Do not use AbsoluteLayout(不要使用絕對布局)

Unlike the other layouts widgets, AbsoluteLayout enforces the use of fixed positions to lay out its child views, which can easily lead to user interfaces that do not work well on different displays. Because of this, AbsoluteLayout was deprecated in Android 1.5 (API Level 3).

不像其他布局控件,AbsoluteLayout強制你在xml文件裡固定每個子View的位置,這很容易導致你的布局文件不能適配其他密度的屏幕.因此,AbsoluteLayout在Android1.5上就被廢棄了.

You should instead use RelativeLayout, which uses relative positioning to lay out its child views. For instance, you can specify that a button widget should appear “to the right of” a text widget.

Android系統推薦你使用RelativeLayout,它可以讓你的子控件的布局可以根據情況動態調整.例如,你可以讓一個Button布局在一個TextView的右邊.

4. Use size and density-specific resources(使用限定符修飾的布局和資源)

Although the system scales your layout and drawable resources based on the current screen configuration, you may want to make adjustments to the UI on different screen sizes and provide bitmap drawables that are optimized for different densities. This essentially reiterates the information from earlier in this document.

盡管Android系統會基於當前屏幕尺寸和密度來調整你的布局和圖片資源,但是你可能希望在不同的屏幕尺寸和密度上顯示不同的資源圖片或者布局.前文已經詳細介紹過這種實現方法了,就是通過限定符來標識目錄.

If you need to control exactly how your application will look on various screen configurations, adjust your layouts and bitmap drawables in configuration-specific resource directories. For example, consider an icon that you want to display on medium and high-density screens. Simply create your icon at two different sizes (for instance 100x100 for medium-density and 150x150 for high-density) and put the two variations in the appropriate directories, using the proper qualifiers:

res/drawable-mdpi/icon.png //for medium-density screens
res/drawable-hdpi/icon.png //for high-density screens

如果你需要能精確的控制你的應用在不同屏幕尺寸和密度下的顯示,你就需要用到限定符修飾的目錄.例如,你想要在mdpi和hdpi兩種屏幕密度下顯示不同的icon圖片,你可以先創建兩個不同尺寸的icon圖片,然後把它們分別放到被特定限制符修飾的目錄下(100x100大小的圖片放到mdpi目錄,150x150大小的圖片放到hdpi目錄下).

Additional Density Considerations(附加注意事項)

This section describes more about how Android performs scaling for bitmap drawables on different screen densities and how you can further control how bitmaps are drawn on different densities. The information in this section shouldn’t be important to most applications, unless you have encountered problems in your application when running on different screen densities or your application manipulates graphics.

這個章節會更加詳細的介紹Android系統是如何調整圖片資源的,同時介紹了更多方法讓你可以更好的操控圖片在不同密度屏幕上的顯示.

To better understand how you can support multiple densities when manipulating graphics at runtime, you should understand that the system helps ensure the proper scale for bitmaps in the following ways:

Pre-scaling of resources (such as bitmap drawables)
Based on the density of the current screen, the system uses any size- or density-specific resources from your application and displays them without scaling. If resources are not available in the correct density, the system loads the default resources and scales them up or down as needed to match the current screen’s density. The system assumes that default resources (those from a directory without configuration qualifiers) are designed for the baseline screen density (mdpi), unless they are loaded from a density-specific resource directory. Pre-scaling is, thus, what the system does when resizing a bitmap to the appropriate size for the current screen density.
If you request the dimensions of a pre-scaled resource, the system returns values representing the dimensions after scaling. For example, a bitmap designed at 50x50 pixels for an mdpi screen is scaled to 75x75 pixels on an hdpi screen (if there is no alternative resource for hdpi) and the system reports the size as such.
There are some situations in which you might not want Android to pre-scale a resource. The easiest way to avoid pre-scaling is to put the resource in a resource directory with the nodpi configuration qualifier. For example:
res/drawable-nodpi/icon.png
When the system uses the icon.png bitmap from this folder, it does not scale it based on the current device density.

Auto-scaling of pixel dimensions and coordinates
An application can disable pre-scaling by setting android:anyDensity to “false” in the manifest or programmatically for a Bitmap by setting inScaled to “false”. In this case, the system auto-scales any absolute pixel coordinates and pixel dimension values at draw time. It does this to ensure that pixel-defined screen elements are still displayed at approximately the same physical size as they would be at the baseline screen density (mdpi). The system handles this scaling transparently to the application and reports the scaled pixel dimensions to the application, rather than physical pixel dimensions.
For instance, suppose a device has a WVGA high-density screen, which is 480x800 and about the same size as a traditional HVGA screen, but it’s running an application that has disabled pre-scaling. In this case, the system will “lie” to the application when it queries for screen dimensions, and report 320x533 (the approximate mdpi translation for the screen density). Then, when the application does drawing operations, such as invalidating the rectangle from (10,10) to (100, 100), the system transforms the coordinates by scaling them the appropriate amount, and actually invalidate the region (15,15) to (150, 150). This discrepancy may cause unexpected behavior if your application directly manipulates the scaled bitmap, but this is considered a reasonable trade-off to keep the performance of applications as good as possible. If you encounter this situation, read the following section about Converting dp units to pixel units.
Usually, you should not disable pre-scaling. The best way to support multiple screens is to follow the basic techniques described above in How to Support Multiple Screens.

為了更好的理解Android系統是如何在運行時對圖片資源進行調整,你需要理解Android系統是如何來選中合適的圖片資源的,以下是Android系統的篩選步驟:

預先調整資源
基於當前屏幕的密度,系統會選擇是否有匹配限定符修飾的資源.如果沒有匹配限定符修飾的資源,系統會使用默認的圖片資源並依據當前屏幕的密度進行適當調整.系統假定默認資源目錄(即沒有被限定符修飾的目錄)中的資源都是為標准屏幕(即mdpi)准備的.
如果開發人員需要知道被預先調整資源的大小,系統會返回已經按照當前屏幕密度調整後的圖片大小.例如,針對mdpi屏幕提供的50x50像素的圖片在hdpi屏幕上返回的大小是75x75像素.
想讓Android不去調整你的資源有很多種方法,其中最簡單的就是將資源放到被nodpi限定符修飾的目錄中.例如:
res/drawable-nodpi/icon.png
當系統使用drawable-nodpi目錄下的icon.png圖片時,無論當前屏幕密度是多少,icon都不會被調整.

自動調節尺寸和坐標值
應用可以通過在AndroidManifest.xml中設置android:anyDensity為false或者在代碼中設置Bitmap的inScaled為false來禁止預先的調整資源.在這種情況下,系統會在繪制時自動調整絕對像素的坐標值和尺寸.這樣做的目的是,為了確保已經定義像素的元素在其他密度的屏幕上仍然能夠以接近它們在基准屏幕密度上的比例顯示出來.系統會把調整後的像素值告知應用程序,調整過程對應用程序來說是透明的.
例如,假定一個設備有WVGA高密度屏幕,即480x800,這與傳統的HVGA屏幕的尺寸大致相同,但是該設備已經禁止了預先調整應用資源的功能.在這種情況下,在應用程序查詢當前屏幕密度時,系統會欺騙應用程序,假定當前的屏幕密度為320x533(欺騙的屏幕密度接近mdpi).然後,當應用程序開始繪制操作時,例如使(10,10)到(100, 100)的區域對應用無效,應用會將這部分坐標值進行相應的調整,最終無效的區域實際是(15, 15)到(150, 150).如果你的應用程序直接使用調整後的Bitmap對象,這個誤差會導致不可預期的行為,但是這被認為是合理的折衷的盡可能保持應用性能的方法.
通常情況下,你不應該禁止系統的預先調整功能.最好的適配多種屏幕密度的方式就是參考本文之前介紹的方法.

If your application manipulates bitmaps or directly interacts with pixels on the screen in some other way, you might need to take additional steps to support different screen densities. For example, if you respond to touch gestures by counting the number of pixels that a finger crosses, you need to use the appropriate density-independent pixel values, instead of actual pixels.

如果你的應用程序在屏幕上以其他某種方式操作Bitmap對象或者直接與像素交互,你可能需要采取額外的步驟來支持不同密度的屏幕.例如,你可以計算手指劃過的像素值來響應觸摸,你需要使用密度無關像素值,而不是使用實際的像素值.

Scaling Bitmap objects created at runtime(在運行時調整Bitmap對象)

If your application creates an in-memory bitmap (a Bitmap object), the system assumes that the bitmap is designed for the baseline medium-density screen, by default, and auto-scales the bitmap at draw time. The system applies “auto-scaling” to a Bitmap when the bitmap has unspecified density properties. If you don’t properly account for the current device’s screen density and specify the bitmap’s density properties, the auto-scaling can result in scaling artifacts the same as when you don’t provide alternative resources.

如果你的應用在內存中創建一個Bitmap對象,系統會認為這個Bitmap對象是為標准密度屏幕設計的,默認情況下,在繪制時會自動調整Bitmap對象.當Bitmap對象沒有明確定義自己的density屬性是,系統會采用自動調整的方式.如果你沒有考慮到當前屏幕密度也沒有聲明Bitmap的density屬性,系統會和沒有提供可選擇資源時的方式一樣去處理Bitmap對象.

To control whether a Bitmap created at runtime is scaled or not, you can specify the density of the bitmap with setDensity(), passing a density constant from DisplayMetrics, such as DENSITY_HIGH or DENSITY_LOW.

為了控制在運行時是否對Bitmap對象進行調整,你可以通過setDensity()函數對Bitmap對象的density屬性進行指定.傳遞的參數應該是DisplayMetrics對象的常量,例如DENSITY_HIGH或者DENSITY_LOW.

If you’re creating a Bitmap using BitmapFactory, such as from a file or a stream, you can use BitmapFactory.Options to define properties of the bitmap as it already exists, which determine if or how the system will scale it. For example, you can use the inDensity field to define the density for which the bitmap is designed and the inScaled field to specify whether the bitmap should scale to match the current device’s screen density.

如果你使用BitmapFactory類從文件或者流中創建Bitmap對象,你可以使用BitmapFactory.Options來定義bitmap的屬性值.例如,你可以使用inDensity字段來定義Bitmap是為哪種屏幕密度設計的,也可以使用inScaled字段來定義Bitmap在當前屏幕密度下是否需要系統進行調整.

If you set the inScaled field to false, then you disable any pre-scaling that the system may apply to the bitmap and the system will then auto-scale it at draw time. Using auto-scaling instead of pre-scaling can be more CPU expensive, but uses less memory.

如果你設置inScaled字段值為false,相當於禁用了系統的Bitmap預先調整功能,系統會在運行時繪制Bitmap的時候對其自動進行調整.使用自動調整方案,會增加CPU的負擔,但同時也會減少內存的使用.

Figure 5 demonstrates the results of the pre-scale and auto-scale mechanisms when loading low (120), medium (160) and high (240) density bitmaps on a high-density screen. The differences are subtle, because all of the bitmaps are being scaled to match the current screen density, however the scaled bitmaps have slightly different appearances depending on whether they are pre-scaled or auto-scaled at draw time.

圖5展示了在hdpi屏幕密度上加載低(120),中(160)和高(240)密度圖片預先調整和自動調整的效果對比.區別是很微小的,因為Bitmap對象都會調整成適應當前屏幕密度的樣式,然而在外觀上還是會有些許不同,這取決於是采用預先調整還是繪制時自動調整.

Converting dp units to pixel units(dp和px單位轉換)

In some cases, you will need to express dimensions in dp and then convert them to pixels. Imagine an application in which a scroll or fling gesture is recognized after the user’s finger has moved by at least 16 pixels. On a baseline screen, a user’s must move by 16 pixels / 160 dpi, which equals 1/10th of an inch (or 2.5 mm) before the gesture is recognized. On a device with a high-density display (240dpi), the user’s must move by 16 pixels / 240 dpi, which equals 1/15th of an inch (or 1.7 mm). The distance is much shorter and the application thus appears more sensitive to the user.

在某些情況下,你可能在xml文件中使用dp來標注大小同時需要在代碼中將其轉成px.在應用程序中,只有當用戶手指劃過16px時才會被系統認為是一個scroll或者fling的手勢.在標准密度的屏幕上,用戶必須移動 16px / 160dpi,相當於 1 / 10 英寸才能被檢測到.在高密度的屏幕上(240dpi),用戶必須移動16px/240dpi,相當於1/15英寸.這個距離在更高分辨率的屏幕上會顯得更加敏感.

To fix this issue, the gesture threshold must be expressed in code in dp and then converted to actual pixels. For example:

為了解決這個問題,gesture threshold必須用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...

How to Test Your Application on Multiple Screens(如何使用模擬器在不同密度屏幕上測試你的應用程序)

Before publishing your application, you should thoroughly test it in all of the supported screen sizes and densities. The Android SDK includes emulator skins you can use, which replicate the sizes and densities of common screen configurations on which your application is likely to run. You can also modify the default size, density, and resolution of the emulator skins to replicate the characteristics of any specific screen. Using the emulator skins and additional custom configurations allows you to test any possible screen configuration, so you don’t have to buy various devices just to test your application’s screen support.

在你發布應用之前,你應該在所有你想支持的密度和尺寸的屏幕上測試你的應用程序.Android SDK中提供了模擬器來幫助你實現在不同屏幕尺寸和屏幕密度上測試你的應用.你可以修改模擬器的屏幕尺寸,屏幕密度和屏幕分辨率.使用模擬器可以幫你模擬任何你想模擬的屏幕,這樣你就不需要去購買真實設備來測試你的應用程序了.

To set up an environment for testing your application’s screen support, you should create a series of AVDs (Android Virtual Devices), using emulator skins and screen configurations that emulate the screen sizes and densities you want your application to support. To do so, you can use the AVD Manager to create the AVDs and launch them with a graphical interface.

為了給你的應用搭建測試環境,你應該使用你想支持的屏幕尺寸和屏幕密度創建一系列Android虛擬設備.要做到這一點,可以使用AVD管理器去創建AVD,然後在圖形化界面啟動AVD.

To launch the Android SDK Manager, execute the SDK Manager.exe from your Android SDK directory (on Windows only) or execute android from the /tools/ directory (on all platforms). Figure 6 shows the AVD Manager with a selection of AVDs, for testing various screen configurations.

為了啟動Android SDK Manager,在window環境下可以在你Android SDK目錄下執行SDK Manager.exe文件,在其他環境下(Linux或者Mac),可以再SDK目錄的tools目錄下執行android這個應用程序.圖6展示了AVD Manager的示例.

Table 3 shows the various emulator skins that are available in the Android SDK, which you can use to emulate some of the most common screen configurations.

表三展示了Android SDK中你可以使用的通用模擬器屬性值.

We also recommend that you test your application in an emulator that is set up to run at a physical size that closely matches an actual device. This makes it a lot easier to compare the results at various sizes and densities. To do so you need to know the approximate density, in dpi, of your computer monitor (for instance, a 30” Dell monitor has a density of about 96 dpi). When you launch an AVD from the AVD Manager, you can specify the screen size for the emulator and your monitor dpi in the Launch Options, as shown in figure 7.

我們同樣建議在屏幕尺寸大約接近的模擬器上測試應用程序.這樣做可以使得比較結果更加明顯.為了做到這一點,你需要知道電腦顯示器的近似密度.當你從AVD Manager啟動AVD時,你可以指定模擬器的屏幕尺寸和顯示器的dpi如表7所示.

If you would like to test your application on a screen that uses a resolution or density not supported by the built-in skins, you can create an AVD that uses a custom resolution or density. When creating the AVD from the AVD Manager, specify the Resolution, instead of selecting a Built-in Skin.

如果你想在一個沒有在內置屬性支持的屏幕上測試應用程序,你可以創建一個使用自定義分辨率或者屏幕密度的AVD.在創建AVD時,應該手動的指定屏幕密度和分辨率.

If you are launching your AVD from the command line, you can specify the scale for the emulator with the -scale option. For example:

如果你從命令行啟動AVD,你可以通過-scale參數來指定屏幕分辨率.例如:

emulator -avd -scale 96dpi

To refine the size of the emulator, you can instead pass the -scale option a number between 0.1 and 3 that represents the desired scaling factor.

為了改變模擬器的尺寸,你可以通過指定-scale參數的值為0.1~3來改變比例因子.