Mobile high-definition, multi-screen adaptation scheme

Background

1. Developing mobile H5 Pages
2. Face different resolution of the phone
3. Face different screen size of the phone

Visual manuscript

Before the front-end development, the visual mm will give us a psd file, called 视觉稿 .

For mobile development, in order to achieve the effect of high-definition pages, visual Draft specifications will often follow the following two points:

1. First of all, choose a phone 屏幕宽高 基准 (formerly iphone4 320×480 , now more Iphone6 375×667 ).
2. For retina screens (such as: dpr=2), in order to achieve high-definition results, the canvas size of the visual manuscript will be 基准 2倍 , that is, the number of pixels is the original 4倍 (for Iphone6: The original 375x667, will become 750x1334).

Problem:

1. For dpr=2 's phone, why the canvas size ×2 can solve HD problems?
2. For twice times the size of the visual manuscript, how to restore each chunk 真实宽高 (i.e. layout problem) in the specific CSS encoding?

Take a question and look down ...

Some concepts

Before you perform a specific analysis, you must first know the following key basic concepts (terminology).

Physical pixels (physical pixel)

A physical pixel is the smallest physical display unit on a display (phone screen), and each device pixel has its own color value and luminance value under the operating system's schedule.

Device independent pixels (density-independent pixel)

Device-independent pixels (also called density-independent pixels) can be thought of as a point in a computer coordinate system that represents a virtual pixel (such as a CSS pixel) that can be used by a program and then converted from a related system to a physical pixel.

So there's a certain amount of physical pixels and device-independent pixels 对应关系 , which is the next thing to say 设备像素比 .

Unit pixel ratio (device pixel ratio)

The device pixel ratio (abbreviated DPR) defines the correspondence between the physical pixels and the device's independent pixels, and its value can be obtained by the following formula:

// 在某一方向上，x方向或者y方向

In JavaScript, you can window.devicePixelRatio get to the current device by DPR.

In CSS, you can use -webkit-device-pixel-ratio , -webkit-min-device-pixel-ratio and -webkit-max-device-pixel-ratio do media queries, for different DPR devices, do some style adaptation (here only for the WebKit kernel browser and webview).

Combined with the above concepts, an example is illustrated below:

Take iphone6 for example:

1. The device is wide-height 375×667 and can be understood as a device-independent pixel (or CSS pixel).
2. DPR is 2, according to the above calculation formula, its physical pixels should be ×2 , for 750×1334 .

Show it with a picture, that's it (forgive me for stealing pictures):

As you can see, for such a CSS style:

width: 2px;height: 2px;

on different screens (normal screen vs retina screen), the size (physical size) of the CSS pixels is consistent, and the difference is that the number of physical pixels corresponding to the 1 CSS pixels is inconsistent.

On a normal screen, 1 css pixels correspond to 1 physical pixels ( 1:1 ).
Under the Retina screen, 1 css pixels correspond to 4 physical pixels ( 1:4 ).

Bit image voxel

A bit image element is the smallest data unit of a raster image (e.g. PNG, JPG, GIF, etc.). Each bit image contains some of its own display information (such as: Display position, color value, transparency, etc.).

When it comes to this, you have to say, what is the display of the retina film?

In theory, the 1-bit pixels correspond to 1 physical pixel images for a perfectly clear display.

There is no problem on the normal screen, but there is not enough bit image dot in the retina screen, which causes the picture to blur.

Use a picture to indicate:

For example, for the retina screen of dpr=2, 1 bit pixels correspond to 4 physical pixel, because the single bit image can not be further segmented, so only the nearest color, resulting in blurred images (note the above several color values).

Therefore, for the picture HD problem, the better solution is 两倍图片 (2x).

such as: 200x300 (CSS pixel) img tag, you need to provide 400x600 pictures.

As a result, the number of bit image points is the original 4 times, in the Retina screen, 位图像素点个数 you can follow 物理像素点个数 1 : 1 the form of proportions, the picture naturally clear (this also explains a question left before, why the canvas size of the visual manuscript to ×2 ?) )。

Here is another question, if the ordinary screen, also used 两倍图片 , what will happen?

Obviously, in the ordinary screen, the 200x300 (CSS pixel) img tag, the corresponding number of physical pixels is 200×300 A, and 两倍图片 the number of bits of the image is 200×300*4 , so there is a physical pixel point corresponding to the 4 bit pixels point, So its color can only pass a certain algorithm (the result is a total of only the original image of One-fourth, we call this process called downsampling ), the naked eye, although the image will not be blurred, but will feel the picture is missing some sharpness, or a bit of chromatic aberration (but still acceptable).

Use a picture to indicate:

For the above two issues, I did a demo (intranet access) Mad poke here.

In the demo, the 100x100 images are placed in the 100x100,50x50,25x25 img container and displayed under the Retina screen.

条形图, you can actually see the difference in the value of the boundary pixel points by magnifying glass:

• Figure 1, the nearest color, color value between the red and white, biased, the picture will appear blurred (can be understood as picture stretching).
• Figure 2, no near the color, the color value is either red, or white, the picture looks very clear.
• Figure 3, the nearest color, color value between the red and white, biased, the picture looks bad color, lack of sharpness (can be understood as image extrusion).

爱字图, you can see the text "Love" to distinguish between blurred picture or clear.

(PS: If it doesn't look obvious, you can use your mobile phone to scan the code page (intranet address) or click on the original view will be more intuitive point.

Several questions

Here to say, mobile H5 development, at different resolutions, different screen phones will encounter a few classic problems.

Retina, picture HD problem

The solution is already covered in this question: 两倍图片(2x) then the picture container shrinks 50% .

such as: Picture size, 400x600;

1.img Label

width: 200px;height: 300px;

2. Background image

width: 200px;height: 300px;background-image: url([email protected]2x.jpg);background-size: 200px 300px; // 或者: background-size: contain;

Such a disadvantage, it is obvious, under the ordinary screen:

1. Also downloaded 2x images, resulting in a waste of resources.
2. The picture loses some sharpness (or chromatic aberration) because of the downsampling.

So the best solution is: 不同的dpr下，加载不同的尺寸的图片 .

Whether it is through CSS media queries, or through JavaScript conditions can be judged.

So the question comes, so, isn't it just to prepare two sets of pictures? (1x and 2x)

I think, do good company, there will be one 图片服务器 , through the URL to get parameters, then you can control the picture quality, you can also cut the picture into different sizes.

So we just upload large image (2x), the rest of the small map to the image server processing, we only need to be responsible for stitching the URL.

For example, such an original image:

https://img.alicdn.com/tps/TB1AGMmIpXXXXafXpXXXXXXXXXX.jpg // 原图

You can do a picture clipping like this:

// 200×200https://img.alicdn.com/tps/TB1AGMmIpXXXXafXpXXXXXXXXXX.jpg_200x200.jpg// 100×100https://img.alicdn.com/tps/TB1AGMmIpXXXXafXpXXXXXXXXXX.jpg_100x100.jpg

(PS: Of course, cutting only to the original image of the cut, to ensure that the picture is clear ~)

Under Retina, border:1px problem

This is probably the designer's most sensitive, most concerned about the problem.

First of all, why is there retina, border:1px this said?

Do we normally write CSS, like this border: 1px; , under the retina screen, what's the problem?

First, take a look at the following figure:

The above two pictures are in iphone3gs(dpr=1) and iphone5(dpr=2) below the test effect, compared to the 1px border display, they are consistent, and no difference.

So what are the advantages of the retina display, and why do designers feel the 高清屏 line is down (right) 粗 ? Clearly and around the same ~

Or a picture to explain (forgive me for stealing the picture again):

, for a 1px wide line, their physical size on the screen (gray area) is indeed the same, the difference is actually the smallest physical display unit on the screen, that is, the physical pixels, so for a straight line, iphone5 it can display the minimum width is actually the red line in the graph circled out of the gray area, Using CSS to represent, theoretically speaking 0.5px .

So, the designer wants the retina border: 1px; , is actually 1 physical pixel width, for CSS, it can be considered border: 0.5px; , this is under the retina (dpr=2) can display the smallest unit.

However, not all mobile browsers can be identified border: 0.5px; , iOS7, Android and other systems, 0.5px will be treated as 0px, then how to achieve this 0.5px ?

The simplest way to do this is this ( 元素scale ):

.scale{position:relative;}    .scale:after{ content:position:absolute; bottom:0px; left:0px; right:0px; border-bottom:1px solid  #ddd; Span class= "Hljs-attribute" >-webkit-transform:scaley (.  5); -webkit-transform-origin:0 0;}   

We write border-bottom: 1px solid #ddd; as usual, and then transform: scaleY(.5) reduce by 0.5 times times to achieve 0.5px the effect, but so hack is not enough general (such as: rounded corners, etc.), writing is also troublesome.

Of course there are many other hack methods, the internet can be searched, but each has pros and cons, here is more recommended or 页面scale the solution is more general, almost meet all scenarios.

For Iphone5 (dpr=2), add the following meta tag, set viewport (scale 0.5):

<meta name="viewport" content="width=640,initial-scale=0.5,maximum-scale=0.5, minimum-scale=0.5,user-scalable=no">

In this way, all of the pages border: 1px will be scaled down by 0.5 to achieve border: 0.5px; the effect.

Some people worry that the page scale will affect performance, @妙净 students have done a performance test, see here (intranet address).

Take a look at the implementation of the comparison (the picture on the right is optimized):

(PS: The picture has been compressed, it may not seem obvious, you can use the phone to scan the code or click here (Intranet address) comparison to see)

However, page scale inevitably poses some problems:

1. Font size will be scaled
2. The page layout is scaled (e.g., the width of the div is higher)

These two questions are mentioned later ...

Multi-screen Adaptive layout problem

Mobile layout, in order to adapt to a variety of large-screen mobile phones, the best solution is to use relative units rem .

Based on the REM principle, all we have to do is 屏幕尺寸 dpr change the size of the root node HTML (the font-size benchmark) for different phones and dynamically.

Here we extract a formula (REM represents a Datum value)

rem = document.documentElement.clientWidth * dpr / 10

Description

1. Multiply DPR because the page is likely to 1px border be scaled (scale) 1/DPR times in order to implement the page (if not, dpr=1).
2. Divided by 10, is for rounding, convenient calculation (theoretically can be any value)

So just like the following, the HTML font-size may:

IPHONE3GS:320PX/10 = 32px

IPHONE4/5:320px * 2/10 = 64px

iphone6:375px * 2/10 = 75px

For dynamically changing the font-size of the root node HTML, we can do it via CSS or through JavaScript.

css方式, you can change the HTML font-size by using the device width for media queries:

html{font-size: 32px;}// iphone 6 @media (min-device-width : 375px) { html{font-size: 64px;}}// iphone6 plus @media (min-device-width : 414px) { html{font-size: 75px;}}

Disadvantage: The device width 范围区间 of the media query to dynamically change the REM benchmark value, in fact, is not accurate, such as: Width of 360px and 320px width of the phone, because the screen width within the same range (<375px), so will be treated equally (REM reference value same), In fact, their screen widths are not equal, and their layouts should be different. In the end, the conclusion is that such a practice is not accurate enough, but sufficient.

javascript方式, using the formula above, calculate the baseline value Rem, then write the style, presumably as follows (code reference from Kimi m-base module)

var DPR,REM, Scale;var docel = Document.documentelement;var Fontel = document.createelement (' style '); var metael = Document.queryselector (' meta[name= ' viewport "] ');DP r = Window.devicepixelratio | |1; rem = docel.clientwidth * Dpr/10;scale = 1/dpr;//set viewport, indent Put, achieve HD effect metael.setattribute (' content ', ' width= ' + DPR * docel.clientwidth + ', initial-scale= ' + scale + ', maximum-scale= ' + scale + ', minimum-scale= ' + scale + ', user-scalable=no ');//Set DATA-DPR property, reserved for CSS hack docel.setattribute (' DATA-DPR ', D PR);//dynamic Write style docEl.firstElementChild.appendChild (fontel); fontel.innerhtml = ' html{font-size: ' + rem and px conversion function window.rem2px = function (v) {v = parsefloat (v); return v * REM;}; Window.px2rem = function (v) {v = parsefloat (v); return v/REM;}; WINDOW.DPR = Dpr;window. rem = rem;         

This way, can accurately calculate the different screen should be the REM benchmark value, the disadvantage is to load such a section of JS code, but personally think this is the best solution for the present.

Because this solution solves three problems at the same time:

1. border:1px problems
2. Picture HD problem
3. Screen adaptation layout issues

When it comes to layout, it's natural to answer the original question: How do you restore the true width of your visual artwork in CSS encoding?

Prerequisites:

1. Got a high-definition visual for iphone6.750×1334
2. Use the above-mentioned HD scheme (JS code).

If there is a chunk in the PSD file: The width of the high 750x300px Div, then how to convert to REM units?

The formula is as follows:

rem = px / 基准值;

For a iphone6 visual manuscript, its benchmark value is 75 (previously mentioned);

So, after we've determined the visual manuscript (that is, we've determined the benchmark), we usually write a mixin with less, like this:

// 例如: .px2rem(height, 80);.px2rem(@name, @px){    @{name}: @px / 75 * 1rem;}

So, for the wide-750x300px Div, we write with less:

.px2rem(width, 750);.px2rem(height, 300);

Convert to HTML, that's it:

width: 10rem; // -> 750pxheight: 4rem; // -> 300px

Finally, because DPR is 2, the page scale is 0.5, so the real width on the phone screen should be 375×150 px, just good.

If the page does not have scale 0.5, our code would have to do this:

.px2rem(width, 375);.px2rem(height, 150);

Such a wide height, we often get the way:

1. After the visual manuscript is converted to 750×1334 375×667 the size, then go to the size of this chunk (feel good silly).
2. 750×1334after the chunk width is 750x300px, then mental arithmetic divided by 2 (feeling good trouble).

At the end of the paper, a 没有布局适配() 用rem布局适配() comparison chart is given:

(The phones above are: IPHONE3GS, iphone5, Iphone6)

It is obvious that the width and height of the various blocks of REM adaptation will vary with the width of the mobile phone screen, the most obvious can see a list of that part, the last picture of the visual draft requirements only a little bit, REM layout on any screen is displayed very well.

Font size Issues

Since the above scheme will make the page scaling (scale), for the width of the page block, we can rely on high-definition visual manuscript, because the visual manuscript is X2, we can directly amount to, then how to handle the font?

For font scaling problems, the designer's original requirement is this: 任何手机屏幕上字体大小都要统一 so we do the following for different resolutions (DPR different):

font-size: 16px;[data-dpr="2"] input {  font-size: 32px;}

(Note that the font can not be used with REM, the error is too large and does not fit any screen under the same font size)

For convenience, we will also write a mixin with less:

. px2px (@name, @px) {@{name}: Round (@px/2) *1px; [data-dpr= "2" & {@{name}: @px * 1PX; }//for mx3 [Data-dpr= "2.5"] & {@{name}: Round (@px * 2.5/2) * 1px;}// for millet note [Data-dpr= "2.75"] & {@{name}: Round (@px * 2.75/2) * 1PX;} [Data-dpr= "3"] & {@{name}: Round (@px/2 * 3) * 1px}//for Samsung Note4 [Data-dpr=" 4 "] & {@{name}: @px * 2PX;}}       

(Note: The HTML DATA-DPR attribute is mentioned in the previous JS scheme, it is useful here.)

According to experience and testing, or will appear these odd DPR, here do a unified compatible ~

When used, it's like this:

.px2px(font-size, 32);

Of course, for other CSS properties, if you also want to be consistent under different DPR, you can also do this, such as:

.px2px(padding, 20);.px2px(right, 8);

At last

The above on the mobile side of the H5 HD and multi-screen adaptation of some of the program summary, and knowledge explained, the wrong place, please also point out, Sina Weibo.

Reference articles

1. http://www.smashingmagazine.com/2012/08/20/towards-retina-web/
2. Http://www.paintcodeapp.com/news/iphone-6-screens-demystified
3. http://www.inserthtml.com/2012/09/designing-retina-devices/
4. http://iconmoon.com/blog2/iphone-6-plus-screen-size/
5. Http://dieulot.net/css-retina-hairline

Mobile high-definition, multi-screen adaptation scheme