The Most Stable and Efficient UI Adaptation Solutions for Android

【Reply to the public account with “1024” to receive a special push】

Since the release of the Android system more than a decade ago, the adaptation of Android’s UI has always been one of the most important issues in the development process. However, I still see many friends who are not familiar with the Android adaptation solutions. Recently, I am preparing to design a UI size adaptation solution for the Qiu Shi Bai Ke Android client, and I can discuss this issue in detail with everyone.

The two core issues of Android adaptation are efficiency, which refers to whether the process of converting design drawings into app interfaces is efficient, and how to ensure the consistency of UI interfaces across different sizes and resolutions of phones. Both issues are crucial; one ensures our development efficiency, and the other ensures the effectiveness of our adaptation. Today, we will discuss these two core issues regarding Android’s adaptation solutions.

First of all, everyone knows that when indicating dimensions, Android does not recommend using the px unit of real pixels, because the resolution varies between different phones. For example, a 96*96 pixel control will appear smaller in the overall UI on phones with higher resolutions.

Similar to the above image, the overall layout effect may deform, so the px unit is not recommended in layout files.

Directly Adapting with dp

In response to this situation, Android recommends using dp as the unit of measurement for UI adaptation.

So, what is dp? dp stands for device-independent pixels. Controls measured in dp represent different real pixels on phones with different resolutions and sizes. For instance, on a phone with a lower resolution, 1dp may equal 1px, while on a phone with a higher resolution, 1dp may equal 2px. This way, a 96*96dp control can appear to be about the same size across different phones. How is dp calculated? We all know a formula: px = dp(dpi/160). The system uses this to determine the mathematical relationship between px and dp.

Now, another question arises: what is dpi?

dpi refers to pixel density, which indicates the number of pixels per unit size specified in the system software. This is often a fixed value recorded in the system’s factory configuration file.

Why do I emphasize that it is a concept in software systems? Because when buying a phone, people often hear another parameter called ppi, which also refers to pixel density in phone screens, but this is a physical concept that objectively exists and does not change. dpi is a value that the software specifies after referencing the physical pixel density, ensuring that within a certain range, the physical pixel density uses the same value in software. This is beneficial for our UI adaptation.

For example, several phones with the same resolution but different sizes might have ppi values of 430, 440, and 450, while in the Android system, dpi might all be specified as 480. This way, dpi/160 becomes a relatively fixed value, ensuring consistent performance of different sized phones under the same resolution.

…

1080*720

1920*1080

In different resolutions, dpi will vary. For example:

…

1080*720

1920*1080

From the above table, we can see that the dpi is different between 720P and 1080P phones, which means that in different resolutions, 1dp corresponds to a different number of px (in 720P, 1dp=2px, in 1080P, 1dp=3px). This achieves a situation where when we define a control size using dp, it will represent the corresponding pixel value size in different phones.

We can say that using dp along with adaptive layouts and weight ratio layouts can basically solve the adaptation issues across different phones, which is the most original Android adaptation solution.

This method has two minor issues. First, it can only guarantee that the interface we create is compatible with the vast majority of phones; some phones still require separate adaptation. Why does dp only solve 90% of the adaptation issues? Because not all 1080P phones have a dpi of 480. For example, Google’s Pixel 2 (19201080) has a dpi of 420, meaning that on Pixel 2, 1dp=2.625px. This can lead to differences in the actual size of a control with the same resolution on different phones. For instance, a 100dp100dp control may measure 300px on a typical 1080P phone, but only 262.5px on Pixel 2, resulting in a noticeable size difference.

To illustrate, suppose we set the width of an ImageView in the layout file to 360dp. In the two images below, the displays will differ:

Image one is a 1080P phone with 480dpi, while image two is a 1080P phone with 420dpi.

From the layouts above, we can see that even with the same 1080P resolution, the differences are quite significant. In such cases, our UI may require some fine-tuning or even separate adaptation.

The second issue is that this method cannot quickly and efficiently translate the designer’s design draft into layout code. By adapting directly with dp, we can only ensure that the UI is generally adaptable to different phones, but the gap between the design draft and the UI code cannot be resolved by dp, as dp is not a real pixel. Moreover, the width and height of design drafts often differ significantly from the actual width and height of Android phones. Taking our design draft as an example, the width and height are 375px750px, while the actual phone is generally 1080x1920.

So how do we cross this gap in daily development? Basically, we do it through percentages, estimates, or by setting a standard value, etc. In short, when we receive a design draft where the ImageView is 128px128px, we cannot directly write it as 128dp128dp in the layout file.

Width and Height Qualifier Adaptation

To achieve efficient UI development, a new adaptation scheme has emerged, which I call Width and Height Qualifier Adaptation. In simple terms, it exhaustively lists the pixel values of all Android phones on the market:

It sets a baseline resolution, and all other resolutions are calculated based on this baseline resolution. In different size folders, corresponding dimens files are written based on that size.

For example, taking 480×320 as the baseline resolution:

• Width of 320, dividing any resolution’s width into 320 parts, yielding values x1-x320.

• Height of 480, dividing any resolution’s height into 480 parts, yielding values y1-y480.

For a dimens file for a resolution of 800*480:

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

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

…

At this point, if our UI design interface uses the baseline resolution, we can fill in the corresponding dimens references according to the sizes on the design draft. When the APP runs on different resolution phones, the system will look for the corresponding values in the dimens reference under the appropriate resolution folder. This essentially solves our adaptation problem and greatly improves our UI development efficiency.

However, this solution has a fatal flaw: it requires precise matching to adapt. For example, a 1920×1080 phone must find the 1920×1080 qualifier; otherwise, it will have to use the unified default dimens file. Using default sizes can lead to UI deformation, making it a solution with very poor fault tolerance.

Nevertheless, some teams have used this solution, and we can consider it a relatively mature and effective solution.

UI Adaptation Framework (No Longer Maintained)

The adaptation solution from Hong Yang is also inspired by the width and height qualifier solution.

The usage is simple:

Step 1: Specify the dimensions of your design draft in your project’s AndroidManifest.

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

Step 2: Make your Activity inherit from AutoLayoutActivity.

Then we can directly use specific pixel values in the layout file. For instance, if the design draft is 96*96, we can directly write 96px, and when the APP runs, the framework will help us scale according to the specific size of different phones.

This can be considered an excellent solution, as it builds upon the width and height qualifier adaptation while further addressing the fault tolerance issue, perfectly meeting the requirements of development efficiency and precise adaptation.

However, we can anticipate that since the framework will perform transformations at runtime in onMeasure, our custom controls may be affected or restricted, and some specific controls may require separate adaptation. The potential pitfalls here are unpredictable. Another important issue is that the entire adaptation work is done by the framework, not the system. Once this framework is used, future difficult problems may be very troublesome to replace, and if the project stops being maintained, future upgrades will rely solely on you. Can the team bear that cost? Of course, it has already stopped being maintained.

However, purely from a technical solution perspective, it is undeniably a good open-source project.

Summary

The adaptation solutions discussed above are all relatively mature solutions that can be practically used in development, and indeed many developers are using them. However, due to their respective flaws, we will need to spend additional effort addressing these potential shortcomings after employing the aforementioned solutions.

So, is there a relatively perfect solution without obvious flaws?

smallestWidth Adaptation

The smallestWidth adaptation, or sw qualifier adaptation, refers to Android’s recognition of the smallest dimension of the screen’s usable height and width in dp (essentially the phone’s width), and then searching for the corresponding resource files in the resource folders based on the recognized results.

This mechanism is similar in principle to the previously mentioned width and height qualifier adaptation, where the system selects the corresponding files based on specific rules.

For example, the Xiaomi 5 has a dpi of 480, and its horizontal pixel is 1080px. According to px=dp(dpi/160), the horizontal dp value is 1080/(480/160), which equals 360dp. The system will look for whether there exists a folder named value-sw360dp and the corresponding resource files.

The biggest difference between smallestWidth qualifier adaptation and width and height qualifier adaptation is that the former has a good fault tolerance mechanism. If the value-sw360dp folder does not exist, the system will look for the nearest value, for example, if the closest is only value-sw350dp, then Android will select the resource files from the value-sw350dp folder. This feature perfectly resolves the fault tolerance issue mentioned in the width and height qualifier adaptation.

This solution is the closest to perfect among the aforementioned solutions. First, in terms of development efficiency, it is on par with any of the aforementioned solutions. Based on a fixed scaling ratio, we can basically fill in the corresponding dimens references according to the UI design size without hesitation. Taking a design draft with a width of 375 pixels as an example, what should we write in the dimens file under the values-sw360dp folder? This folder indicates that the minimum width in dp is 360; we can divide 360dp into 375 parts, meaning each pixel in the design draft approximately represents 0.96dp in a 360dp phone. The subsequent steps are straightforward: if the design draft has an ImageView of 10px*10px, we can directly write the corresponding size in the layout file without hesitation.

And this dimens reference will have different values under different values-swdp folders, such as values-sw360dp and values-sw400dp.

When the system recognizes the smallestWidth value of the phone, it will automatically look for the resource files in the folder corresponding to the target data.

Secondly, in terms of stability, it also surpasses the aforementioned solutions. Native dp adaptation may encounter special phones like Pixel 2 that require separate adaptation. However, in smallestWidth adaptation, by calculating the smallestWidth value of the Pixel 2 phone as 411, we only need to generate a values-sw411dp folder (or rounding to generate values-sw410dp is also acceptable) to resolve the issue.

The smallestWidth adaptation mechanism is guaranteed by the system; we only need to generate the corresponding resource files based on this rule, avoiding difficult problems and not affecting our business logic code. Moreover, as long as the resource files we generate are reasonably distributed, even if there are no completely corresponding resource files for the smallestWidth value, it can still be backward compatible and find the closest resource files.

Of course, the smallestWidth adaptation solution has a minor issue: it was introduced after Android 3.2. Google’s original intention was to use it to adapt layout files for tablets (but it clearly works better for dimens adaptation). However, all current projects should have a minimum support version of 4.0 (even the Qiu Shi Bai Ke project has a minimum of 4.0), so this issue is not particularly important.

Another flaw I forgot to mention is that multiple dimens files may increase the size of the apk. This is a fact; depending on the coverage range of the generated dimens files and their size range, the apk may increase by around 300kb-800kb. Currently, the size of the dimens files in Qiu Bai is 406kb, which I believe is acceptable.

Toutiao Adaptation Solution (Updated)

The article link indicates that I had not encountered this before. After a brief overview, I can say that this is also a relatively perfect solution. Let me briefly explain the idea behind this solution: it forcibly modifies the density value to unify the width dp values of all phones with different sizes and resolutions, thus resolving all adaptation issues.

For instance, if the design draft width is 360px, the development side will set the target dp value to 360dp. In different devices, the density value is dynamically modified to ensure that (phone pixel width)px/density remains 360dp, thereby ensuring consistent UI performance across different devices.

This solution has very low invasiveness and does not involve private APIs, making it an excellent solution. I currently cannot think of any other impacts that forcibly modifying density might have. Since a large company like Toutiao uses it, its stability should be guaranteed.

However, based on my observations, this solution is not very friendly to older projects, because modifying the system’s density value will change the actual size of the entire layout. If one wants to use this solution in older project files, they will likely need to modify the dimensions in all layout files according to the design draft again. Therefore, if you are maintaining or transforming an older project, you should think twice before using this solution.

Benefits Offered

The process of generating dimens files and the calculation methods have been explained above, and everyone can generate these files themselves. Here, I will provide the project code for generating values-swfor you to use directly; it is a Java project.

Click here to access the project address

https://github.com/ladingwu/dimens_sw

Author: Latin Wu | Original link:https://www.jianshu.com/p/a4b8e4c5d9b0