移动开发入门概述

PPK的《移动Web手册》 是对移动Web现状（2014年夏）的一个系统检阅，市场上有不少公司将赌注放在HTML5上，因此对于HTML5在移动Web上的应用多有炒作，但实际上如何呢？看完本书能让你有个清醒的认识。

移动浏览器虽然大都实现了桌面浏览器的功能，但实际上移动设备上的情况更加复杂，而且由于Android系统的碎片化直接导致浏览器的碎片化，它们对于一些和桌面不同情况的处理，以及一些最新特性的支持都是不尽相同的。

所以HTML5在移动Web上的兼容性目前是很差的， 还有像触摸事件向指针事件标准化的过渡，估计最少需要5-10年才能达到一个比较理想的状态。

浏览器相关

浏览器的类型

内置浏览器
可下载浏览器
代理浏览器
webview

大多数内置浏览器都被紧密集成到底层的操作系统中，也就是说，无法单独升级浏览器。因此，为了得到新的Safary版本，你必须升级IOS。内置浏览器都有不同的内核比如：安卓是webkit、winphone是ie、ios是safari，大致上就是这样。

可下载浏览器，顾名思义用户可下载安装的浏览器，见的多的就是firefox、chrome了、360等。

代理浏览器是指服务端进行对页面的渲染，再把结果发送给客户端进行显示，比较少见。代理浏览器与完备浏览器（full browser）相对，代表为opera mini、UC mini。

WebView是留给原生应用的一个操作系统浏览接口。苹果不允许在IOS设备上安装其他渲染引擎。（其他平台是可以的）因此，其他浏览器要想在IOS上安装就必须用苹果的WebView。IOS上的Chrome就是这样的，同样的还有Opera Coast。大体上，WebView是独立的程序，用了内置浏览器很多底层的组件（比如渲染引擎），但是在其他方面可能会有所不同。如果希望你的页面能在WebView里跑起来的话，你最好在WebView上测试一下。

补充：

代理浏览器的原理：当用户请求页面，它不会发送一个普通HTTP请求而是通过加密链接发送特殊请求到一个特殊的代理服务器。代理服务器来抓取用户希望访问的内容，渲染页面，然后压缩渲染的页面成为某种图片，类似于PDF，然后代理服务器将这个文件发到客户端。

好处：给用户节省流量。

弊端：页面内的javascript不能正常工作。

随着现在wifi的普及等原因，代理浏览器用得很少。

手机上的WebKit

先列出不使用WebKit的浏览器：

1. IE Mobile(即将替换为edge)，使用Trident 2. Opera Mini使用Presto，但是最终会换成Blink 3. Chrome浏览器用Blink 4. Firefox Mobile和Firefox OS使用Gecko 5. UC Mini、Nokia Xpress还有Jolla的Sailfish OS上的内置浏览器也用的是Gecko

任何没在上面提到的浏览器都用WebKit。乍一看，这么多浏览器都用WebKit的事实对于Web开发者似乎是一个强大的支持，不幸的是，一个浏览器用Webkit并不意味着它跟其他任何基于Webkit的浏览器一样。实际上，**它们有很大的不同，依赖于操作系统、键盘、鼠标还有触屏交互。平台所有者必须提供所有这些功能。**手机上的Webkit名存实亡。

很多浏览器用着差不多一样的渲染引擎但是在细节上却大不相同。你最好在所有不同的基于WebKit的浏览器上测试你的网站。

测试Android浏览器

对于Android设备的浏览器，有三个必须测试的浏览器：

1. 安卓WebKit4，富含不同的设备和不同版本的安卓系统。一个专门的设备实验室需要大概6到8个这样的来自不同厂商的设备。一个小型实验室必须拥有2到3个：三星、HTC和一个其他厂商的设备 2. Google Chrome。如果你的设备上没有，下载一个。 3. 三星Chrome（三星字Galaxy S4发布以来，三星开始使用他自己开发的基于Chromium的一款浏览器作为内置浏览器，因此出现三星Chrome）。你讲需要购买一个2013年获以后发布的三星高端手机——类似Galaxy S4或更新的设备

视口相关

css像素和设备像素

设备像素：设备屏幕的物理像素。

CSS像素：为Web开发者创造的，在CSS和JS中使用的一个抽象层。CSS像素和设备像素的比例取决于屏幕是否高DPI和用户缩放的比例。

css像素是专门为我们Web开发者创造的一个抽象层。当在使用css和javascript的时候，你并不在意一个css像素跨越了多少个设备像素。你开心地将这个依赖于屏幕特性和用户缩放程度的复杂计算交给了浏览器。

用户放大得越大，一个css像素覆盖的设备像素越多。

布局视口

CSS布局会根据它来计算，并被它约束。在手机上，为了容纳为桌面浏览器设计的网站，**默认的布局视口宽度远大于屏幕的宽度。**为了让用户看到网站全貌，它会缩小网站。

<!-- width属性设置布局视口的宽度为特定的值 -->
<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=1, user-scalable=no">

但在另一篇文章里面，并不推荐设置width属性。

视觉视口

它是用户正在看到的网站的区域。这个视口与设备屏幕一样宽。

用户可以缩放来操作视觉视口，同时不会影响布局视口，布局视口仍保持在原来的宽度。视觉视口与设备屏幕一样宽，并且它的CSS像素的数量会随着用户缩放而改变。

理想视口

对于特定设备上的特定浏览器的布局视口的一个理想尺寸，在这个尺寸下，用户刚进入页面时不再需要缩放，拥有最理想的浏览和阅读的宽度。

缩放

桌面浏览器的缩放仅改变内容尺寸，不改变布局视口；移动端缩放则整体改变。

不要禁止缩放！ 禁止缩放是邪恶的，并且浏览器可以关闭禁止缩放功能。

禁止缩放的代码为：

<meta name="viewport" content="user-scalable=no">

分辨率

物理分辨率：设备每英寸内点数（DPI）

设备像素比：设备像素个数和理想视口的比（DPR）

dppx和dpi：每一个像素的点数。JS中的window.devicePixelRatio和媒体查询的device-pixel-ratio的单位。IE不支持，因此要使用dpi单位：

if(window.devicePixelRatio) {
    // DPR大于等于2时执行
}

@media all and((-webkit-min-device-pixel-ratio:2), (min-resolution:192dpi)) {
    // DPR大于等于2时生效
}

1dppx = 96dpi：一英寸对应CSS中96个像素。

meta视口标签：

meta视口标签存在的主要目的是让布局视口的尺寸和理想视口的尺寸匹配。

<meta name="viewport" content="name=value,name=value">

其中可用的name为：

width：device-width适用于大多数情况。
initial-scale：一般设为1，为了兼容应同时设置width=device-width。
minimum-scale
maximum-scale
user-scalable

媒体查询

媒体类型：目前只有print被正确实现。一般使用all。

Web开发者希望区分能力弱和能力强的浏览器，而弱浏览器为了避免探测开始伪装自己。

过去的浏览器最多可处理WAP和HTML的子集XHTML-MP，它们大都遵循标准并实现handheld，Web开发者为这些类型提供简单的样式。而新的现代移动浏览器出现后，它们支持全部样式、JS，因此宁愿不实现handheld而获得和桌面浏览器一样的待遇。

JavaScript

媒体查询与JavaScript属性相对应。

物理屏幕分辨率：screen.width/height（有兼容问题不建议使用）
布局视口：document.documentElement.clientWidth
视觉视口：window.innerWidth
理想视口：screen.width/height（有兼容问题不建议使用）
设备像素比：window.devicePixelRatio
屏幕方向：window.orientation

document.documentElement.clientWidth/Height返回的是布局视口的尺寸，被普遍支持。

window.innerWidth/Height返回视觉视口的尺寸。接近被普遍支持。

screen.width/height返回理想视口的尺寸。有很严重的浏览器兼容性问题，不建议使用。

CSS相关

移动浏览器与桌面浏览器对CSS支持的差异：

桌面用例在移动端不存在。如hover。
视口不统一。如单位vw和vh。
对独立可滚动层的需求在移动设备上更难实现。如background-attachment。
硬件限制。在老设备上transition和animation可能无法使用。

以下属性都不建议在移动Web上使用:

position:fixed

此属性标准没有支持缩放。

overflow:auto

多个可滚动层体验不好，并且移动上默认不显示滚动条会漏掉内容。

-webkit-overflow-scrolling:auto：平滑滚动。

background-attachment

三个可选值scroll、fixed、local。会创建过多的可滚动层，影响性能。

尺寸单位vw和vh

非常冷门的单位，本来也没什么人用，这里就不多说了。

:active和:hover

:hover在桌面浏览器用的过多，因此移动设备必须支持，但实际上在用户触摸元素时触发，引起事件级联。

:active相对支持的不好，可以和:focus同时使用，后者支持的较好。

transition和animation

实际上浏览器支持的很好，但这两个属性会用到GPU，而移动设备GPU很糟糕，至少是早期的很糟糕。

css过度和动画

只要你使用了过度和动画，就在你能找到的最老、最差的设备上进行测试。它们的问题不在浏览器，而在设备，浏览器对两者的支持都很好。但是为了达到非常平滑的效果，浏览器必须借助设备GPU的计算能力。在高端智能手机上不成问题，但对于早期和廉价的手机来说，它们可能根本没有响应的硬件和系统API。这就导致最终的动画效果很生硬。

触摸和指针事件

触摸事件为苹果发明，它将触摸和鼠标两种行为区分开，而微软的指针事件则将它们合并，此标准更具前瞻性，现已被W3C采纳为正式标准。

内容详见另一篇文章：

克服过时的惯性思维

浏览器探测。事实上无论是浏览器探测还是特性探测在移动浏览器上都可能表现不佳。

浏览器只会返回它支持某项特性，但不会告诉你支持程度有多差。

Javascript脚本库。**在编写小功能时不要依赖脚本库而是应该用原生JS实现。 **

移动Web的未来

HTML5 vs 原生应用

全面追赶原生应用并不是Web技术的关键所在。我感觉我们应该聚焦在Web擅长的方面，并将它们做得更好。或者找出我们能够做好的方面，将它们做得超越原生应用。

模拟原生应用

网络连通性和AppCache。离线存储对移动Web应用非常有意义，但是AppCache简直是个垃圾。新的Service Worker试图取代它。
安装到主屏幕。被支持的并不好。
设备API。第一支持不完善，标准总是落后于现实；第二有安全问题，需要授权，而像安卓的用户授权是行不通的。

当你安装一个安卓应用时，系统会让你授权该应用可以具备哪些权限。这个设计的失败不仅在于我们需要更精细的权限控制，而且还在于它出现的时机不对：当用户安装某个应用时，用户只想尽快的用上它，他们会同意任何事情。

模拟Web

Applink，直达应用的深层页面。（注：Android M和iOS 9都有类似的更新支持这项特性）

az22c 博客