This paper considers different audiences and takes a conclusion first approach (e.g., “Part I: Overview”), focusing on technical principles and details before moving on to “Part II” and “Part III”.
Part ONE: Overview
background
Design sister: When users jump between the App’s native page and H5 page, can the overall size of elements on both sides be consistent? For example, the original and H5 designs each have a 10px square element, and the two elements have the same perceived size (on any model, the size of the two elements either changes in equal proportion or does not change at all).
I sipped my tea and said, “That won’t do.”
Design sister:… ?
Me: Let me see.
— The design student’s idea is that there are native pages and H5 pages in the App. He does not want users to browse in the two pages and feel the overall size difference. This demand is understandable, as to whether it can be done, we need to investigate.
Research conclusion
The current situation of the page in the App is that “the original page is based on PT (iOS) and DP (Android) as the unit, while the front-end H5 is based on REM”. So in order to achieve unity on both sides:
- 1, native and H5 alignment: it is said that native costs a lot, and the author does not understand native, so this article will not elaborate.
- 2. Front H5 aligned with native
- (1) USE H5 instead
px: The H5 design draft is the same as the original design draft, marking the adaptation rules under different screens, and the front-end development, testing and product regression should also pay attention to the acceptance of different mobile phone screens (not recommended, H5 development is mentally heavy, and does not conform to the front-end development habits, prone to failure, detailed below). - (2) H5 is still used
remAs a unit: Individual pages require element and native alignment, with a fixed width in the middle and white space on the left and right sides. (Please confirm whether the design is acceptable to the students, Case By Case)
- (1) USE H5 instead
If you think “the industry front end is REM, so you don’t need to think about unification”, congratulations, the end of the series.
If you still want to make “H5 aligned with native” pinch? So you can move on.
Part 2: Detail “H5 with native alignment?”
Noun parsing
For clarity, the nouns and abbreviations used here will be used directly below.
1. Unit of length
- Cm: 1 cm = 0.01 m
- Mm: 1 mm = 0.1 cm
- Inch: 1 inch = 2.54 cm = 25.4 mm
2. Horizontal size of mobile phone
In this paper, when measuring the size of elements, inch will be changed into cm or mm, so that domestic users can better perceive.
The phone’s official size is the number of diagonal inches on the screen. For example, the iPhone12 is 6.1 inch:
Its horizontal and vertical pixel resolution is 1170 X 2532 (point resolution is 390 X 844), and each pixel (point) is considered to be completely square, so the horizontal size XXX of the phone meets:
The horizontal dimension XXX of iPhone12 is 2.558 inch, equivalent to 6.4992cm.
Note in particular that phones with a larger official size may not necessarily have a larger horizontal size due to inconsistent aspect ratio of their screens (see table below, mi 6X has a larger official size but a smaller horizontal size) :
| models | The official size | Transverse dimensions |
|---|---|---|
| Oppo R9s/R11 | 5.5 inch | 6.84895 cm |
| Millet 6 x | 5.99 inch | 6.804176 cm |
3. User-perceived size of elements
The page ultimately serves the user, so the actual size of the element is not important, but the perceived size of the element is important. Because the dimensions of page elements generally vary proportionally from length to width, this article measures only horizontal dimensions (the same goes for vertical dimensions).
The user-perceived size of an element is the same as the physical size (measured with a ruler) that the element occupies when rendered on the screen. In detail:
- On the same phone, different elements: user-perceived dimensions, determined by their rendered physical dimensions.
- The same page element, on different phones: the perceived size of the user is also determined by the physical size of the rendered element (which has little to do with the width of the screen on different phones).
If a mobile phone screen has XXX mm horizontally, the screen is divided into TTT units, and an element occupies NNN units, the physical width of the element is: (X/t ∗n(X/t) * N (X/t)∗n mm.
4. Point and point resolution
The phone’s official screen resolution (in pixels) and power ratio (usually 2 or 3; older phones with a power ratio of 1 are rarely found on the market) are given.
The point resolution of mobile phone = screen rendering resolution/multiplier, as shown in the following table:
| models | Official screen size | Render resolution | ratio | Point resolution (X) | Point resolution (Y) |
|---|---|---|---|---|---|
| iPhone 6/6s/7/8 | 4.7 | 750 x 1334 | 2 | 375 | 667 |
| iPhone 12/13 | 6.1 | 1170 x 2532 | 3 | 390 | 844 |
| iPhone (12/13) Pro Max | 6.7 | 1284 x 2778 | 3 | 428 | 926 |
| Oppo R9s/R11 | 5.5 | 1080 x 1920 | 3 | 360 | 640 |
| Millet 6 x | 5.99 | 1080 x 2160 | 3 | 360 | 720 |
In the case of iPhone12, the point resolution is 390 X 844, which means the screen is divided horizontally into 390 units, or 390 points, and vertically into 844 units, or 844 points.
In native development, iOS calls this “dot” PT, and Android calls this “dot” DP.
In the CSS development of H5, a 390px Banner can also fill the width of iPhone12, so the size of a “dot” here is also the same as the size of 1 px in the front-end development.
Note that the px here is the style unit for front-end CSS development, and the number of pixels in the width of a mobile page in front-end development = the number of horizontal (x-direction) points in its point resolution, which is different from the px in screen resolution. The relationship is “the former times the device multiplier is the latter”). On this issue, native and H5 students tend to communicate differently due to their different knowledge backgrounds.
To sum up:
- “Dot resolution” represents the horizontal and vertical orientation of the screen, divided into how many individual pixels (also known as “dots”).
- Each point represents a PT or DP in native development and a PX in H5 CSS development.
H5 aligned with native?
1px = 1pt = 1dp H5 should be aligned with pt or DP instead of px.
However, for mobile H5 development, rem is generally used to adapt to different screen widths:
The front end only needs to be developed on the basis of 375px. For a wide/narrow mobile phone screen, the base size of the root node can be scaled up/down to achieve the whole rendered page. Font-size: calc(100vw / 3.75)} On a phone with an NPX screen width, the root font size is (n/3.75)px(n/3.75)px
If you want to use PX as a unit, there is a certain mental burden:
After the front end is developed on the basis of 375px, it is necessary to look at different screens (iPhone has 320, 390, 414, 428px width, etc.) to see whether there will be element dislocation (for example, some elements fall to the next line or run to the top line). If it is serious, “blocked by misplaced elements” may lead to some models. The user cannot click the fault.
There are really two ways to align H5 with native:
(1) Use PX as the unit at the front end: the business design draft should consider the adaptive rules under different screens such as 320, 375 and 400+, and mark them if necessary. In addition, different models should also be considered for testing, product acceptance and design acceptance.
(2) The front end still uses REM as the unit: most pages are not unified with the original, individual design does have strong requirements of the page, it is developed under the smaller screen, in the larger screen “adaptive”, such as “fixed px width in the middle area, left and right sides white”. In this implementation, the element size is similar to that of the original (e.g. font size, element size), but the white space is still different (the original page white space is on the element spacing, H5 is on the left and right sides of the page). The diagram below:
Part three: Discrimination of domain concepts
The first and second parts have solved the problem of “keeping the size of H5 consistent with the original element”. However, when I researched this issue, I found that the field is plagued with “inaccurate intuitions” and “the Internet is full of misleading claims” that make you doubt your life every minute (don’t ask me how I know 😭), so I added this section to explain.
Noun Analysis (continued)
- Q: Why aren’t these nouns in part 2, “Noun analysis”?
- A: Because this part of the ranking and alignment problem “really” has nothing to do, put together will aggravate the misunderstanding.
1. Resolution (point resolution, render resolution, physical resolution)
(1) Point resolution: “point” is an abstract unit, which refers to the number of units in the horizontal and vertical coordinate systems.
Rendered Pixels: Points on the page, Rendered by a multiplier (usually 1/2/3). The higher the magnification, the more pixels will be rendered.
Physical Pixels: The actual number of Pixels on the screen of the device may be less than the number of Pixels rendered on the page, which should be divided by a factor to match. For example, the iPhone 6+/6s+/7+/8+ factor is 1.15, while the iPhone 12mini/13mini factor is 1.041.
2. Density
Density, set by the handset manufacturer, is the scaling factor that must be used to convert DP units to pixels based on the current pixel density. On a medium density screen (MDPI), density equals 1.0 (i.e. 160dpi); On high density screens (HDPI), it equals 1.5; On ultra High density screens (XHDPI), it equals 2.0; On ultra High Density screens (XXHDPI), equal to 3.0. This number is a coefficient multiplied by dp units to get the actual number of pixels on the current screen. See the Android developer documentation for density.
The current market of mobile phones are generally 2 and 3, see the screen size.
3. Screen density (PPI)
PPI (Pixel Per Inch) is the number of pixels Per Inch in the diagonal direction of a screen. In the following formula, the numerator and denominator are the pixels and inches of the screen’s diagonal dimension, where X and Y are the physical resolution (PX).
PPI is designed so that large physical pixels can be displayed on the real screen. Take the iPhone 6S + as an example:
| models | Official screen size | Render resolution | Physical resolution | Screen density (PPI) |
|---|---|---|---|---|
| iPhone 6+/6s+/7+/8+ | 5.5 | 1242 x 2208 | 1080 x 1920 | 401 |
Note in particular: in measuring “What visual size do N elements (pt/dp/px) occupy on the screen?” Do not use PPI. Because the former requires point resolution and transverse size, the latter uses physical resolution and diagonal size. So don’t be fooled by PPI just because it says “pixels per inch.”
Tip: Dot per inch (DPI). 1 DPI indicates that there is one dot per inch on the printing device. For screens, DPI is PPI, so PPI is used uniformly in this paper.
4. Pixel (unit: px)
A Pixel, “Pixel,” is the smallest point in the picture.
Before 2010, 1px was the physical unit that could be measured, and one inch could hold 163px (average screen PPI was 163). But since the introduction of the Retina display on the iPhone, one inch can fit 326px (retina display PPI is 326, a multiplier of 2).
At this point, the 4px X 2px icon given by the designer occupies different visual sizes under different PPI screens.
So for different screens, designers need to cut images at different image resolutions, such as 2x and 3X. (Generally, mobile developers need 3x images because 2x images are not clear on 3x devices.)
5. Pt (Apple custom unit)
Pt (points) stands for individual pixels. Apple introduced PT units to solve the problem of visual size under different PPI devices.
On a 163 ppi screen, 1pt = 1px = 1/163 inch ~ =0.16 mm.
On a 326 ppi screen, 1pt = 2px. The development system provides the unit, the above icon display problem can be perfectly solved:
Note that pt in print is different from PT in iOS. 1pt in print = 1/72 inch.
6. Dp (Independent unit created by Android for design)
Dp (Density independent Pixel), similar to Apple, Android created DP as density independent pixel.
7, rem
Rem (font size of the root element), a unit of font size relative to the root element. If the front-end developer has set the root font size to 100px, then 0.12rem is 12px on a 375px width screen and 12*428/375 =13.696px on a 428px width screen. That is, REM is proportional to the number of logical pixels on the screen.
The effect is as follows:
myth
❌ 1px in native development is the same as 1px in front-end H5 CSS
| models | Official screen size | Render resolution | Physical resolution | ratio | Some resolution |
|---|---|---|---|---|---|
| iPhone 6+/6s+/7+/8+ | 5.5 | 1242 x 2208 | 1080 x 1920 | 3 | 414 x 736 |
Rendered Pixels the px in native development represents the Rendered Pixels px.
The PX in the CSS of the front-end H5 page is the PX in Points.
A 10px design element on the 375px design draft:
If you use PX in native development, you need to multiply it by 3 to get 30px.
In front-end H5 development, CSS only needs to be 10px, regardless of ratio /PPI etc.
In this way, the elements developed on both sides are the same size on different models. In other words:
1px in front-end H5 CSS = 1px * multiplier in native development
❌ 1dp = (DPI/160) px, that is, dp/px varies with the DPI of the screen. Right?
Note: in the previous 1dp = 1px, px is the H5 CSS development PX, but here is the actual screen rendering pixels, in fact = CSS PX * device multiplier.
Q: 1dp = (DPI/160) px. By 320dpi, 1DP is equal to two pixels.
A: That’s not accurate. Dp/px = multiplier, and DPI / 160 is A lot of times A decimal that can’t be divided.
Take Oppo R9s for example, the official DPI (PPI) is 401, but its print density (screen dot density per inch) is 480, dp/px = 480/160 = 3 (3! = = 401/160).
❌ 1pt = 1/163 inch?
Q: 1pt = 1/163 inch, so pt is a measurable physical unit?
A: Pt is abstract and cannot be measured in physical units. It is necessary to calculate how much size 1pt lateral represents on different models. Combining with the above, we can know the calculation method.
(1) Calculate the horizontal dimension XXX (inch) of the mobile phone. XXX meet:
(2) Calculate the size TTT (inch) of 1 point (i.e. 1pt), TTT meets the following requirements:
The calculation results of some models are as follows:
❌ type px, large phone screen will not enlarge, but REM will enlarge?
Q: Comparing iPhone12 and iPhone (12/13) Pro Max, it is found that the native page has 17 pt/ DP text and the rendered size is the same. It can be inferred that H5 font size, written in PX mode, will not be enlarged on larger screens, while REM will be enlarged.
A: Whether dot (PT/DP/PX) and REM will enlarge on different screen widths depends not on direct cognition, but on careful calculation. According to the previous question (” 1pt = 1/163 inch? ), the calculation method of the size of each point.
Rem writing 1px elements will actually be scaled up in proportion to the width of the screen by the number of points across the screen / 375. The calculation formula is as follows:
The calculation results of some models are as follows:
Look at the last two columns to see the difference between using PX and REM for the 375px design:
- In REM implementation, the px number will be enlarged with the horizontal points /375 equal ratio of the screen, but the actual size is unequal. .
- Px is calculated according to multiple parameters. If the screen is wider, it may not be enlarged (iPhone 12 vs iPhone 12 Pro Max). If the official size is larger, the actual effect may be reduced (Mi 6X vs HUAWEI P30).
❌ type px, the higher the device resolution on the phone, the smaller the word?
Q: Using PX, the higher the device resolution, the smaller the text on the phone
A: The device resolution here should be Physical Pixels. Referring to the previous question, we know the calculation method of the horizontal size of each point, plus the resolution, we can see:
“Implement with PX” should be considered, whether H5 uses PX or native px.
H5 is implemented with PX. You can see the “physical resolution” and “Each point (1pt/ DP/PX) horizontal size (inch)” columns in the above table to see the size of the point. IPhone as a whole increases with the physical resolution. Oppo R9s, R11 Mi 6X and HUAWEI P30 have the same horizontal physical resolution, but different point sizes.
To achieve the size of 1px using PX natively, you can use the following formula:
Use px to achieve 1px size = H5 Use PX to achieve 1px size/ratio
On the whole, the size of the original 1px May be smaller on a mobile phone with high magnification. For example, the OnePlus 7 Pro has a higher physical resolution than HUAWEI P30, but its magnification is 4, resulting in a smaller size of the original 1px.
In the native page of ❌ competing App, the bigger the phone is, the bigger the word is, so they must have made a special technical solution of equal proportion enlargement?
Q: In the native page of the rival App, we compared the two phones and found that the larger phone has bigger characters, so did they make a special technical solution of equal ratio enlargement?
A: Referring to the previous question, it can be seen that the default unit is used for native devices (PT for iOS, DP for Android), and the size of the default unit on larger phones. There are exceptions, such as the Mi 6X, which is officially larger than the Oppo R9s/R11, but has a smaller lateral size and a smaller default unit size. Therefore, intuition is not necessarily true. It is more reasonable to use the calculation formula in this paper.
❌ In some units (such as PX), the font display size is affected by the system size?
Q: As the system size increases, some native/H5 page fonts in App will be affected. What is the rule?
A: Currently tested on several Android+iOS phones, the use of PX and REM in H5 is not affected by the system font (page development, all text will set the size, if omitted, will inherit the root node size).
Dp /pt/ PX for native development is also not affected, only a few places are missing Settings, not specified size will be affected by the system size.