The most stable and efficient UI adaptation solution available on Android

Android for more than 10 years, the adaptation of the Android UI has been the most important issue in the development process, but I've seen a lot of small partners who don't know about the Android adaptation formula. In the near future, we are going to design a set of UI size adaptation schemes for the embarrassing encyclopedia Android client, and we can talk to the small partners in detail about the problem.

Android adaptation is the core of the two issues, one is the efficiency of adaptation, that is, the process of transforming the design diagram into an app interface is efficient, and the other how to ensure that the UI interface in different sizes and resolutions of the UI consistency in the phone. Both of these issues are important, one is to ensure the efficiency of our development, one is to ensure that we adapt to the results; today we will talk about the two core issues of Android adaptation program.

Image

First of all, we all know that when it comes to labeling, Android does not recommend that we use PX as a true pixel unit, because the resolution is different between different phones, such as a 96*96 pixel control that looks smaller in the overall UI in the increasingly high-resolution phone.

Image

Appears similar to this, the overall layout effect may deform, so the PX unit is not recommended in the layout file.

DP Direct Adaptation

For this scenario, Android recommends using DP as a unit of size to fit the UI.

So what is DP? DP refers to a device-independent pixel, a DP-sized unit of control, in different resolutions and sizes of the phone on behalf of different real pixels, such as in the lower resolution of the phone, may be 1dp=1px, and in the higher resolution of the phone, may 1dp=2px, so that a 96*96DP control , you can show the same size in different phones. So how is this DP calculated? We all know a formula: the PX = DP (DPI/160) system uses this to determine the mathematical relationship between PX and DP,

So here comes another question, what is DPI?

DPI is pixel density, which refers to the number of pixels in the unit size specified on the system software , which is often a fixed value written in the system's factory configuration file.

Why should I emphasize that it is a concept on a software system? Because when you buy a cell phone, you often hear another parameter called PPI, which is the pixel density on the phone screen, but this is the concept of physics, it is an objective existence will not change. DPI is a user-specified value after the software references a physical pixel density, which ensures that the physical pixel density within a range uses the same value on the software. This will help with our UI adaptation.

For example, several phones with the same resolution and different sizes may have a PPI of 430,440,450, so on Android, the DPI may be all specified as 480. In this case, the dpi/160 will be a relatively fixed value, This will ensure that the same resolution of different sizes of mobile phone performance consistent.

At different resolutions, the DPI will be different, for example:

...
1080*720
1920*1080

Dpi
320
480

dpi/160
2
3

According to the above table, we can find that 720P, and 1080P of the phone, DPI is different, which means that, in different resolutions, 1DP corresponds to a different number of PX (720P, 1dp=2px,1080p in 1dp=3px), which is achieved, When we use DP to define the size of a control, he displays the pixel value of the corresponding size on different phones.

Image

We can say that with DP plus adaptive layout and weight scale layout can basically solve the problem of different mobile phone adaptation, this is basically the most original Android adaptation program.

There are two small problems in this way, first, this can only ensure that the interface we write out to fit most of the mobile phone, some phones still need to be individually adapted, why DP only solves 90% of the adaptation problem, because not all 1080P phone dpi is 480, such as Google The DPI of the Pixel2 (1920*1080) is 420, that is, in Pixel2, 1dp=2.625px, this will result in the same resolution of the phone, so that a 100dp*100dp control, on the general 1080P phone, may be 300px , and in Pixel 2, only 262.5px, so the actual size of the control will be different.

For a more visual display, suppose we set the width of a imageview in the layout file to 360DP, then the following two images are different:

Figure one is 1080P,480DPI's cell phone, figure two is 1080P,420DPI's cell phone

1080P,480DPI's cell phone.

1080P,420DPI's cell phone.

From the above layout can be seen, the same 1080P phone, the difference is more obvious. In this case, our UI may need to do some fine tuning or even a separate adaptation.

The second problem, this way can not quickly and efficiently implement the design of the designer to the layout code, through DP direct adaptation, we can only let the UI basically adapt to different phones, but in the design diagram and UI code between the gap, DP is not resolved, because DP is not true pixels. Moreover, the width of the design draft is often and Android phone real wide difference greatly, with our design manuscript for example, the design manuscript width is 375px*750px, and the real phone may be generally 1080*1920,

So how do we cross this gap in our daily development? It's basically a percentage, or an estimate, or a canonical value, and so on. In short, when we get the design manuscript, the design manuscript ImageView is 128px*128px, when we write the layout file, but can not be directly written 128DP*128DP. In the process of converting a design manuscript to a UI code, we need to devote considerable effort to the conversion of dimensions, which greatly reduces our productivity and slows down development efficiency.

Wide Height Limited applies with

In order to implement UI development efficiently, a new adaptation scheme has emerged, which I call the wide-height limited applies . To put it simply, the wide and high pixel values of all Android phones on the market:

Image

Set the resolution of a datum, other resolutions are calculated based on this datum resolution, in different size folders, according to the size of the corresponding Dimens file.

For example, using 480x320 as the reference resolution

• Width of 320, the width of any resolution is divided into 320 parts, the value is x1-x320
• Height of 480, the height of any resolution is divided into 480 parts, the value is y1-y480

So for the 800*480 resolution of the Dimens file,

x1= (480/320) *1=1.5px

X2= (480/320) *2=3px

...

Image

At this point, if our UI design interface is using a baseline resolution, then we can fill in the corresponding Dimens reference in the size of the design, and when the app is running in a different resolution of the phone, These systems will look for the corresponding values under the folder that the Dimens references to that resolution. This basically solves the problem of our adaptation, and greatly improves the efficiency of our UI development,

But this solution has a fatal flaw, that is the need for precision hit to adapt, such as 1920x1080 's mobile phone must find the qualifier of 1920x1080, otherwise it can only use the unified default Dimens file. Using the default size, the UI is likely to deform, simply put, the fault-tolerant mechanism is poor.

However, this program has been used by some teams, we can consider it a more mature and effective solution.

UI adaptation Framework (Maintenance is stopped)

The project of the Hongda's adaptation program also comes from the wide-height qualifier scheme.

The way to use it is simple:

The first step:
In the androidmanifest of your project, indicate the size of your design manuscript.

<meta-data android:name="design_width" android:value="768"></meta-data><meta-data android:name="design_height" android:value="1280"></meta-data>

Step Two:
Let your activity inherit from the autolayoutactivity.

Then we can directly in the layout file to use the specific pixel value, for example, the design manuscript is 96*96, then we can directly write 96px,app runtime, the framework will help us according to the specific size of different mobile phones scaling.

This can be said to be an excellent solution, because it is on the basis of the wide-height limited applies, and solves the problem of fault-tolerant mechanism, it can be said that the development of efficient and adaptable to the accuracy of the two requirements.

But we can think of that because the framework is going to be transformed in the Onmeasure at runtime, our custom controls may be affected or restricted, there may be some specific controls that need to be individually adapted, where the dark pits that may exist are unforeseeable, and a more important question, That is, the entire adaptation work is a framework to complete, not the system to complete, once the use of this framework, the future once encountered difficult to solve the problem, the replacement is very troublesome, and once the project stopped maintenance, the subsequent upgrade can only rely on you, the cost of the team can bear? Of course, it has stopped maintenance.

But just for technical solutions, admittedly, this is a good open source project.

Summary

The above-mentioned adaptation schemes discussed above are more mature solutions that can be actually used in development, and indeed many developers are using them. However, because of the shortcomings of each of them, we also need to spend extra effort to address these potential flaws when we use the above scheme.

So, is there a solution that is relatively perfect and has no obvious flaws?

Smallestwidth adaptation

Smallestwidth fit, or SW limited applies match. Refers to the minimum size of the DP value (which is actually the width of the phone) that Android will recognize as the height and width of the screen , and then the resource file under the folder where the identified results go to the resource file to find the corresponding qualifier.

This mechanism is the same as the above-mentioned applies matching principle, and it is the system that chooses the corresponding file by certain rules.

For example, Xiaomi 5 dpi is 480, the transverse pixel is 1080px, according to PX=DP (dpi/160), the transverse DP value is 1080/(480/160), that is, 360DP, The system will go to find out if there are VALUE-SW360DP folders and corresponding resource files.

Image

Smallestwidth Limited applies and wide-height limited applies with the biggest difference is that the former has a good fault-tolerant mechanism, if there is no VALUE-SW360DP folder, the system will look down, such as the closest to 360DP only VALUE-SW350DP, Then Android will select the resource file under the VALUE-SW350DP folder. This feature perfectly solves the problem of fault tolerance for the wide-height qualifier mentioned above.

This package is the closest to the perfect solution for the above scenarios.
First of all, from the development efficiency, it is not inferior to any one of the above scenarios . Based on the fixed scaling ratio, we can basically fill in the corresponding Dimens reference with the dimensions of the UI design without hesitation.
We also have 375 pixel width of the design as an example, in the VALUES-SW360DP folder of the Diemns file should be how to write it? This folder, means that the minimum width of the cell phone DP value is 360, we divide the 360dp into 375 equal parts, each of the design of the pixel in the manuscript, Probably represents the Smallestwidth value of 360DP mobile phone 0.96DP, then the next thing is very simple, if there is a 10px*10px on the design manuscript ImageView, then, We can write the corresponding size in the layout file without thinking about it.

Image

And this diemns reference, in different VALUES-SW<N>DP folder values are different, such as VALUES-SW360DP and VALUES-SW400DP,

Image

Image

When the system recognizes the Smallestwidth value of the phone, it automatically looks for the size of the resource file closest to the target data.

Secondly, from the stability, it is also superior to the above scheme. Native DP adaptation may encounter Pixel 2, some of which have special handsets that need to be individually adapted, but in smallestwidth adaptation, the smallestwidth value of the Pixel 2 phone is 411, We only need to generate a VALUES-SW411DP (or take the whole build VALUES-SW410DP and no problem) to solve the problem.

The adaptation mechanism of smallestwidth is guaranteed by the system, we only need to generate corresponding resource files for this set of rules, there will be no problem which is difficult to solve, and it will not affect our business logic code, and as long as the resource files we generate are reasonably distributed, Even if the corresponding Smallestwidth value does not find the exact corresponding resource file, it can be backwards compatible, looking for the closest resource file.

Of course, the Smallestwidth adaptation scheme has a small problem, that is, it was introduced after Android 3.2, Google's intention is to use it to adapt to the layout of the flat file (but in fact, obviously used for diemns adaptation of the better), However, at present all the projects should be the minimum support version should be 4.0 (embarrassing encyclopedia such an old project is the lowest 4.0 OH), so, this problem is not important.

Another flaw I forgot to mention is that multiple dimens files may cause the APK to become larger, which is the fact that, depending on the coverage and size range of the generated Dimens file, the apk may increase the 300kb-800kb around, and the current embarrassing hundred dimens file size is 406kb, I think this is acceptable.

Today's Headlines Adaptation plan (update)

Article link, before really did not contact, I simply read it again, it can be said, this is relatively perfect solution, I first briefly talk about the idea of this scheme, it is by modifying the density value, forcing all the different size resolution of the phone's width DP value to a unified value, This solves all the adaptation issues.

For example, the design manuscript width is 360px, then the development side will set the target DP value to 360DP, in different devices, dynamically modify the density value, so as to ensure (cell phone pixel width) px/density This value is always 360DP, so that, Will ensure that the UI behaves consistently on different devices.

This scheme is very intrusive, and does not involve the private API, it should also be a very good solution, I do not think that the forced modification of density will have other effects, since there are today's headlines of the manufacturers in use, stability should be guaranteed.

But according to my observation, this scheme is not very friendly to the old project , because after modifying the density value of the system, the actual size of the whole layout will change, if you want to use it in the old project file, I'm afraid the size of the entire layout file may have to be re-edited in the design draft again. Therefore, if you are in the maintenance or transformation of the old project, the use of this package will think twice.

Welfare Gift

The process of generating the Diemns file and the method of calculating the data have already been made clear, we can completely generate these files on their own, I am here with the project code to generate values-sw<n>, we directly take to use, is the Java project. Click here for the project address

About some questions

Q: How is the adaptation scheme used?

A: Click on the GitHub project above, download it locally, then run the Java project, generate the corresponding file in the local root directory, if you need to generate more dimensions, fill in the Dimentypes file with the size you need.

Q: Is there a recommended size?

A 300,320,360,411,450, these dimensions are more necessary, and then insert some other dimensions in it, if not at ease, you can be in between 300-450, 10 as a step to generate more than 10 files.

Q: What is the problem with the tablet?

A: This can be divided into two questions, first, does the team have a specific UI for the flat panel design? Second, how to fit the tablet. If the team does not have a flat design UI for the tablet, then the requirement for the app to run on the tablet is probably not too ugly. The adaptation method for this situation is passive adaptation, that is, do not generate more than 480 of the adaptation file, so on the tablet, the system will use the 480 size of the Dimens file, so that the effect is better than the active adaptation, and if the team actively design the UI of the tablet, then we need to actively generate a tablet adapter file, About 600-800, the key size is 640,768. Then follow the UI design diagram to write.

Q: Is it necessary to use this package to lay out the wrap_content?

A: This is absolutely wrong practice! If the UI design is clearly more suitable for use wrap_content,match_parent,layout_weight, and so on, we will not hesitate to use, and in the high dimension, we should be designed as a sliding way, or match_parent, Try not to write dead. In short, all adaptation schemes are not intended to replace match_parent,wrap_content, but to refine them .

The most stable and efficient UI adaptation solution available on Android