Open and closed principle-variable and unchanging separation and easy customizationThe purpose of the application is to do as much as possible for a variety of devices, which are configured differently, with some different physical dimensions and resolutions. To achieve optimal adaptation, with minimal code duplication, and best scalability, It is necessary to separate the use and resources of resources. Manage resources with a single resource manager. The code obtains resources through a unified interface provided by the resource manager. This way, for the user to access the resource is unified, Resource holders don't have to worry about how to get different resources for different devices. This minimizes the code that changes with different devices, and only resource managers need to worry about the different resources associated with different devices.
For example: the acquisition and use of strings. The most straightforward way is to use literal constants directly in your code. But when dealing with multiple languages, this is very troublesome, requires code to judge the current system language, and then decide which to use! But if you use the Resource Manager to get a string, you minimize code coupling: Only the resource manager needs to determine the current system language, and then go to the corresponding string. Other people don't need to care.
The same is true of Android, where the code obtains system resources through a unified interface, and the resource Manager handles device affinity issues.
Android resources inside the common hdpi and so on what does this mean? To understand this, first look at some of the metrics and dimensions in standard graphic design
Basic Terminology and concepts:Screen Size screens sizeRefers to the physical size of the screen, measured by the length of the screen diagonal, in inches (1 inches = 2.54 centimeters).
The size of the screen is large and small, which usually determines how much content the screen can display, such as the areas of the computer that can be displayed more often than the phone.
Resolution resolutionusually in pixels, the pixel is defined as the basic unit that the device can display, such as 480x800, or 1024x768, which means that the screen can display 1024 points in length, 768 points can be displayed at height. The resolution is typically used to represent the size of the image. However, the resolution does not represent the actual physical size of the image. You cannot determine the physical dimensions that are displayed on the screen.
screen density densityRefers to the number of pixels that the screen can display per unit length, that is, the number of pixels that can be displayed on an inch, by dividing the resolution by the physical size. The screen density can reflect the clarity of the device. The unit is usually the PPI (Pixels per inch). The higher the PPI value, the better the clarity of the screen and the clearer the display. Apple's Retina screen, for example, reaches 326PPI. The recognition ability of the human eye is around 300PPI, so the human eye can not distinguish the pixel point when it reaches 326, so it shows more clearly.
With the concept of screen density, you can see that the same size (resolution) of the picture on the high-density screen of the physical size will be small (look small), on the low-density screen display of the physical size will be larger (looks big).
So why, no software for the MBP Retina screen, such as the PS icon will look blurry. Because the density of the MBP retina screen is greatly increased, is 4 times times the previous, so the same size of the picture will look smaller than the original 1/4, too small will be invisible, But this is very inconvenient to use. So the Mac system in order to adapt to the new Retina screen, you have to scale the image, magnified the original four times times, so that in the user's eyes "look" (physical size) picture is still so big! Because the icon is pulled four times times, of course, it will blur! So, Mac Apps The application must be specifically optimized and adapted after the retina.
Aspect ratio of the screenthe ratio of the physical length to the physical width.
How to fit a different screenThe purpose of adapting to different screens is to allow the application to experience consistency across all systems. There are different strategies for this platform. Some platforms are based on screen resolution only. That is, the device is based on the screen resolution. This is also the source of the commonly seen VGA class name:
Differentiate different devices according to different screen resolutions, such as some common names:
QVGA: 240*320 Quarter VGA One-fourth meaning (for a quarter)
HVGA: 320*480 Half size VGA meaning one-second (1 = a)
VGA: 480*640 The age-old computer monitor resolution, The rest is based on this to scale the
WVGA: 480*800 wide VGA
SVGA: 600*800 super VGA
And so on, the resolution of the distinction can be referred to Wikipedia: Graphics display resolution
Then, there are some GUI systems that distinguish different resources in a resolution way.
However, as mentioned earlier, the resolution does not represent the clarity of the screen. Images of the same resolution, or the same length, will look small on a high-density screen and become larger on a low-density screen. Because it's in pixels. So, if you use resolution as a basis to differentiate resources, Then you must set up resources for all the different resolutions, and do the optimization of the adaptation, otherwise you will not get a good display effect! And think about how big the workload will be!
screen density-independent unit lengthWhat is the purpose of adapting a different screen? Just to get
1. The application can be displayed normally on different platforms, that is, display the display, not too large (low density) nor too small (high density)
2. Typesetting can be consistent. This means that the elements are larger on large screens (high resolution) and smaller on small screen sizes (low resolution)
The purpose of being lazy humans is to use the smallest amount of work to fit the most screens, so how do you do that? If you can have a unit of measure that changes with the screen, that's good, so you can specify a length so that the device will handle the change factor on its own.
So, it comes out a new length unit dip---Density independent Pixels, which is the density independent of an abstract unit length. It is not fixed like pixels or inch, but varies with the density of the device. It has a small value on low-density devices. , and on a high-density screen its value will become larger, so that developers can specify a length to adapt to different density of the screen to solve the problem of low-density screen size, high-density screen becomes smaller. In detail: For example, the length of a window is 100DIP, dip value on low-density screen, If it is 1pixel, then the length becomes the pixels, and on the high-density screen, dip may become 1.5 pixel, so the length becomes 150pixels. This is achieved, the purpose of the status quo. And the dip specifically takes what value, is also provided by the device, because the device knows its own density.
adaptation strategies on Android
How does Android solve the problem of adapting to different sizes (resolutions) and densities? It is mainly through the density classification, coupled with the resolution of the way to reduce the amount of work to adapt to different sizes of the screen.
Generally speaking, the higher the screen resolution, the higher the clarity should be, that is, the density should be greater, otherwise it will look very unclear, such as 4-inch screen display only 100 pixels, the nearest distance to see the movie, or see the projector, very rough and not clear. So, Android is mainly based on screen density to distinguish between different devices:
Density: hdpi (high dots per inch)
Medium density: mdpi (Medium dots per inch)
Low density: ldpi (lower dots per inch)
It is recommended that the density-independent unit dip or DP be used as a unit of length or width in the layout. In theory, developers only need to do:
1. Prepare picture resources for different density screens
(The picture is not possible, because the length and width of the image is a fixed pixel value, can not be changed with the density changes, may be forced to stretch, but the picture will be distorted.) Of course, there are 9 patch images to solve the problem of arbitrary stretching. But the length and width of the normal picture are fixed.
2. Specify length or width using dip as unit
Of course, the reality of life is not so perfect, a variety of devices vary widely. But the overall can still be divided into these three categories, for these three categories to prepare the picture, the other as long as with a certain category is closer, even if a slight stretch or distortion, is not too obvious, is acceptable. So, for general applications, Write a layout file in layouts, prepare images for three densities drawable-hdpi, drawable-mdpi, drawable-ldpi, enough to handle 80% of the device.
res/
drawable-hdpi/
Ic_launcher.png
drawable-mdpi/
Ic_launcher.png
drawable-ldpi/
Ic_launcher.png
layout/
main.xml
(This may be a bit out of date, because now more xdpi, and many devices are also xdpi.)
But it is not enough to classify and deal with the density screen. As devices become more and more large, and the tablet appears, the problem arises: the device's screen density is not high, but its resolution is high. For a simple example: the resolution of iPad2 is 1024x768, The iphone 4 960x640, but the iphone 4 is 326ppi in density, much larger than iPad2. However, no matter how dense the screen is, it can display up to 960x640 pixels, a 1024x768 image can be seen on the ipad, And you can only see more than half on the iphone! This is why the ipad is used to run apps on the iphone just as part of the middle of the screen to simulate the cause of the display.
It's the same for Android. As a result, even if the same dpi, if its screen size is very large, then the picture prepared for it will be stretched very large or not complete. UI elements are also stretched very long. This is not a very good experience. For large screens, you should let them show more content, rather than stretching a portion of the elements to a large extent. Therefore, many mobile phone Android applications without special adaptation, the direct use of the tablet experience will be very poor.
In order to solve this problem, the device must also be differentiated by screen size
There are four main screen sizes: small, normal, large and xlarge
This is mainly used in conjunction with screen density, for example, a picture of a tablet:
Drawable-xlarge-hdpi/ic_launcher.png
The correspondence between density, size and resolution is mentioned here. Screen resolution is the most obvious change with the device, the above two classification method is only a general classification of the screen. Although the screen resolution is not directly related to density, all devices are basically consistent (conventional?):
LDPI QVGA 240*320 0.8
MDPI HVGA 320*480 1.0
HDPI WVGA 480*800 1.5
HDPI QHD 540*960 1.5
xdpi WXGA 720*1280 2
For, how to fit, and how to provide resources to read the official documentation, which is detailed. http://developer.android.com/guide/topics/resources/providing-resources.html
frequently asked questions to fit different screensAlthough the above strategy is the way, but in practice is not enough. Because the scale of the screen size is not the same as the ratio of density. For example, the ratio of width to density is the same as that of HVGA compared to WVGA 480/320=1.5. So there's as much content on the width. Don't worry about it. But the height above is not the same. 800/480 >1.5, this is what happens, that is, the same thing scaled 1.5 times times later, for WVGA there will be quite a screen empty. Or if you are using WVGA as a benchmark, Put it on the HVGA and it will not be fully displayed. The problem will be more pronounced on the QHD. Even the same hdpi WVGA and qHD have problems, and QHD can show more than WVGA.
use dimension resources to solve problemsAs can be seen from the above questions, the density-independent units can not solve the above problems. Of course, there is a choice for each resolution to make a layout, but this will cause a lot of duplication, because the layout is the same, only the height or width of the elements need to consider the resolution and screen density.
You can then abstract the height or width out into a separate resource dimensions to minimize the change:
For example, the height of a view:
layout/
main.xml # android:layout_height= "@dimen/view_height"
values-mdpi
Dimensions.xml Item Name= "View_height" >20dip</item>
values-hdpi
Dimensions.xml 30dip
values-hdpi-960x540
Dimensions.xml 40dip
Also, use relative values as much as possible, such as wrap_content and fill_parent (or match_parent), which are not fixed values but are calculated at the time of the specific layout.
Finally, share a pit where the default value of the resource is not always values,drawable and layout. When you specify a value in values and a value in values-mdpi, for other types such as hdpi, the value in MDPI is used instead of the value in values.
In addition, it is necessary to pay attention to the size problem when making pictures
Because the size of the picture is in pixels, and the Android app is mostly in dip or DP units, So pay attention to their correspondence on different densities. The Suren value and the dip are all integers. For example, the 1 dip on HVGA or mdpi equals 1 pixels. But to WVGA or hdpi 1 dips are 1.5 pixels, So the pixel value of the size of the WVGA picture is better to be a multiple of 1.5. This makes it easier to use a dip to define the width of the length of the picture.
Other useful information:
1. Support different Android device configurations with dimension resources
2. Providing Resources
3. Suitable for specific resolutions
-
Top
Solving problems with multi-screen adaptation dimension
