This is the 9th day of my participation in the November Gwen Challenge. Check out the event details: The last Gwen Challenge 2021
Recently opened new projects when they considered the Android screen adaptation, honestly never thought of doing some optimization for this block, the original screen adaptation scheme is simply to use dp and weight to screen adaptation, this method still can be in for the moment, of course, at the lowest cost to fit at least 80% of the mobile phone, But the remaining 20% is also something we need to consider for the sake of perfection.
Another reason is that I have read many excellent blog posts about this area recently, so I will summarize it briefly based on my own experience here:
1. Why does it need to fit?
The most important reason is that Android screen sizes vary, and it is impossible for us to design a set of prototypes to match each size. We need to use the process of adaptation to make the design of the same prototype appear on different screens with the same visual effect as possible.
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.
Below I will introduce you may be more commonly used several methods, and will be attached to a detailed tutorial link, I hope this article can be in your need to do screen adaptation when a guiding role, according to the specific needs and time cost to choose suitable for their own project scheme!
2. Dp adaptation scheme
Android recommends that we use DP instead of PX as the size of the controls to fit from the start.
2.1 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. In short, DP is for developers, but system recognition will eventually be converted to PX.
2.2 How to calculate DP
Px = dp(dpi/160) px = dp(dpi/160)
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.
For example: first of all your DPI is different at different resolutions
| . | 1080 * 720 | 1920 * 1080 |
|---|---|---|
| dpi | 320 | 480 |
| dpi/160 | 2 | 3 |
Therefore, the conversion ratio of DP and PX is also different, which also completes the basic adaptation function. The same DP is finally enlarged into the corresponding PX according to the actual screen size.
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.
2.3 Scheme Defects
As mentioned above, this is the simplest solution with the smallest adaptation range. Some mobile phones need to be adapted separately, because not all mobile phones have A DPI of 480 at 1920*1080 resolution. For example, Google’s Pixel2 (19201080) has a DPI of 420. In Pixel2, 1dp=2.625px, which results in the same resolution on a phone, so a 100DP100dp control might be 300px on a typical 1080P phone, but in Pixel2, it might be 262.5px, which makes the actual size of the control different.
Another problem is that the size of the prototype drawing may not be in accordance with this proportion, so it is very difficult for us to convert the size of the design drawing into DP according to the proportion. The width and height of the prototype drawing are often greatly different from the real width and height of Android phones. Take our design draft for example, the width and height of the design draft is 375px750px. A real phone might be 10801920.
Usually to solve this problem is basically by giving a percentage, or by estimating, or setting a standard value (the method used in the internship) and so on. In short, when we get the prototype, the ImageView of the design draft is 128px128px, but when we write the layout file, we cannot write 128dp128DP 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.
3. Width and height qualifier adaptation scheme
3.1 concept
To put it simply, use the official width and height qualifier to list as many common resolution units as possible in the market, as shown below:
At the same time, we set a benchmark resolution. Under this benchmark resolution, px and DP have a 1:1 relationship, and each pixel will be divided equally:
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
Then the prototype image is designed with the benchmark resolution specified by us, so we can directly fill the size of UI controls with X and Y, and the size is consistent with the prototype image. Later, the system will automatically replace the folder with appropriate PX under the corresponding resolution
3.2 Scheme Defects
In fact, as mentioned above, it is necessary to accurately list all possible resolutions so that they can be accurately converted into the corresponding PX.
Otherwise, the default dimens file is the same. With the default size, the UI is likely to be distorted or, in short, poorly fault-tolerant.
However, this scheme has been used before or it is a more mature and effective scheme.
4. Density Adaptation solution of Toutiao
4.1 concept
I also read toutiao’s technical public account before, which mentioned one of their adaptation solutions. This solution is simply to modify a density value through control to complete adaptation.
The core principle of toutiao screen adaptation solution is to calculate density according to the following formula
Current device total screen width (in pixels)/prototype diagram total width (in dp) = density
Density means how many pixels 1 DP takes up on the current device.
Our goal is to control this density to ensure that the overall width of the resulting prototype is consistent.
For example, if the prototype is 360px wide, the developer will set the target DP value to 360DP and dynamically change the density on different devices to ensure that the PX/DENSITY value is always 360DP. In this way, the UI will behave consistently on different devices.
4.2 Why does the scheme use only one width and height as the benchmark?
There are some schemes including the toutiao scheme where they only consider one wide or one high dp transformation ratio, so why not both? This is mainly because the screen aspect ratio of most Android devices on the market is inconsistent. For example, with the advent of full-screen phones, this problem is even more serious. The full-screen phones launched by different manufacturers may have different screen aspect ratios. This will effectively prevent the layout from distorting on screens with inconsistent aspect ratios. In simple terms, to prevent the appearance of inconsistent aspect ratio
4.3 Detailed understanding and implementation
Follow-up if you consider this kind of program and want to continue to in-depth can take a look at the official public article
4.4 Advantages
It’s easy to get started and the time cost is low.
Invasive is very low, the scheme and the project completely decoupled, the project layout does not rely on a single line of the program code, and use or official Android API, means that when you meet any problem cannot be solved, want to switch to other screen adaptation scheme, basic don’t need to change the code before, the switching process is almost completed in an instant, A lot less hassle, a lot of time saved, and the cost of trial and error is close to zero
Can be adapted to third-party library controls and system controls (not only activities and fragments, Dialog, Toast and other system controls can be adapted), because the modified density is global throughout the project, so a single change will benefit all parts of the project.
4.5 Solution Defects
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 change. 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 according to the design draft. So, if you’re maintaining or retrofitting an old project, think twice about using this solution.
When this adaptation scheme regardless of type, all controls are forced to use our own design drawing size for adaptation, then the problem will occur, when the size of a system control or tripartite library control and our own design drawing size gap is very large, this problem will be more serious
5. SmallestWidth adaptation
5.1 concept
Minimum width qualifier adaptation, using the SW qualifier for adaptation, means that Android will recognize the dp value of the minimum screen height and width (in fact, the width value of the phone), and then find the resource file in the resource file folder corresponding to the qualifier based on the recognition result.
In fact, the idea is the same as our second solution, the system through specific rules to select the corresponding file. But it’s more flexible and doesn’t require a 100% accurate hit resolution.
Let’s take an 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 360DP. The system will look for whether there is a folder of value- SW360DP and corresponding resource files.
If there is no value- SW350DP folder, the system will look down. For example, if the nearest value to 360DP is value- SW350DP, Android will select the resource file under value- SW350DP folder. This feature perfectly solves the problem of tolerance for width and height qualifiers mentioned above.
How do YOU write dimens in the values-SW360DP folder, for example, with a 375 pixel wide design?
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.
This diemns reference has different values in different values-swDP 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.
5.2 Advantages
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.
It is also superior to the above schemes in 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.
5.3 Scheme Defects
A large number of DIMens files need to be imported, so the apK package may be increased. Depending on the coverage and size range of the generated DIMens file, the APK may be increased by about 300KB-800KB.
If the project wants to switch to other screen adaptation solutions, because there are a large number of Dimens references in each Layout file, it will be a huge amount of work to modify, and the switching cost will be very high.
It cannot automatically support adaptation for vertical/horizontal switching. As mentioned above, if you want to automatically support adaptation for vertical/horizontal switching, you need to use values-wDP or screen orientation qualifier to regenerate a set of resource files, which will increase the size of the App again.
If you want to use sp, you also need to generate a series of Dimens, resulting in the size of the App increasing again
6. Your own summary
There are a total of four options for screen adaptation. There is no completely useless solution and no perfect solution. Let’s briefly talk about some of the options I consider.
Dp adaptation: this solution is the simplest and most straightforward to use. If your project is small or even does not have a dedicated designer, combining DP and weight as well as relative layout, constraint layout and other self-applicable layout solutions can actually solve the vast majority of screen adaptation problems. But for a company’s main App, it’s definitely not enough.
Width and height qualifier adaptation: This scheme is very simple, but requires some time. The fourth SW qualifier scheme is recommended when using this scheme.
This solution is suitable for some new projects, in addition, these projects may use the third party UI control is relatively few cases, in this case, this solution is relatively perfect, easy to use, easy to switch, in short, it is better not directly used in the old project.
Sw qualifier adaptation: this solution is suitable for use in APK package size is not particularly sensitive, and it is best not sp size and landscape features of the APP, the time cost above the following reference link has open source projects can be directly generated, but also a lot less time.
7. Reference links
Android currently stable and efficient UI adaptation solution – Radin Wu
Dimens automatic generation tool – Radine Wu
Toutiao adaptation solution details -JessYan
SmallestWidth qualifier adaptation scheme -JessYan
AndroidAutoSize open source adaptation -JessYan