Since the release of Android system for more than 10 years, the adaptation of Android UI has been the most important issue in the development process, but I see that there are still many partners who do not understand the adaptation of Android. Just, the recent preparation of qiushibaike Android client design a set of UI size adaptation scheme, and partners can talk about this problem in detail.

There are two core issues for Android adaptation. One is the efficiency of adaptation, that is, whether the process of converting design drawings into App interface is efficient, and the other is how to ensure the consistency of UI interface in mobile phones with different sizes and resolutions. These two problems are very important, one is to ensure the efficiency of our development, one is to ensure the effectiveness of our adaptation; Today we will talk about the adaptation of Android on these two core issues.

First of all, as we all know, Android doesn’t recommend using px as a real unit of pixels when it comes to sizing, because the resolution is different from phone to phone. For example, a 96 by 96 pixel control will look smaller and smaller in the overall UI on a phone with a higher and higher resolution.

Px is not recommended in layout files because the overall layout effect can be distorted by something like this.

Dp direct adaptation

In this case, Android recommends using DP as a unit of size for the UI.

So what is DP? Dp refers to device-independent pixels. Dp controls represent different real pixels in phones with different resolutions and sizes. For example, in a phone with a lower resolution, 1DP May be 1px, while in a phone with a higher resolution, 1DP May be 2px. It can be similar in size in different phones. So how does this dp compute? We all know the formula px = dp(dpi/160) and the system uses this to determine the mathematical relationship between PX and dp,

So here comes the question, what is dPI?

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

Why do I emphasize that it’s a concept on a software system? When people buy a mobile phone, they often hear another parameter called PPI, which is also the pixel density on the mobile phone screen, but this is a physical concept, which exists objectively and will not change. Dpi is a value artificially specified by the software after referring to the physical pixel density, so as to ensure that the software uses the same value for the physical pixel density in a certain range. This will benefit our UI adaptation.

For example, ppi of several mobile phones with the same resolution and different sizes may be 430,440 and 450 respectively, so in Android system, DPI may all be specified as 480. In this way, dPI /160 is a relatively fixed number, which ensures that phones of different sizes behave the same at the same resolution.

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

. 1080 * 720 1920 * 1080
dpi 320 480
dpi/160 2 3

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

We can say that dp plus adaptive layout and weight proportional layout can basically solve the problem of adaptation on different mobile phones, which is basically the most original Android adaptation scheme.

There are two small problems with this method. First, it can only ensure that the interface written by us can be adapted to most mobile phones, and some mobile phones still need to be adapted separately. Why does DP only solve 90% of the adaptation problems? For example, Google’s Pixel2 (1920*1080) has a DPI of 420, which means that in Pixel2, 1dp=2.625px. This will result in the same resolution on a phone, so that a 100DP * 100DP control on a typical 1080P phone, It might all be 300px, but in Pixel 2, it’s only 262.5px, so the actual size of the control will be different.

For visual purposes, suppose we set the width of an ImageView to 360dp in the layout file. This will look different in the following two images:

Figure 1 shows a 1080P,480dpi mobile phone, figure 2 shows a 1080P,420dpi mobile phone

As can be seen from the above layout, the difference is quite obvious for the same 1080P phone. In this case, our UI may need to be tweaked or even adapted separately.

The second problem is that this method cannot quickly and efficiently implement the designer’s design draft into the layout code. Through DP direct adaptation, we can only make the UI basically adapt to different mobile phones, but DP cannot solve the gap between the design drawing and UI code, because DP is not a real pixel. In addition, the width and height of the design draft are often very different from the real width and height of Android phones. Take our design draft as an example, the width and height of the design draft is 375px*750px, while the real phone may generally be 1080*1920.

So how do we cross this gap in daily development? It’s usually done by percentage, or by estimation, or by setting a standard value, etc. In short, when we get the design draft, the ImageView of the design draft is 128px*128px, but when we write the layout file, we cannot write 128DP * 128DP directly. In the process of converting design to UI code, we need to spend a considerable amount of effort to convert dimensions, which can greatly reduce our productivity and development efficiency.

Width and height qualifier fit

In order to efficiently implement UI development, a new adaptation scheme has emerged, which I call width and height qualifier adaptation. To put it simply, this is an exhaustive list of all the Android phones on the market:

Set a baseline resolution, and all other resolutions are calculated according to this baseline resolution. In different size folders, write corresponding DIMens files according to this size.

For example, use 480×320 as the base resolution

  • The width is 320, and the width of any resolution is rounded into 320 parts, ranging from X1 to x320
  • The height is 480. The height of any resolution is rounded into 480 parts, and the value is Y1-Y480

So for dimens files with 800*480 resolution,

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

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

.

At this time, if our UI design interface uses the benchmark resolution, we can fill in the corresponding DIMens reference according to the size on the design draft. When the APP runs on mobile phones with different resolutions, these systems will look for the corresponding value under the folder of this resolution according to these Dimens references. This basically solved our adaptation problem, and greatly improved the efficiency of our UI development,

A fatal flaw in this solution is that it requires a precise hit to fit. For example, a 1920×1080 phone must find the 1920×1080 qualifier, otherwise it will have to use the same default Dimens file. With the default size, the UI is likely to be distorted or, in short, poorly fault-tolerant.

However, this scheme has been used by some teams, and we can consider it to be a mature and effective scheme.

UI Adaptation framework (maintenance stopped)

Hongyang big man’s adaptation project is also inspired by the wide and high qualifier scheme.

It’s easy to use:

Step 1: Specify the size of your design in the AndroidManifest of your project.

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

Step 2: Make your Activity inherit from AutoLayoutActivity.

Then we can directly use the specific pixel value in the layout file. For example, if the design is 96*96, we can write 96px directly. When the APP runs, the framework will help us scale according to the specific size of the phone.

This can be said to be an excellent scheme, because it goes further on the basis of wide and high qualifier adaptation, and solves the problem of fault tolerance mechanism, which can be said to perfectly achieve the two requirements of efficient development and accurate adaptation.

But we can think of, because the framework to do change at run time in onMeasure, our custom controls may be affected or restricted, there may be some specific controls, requires a separate adapter, there may exist the dark pit is unpredictable, there is a more important question, that is the whole adaptation is a framework to complete, Once this framework is used, it will be very troublesome to replace problems that are difficult to solve in the future. Moreover, once the project stops maintenance, you have to rely on yourself for subsequent upgrades. Can the team afford this cost? Of course, it’s out of maintenance.

But as far as the technical solution goes, it’s undeniably a good open source project.

summary

The adaptations discussed above are mature ones that can actually be used in development, and many developers are actually using them. However, each of them has some defects, so we need to spend extra effort to solve these possible defects after using the above solution.

So, is there a relatively perfect solution with no obvious flaws?

SmallestWidth adaptation

SmallestWidth adaptation, or SW qualifier adaptation. Android will recognize the minimum dp size of the available height and width of the screen (in fact, the width of the phone) and then go to the resource file to find the resource file under the corresponding qualifier folder.

This mechanism is the same as the width and height qualifier adaptation mentioned above, in that the system selects corresponding files according to specific rules.

For example, the DPI of Mi 5 is 480, and the horizontal pixel is 1080px. According to px=dp(DPI /160), the horizontal DP value is 1080/(480/160), i.e. 360DP, the system will look for whether there is a folder of value- SW360DP and corresponding resource files.

The difference between smallestWidth qualifier adaptation and width and height qualifier adaptation is that the former has a very good fault tolerance mechanism. If there is no value-SW360DP folder, the system will look down. For example, the nearest value to the 360DP folder is only value-SW350DP. Android then selects the resource file under the value- SW350DP folder. This feature perfectly solves the problem of tolerance for width and height qualifiers mentioned above.

This scheme is as close to perfect as any of the above. First, in terms of development efficiency, it is no less efficient than any of the above schemes. According to the fixed scale, we can basically fill in the corresponding DIMens reference according to the UI design size without thinking. For example, how to write a diemns file in the values-sw360DP folder? In this folder, it means that the dp value of the minimum width of the phone is 360. We divide 360DP into 375 equal parts, and the pixels in each design draft roughly represent 0.96 DP in the phone with smallestWidth of 360DP. Then the following things are very simple. If a 10px by 10px ImageView appears on the layout, you can write the size in the layout file without thinking about it.

The diemns reference has different values in different values-sw<N>dp folders, such as values-sw360DP and values-sw400dp.

When the system recognizes the smallestWidth value of the phone, it will automatically find the size of the resource file closest to the target data.

Secondly, it is superior to the above schemes in terms of stability. The native DP adaption may encounter Pixel 2 phones that require a separate adaption, but in the smallestWidth adaption, the Pixel 2 phone’s smallestWidth value is 411. We just need to generate a values-SW411DP (or round to values-SW410DP) to solve the problem.

The adaptation mechanism of smallestWidth is guaranteed by the system, we only need to generate the corresponding resource files for this set of rules, there will be no difficult problems, and it will not affect our business logic code, and as long as the distribution of the generated resource files is reasonable, Even if the corresponding smallestWidth value does not find the exact corresponding resource file, it is backward compatible to find the closest resource file.

Of course, there is a slight problem with smallestWidth adaptation, which was introduced after Android 3.2, and Google intended to use it for tablet layout files (but it works better for Diemns, apparently). However, the minimum supported version of all projects should be 4.0, so this question is not really important.

Another flaw mentioned in the comment that I forgot to mention is that multiple Dimens files can cause apK to become larger, which is true, depending on the coverage and size range of the generated DIMens file, APK can increase by around 300KB – 800KB, currently the top 100 Dimens file size is 406KB, I think that’s acceptable.

Toutiao Adaptation Solution (update)

Article links, do not contact before, I watched it again, simple, so to speak, it is also a relatively perfect solution, I first simple speak of this scheme, it is by changing the density value, to put all the different resolution to the size of the mobile phone the width of the dp value into a unified, so that it can solve the problem of all the adapter.

For example, if the width of the design is 360px, the development side will set the target DP value to 360DP and dynamically change the density value on different devices to ensure that the PX/DENSITY value is always 360DP. This will ensure that the UI behaves consistently on different devices.

This solution is very low in invasions, and does not involve private API, should be a very good solution, I do not know if the forced change of density will have other impact, since there are toutiao’s big factory using, the stability should be guaranteed.

However, 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 entire layout will be changed. If you want to use it in the old project file, I am afraid that the size of the entire layout file may have to be modified again according to the design draft. So, if you’re maintaining or retrofitting an old project, think twice about using this solution.

Welfare gifts

The process of generating diemns files and data calculation method has been explained above, you can completely generate these files, I present here to generate values-sw project code, you can directly use, is Java project. Click here for the project address

Student: Some questions

Q: How is the adaptation scheme used?

A: Click on the Github project above, download it to the local directory, and then run the Java project. The corresponding file will be generated in the local root directory. If you need to generate more sizes, fill in the DimenTypes file with the size you need.

Q: Is there a recommended size?

A 300,320,360,390, 411,450, these several sizes are necessary, and then insert some other sizes. If you don’t trust, you can choose between 300 and 450, and generate more than A dozen files with 10 steps.

Q: Tablet fit?

A: This can be broken down into two questions. First, did the team design the UI specifically for the tablet? The second is how to fit the tablet. If the team doesn’t design the UI for the tablet, the requirement for the App to run on the tablet is basically that it shouldn’t look bad. In this case, the adaptation method is passive adaptation, that is, do not generate adaptation files of more than 480, so that on the tablet, the system will use dimens files of 480 size, which is better than active adaptation. If the team took the initiative to design the UI for the tablet, we would have to take the initiative to generate adaptation files for the tablet, somewhere between 600-800, with a critical size of 640,768. Then follow the UI design diagram to write.

Q: Does this solution eliminate the need to use wrAP_content and other layouts?

A: That’s absolutely wrong! If the UI design is obviously better for wrap_content,match_parent,layout_weight, etc., we should not hesitate to use wrap_content,match_parent,layout_weight, etc., and in the higher dimension, we should make it slippable according to the situation, or match_parent, and try not to write dead. In short, all matches are not designed to replace match_parent or wrap_content, but to improve them.

Afterword.

In a few days, QiusbaiAPP will release a new version of the 11.2.0 UI revision, in which sw adaptation is widely used. You can try it with various Android phones to see the adaptation effect. If there is any problem with the adaptation, please contact me in time.