Scaling of Android image resources

1. Alignment after image scaling

In Android development, how to use images is a headache for many developers. The most common problem is that the UI debugged on a mobile phone is distorted on different dpi mobile phones.

Android provides a solution to adapt to different dpi. Each dpi has a corresponding resource directory. However, when developing programs, we cannot process image resources in this way, because the image resources are too large. If we use a set of images for each type of dpi, the size of the application will expand sharply, this is not the result we want to see.

If there is only one set of images, but there are several directories such as drawable, drawable-mdpi, and drawable-hdpi, under which directory can we ensure that they are correctly displayed on each dpi device? You cannot give a simple answer to this question. It can only be analyzed based on the actual situation.

First, we need to understand the consequences of placing images in these directories:

QDrawable Directory: this is the so-called "default" directory. If you put the image here, the final effect is the same as that in the drawable-mdpi directory.

QDrawable-nodpi Directory: After images in this directory are loaded into the memory, they will not be scaled. The so-called "No scaling" means a 72X72 pixel image, the memory size is still 72X72 pixels. But on different devices, the image looks different in size.

QDrawable-mdpi, drawable-xdpi, and dreawable-xhdpi: If you place images in these dpi-related directories, programs running on devices with the same dpi will not be scaled; when running on devices with different dpi, the system scales according to the Conversion Relationship between dpi.

It is relatively simple for images placed in drawable-nodpi, so there is no need to explain them too much. But what is the purpose of Android for scaling images in other directories? In fact, the purpose is the same as using dp as the number unit in the layout file to make an image look the same size on devices of different dpi. For example, if an image is placed in the drawable-mdpi directory with a size of 72X72 pixels and runs on an mdpi device, the size is still 72X72 pixels, however, when running on a drawable-hdpi device, the size is enlarged to pixel x108.

If you don't consider the image scaling effect, isn't it good to make the application adapt to different screens through scaling? Why do developers still feel headaches? This is because in development, many UI effects are implemented by means of puzzles. If two images cannot be aligned after scaling, even if there is only one pixel, the effects will be eclipsed. To solve this problem, let's see how Android scales.

The four most common dpi types on Android are ldpi (120 dpi), mdpi (160 dpi), hdpi (240 dpi), and xhdpi (320 dpi ). The ratio of these four dpi types is 120: 160: 240: 320. After simplification, the ratio is 3: 4: 6: 8. Files in the mdpi directory are scaled n * 3/4, n * 4/4, n * 6/4, and n * 8/4 (n indicates the image size) on devices of different dpi ), if you want to scale the image under the mdpi, the image size must be a multiple of 4. Otherwise, when the algorithm is processing the image, several rows (or columns) of pixels are not added or deleted proportionally, so that the lines in the two images may be staggered by several pixels after scaling. Similarly, for an image placed under ldpi, the size should be a multiple of 3; for an image placed under hdpi, the size should be a multiple of 6; for an image placed under xhdpi, the size should be a multiple of 8. Of course, we do not require that each image comply with this rule, but it is necessary to precisely align images.Therefore, it is not critical to store a set of images in a directory. The key is to determine the image size.

Note: The image scaling problem mentioned here refers to the scaling that will be performed when the image is loaded into the memory. In addition, many widgets are scaled again when using images. Of course, Android also provides a way to disable widget scaling. For example, the most common ImageView class can disable scaling by setting the scaleType attribute to "center", or set the width and height of the ImageView to "wrap_content ". However, it should be clear that the image view is not scaled, and the image is still scaled by the system during image loading. Many developers are confused here, after the Widget is set to prohibit zooming, the display effect will be the same as that of the source image. After a long time, I don't know what the problem is.

If the widget is in use, it also scales the image. The principle is to scale each image by an integer multiple. Note that in many cases, the layout of the UI will fill the entire screen with the width of the UI. However, many devices with the same dpi and size may have slightly different screen resolutions. In this way, some devices may look perfect if they are scaled Based on the screen width, some devices are still not properly aligned. In this case, if you want to achieve the best effect, you can only calculate an optimal width dynamically based on dpi and screen width. This requires that the screen be fully occupied as much as possible, make the scaling conform to the ratio. However, this is too troublesome, and it may not be possible to have such a perfect value in all circumstances. The best way is to avoid this problem from the uidesign after understanding the problem. Therefore, similar problems do not have a permanent solution. We need to adjust the solution based on the actual situation.

2. NinePatch Image Scaling

NinePatch is a special image format defined in Android. It marks the edge of a normal image and divides it into nine parts. As follows:

When scaling a NinePatch image, the angle values of 1, 3, 7, and 9 remain unchanged. Horizontal scaling of Area 2 and Area 8, vertical scaling of Area 4 and Area 6, and full scaling of Area 5.

However, the biggest misunderstanding of the NinePath image is that the four corners of NinePatch are never scaled. Unless the image is placed in the directory drawable-nodpi or on a device running the same dpi, the NinePath image is scaled according to the ratio of dpi when loaded into the memory. When the four corners are not scaled, the size of the four corners is no longer changed after the four corners are loaded into the memory and then called to scale. Therefore, when creating a NinePathc image with rounded corners, we should note that the size of the four corners must comply with the rules described above. The pixel size of the four corners is determined based on the dpi of the directory.

3. Specify Density for the image

Android scales the Image Based on the dpi of the current device. We can also call setDensity () and setTargetDesnsity () in the Bitmap class or BitmapDrawable class to change the scaling ratio of an image.

Publicfinal class Bitmap implements Parcelable {

Public void setDensity (intdensity );

......

}

Publicclass BitmapDrawable extends Drawable {

Public void setTargetDensity (intdensity );

......

}

After the two methods are called, the image is scaled according to the specified density instead of the default density.