Android UI and android UI

Android UI and android UI

I thought the previous article was the last one written before the arrival of the Lunar New Year, but it seems that it is necessary to continue to record the useful information, which is relatively basic. I didn't pay much attention to it before.

Let's get down to the truth. This article mainly talks about android's self-adaptation. Why do we suddenly think about it? It's mainly because we read the launcher code, and the code we see is not clear, so I checked the information. Check the code,

BitmapDrawable bitmapDrawable = (BitmapDrawable) icon;Bitmap bitmap = bitmapDrawable.getBitmap();if (bitmap.getDensity() == Bitmap.DENSITY_NONE) {bitmapDrawable.setTargetDensity(context.getResources().getDisplayMetrics());

The above code is from Utilities in Launcher2 source code. in java, the static Bitmap createIconBitmap (Drawable icon, Context context), first let's look at Bitmap. the meaning of the DENSITY_NONE parameter is as follows: it indicates that the bitmap is created based on unknown pixel density. So it's easy to guess what the following code means: If a bitmap is created based on the unknown pixel density, the bitmapDrawable pixel density will be set to the pixel density of the current screen, that is, the pixel density of the created bitmap during display is the current screen pixel density.

However, I know little about DisplayMetrics. I can say that I only know how to obtain the screen resolution, so I can quickly query the information.

The following is the original description of the API.

Android. util class DisplayMetrics java. lang. android. util. displayMetrics public class DisplayMetrics extends Object A structure describing general information about a display, such as its size, density, and font scaling. field abstract static intDEFAULT_DENSITY The reference density used throughout the system. floatdensity The logical density of the display. intheightPixels The absolute height of the display in pixels. floatscaledDensity A scaling factor for fonts displayed on the display. intwidthPixels The absolute width of the display in pixels. floatxdpi The exact physical pixels per inch of the screen in the X dimension. floatydpi The exact physical pixels per inch of the screen in the Y dimension. constructor abstract DisplayMetrics () method abstract voidsetTo (DisplayMetrics o) voidsetToDefaults () from class java. lang. object Inheritance Method equals, getClass, hashCode, y, policyall, toString, wait field details DEFAULT_DENSITY public static final int DEFAULT_DENSITY The reference density used throughout the system. for more information, see: constant field value widthPixels public int widthPixels The absolute width of the display in pixels. heightPixels public int heightPixels The absolute height of the display in pixels. density public float density The logical density of the display. this is a scaling factor for the Density Independent Pixel unit, where one DIP is one pixel on an approximately 160 dpi screen (for example a 240x320, 1.5 "x 2" screen ), providing the baseline of the system's display. thus on a 160 dpi screen this density value will be 1; on a 106 dpi screen it wocould be. 75; etc. this value does not exactly follow the real screen size (as given by xdpi and ydpi, but rather is used to scale the size of the overall UI in steps based on gross changes in the display dpi. for example, a 240x320 screen will have a density of 1 even if its width is 1.8 ", 1.3", etc. however, if the screen resolution is increased to 320x480 but the screen size remained 1.5 "x 2" then the density wocould be increased (probably to 1.5 ). for more information, see DEFAULT_DENSITY scaledDensity public float scaledDensity A scaling factor for fonts displayed on the display. this is the same as density, doesn t that it may be adjusted in smaller increments at runtime based on a user preference for the font size. xdpi public float xdpi The exact physical pixels per inch of the screen in the X dimension. ydpi public float ydpi The exact physical pixels per inch of the screen in the Y dimension. construction Method details DisplayMetrics public DisplayMetrics () method details setTo public void setTo (DisplayMetrics o) setToDefaults public void setToDefaults ()

The format is not very good, just look at it, because it is just as an understanding of the content, so it is enough to read it. My understanding is that through the DisplayMetrics class, we can obtain most of the information about the screen display. The specific acquisition method should be flexible, like the code that was first pasted.

Use context. getResource (). getDisplayMetrics () directly, or initialize a DisplayMetrics object before obtaining it, as shown in the following figure:

DisplayMetrics metrics = new DisplayMetrics ();

GetWindowManager (). getDefaultDisplay (). getMetrics (metrics );

It is generally recommended to use the latter, because the application is used for calling. In this way, the width and height obtained are the width and height of the screen, however, if the first method is also called in the onCreate function of the Activity and is called before setContentView (), it is very likely that the resource files have not been loaded yet, therefore, calling getResource may cause problems. Therefore, the second type is recommended, because the window object must have been created after initialization of the Activity is started. Now, calling getWindowManager does not cause any problems. Naturally, the data obtained is correct. First, we recommend that you call it after the acitiworkflow is created successfully.

The simple code is as follows:

protected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);DisplayMetrics metrics = new DisplayMetrics();getWindowManager().getDefaultDisplay().getMetrics(metrics);metrics.toString();Log.e("Mylog----------", metrics.toString());......}

The following is the log demonstrated by the simulator.

We can see the printed information in the log, density = 1.0 width = 1024, height = 552 scaledDensity = 1.0 xdpi = 160 ydpi = 160 because the simulator resolution I set is 1024*600, the actual height is 48. I personally think it is the height of navigation_bar below, but it is also a bit strange why it is not included.

The following log is the log I obtained on the real machine. It is normal.

E/Mylog ---------- (29597): DisplayMetrics {density = 1.0, width = 1024, height = 600, scaledDensity = 1.0, xdpi = 160.0, ydpi = 160.0}

After a brief look at the API description, I am not very familiar with it. I just want to know about density. This value is a logical display density and is an independent Proportional unit of pixel density, the standard value is 160 pixels per square inch, that is, 160 dpi. In addition, this value does not change completely according to the actual size of the screen. Just like a screen with a resolution of 240*320, its density is 1, but its size width can be 1.8, it can also be 1.3. It can be seen from these that the pixel density ratio parameter should only depend on the pixel density of the actual screen. Once this value changes, it is no longer 1, in practice, if we say that the layout UI is based on the actual pixel value unit, different la s will be displayed at different resolutions, and different resolutions cannot be adapted. Then, android directly introduces resolution-independent measurement units to support these adaptive la S.

Px: The description of the pixel directly corresponds to the actual resolution of the image. That is, the actual physical pixel on the 1px screen. It is not officially recommended because the display effect varies with different resolutions and cannot be automatically adjusted based on the actual pixel density.

Dp: This is officially recommended unit that can be adjusted based on the pixel density of the screen. I personally think the following is the most reasonable explanation. It is related to "pixel density", so we will first explain what is pixel density. Suppose there is a mobile phone with a physical screen size of 1.5 inch x 2 inch and a screen resolution of 240x320, then we can calculate it on the screen of this mobile phone, the number of pixels per inch is 240/1. 5 = 160 dpi (horizontal) or 320/2 = 160 dpi (portrait). 160dpi is the pixel density of the mobile phone. The unit of pixel density dpi is the abbreviation of Dots Per Inch, the number of pixels per inch. The horizontal and vertical values are the same, because most mobile phone screens use square pixels. Different mobile phones/tablets may have different pixel density. For example, for a 4-inch mobile phone, x320 resolution and X resolution, the former has a relatively low pixel density. The Android system defines four pixel density types: low (120 dpi), medium (160 dpi), high (240 dpi), and ultra (320 dpi ), the coefficients from dp to px are 0.75, 1, 1.5, and 2 respectively. The coefficient multiplied by the dp length is the number of pixels. For example, if there is an image with a length of "80dp" on the interface, it is displayed as 80x1.5 = 120px on a DPI mobile phone, the actual display on the 320dpi mobile phone is 80x2 = 160px. If you compare the two mobile phones, you will find that the physical size of the image is "similar", which is the effect of using dp as the unit.

Dip: it is the same as dp, but the name is different. Dip was used in earlier Android versions. We recommend that you use the dp name for consistency with sp.

Sp: Scale-independent? Pixel ). Sp is similar to dp, but the only difference is that the Android system allows users to customize the text size (small, normal, large, large, and so on ), when the text size is "normal", 1sp = 1dp = 0.00625 inch, and when the text size is "large" or "super large", 1sp> 1dp = 0.00625 inch. It is similar to the effect after we adjust the font size in windows-the window size remains unchanged, only the text size changes.

There are also a few less used units:

Mm: mm; in: inches, 1 inch = 2.54 cm (approx );

Pt: 1pt = 1/72 inch = 0.035 cm; best practice: all text sizes are in sp units, and all non-text sizes are in dp units. For example, textSize = "16sp", layout_width = "60dp", and occasionally use px units. For example, when you need to draw a thin separator line on the screen.

Through the above understanding, we also probably know the setting principles of pixel units in the UI layout of android, we recommend that you use the dp units related to the pixel density when setting the fixed length and width. If you want to use the actual length and width of the control in the actual layout for self-adaptation, therefore, wrap_content should be used as much as possible to set the length and width, rather than forcibly specifying a fixed length and width value. Even if it is a specified dp unit, it is difficult to perfectly display the adaptive advantage. However, we can also use px and other units to make our applications more convenient and more beautiful.

After summing up the above information, it is very intuitive for me to note that I am still doing application layout, compared with the actual results I made, I always felt that the image size was adaptive or directly specified with the same dp value as the actual image resolution, but the effect was different from the design. I always thought that dp and pixels were equal, so I couldn't figure it out until now I finally realized that our dp value would be 1dp = 1px only when density is 1, when this value changes, it will lead to the discrepancy between the actual design effect and the actual demonstration effect, at this time, the solution is probably to directly specify the fixed pixel value px to meet our single design.

The above understanding is my personal understanding. I hope that I can correct this understanding if I have any research.