background
Adaptation scheme based on the headlines before writing the article Android screen adaptation has never so simple, but later found that there are still a lot to the pit, the pit is recorded in the lot screen adaptation problem summary and solution, based on so many, I finally found a more perfect adaptation scheme, intended to write this article for more than a month ago, But because the company is busy with business has not been out of space, drag more just released now, let me share this method, first blow the advantages of it.
advantages
1. Non-invasive
Pt, which represents a point, is the physical size of the screen. Its size is 1/72 of an inch, so 72pt is equal to an inch. The unit used in my adaptation this time happens to be PT, so it won’t have any impact on the layout you used before. You can boldly join the adaptation scheme to develop new functions in the old project, and you can adopt the adaptation without hesitation in the new project. And after closing the closure, the pt effect is the same as DP.
2. High flexibility
If you want to do a View different resolution device, make its size proportion on adaptation dimension, it can be use pt units to it, if you don’t want such result, but want a bigger size of the device display more content, you can write dp, sp of what can be like once upon a time, Combine these two things and you have a lot of flexibility in the layout of the interface to achieve what you want.
3. Does not affect the size of system View and tripartite View
As toutiao’s solution directly changes the dp adaption of DisplayMetrics#density, it will cause the system View size to be inconsistent with the original, such as Dialog, Toast and size. Similarly, The size of the three-way View will also be inconsistent with the original effect, which is one of the reasons WHY I chose PT adaptation.
4. It won’t fail
This point is the most worth bragging about, because regardless of the headline adaptation or AndroidAutoSize, there will be DisplayMetrics#density is restored, need to reset back, the most obvious is the interface WebView, There is a solution for this, of course, but there are many other cases where the DisplayMetrics#density value will be restored and the adaptation will fail. My solution is to solve this pain point, so that the value of DisplayMetrics is not restored and the adaptation fails.
The effect
Said so much, first up and down effect picture pressure, each resolution of the picture is the width 1080pt adaptation, height 1920pt adaptation and close adaptation effect.
480 x 800 – mdpi(160dpi)
720 x 1280 – xhdpi(320dpi)
1080 x 1920 – xxhdpi(480dpi)
1440×2560 – 560dpi
It can be seen that the WebView in the effect diagram does not produce the problem of adaptation failure for the later View, which is the problem that the previous adaptation can not solve.
How do I create a preview?
Tools -> AVD Manager -> Create Virtual Device… , we take 1080 x 1920px as an example, the specific operation is as follows:
After creating the device, select the device in the preview screen to see the PT unit effect.
For example, 720 x 1280px, change the size of the picture to 720 and 1280, and calculate the screen size. If it is 360 x 640DP, Then change the size of the figure to 360 and 640, and calculate the screen size. You don’t need to care what the unit is, and you can write as much as the design drawing is marked. There is no need to convert. For example, if the width is 720 x 1280, pass in 720.
Principle and Usage
In fact, the principle is also based on the toutiao principle, but I am operating pt, so instead of changing the DisplayMetrics#density, I am changing the DisplayMetrics#xdpi. Since the adaptation does not fail, Therefore, we need to rewrite the getResources() function in the adaptive Activity, because getResources() is called every time the View changes its size, so we directly adapt here will not cause failure, the corresponding code in the renderer is as follows:
override fun getResources(a): Resources {
return AdaptScreenUtils.adaptWidth(super.getResources(), 1080)}override fun getResources(a): Resources {
return AdaptScreenUtils.adaptHeight(super.getResources(), 1920)}override fun getResources(a): Resources {
return AdaptScreenUtils.closeAdapt(super.getResources())
}
Copy the code
The source code, Demo, and API are as follows:
Java][adaptscreen.java] -> [Demo][adaptscreen.demo]
AdaptWidth width adaptHeight height closeAdapt (PT equals DP) pt2Px: pt to px px2Pt: px to PTCopy the code
Pt2Px and px2Pt are provided for views that need to be manipulated dynamically.
Just rely on the latest version of AndroidUtilCode:
implementation 'com. Blankj: utilcode: 1.22.3'
Copy the code
At the end of it
After looking at the principle, I don’t think it is very simple, but how many people can think of this solution? I also stand on the shoulders of giants to think of this level, I hope that the adaptation scheme can end our adaptation like the title of the article, this is the simplest and effective adaptation scheme I have found so far. If you like it, please recommend it to your Androider. If you have any problems with it, please sync it to the “Android Screen Adaptor” issue.
Finally, the AndroidUtilCode project has been converted to componentization. If you are interested, you can browse the source code. You will learn a lot of good things.