Give you a fully automatic screen adaptation scheme (based on SW solution)! --Free your hands and the UI

Calces Series related articles: Calces automatic implementation of Android component module building

Objective

Screen adaptation has always been a hot topic in mobile development, but the adaptation scheme often conflicts with the design draft provided by the UI when actually developing. This article is based on the official Recommended configuration qualifier scheme (smallest width currently the best solution for Android screen adaptation) to achieve a near-perfect screen adaptation scheme.

For the perfect Fit solution The author defines this:

1. The perfect fit for UI artwork.
2. When the adapter is complete, there will be no blur on the HD device.
3. Minimize the invasive nature of the project.

Below I will start with some basic knowledge of screen adaptation, to show you an optimal screen adaptation program.

This is my Android Build helper library, where the screen plug-in is the key to implementing auto-fit. Because you are afraid to miss this plugin, so here in advance to recommend to everyone.

The screen plugin provides two main features:

1. Configure the design density to automatically generate the corresponding resource file with the smallest width value that needs to be adapted to the screen
2. Provides the highest-clear bitmap needed to automatically scale bitmap resources as needed to scale the density.

Github: If you think this tool is going to help you, you can click Star, which is the motivation for me to stick with it.

If you want to learn more about how this plugin automatically helps you achieve screen adaptation, read on.

The demo address of this article: Screenadaptation in the project is the demo of this article.

Screen Adaptation Overview concept

• Screen Size: The screen size refers to the physical size of the screen, measured by the diagonal of the measurement screen.

• Screen density: The amount of pixels in the physical area of the screen, often referred to as DPI (pixel points per inch). The higher the density, the better the realistic effect.

• Resolution: The total number of physical pixels on the screen. Do not adapt directly to the screen, and should be adapted with screen size and screen density

• DP:DP is an Android-specific unit of virtual pixels, independent of physical parameters. 1DP equals a physical pixel on the screen of a stroke, and at run time, the system transparently handles any scaling of the DP units as needed, depending on the actual density of the screen in use. The conversion of DP units to screen pixels is simple: px = DP * (dpi/160). On a 1-DPI screen, the DP equals 1.5 physical pixels.

How to support multiple screens

Android supports a variety of screens based on the ability to render the layout and bitmaps of the application in the appropriate way for the current screen configuration, which is supported at the system level. We can better handle the adaptation of different screen configurations in the following ways:

1. Provide different layouts for different screen sizes
   By default, Android adjusts the size of the app's layout to fit the current device's screen, and in most cases the system provides support to meet our needs. However, there are times when you need to design different layouts for different screen resolutions to achieve a better realistic effect.
2. Provide different picture resources for different screen densities
   We can provide images of different pixels by configuring the density resource's configuration qualifier to fit different screen densities.

For the 1th, in the actual work is difficult to achieve. Because the general UI only provides a set of design drafts, it does not provide the appropriate fit based on the screen at different resolutions. But we have no way of controlling what resolution our app will eventually run on, and to achieve a different screen display, we can achieve screen adaptation by providing a different density of bitmap resources with the smallest width scheme.

What is a smallest width adaptation

Smallest width literally means the minimum width, specified by the minimum size of the available screen area. Specifically, the smallestwidth of the device is the minimum size of the screen's available height and width.

For example, you can use this qualifier to create a layout resource if the layout requires that the minimum size of the screen area is always at least a maximum of $ DP res/layout-sw600dp/ . These resources are used only when the minimum size of the available screen is at least 600DP, regardless of whether the edge represented by 600DP is the height or width that the user considers. Smallestwidth is the fixed screen size feature of the device, and the smallestwidth of the device does not change with the screen orientation .

So we can provide different resources for screen adaptation depending on the SW value of the screen that needs to be adapted.

Some basic concepts of UI design and screen adaptation

I think a lot of screen adaptation tutorials have missed a very important point: there is no explanation for the relationship between screen adaptation and UI design!

In practice, UI designers provide a set of UI drafts and rulers that engineers use to develop the UI. UI if we're going to do a good job with Android screens, we have to understand that UI drafts act as anchors in our interface development. To fit other screens, you must calculate the value of the Dimens resource on the other screen based on this benchmark.

As an example:
For example, many UI designers will use IPhone6 size as the standard to make designs and rulers, and IPhone6 's screen width is 375px, so this design with 375px width is the benchmark for our screen.

If there is a SW equal to 375DP equipment, then this device and the design of the corresponding relationship is 1DP = 1px, then we do not need to do any adaptation, directly the design draft in PX units of the ruler value is converted to 1:1 in the proportion of DP units.

Here, we can come to the conclusion that the screen adaptation needs to be based on the UI draft to formulate a suitable formula for the case!

One problem, however, is that each UI designer's preferences are different, and the scale of the design manuscript provided is not fixed. and Android screen fragmentation is very serious, we need to adapt the value of the SW of the screen is also changeable. So if you need to manually calculate the corresponding Dimens value each time, it is very time-consuming and cumbersome. There are tools available on the Web to quickly generate Dimens values for the corresponding SW, but there are two drawbacks to these tools:

1. There's no way to convert based on UI design, so it doesn't have to be 100% to restore the design effect.

2. A large number of useless dimens values are generated. In fact, if we carefully observed the design manuscript, we will find that in fact, each design manuscript commonly used PX value is fixed 10 of a dozen. For example, the same 375px design as the benchmark, using the tool will generate 1PX ~ 375px corresponding DP value, so there will be a lot of useless dimens value. This will only increase the size of the installation package.

This two shortcomings, can use the author's Calces.screen plug-in to solve, the following will introduce the use of the plug-in and use of the effect.

Use of Calces.screen to quickly implement smalles widths adaptation before and after matching

or the design of the IPhone6 as an example, if there is such a design draft, if not for any adaptation, the display on different devices compared to the following:

The first mobile phone is said above in the SW = 375DP mobile phone, we can see the SW for other values of the phone above, the display effect is not good. On the SW = 411DP and SW = 900DP devices, there is a large amount of blank space, and on the SW = 360DP device, there is a phenomenon beyond the screen range. Our goal is to match the results shown on all devices with the design (SW = 375DP effect).

The effect of using the Calces.screen plugin after adaptation:

Here is a point to note is that you can see the third device inside the adaptation or a bit of a problem, probably left around 1DP white edge. This is the Pixel 2 XL simulator, you can see that the measured value of the SW should be 411DP, but after the actual measurement of the author, found that SW should be 412DP. Interested readers can create a 411DP-width control in the layout editor themselves, and can see that there are approximately 1DP white edges under the pixel 2 XL device. So this 1DP error should be related to the device, here affixed with the calces.screen generated SW = 411DP of the value of the Dimens file view of the reference.

<resources>  <!-- sw411dp -->  <dimen name=‘px_48‘>53dp</dimen>  <dimen name=‘px_75‘>83dp</dimen>  <dimen name=‘px_100‘>110dp</dimen>  <dimen name=‘px_125‘>137dp</dimen>  <dimen name=‘px_150‘>165dp</dimen>  <dimen name=‘px_200‘>220dp</dimen>  <dimen name=‘px_250‘>274dp</dimen>  <dimen name=‘px_300‘>329dp</dimen>  <dimen name=‘px_375‘>411dp</dimen>  <dimen name=‘text_px_28‘>31sp</dimen>  <dimen name=‘text_px_32‘>36sp</dimen>  <dimen name=‘text_px_40‘>44sp</dimen></resources>

When SW = 411DP, the actual value of px_375 is 411DP, so this is in line with our expected conversion results.

How to introduce Calces.screen

First, we need to introduce the Calces plugin, which is simple to introduce:

Add code to the Build.gradle of the project:

//Gradle版本高于2.1的情况下（推荐方案）plugins {    id "calces.screen" version "1.2.3"}//Gradle版本低于2.1的情况下（2.1以上版本也兼容这种方式）buildscript {  repositories {    maven {      url "https://plugins.gradle.org/m2/"    }  }  dependencies {    classpath "gradle.plugin.com.tangpj.tools:calces:1.2.3"  }}

Add code in Modules's Build.gradle:

apply plugin: "calces.appconfig"

Using the Calces.screen adaptation screen

First, we need to create the Dimens.xml file in the Res/values/folder, and then follow the design's ruler to write the required dimensions to the file. For example:

<?xml version="1.0" encoding="utf-8"?><resources>    <!--design 375px-->    <dimen name="px_48">48dp</dimen>    <dimen name="px_75">75dp</dimen>    <dimen name="px_100">100dp</dimen>    <dimen name="px_125">125dp</dimen>    <dimen name="px_150">150dp</dimen>    <dimen name="px_200">200dp</dimen>    <dimen name="px_250">250dp</dimen>    <dimen name="px_300">300dp</dimen>    <dimen name="px_375">375dp</dimen>    <!--text size-->    <dimen name="text_px_28">28sp</dimen>    <dimen name="text_px_32">32sp</dimen>    <dimen name="text_px_40">40sp</dimen></resources>

This is our benchmark Dimens file.

Now all we need to do is to configure the reference size and the size needed to fit through the gradle, for example, in the example above, we needed to fit the SW: 320DP, 411DP, 900DP, Then we need to add the following code under modules's Build.gradle file:

screen{    dimens{        designPx 375        smallesWidths 320,375,411,900        scale BigDecimal.ROUND_UP        auto true    }}

The corresponding relationship of the above configuration information is:

• DESIGNPX: The SW size of the design (unit px)

• Smalleswidths: Screen SW size required for adaptation (unit DP)

• Scale: How numbers are rounded
  Because the Android system can only fit the DP value of an integer unit, we can configure the specific positive way by scale. Here directly to take the bigdecimal provided by the round to achieve. If not set, a double-type DP value is generated (the decimal digits are discarded when actually used)

• Auto: Whether Dimens is automatically generated, and when Auto is true, each build will regenerate the appropriate dimens file.
  If you do not set auto or set to False, you can manually invoke the Gradle task to generate it.
  Invoke command: /gradlew dimenscovert
  You can also directly click on Gradle task execution, such as:

After the configuration is complete, rebuild the following project to see the generated resource files, such as:

In order to not affect the compile time auto recommendation is set to FALSE, you need to manually start the task to generate an adaptation resource file.

How do we determine what SW value we need to fit?

In addition to automatically generating SW, we also need to make sure that our app needs to support those SW values. The simplest way to do this is to first determine which devices we want to support. Here the author gives a suggestion is that there are very many devices on the market SW value is 360DP, so we have to adapt to 360DP equipment. As for the other devices, we can make sure that we find a parameter called the minimum width in the developer mode, the value of which is the SW value we need. Specific example:

For example, this is the SW value of Nexus S. If we do not specifically adapt to the SW = 384DP screen, then the system will default to find a suitable resource of less than 384DP (so 360DP is a relatively common adaptation value). When we have test equipment, it is very easy to use the Calces.screen adaptation. So what if we don't know that there are no test equipment? (e.g. with user feedback, there is a big problem with the adaptation under a device)

Here we recommend a website: Device Metrics

This site is material design device parameter search site, users here directly find the corresponding device size can be (before the method overturned, slipped away).

In general, the SW 360DP and 480DP screen will be more common, so we have to generate these two sets of resources, if you need to support pad, you need to adapt to SW = 600DP or SW = 720DP screen, and then according to the actual situation to adapt to other SW values of the screen.

So far, we have completed the Android SW-based screen adaptation, very simple!

However, this article is not finished, this plug-in in addition to provide automatic implementation based on the SW scheme, but also provides a killer function: According to the configuration automatically generate the corresponding resolution of the bitmap resources. When we need to adapt to a variety of different screen density of the mobile phone, only need to provide a set of high-definition bitmap resources to free you and the UI designer's hands.

Calces.screen realizing bitmap auto-scaling adaptation

Providing different bitmap resources for different densities of screens is the official Google recommended screen fitting practice. The advantage of this is that the app can achieve the best results on a screen of different densities, and will not appear in the HD screen display of old age machine, and in different densities of the screen can maintain a relatively stable display effect. The following is the proportional relationship of the bitmap resource density:

Density qualifier	Proportional Relationship	Description
ldpi	0.75	Resources for low-density screens (~120DPI)
mdpi	1	Resources for the medium density screen (~160dpi) (baseline density)
hdpi	1.5	Resources for high-density screens (~240DPI)
xhdpi	2	Resources for ultra-high-density screens (~320DPI)
xxhdpi	3	Resources for ultra-high-density screens (~480DPI)
xxxhdpi	4	Resources for ultra-ultra-high-density screens (~640dpi). This qualifier applies only to the launcher icon.

But there is a problem here, in general, bitmap resources are provided to us by the UI designer. I've talked to a lot of UI designers, and their solution is to first cut a set of top-level pictures, then scale them as needed, and then provide it to the engineer.

In general, this practice is no problem except for the tedious point. But what if there's a situation where you need to support a lower-density screen? This only allows the UI designer to scale a set of density bitmaps. So what if a part of the bitmap is no longer in use and needs to be deleted? The engineer needs to find the bitmap of the other density and delete it. Adding new bitmaps to the project will also need to be added manually.

So in general, the UI provides a picture resource--engineers use the picture resources in this process is purely hand-controlled. The work is tedious and meaningless, and the manual migration process can be very error-prone (think about what would happen if you copied a bitmap resource with a certain number of densities?). ）。 So Calces.screen also provides bitmap management functionality.

Calces.screen managing bitmaps

Before using the bitmap zoom feature of screen, discuss with the designer/product the highest-density screens that the app needs to support. Then the designer will only need to provide a bitmap of this density. Then we only need to configure it in the modules Build.gradle, which is configured as follows:

screen{    mipmap{        designDensity "xxxhdpi" //测试用，目前手机屏幕最高只支持到xxhdpi        mipmapDensity ‘xxhdpi‘,‘xhdpi‘,‘hdpi‘,‘mdpi‘        auto true    }}

After the configuration, rebuild the file is ready, of course, do not want to increase the compilation time, you can put auto to false or not set. Mipmap supports the incremental compilation feature, only the bitmap that does not exist in the folder is scaled, the existing is skipped, and the recognition condition is the file name. The bitmap zoom function is manually initiated in the same manner as described above, and the task name is Mipmapzoom. Let's take a look at the conversion effect:

Before conversion

After conversion

Readers can click to see the converted image size, you can find that the converted image to meet the proportions we need. Interested readers can download the demo and delete the bitmap resources from other resolutions and regenerate them through the Mipmapzoom task.

Through the Mipmapzoom task, we can greatly reduce the workload of the UI designer and engineer, and only need to manage a set of bitmap files, freeing us from the mechanized task.

Note: The current version does not support the bitmap deletion function, so when we need to delete some of the bitmap, we need to delete the auto-generated picture files, regenerate, the subsequent version will increase the function.

Conclusion

Screen fit has always been a big problem for mobile developers, and we've been looking for a better fit when it comes to the vast array of screen sizes and screen densities. Smallest width is currently the simplest and best fit solution in Android, not one, it is supported by the system, and in the adaptation will not be due to the screen resolution and design of the differences too big cause some weird problems (big screen on the top of the paste, small screen and appear too dense pixels). This adaptation scheme is based on the smallest width and the provision of multiple sets of bitmaps, through the Gradle plug-in to automatically handle the SW scale calculation and file generation, bitmap auto-scaling to achieve a relatively better adaptation scheme.

Calces.screen's development was designed to simplify the workload of UI designers and Android engineers, which is now largely achieved.

Well, the introduction of the Calces.screen plug-in is over, here again to remind you, if you feel calces to help you, you can click Star, encourage the author. If there are any better ideas, you can participate in this open source project. The author will always maintain the project, to reduce the burden of Android engineers, the repetitive mechanical work is all handed over to Gradle to deal with.

Github: If you think this tool is going to help you, you can click Star, which is the motivation for me to stick with it.

Public Number:
If you think this article is enlightening to you, you can follow my public number.

Give you a fully automatic screen adaptation scheme (based on SW solution)! --Free your hands and the UI