Android荧幕支持-from development center

The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a "medium" density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use. The conversion of dp units to screen pixels is simple:?px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels. You should always use dp units when defining your application's UI, to ensure proper display of your UI on screens with different densities.

Range of screens supported

Starting with Android 1.6 (API Level 4), Android provides support for multiple screen sizes and densities, reflecting the many different screen configurations that a device may have. You can use features of the Android system to optimize your application's user interface for each screen configuration and ensure that your application not only renders properly, but provides the best user experience possible on each screen.

To simplify the way that you design your user interfaces for multiple screens, Android divides the range of actual screen sizes and densities into:

• A set of four generalized?sizes:?small,?normal,?large, and?xlarge
  • xlarge?screens are at least 960dp x 720dp
  • large?screens are at least 640dp x 480dp
  • normal?screens are at least 470dp x 320dp
  • small?screens are at least 426dp x 320dp

    Maintaining density independence is important because, without it, a UI element (such as a button) appears physically larger on a low density screen and smaller on a high density screen. Such density-related size changes can cause problems in your application layout and usability. Figures 2 and 3 show the difference between an application when it does not provide density independence and when it does, respectively.

    

    drawable/?are the default drawable resources. The system assumes that default resources are designed for the baseline screen size and density, which is a normal screen size and a medium density. As such, the system scales default density resources up for high-density screens and down for low-density screens, as appropriate.

    However, when the system is looking for a density-specific resource and does not find it in the density-specific directory, it won't always use the default resources. The system may instead use one of the other density-specific resources in order to provide better results when scaling. For example, when looking for a low-density resource and it is not available, the system prefers to scale-down the high-density version of the resource, because the system can easily scale a high-density resource down to low-density by a factor of 0.5, with fewer artifacts, compared to scaling a medium-density resource by a factor of 0.75.

    For more information about how Android selects alternative resources by matching configuration qualifiers to the device configuration, read?How Android Finds the Best-matching Resource.

    Using configuration qualifiers

    Android supports several configuration qualifiers that allow you to control how the system selects your alternative resources based on the characteristics of the current device screen. A configuration qualifier is a string that you can append to a resource directory in your Android project and specifies the configuration for which the resources inside are designed.

    To use a configuration qualifier:

    1. Create a new directory in your project's?res/?directory and name it using the format:?<resources_name>-<qualifier>
       • <resources_name>?is the standard resource name (such as?drawable?or?layout).
       • <qualifier>?is a configuration qualifier from table 1, below, specifying the screen configuration for which these resources are to be used (such as?hdpi?or?xlarge).

         You can use more than one?<qualifier>?at a time—simply separate each qualifier with a dash.

       • Save the appropriate configuration-specific resources in this new directory. The resource files must be named exactly the same as the default resource files.

    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.

    landResources for screens in the landscape orientation (wide aspect ratio).portResources for screens in the portrait orientation (tall aspect ratio).Aspect ratiolongResources for screens that have a significantly taller or wider aspect ratio (when in portrait or landscape orientation, respectively) than the baseline screen configuration.notlongResources for use screens that have an aspect ratio that is similar to the baseline screen configuration.

    larger?than the current screen, the system will not use them and your application will crash if no other resources match the device configuration (for example, if all layout resources are tagged with the?xlarge?qualifier, but the device is a normal-size screen). For more information about how the system selects resources, read?How Android Finds the Best-matching Resource.

    large?or?xlarge).

    The reason designing for 7" tablets is tricky when using the generalized size groups is that a 7" tablet is technically in the same group as a 5" handset (the?large?group). While these two devices are seemingly close to each other in size, the amount of space for an application's UI is significantly different, as is the style of user interaction. Thus, a 7" and 5" screen should not always use the same layout. To make it possible for you to provide different layouts for these two kinds of screens, Android now allows you to specify your layout resources based on the width and/or height that's actually available for your application's layout, specified in dp units.

    For example, after you've designed the layout you want to use for tablet-style devices, you might determine that the layout stops working well when the screen is less than 600dp wide. This threshold thus becomes the minimum size that you require for your tablet layout. As such, you can now specify that these layout resources should be used only when there is at least 600dp of width available for your application's UI.

    You should either pick a width and design to it as your minimum size, or test what is the smallest width your layout supports once it's complete.

    <N>?dps of width available for it 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.

    This is an alternative to the generalized screen size qualifiers (small, normal, large, xlarge) that allows you to define a discrete number for the effective size available for your UI. Using smallestWidth to determine the general screen size is useful because width is often the driving factor in designing a layout. A UI will often scroll vertically, but have fairly hard constraints on the minimum space it needs horizontally. The available width is also the key factor in determining whether to use a one-pane layout for handsets or multi-pane layout for tablets. Thus, you likely care most about what the smallest possible width will be on each device.

    Available screen widthw<N>dp
    
    Examples:
    w720dp
w1024dp
    

    Specifies a minimum available width in dp units at which the resources should be used—defined by the?<N>?value. The system's corresponding value for the width changes when the screen's orientation switches between landscape and portrait to reflect the current actual width that's available for your UI.

    This is often useful to determine whether to use a multi-pane layout, because even on a tablet device, you often won't want the same multi-pane layout for portrait orientation as you do for landscape. Thus, you can use this to specify the minimum width required for the layout, instead of using both the screen size and orientation qualifiers together.

    Available screen heighth<N>dp
    
    Examples:
    h720dp
h1024dp
    etc.

    Specifies a minimum screen height in dp units at which the resources should be used—defined by the?<N>?value. The system's corresponding value for the height changes when the screen's orientation switches between landscape and portrait to reflect the current actual height that's available for your UI.

    Using this to define the height required by your layout is useful in the same way as?w<N>dp?is for defining the required width, instead of using both the screen size and orientation qualifiers. However, most apps won't need this qualifier, considering that UIs often scroll vertically and are thus more flexible with how much height is available, whereas the width is more rigid.

    While using these qualifiers might seem more complicated than using screen size groups, it should actually be simpler once you determine the requirements for your UI. When you design your UI, the main thing you probably care about is the actual size at which your application switches between a handset-style UI and a tablet-style UI that uses multiple panes. The exact point of this switch will depend on your particular design—maybe you need a 720dp width for your tablet layout, maybe 600dp is enough, or 480dp, or some number between these. Using these qualifiers in table 2, you are in control of the precise size at which your layout changes.

    For more discussion about these size configuration qualifiers, see the?Providing Resources?document.

    Configuration examples

    To help you target some of your designs for different types of devices, here are some numbers for typical screen widths:

    • 320dp: a typical phone screen (240x320 ldpi, 320x480 mdpi, 480x800 hdpi, etc).
    • 480dp: a tweener tablet like the Streak (480x800 mdpi).
    • 600dp: a 7” tablet (600x1024 mdpi).
    • 720dp: a 10” tablet (720x1280 mdpi, 800x1280 mdpi, etc).

      Using the size qualifiers from table 2, your application can switch between your different layout resources for handsets and tablets using any number you want for width and/or height. For example, if 600dp is the smallest available width supported by your tablet layout, you can provide these two sets of layouts:

      sw<N>dp, which specifies the smallest of the screen's two sides, regardless of the device's current orientation. Thus, using?sw<N>dp?is a simple way to specify the overall screen size available for your layout by ignoring the screen's orientation.
      However, in some cases, what might be important for your layout is exactly how much width or height is?currently?available. For example, if you have a two-pane layout with two fragments side by side, you might want to use it whenever the screen provides at least 600dp of width, whether the device is in landscape or portrait orientation. In this case, your resources might look like this:
      w<N>dp. This way, one device may actually use both layouts, depending on the orientation of the screen (if the available width is at least 600dp in one orientation and less than 600dp in the other orientation).
      If the available height is a concern for you, then you can do the same using the?h<N>dp?qualifier. Or, even combine the?w<N>dp?and?h<N>dp?qualifiers if you need to be really specific.
      Declaring screen size support
      Once you've implemented your layouts for different screen sizes, it's equally important that you declare in your manifest file which screens your application supports.
      Along with the new configuration qualifiers for screen size, Android 3.2 introduces new attributes for the?<supports-screens>?manifest element:
      android:requiresSmallestWidthDp
      Specifies the minimum smallestWidth required. The smallestWidth is the shortest dimension of the screen space (in?dp?units) that must be available to your application UI—that is, the shortest of the available screen's two dimensions. So, in order for a device to be considered compatible with your application, the device's smallestWidth must be equal to or greater than this value. (Usually, the value you supply for this is the "smallest width" that your layout supports, regardless of the screen's current orientation.)
      For example, if your application is only for tablet-style devices with a 600dp smallest available width:
      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.
      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:
      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.
      ?
      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.
      Scaling Bitmap objects created at runtime
      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.
      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.
      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.
      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.
      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. You can find the source code for this sample application, which demonstrates using pre-scaled and auto-scaled bitmaps, in?ApiDemos.
      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 Android SDK and AVD Manager, specify the Resolution, instead of selecting a Built-in Skin.
      If you are launching your AVD from the command line, you can specify the scale for the emulator with the?-scale?option. For example:
      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.
      For more information about creating AVDs from the command line, see?Managing AVDs from the Command Line