"Learning Notes" mobile Web Manual (PPK masterpiece)

It is a long time not to write a blog, the recent summary of nearly half a year, all summed up to the blog Park Bar. Write a recent study note on the mobile side. After all, mobile development for a period of time, write a degree in the "Mobile Web Handbook", I felt a few deep points--

First, browser-related

1. Browser type-built-in browser, downloadable browser, proxy browser, and WebView. The proxy browser here refers to the service side of the page rendering, the results sent to the client for display, relatively rare.

2. Built-in browser upgrades- most built-in browsers are tightly integrated into the underlying operating system, which means that browsers cannot be upgraded separately. Therefore, in order to get the new Safary version, you must upgrade iOS.

3. Explanation webview--WebView is an operating system browsing interface that is left to native applications. Apple does not allow other rendering engines to be installed on iOS devices. (other platforms are available) so other browsers that want to install on iOS must use Apple's WebView. This is the case with Chrome on iOS, as well as opera Coast. In general, WebView is a standalone program that uses many of the underlying components of a built-in browser (such as a rendering engine), but may be different in other ways. If you want your page to run in WebView, you'd better test it on the webview.

4. the webkit--on the phone first lists browsers that do not use WebKit:

1 . IE Mobile uses Trident2. Opera Mini uses Presto, but will eventually change to blink3. Chrome browser with Blink4. Firefox mobile and Firefox OS use Gecko5. The built-in browser on UC Mini, Nokia Xpress, and Jolla's Sailfish OS is also gecko

Any browsers that are not mentioned above are used WebKit. At first glance, the fact that so many browsers use WebKit seems to be a powerful support for Web developers, unfortunately, a browser with WebKit doesn't mean it's like any other WebKit-based browser. In fact, they vary greatly, depending on the operating system, keyboard, mouse, and touch screen interaction. The platform owner must provide all of these features.

So, there is no webkit on the phone. Many browsers use almost the same rendering engine but differ greatly in detail. You'd better test your site on all the different WebKit-based browsers.

5. Test Android Browser- for Android device browser, there are three browsers that must be tested:

1. Android WEBKIT4, rich in different devices and different versions of the Android system. A specialized equipment laboratory requires about 6 to 8 such devices from different manufacturers. A small lab must have between 2 and 3: Samsung, HTC, and a device from another manufacturer 2. Google Chrome. If not on your device, download one. 3. Samsung Chrome (Samsung Chrome) has come into use as a built-in browser for a chromium-based browser that Samsung has developed since Samsung's Galaxy S4 was released. You need to buy a 2013-year-old Samsung high-end phone-similar to a Galaxy S4 or newer device

Second, the viewport-related

1. css pixels and device pixels-- How many device pixels a CSS pixel will have depends on the characteristics of the screen (whether it is high density) and the user's scaling. The larger the user zooms in, the more pixels a CSS pixel overwrites. When using CSS and JavaScript, you don't care how many device pixels a CSS pixel spans. You're happy about this. A complex calculation that relies on screen characteristics and user zoom is given to the browser. That's why CSS pixels are an abstraction layer created specifically for our web developers.

2. Layout viewport: The CSS layout is calculated based on it and constrained by it. On the phone, the default layout viewport width is much larger than the width of the screen in order to accommodate Web sites designed for desktop browsers.

<!---<name= "Viewport"  content = "Width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=1, User-scalable=no" >

3. Visual Viewport: It is the area of the website that the user is seeing. The user can zoom to manipulate the visual viewport without affecting the layout viewport, and the layout viewport remains in its original width. The visual viewport is as wide as the device screen, and its number of CSS pixels changes as the user zooms in.

4. Ideal viewport: An ideal size for a particular browser's layout viewport on a particular device, where users no longer need to zoom when they first enter the page, with the most ideal width for browsing and reading

5. Device pixel ratio: The ratio of the number of device pixels to the ideal viewport becomes the device pixel ratio (Devices Pixel Ratio), or DPR. In JS, you can use Window.devicepixelratio to get

6. Meta Tags:theprimary purpose of the meta-viewport label is to match the size of the layout viewport to the size of the ideal viewport.

7. Viewport Dimension measurement:Document.documentelement.clientwidth/height Returns the size of the layout viewport, which is generally supported. Window.innerwidth/height returns the dimensions of the visual viewport. Close to being universally supported. Screen.width/height returns the dimensions of the ideal viewport. There is a serious browser compatibility issue.

Third, performance-related

1. CSS over and animation-their problem is not the browser, and on the device, the browser support both are very good. However, in order to achieve a very smooth effect, the browser must rely on the computing power of the device's GPU. There is no problem with high-end smartphones, but for early and inexpensive handsets, they may not respond at all to hardware and system APIs. This results in a very stiff final animation. So, as long as you're using overkill and animations, test on the oldest and worst device you can find.

Finally, attach the cover picture of the book--

"Learning Notes" mobile Web Manual (PPK masterpiece)