IPhone multi-size screen adaptation-proportional numeric computing, iphone adaptation
As an iOS opener, after the release of iPhone 6 and iPhone 6 plus, screen adaptation problems will gradually occur.
Before discussing adaptation, let's take a look at the amplification mode provided by the system.
In the zoom-in mode, the screen size is still 320 in width. The screen size is enlarged to other screen width based on the device-interface aspect ratio. The screen size may be slightly blurred due to the magnification, and the status bar will be different from the normal time (obviously larger ).
What about the adaptation mode? The screen pixels of devices of different sizes are different. If you want to process an interface and require that the iPhone 6 plus and iPhone 5 S be the same design draft, it looks the same proportion. How can this problem be solved?
Both the traditional layout and AutoLayout cannot be used to avoid the interface numerical calculation. For example, if the same left margin is 10 PX under iPhone 5, however, when the ratio is converted to iPhone6plus, it is about 13px. Does it mean that the ratio is the same for different screens? Do we have to separate them and use conditions to determine and layout them separately?
When I started thinking this way, I refused. Because we are developers of aijia special effects, how can we not even play proportional computing?
Now, what is the design draft with an iPhone 5S screen size of 640*1136? Is the left margin 20px?
CGFloat leftPadding = 10*SCREEN_WIDTH/320.0;
LOOK! We already have a left margin that can adapt to the ratio of the same design draft under various screen sizes! Well, there are many other values. Come one by one...
CGFloat rightPadding = 15*SCREEN_WIDTH/320.0;CGFloat topPadding = 20*SCREEN_WIDTH/320.0;.....
Wait, it seems that there are a lot of repeated things:SCREEN_WIDTH/320.0
As a developer, how can we endure so many repeated computations. Special effects are required!
For convenience, I use C functions like CGRect for implementation, considering that the performance is not using inline. Create an empty UIView category
In the. h header file:
extern CGFloat CGFloatIn320(CGFloat value);
In the. m implementation file:
Static CGFloat ratio = 0; // This is to calculate the performance of not wasting too much computing ratio only once CGFloat CGFloatIn320 (CGFloat value) {if (ratio = 0) {ratio = ([UIScreen mainScreen]. bounds. size. width> [UIScreen mainScreen]. bounds. size. height? [UIScreen mainScreen]. bounds. size. height: [UIScreen mainScreen]. bounds. size. width)/320.0;} return value * ratio ;}
Now let's calculate our margin:
CGFloat leftPadding = CGFloatIn320(10);CGFloat rightPadding = CGFloatIn320(15);CGFloat topPadding = CGFloatIn320(20);.....
This looks really good. I believe many developers are also doing layout in a similar way. In general, this is a feasible solution that requires the same ratio of different sizes, but there are two more statements:In this mode, computation sometimes has a small deviation.
, Although not many, but sometimes it will also affect the effect, so when necessary, the use of equals computing, automatic layout is to improve the accuracy of the interface.
Of course, everyone can understand this simple article. Finally, I post an article about other people's families. I hope everyone can adapt to the article:
After the iPhone 6 appears, how does one design draft support multiple sizes?