Due to the fragmentation of Android, screen adaptation has always been a headache for development. Faced with a variety of screen sizes and resolutions on the market, Android's solution based on the dp and res directory names has been unable to meet the needs of writing full-screen adaptations at one time. In order to achieve optimal visual effects, it is always necessary to develop the process. It takes more resources to adapt. Some developers have also given their own solutions. First, analyze the status quo of some common solutions:
Official adaptation program
Dp. Dp is a unique unit in Android development. Unlike px, dp is a unit based on screen pixel density. On a screen with a low density, perhaps 1dp=1px, but on a screen with a high density 1dp=4px. When writing a layout xml, if the length and width of a control are specified using dp, then the absolute size of the control under various screens of various sizes and resolutions can be ensured. In other words, regardless of the size of the screen under the pad or mobile phone, we actually see the size of the control is similar:
Resource directory name. The above figure shows that using dp ensures that the absolute size of the control is consistent across screens. The advantage of this is that in a screen of similar size, no matter how large the resolution is, it will not affect the layout; but when the screen size is greatly different, it is only guaranteed that the absolute size of the control looks problematic. In the res directory, you can add a suffix such as '-1920x1080' to each resource directory to adapt to different screens. The specific rules can be found in the official website. This can provide different layouts for different screens, and even provide two completely different layout styles for the pad and the phone. But usually, designers don't provide different designs for different screens. Their requirement is that the relative sizes of the controls on different screens are the same, so dp does not satisfy this, but adapts to various screens. Again and again it is a bit tedious, and the modification is also more troublesome. The usual adaptation we need is this:
Percentage layout support library. Not used, but deprecated in API level 26.0.0-beta1.
ConstraintLayout. The recommended layout after the percentage support library is deprecated may seem a bit complicated.
Player adaptation program. The purpose of the adaptation of the majority of players is very clear, the purpose is to ensure that the relative size of the control in different screens is consistent and looks like a hair. Take two adaptations of a big God player as an example:
Option One. Writing a script converts the length to length at each resolution, the disadvantage being that it is difficult to cover all resolutions on the market.
Option II. AutoLayout support library. The idea of ​​the library is very good: against the design diagram, using px to write the layout does not affect the preview; the drawing stage converts the corresponding px value calculation of the design diagram to the size of the current screen adaptation; to simplify the access, inflate automatically when each Layout is converted to the corresponding AutoLayout so that it does not need to be changed in all xml. But at the same time, the library also has the following issues:
Poor scalability. For each ViewGroup must be corresponding to write corresponding AutoLayout to expand, for each View need to adapt to the properties to write code to adapt to expand;
Perform numerical calculations in the onMeasure phase. Consumes performance, and this is more unreasonable for properties in non-LayoutParams. For example, on the onMeasure TextView textSize conversion and setTextSize, then the player in the code dynamically set the textSize will fail, because each onMesasure will be re-set by AutoLayout override.
There are many issues and the author no longer maintains them.
Second, ideasFor screens with large differences in size, the same design plan should not be used. Otherwise, the advantages of the big screen are not fully reflected. It seems that the official adaptation plan also expresses this meaning. However, in the actual design and development, for an ordinary App, few projects have the will to have the energy to design and develop a set of design solutions for each screen.
A simple adaptation requirement is usually: if the design width is 200, and a control has a length of 3 on the design diagram, then the length of the control is equivalent to 3/200 of the total width, then we want to have a screen of any size. The length displayed on the control is 3/200 of the screen width.
Personally think that AutoLayout's design idea is very good, but the LayoutParams and attributes as a cut in the conversion process in the mesure process of the calculation of the efficiency and scalability problems. So where is the length of the Android calculation length, can it be converted when Android calculates the length? If you can calculate the length of the Android calculation, then you do not need a series of extra calculations and adaptation, all problems will be solved.
After some searching, we find that the length of the system's calculation is the applyDimension function in TypedValue, and the unit and value are passed to calculate the corresponding px value.
You can see the conversion method is very simple, and all the properties of DisplayMetrics are public, you can modify without reflection;
The original meaning of pt is the unit of length in pounds. Modifying the metrics.xdpi according to the current screen and design drawing size can be achieved by redefining the pt unit as the relative length unit we need, so that the actual px corresponding to 1pt calculated after the modification is calculated. / Screen width px = 1px / Design width px.
Where does this DisplayMetrics come from? From the source code can be seen generally mContext.getResources (). GetDisplayMetrics (), this mContext is where the AcTIvity;
Changes in ConfiguraTIon, such as horizontal and vertical screen switches, will cause the recalculation of DisplayMetrics to revert.
Px, dp, and sp are usually used units, but pt, in, and mm are almost never seen. Starting from these unusual units can just not affect other commonly used units.
Based on the above points, we have the following solutions.
Third, the programThe goal of this adaptation scheme is to write pages exactly as they were dimensioned on the design diagram. The pages that are written are identical on all sizes and resolutions of the screen, ie the relative size of the controls on all screens relative to the entire screen. It's all the same (it looks like just scaling the design to screen width).
core. Using the unpopular pt as a unit of length, according to the above idea, it is redefined as the relative unit relative to the screen size, which will not affect the use of common units such as dp.
draw. When writing xml, it is written against the size of the design draft, but the unit is changed to pt. If the width of the design diagram is 200, the length of a control on the design diagram is 3, it only needs to define a width of 200 when initializing, and when the length of the control is drawn as 3pt, the control shows the control on any size screen. The length is 3/200 of the screen width. If you need to dynamically convert to px in your code, use TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_PT, value, metrics).
Preview. Drawing a page in real-time preview is a very important part. Take the 1334x750 design as an example. To achieve the same preview function as in normal drawing, create a device with a length of 1334 pounds and a width of 750 pounds as a preview, converted to approximately 21.5 inches ((sqrt(1334^2+750 ^2))/72). Select this device when previewing.
Code processing. Modify DisplayMetrics when acTIvityonCreate, recommended to write in the base class or AcTIvityLifecycleCallbacks, reference github demo.
Point size = new Point(); activity.getWindowManager().getDefaultDisplay().getSize(size); context.getResources().getDisplayMetrics().xdpi = size.x / designWidth * 72f;
The page drawn in this way is almost exactly the same as the design, and it will only appear as a result of scaling the design on both large and small screens.
Before fitting (API19 400x800 on the left, API24 1440x2560 on the right):
After fitting (API19 400x800 on the left, API24 1440x2560 on the right):
Although the program is relatively simple, but it is organized into a library for convenience, the code and demo see github
Photo Studio Kit,Photography Lighting Kit,Photography Studio Kit,Photography Studio Lighting Kit
SHAOXING SHANGYU FEIXIANG PHOTOGRAPHIC CO.,LTD , https://www.flying-photography.com