## HTML5 vs 原生应用 > 全面追赶原生应用并不是Web技术的关键所在。我感觉我们应该聚焦在Web擅长的方面，并将它们做得更好。或者找出我们能够做好的方面，将它们做得超越原生应用。 ## 模拟原生应用 * 网络连通性和AppCache。离线存储对移动Web应用非常有意义，但是AppCache简直是个垃圾。新的Service Worker试图取代它。 * 安装到主屏幕。被支持的并不好。 * 设备API。第一支持不完善，标准总是落后于现实；第二有安全问题，需要授权，而像安卓的用户授权是行不通的。 > 当你安装一个安卓应用时，系统会让你授权该应用可以具备哪些权限。这个设计的失败不仅在于我们需要更精细的权限控制，而且还在于它出现的时机不对：当用户安装某个应用时，用户只想尽快的用上它，他们会同意任何事情。 ## 模拟Web Applink，直达应用的深层页面。（注：Android M和iOS 9都有类似的更新支持这项特性） ## 分享应用 作者的脑洞：Web应用由于其良好的兼容性，应该让它可以通过蓝牙、NFC等在不同设备之间共享。

呵呵，看了这本书，如果还没有开始，那么大概不会想成移动Web开发者。但是，如果不小心入了这个坑，那么就要做好准备。 ## 克服过时的惯性思维 * 浏览器探测。事实上无论是浏览器探测还是特性探测在移动浏览器上都可能表现不佳。 > 浏览器只会返回它支持某项特性，但不会告诉你支持程度有多差。 * Javascript脚本库。在编写小功能时不要依赖脚本库而是应该用原生JS实现。

本章的前三节在[InfoQ网站](http://www.infoq.com/cn/articles/touch-pointer-event)上有转载。 触摸事件为苹果发明，它将触摸和鼠标两种行为区分开，而微软的指针事件则将它们合并，此标准更具前瞻性，现已~~加入肯德基豪华套餐~~被W3C采纳为正式标准。 ## 触摸事件 1. touchstart 2. touchmove 3. touchend 4. touchcancel （不太被使用） 手势事件：两个或多个触摸事件同时发生。仅Safari和IE支持，不建议使用。 ## 实例 通过实例对比触摸、指针事件与鼠标键盘事件。 * 下拉菜单。对于用mouseover的下拉菜单，触摸几乎不可用。 * 拖拽。触摸和鼠标差不多，键盘难操作。 * 滚动层。鼠标难操作。 ## 指针事件 指针事件合并了触摸和鼠标操作，它的必要性在于有一些超极本、平板电脑（Surface系列）同时支持触摸和鼠标操作，并且需要在两者间进行无缝的切换。 * pointerdown * pointermove * pointerup * pointerover * pointerout ## 触摸事件的级联 移动浏览器同时支持触摸事件和鼠标事件，会导致一个触摸动作触发多个事件。 * 触摸（Tap）：touchstart/pointerdown、touchend/pointerup、mouseover、mousemove、mousedown、mouseup、click、:hover样式（需要注意的是为了兼容mouseover，抬起手指并不会触发mouseout，再次触摸才会） * 滑动（Swipe）：touchstart、touchmove、touchend、scroll * 缩放（Pinch）：touchstart、touchmove、touchend、scroll，可能还有resize * 双触（double-tap）：touchstart、两次touchend、scroll，可能还有resize * 按住（touchhold）：touchstart、touchend，有些浏览器还有contextmenu ## 剖析click 300毫秒问题，无解。（Chrome支持但苹果不可能支持） ## 使用指针事件 事实上因为兼容性问题，直到现在指针事件仍是不可用的，最好还是用苹果的触摸事件。

移动浏览器与桌面浏览器对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很糟糕，至少是早期的很糟糕。

讲述meta视口标签和媒体查询相关的内容。 示例代码： ~~~ <meta name="viewport" content="width=device-width, initial-scale=1"> @media screen and (max-width:480px) { // some style } ~~~ ## 像素（pixel） * 设备像素：设备屏幕的物理像素。 * CSS像素：为Web开发者创造的，在CSS和JS中使用的一个抽象层。 CSS像素和设备像素的比例取决于屏幕是否高DPI和用户缩放的比例。 ## 三个视口 桌面上视口宽度等于浏览器宽度，但在手机上有所不同。 * 布局视口。手机上为了容纳为桌面浏览器设计的网站，默认布局视口宽度远大于屏幕宽度，为了让用户看到网站全貌，它会缩小网站。 * 视觉视口。用户正在看到的网站的区域，与设备屏幕一样宽。 * 理想视口。当网站是为手机准备的时候使用。使用meta声明。早期iPhone理想视口为320*480px。 ## 缩放 桌面浏览器的缩放仅改变内容尺寸，不改变布局视口；移动端缩放则整体改变。 > 不要禁止缩放。 ~~~ <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 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

灾难的一章，Android设备商在定制内置浏览器的同时，Google在尝试将旧的Android WebKit浏览器替换为Chrome，直到Google IO 2015，这种尝试仍在进行当中。 三星自己定制了一个Chrome，连Chrome也没逃脱碎片化的魔爪（笑哭

四种浏览器类型：内置浏览器、可下载浏览器、代理浏览器以及WebView。 代理浏览器：与完备浏览器（full browser）相对，代表为opera mini、UC mini。 原理：当用户请求页面，它不会发送一个普通HTTP请求而是通过加密链接发送特殊请求到一个特殊的代理服务器。代理服务器来抓取用户希望访问的内容，渲染页面，然后压缩渲染的页面成为某种图片，类似于PDF，然后代理服务器将这个文件发到客户端。 * 好处：给用户节省流量。 * 弊端：页面内的javascript不能正常工作。 ## 渲染引擎 手机上四种渲染引擎：WebKit、Gecko（Firefox、UC mini、Sailfish OS内置浏览器）、Trident（IE，即将替换为Edge）、Blink（Chrome、Opera）。 > 手机上没有WebKit WebKit不包含用于请求资源或者真正把渲染的页面显示在手机屏幕上的模块。不包含于GPU通信并且保证硬件动画真正显示到屏幕上的模块，Javascript引擎也是可选的。 即使是用相同版本的WebKit，但在不同浏览器中的细节有可能不同，所以说手机上没有WebKit，你需要测试尽可能多的设备和浏览器。

> 从2008年开始，操作系统（软件层）的质量就变得比设备（硬件层）更重要了。 可惜这点国内的手机厂商几乎没一个理解的，都还在拼硬件这么low的层次上。

> 原文出处：http://idlelife.org/archives/969 《*The Mobile Web Handbook*》 作者是荷兰的Peter-Paul Koch 译者是360的前端团队 奇舞团 ## Overview 本书是对移动Web现状（2014年夏）的一个系统检阅，市场上有不少公司将赌注放在HTML5上，因此对于HTML5在移动Web上的应用多有炒作，但实际上如何呢？看完本书能让你有个清醒的认识。 移动浏览器虽然大都实现了桌面浏览器的功能，但实际上移动设备上的情况更加复杂，而且由于Android系统的碎片化直接导致浏览器的碎片化，它们对于一些和桌面不同情况的处理，以及一些最新特性的支持都是不尽相同的。 所以HTML5在移动Web上的兼容性目前是很差的，还有像触摸事件向指针事件标准化的过渡，估计最少需要5-10年才能达到一个比较理想的状态。 作序的除了奇舞团leader月影，还有winter，原来winter的真名叫程劭非。 配套网站： http://quirksmode.org/mobilewebhandbook 目录：http://book.douban.com/subject/26369130/ 以下为对书中的重点做的一个笔记。