一、部署Shadow：

相比Weinre，Shadow的部署可以用简单、轻松来形容，3步搞定：

1. 访问Adobe Shadow官方下载页，下载并安装PC端程序：Shadow（支持Win、Mac，但不支持win xp）
2. 下载安装移动端应用程序：Shadow Mobile Device Client（支持iOS、Android平台），在下载页可以找到链相关接
3. 安装Chrome Adobe Shadow插件

二、启动 & 使用：

• Shadow的启动也非常简单，依次运行PC端、移动端的Shadow程序以及Chrome浏览器；
• 移动端的Shadow会扫描可被链接的PC端，并生成一段验证码，将验证码填入Chrome的Shadow插件中就完成了Shadow的启动工作；
• 连接成功后我们在Chrome中浏览的网页就会同时显示在移动设备中，通过点击”<>“就可以打开Web Inspector进行页面代码调试了。

三、Shadow的不足：

1.Web Inspector调试工具有明显的延迟，因为Shadow会连接Adobe的服务器，所以在网络环境不好的情况下Shadow可用性不尽人意。

2.页面调试的局限性，通过Shadow调试移动设备上页面时，只能在其本身的应用中展现页面，而Weinre没有这个限制，通过添加调试的js可以在任何浏览器中展现并调试。

小结

简单介绍了下Shadow，它的优势就是简单方便，无论是在跨平台的部署上还是在多设备的预览上都要比Weinre更容易，缺点也很明显就是没有Weinre灵活，并且受到网络的限制。在日常工作中我基本不使用Shadow的Web Inspector进行调试，因为太卡，而更多的是利用Shadow的易部署性在各种移动终端上预览页面的效果，特别是在需要支持多平台的项目中能节省不少调试时间。

一、用CSS替代图片

这一点在任何时候都适用；只是在当前我们可以更多的使用样式表来制作出设计效果，CSS3的圆角、渐变、模盒阴影、字体阴影能帮助我们处理绝大多数视觉效果，并且在各种分辨率下都有良好的表现。

二、为高分辨率设备提供高清图片

如果必须使用图片，通常是准备2套图片，一套原始尺寸( 为普通设备准备 )，一套两倍尺寸( 为高分辨设备准备 )，再根据设备的分辨率调用不同的图片，调用的方式有2种：

1.使用CSS媒体查询( CSS media queries )，适用于根据不同分辨率来加载不同的背景图片
内联样式：
@media only screen and (-webkit-min-device-pixel-ratio: 2), only screen and (min-device-pixel-ratio: 2){
/* 2倍分辨率 执行样式*/
}

外链样式：
<link href="retina.css" rel="stylesheet" type="text/css" media="only screen and (-webkit-min-device-pixel-ratio: 2), only screen and (min-device-pixel-ratio: 2)"/>


2.使用Javascript替换图片地址，适用于<img>标签加载的外链图片
首先使用 window.devicePixelRatio 来判断是否为高分辨率，然后替换图片的地址。

想了解此方法的细节，可以参考下这篇分析apple.com方案的文章：
http://blog.cloudfour.com/how-apple-com-will-serve-retina-images-to-new-ipads/
下面是文中提到的 image_replacer.js 源码：
https://gist.github.com/2029936

三、 Icon优化

独特的Icon是大多数网站必备的设计元素，常规的处理方式是使用 sprite 技术，配合上面介绍的 CSS media queries 方法达到最优的显示效果，除此之外前端工程师也在探索一些新的优化方式：

1.Icon Fonts
将图标制作成特殊的字体，然后使用CSS3的自定义字体(@font-face)调用

优点：

• 文件体积小，一般20-50kb；
• 图标可以通过CSS更改尺寸和颜色，添加阴影，hover颜色等。

缺点：

• 制作成本较高，你需要矢量图形处理软件和专业的字体制作软件；
• 不易维护，不同浏览器支持的字体格式不一样，需要制作多份。

一些现成的Icon Fonts资源，基本可满足常规的设计需求：

• MODERN PICTOGRAMS
  
• Font-Awesome
  
• Social Media Icons Pack
  
• PulsarJS @FontFace
• ClickBits Web Icon System( 需付费 )

如果你对Icon Fonts的制作方法感兴趣可以参考这篇文章《CSS3 icon font完全指南》：
http://www.qianduan.net/css3-icon-font-guide.html

2.CSS Icon
与Icon Fonts思路类似，不同的是使用CSS来制作各种图标

优点：

• 文件体积小，尺寸与Icon Fonts相当
• 同样可以随意修改尺寸和颜色，添加阴影等。
• 修改方便，调用灵活

缺点：

• 受限于浏览器渲染能力，在不同浏览器中表现不一

资源：

• Pure CSS GUI icons
  

关于CSS Icon的制作会在以后做介绍( 先挖个坑=。= )

3.SVG Icon
SVG是一种可伸缩矢量图形，调用方式和jpg、png等格式图片一样，通过CSS即可加载：
background-image: url('sprite.svg');
优点：

• 文件体积小，因为SVG是XML格式定义图形，所以可压缩性更高
• 在缩放时图形质量不会有所损失
• 可以用来动态生成图形

缺点：

• 同样受限于浏览器，支持SVG的浏览器有：Internet Explorer 9+、Firefox 4+、Chrome 4+、Safari 4+、Opera 9.5+

四、Canvas图片处理

这个方法有点偏门，来自嗷嗷的一篇文章：Retina 显示屏下 @2x 图片的模拟

优点

• 大部分图片效果比原来好，不用做@2x 的图片
• 多终端统一维护，脚本渐进增强
• 文件小省带宽，3G 时还是有一定的优势 用EDGE的就更不用说了。

缺点

• 效果真心没 @2x的好，当然如果有更好的算法也难说
• canvas 读图片数据存在跨域问题
• 锐化目前的实现，基本就是读点的操作，大图片手机估计吃不消

写在最后

达到高分辨率下最佳的视觉效果固然不错，但加载速度也是用户体验重要指标之一。所以有时候我们也要在优质与高速之间找一个平衡点，这里可以通过 navigator.connection 来判断用户的网络环境，如果是EDGE那还是斟酌下是否要给用户提供高清图片。

以Windows系统为例：
1.下载Weinre的Java版本 weinre-jar-1.6.1.zip 并解压；
2.运行cmd，在weinre文件夹所在路径，运行代码：
java -jar weinre.jar --httpPort 8081 --boundHost -all-
成功后会出现相应信息(不要关闭cmd)：

3.使用webkit内核浏览器(chrome、safari)访问 http://localhost:8081/，不出意外的话可以看到weinre的基本信息。

二、添加Debug Target
为了让需要调试的页面被weinre检测到，需要添加Debug Target，有两种方法：
1.Target Script
该方法需要在调试的页面中增加一个js：
http://localhost:8081/target/target-script-min.js#anonymous
添加后在移动设备中访问该页面即可，如果调试的页面比较少可以使用这个方法，如果多的话推荐第二种方法

2.Target Bookmarklet
该方法是将一段js保存到移动设备的书签中，可以在 http://localhost:8081/ 找到这段js：
javascript:(function(e){e.setAttribute("src","http://localhost:8081/target/target-script-min.js#anonymous");document.getElementsByTagName("body")[0].appendChild(e);})(document.createElement("script"));void(0);
我将这段js保存到名为Debug书签中，然后使用移动设备访问我想要调试的页面，比如说 http://iinterest.net，最后点击Debug书签就OK了。

三、真机调试
回到http://localhost:8081页面，点击“debug client user interface:”链接进入weinre的Debug界面，如果成功添加了Debug Target，这里可以看到它。

接下来我们就可用自己熟悉的方式调试页面了，并且调试结果会实时显示在移动设备上

MAC系统更为简单，不用命令行，直接运行app即可启动weinre，接下来的步骤和windows一样。

参考文章：
https://www.ibm.com/developerworks/mydeveloperworks/blogs/94e7fded-7162-445e-8ceb-97a2140866a9/entry/debugging_mobile_javascript_with_weinre?lang=zh
http://envyandroid.com/archives/483/easily-debug-mobile-websites-with-weinre

实现起来也非常简单，为input添加名为 x-webkit-speech 的属性就行了。

<input type="text" x-webkit-speech />
相关的属性设置：
lang
设置语言种类：
<input type="text" x-webkit-speech lang="zh-CN" />
onwebkitspeechchange
语音输入事件，当发声语音改变时触发：
<input type="text" x-webkit-speech onwebkitspeechchange="foo()" />

x-webkit-grammar
语音输入语法，”builtin:search”值使得语音输入的内容尽量靠近搜索内容，去除多余的字符，例如「的」
<input type="text" x-webkit-speech x-webkit-grammar="builtin:search" />
还有个值：”builtin:translate”看到taobao在用，但目前还不清楚是什么意义，有时间再仔细看看W3C的文档。

测试了下效果，语音识别率还不错，但中英夹杂的时候就很悲剧了，而且该服务需要走google的服务器所以有时响应速度很慢，另外在mac中遇到提示“麦克风无法使用”的情况，猜测可能存在一些硬件兼容性问题。总的来说是趣味性大于实用性；比较期待能在手机浏览器上实现这个功能，可以做一些比较有趣的应用。

相关资料：
http://www.w3.org/TR/capture-api/
http://www.w3.org/TR/xhtml+voice/
http://www.w3.org/2005/Incubator/htmlspeech/2010/10/google-api-draft.html

一、简介

浏览器可以被认为是使用最广泛的软件，本文将介绍浏览器的工作原理，我们将看到，从你在地址栏输入google.com到你看到google主页过程中都发生了什么。

1.将讨论的浏览器
今天，有五种主流浏览器——IE、Firefox、Safari、Chrome及Opera。
本文将基于一些开源浏览器的例子——Firefox、 Chrome及Safari，Safari是部分开源的。
根据W3C（World Wide Web Consortium 万维网联盟）的浏览器统计数据，当前(2011年9月)，Firefox、Safari及Chrome的市场占有率综合已快接近50％。(原文为2009年10月，数据没有太大变化)因此，可以说开源浏览器将近占据了浏览器市场的半壁江山。

2.浏览器的主要功能
浏览器的主要功能是将用户选择得web资源呈现出来，它需要从服务器请求资源，并将其显示在浏览器窗口中，资源的格式通常是HTML，也包括PDF、image及其他格式。用户用URI(Uniform Resource Identifier 统一资源标识符)来指定所请求资源的位置。
HTML和CSS规范中规定了浏览器解释html文档的方式，由W3C组织对这些规范进行维护，W3C是负责制定web标准的组织。
HTML规范的最新版本是HTML4(http://www.w3.org/TR/html401/)，HTML5还在制定中(译注：两年前)，最新的CSS规范版本是2(http://www.w3.org/TR/CSS2)，CSS3也还正在制定中(译注：同样两年前)。
这些年来，浏览器厂商纷纷开发自己的扩展，对规范的遵循并不完善，这为web开发者带来了严重的兼容性问题。
但是，浏览器的用户界面则差不多，常见的用户界面元素包括：

• 用来输入URI的地址栏
• 前进、后退按钮
• 书签选项
• 用于刷新及暂停当前加载文档的刷新、暂停按钮
• 用于到达主页的主页按钮

奇怪的是，并没有哪个正式公布的规范对用户界面做出规定，这些是多年来各浏览器厂商之间相互模仿和不断改进得结果。

HTML5并没有规定浏览器必须具有的UI元素，但列出了一些常用元素，包括地址栏、状态栏及工具栏。还有一些浏览器有自己专有得功能，比如Firefox得下载管理。更多相关内容将在后面讨论用户界面时介绍。

3.浏览器的主要构成
浏览器的主要组件包括：

• 用户界面－ 包括地址栏、后退/前进按钮、书签目录等，也就是你所看到的除了用来显示你所请求页面的主窗口之外的其他部分
• 浏览器引擎－ 用来查询及操作渲染引擎的接口
• 渲染引擎－ 用来显示请求的内容，例如，如果请求内容为html，它负责解析html及css，并将解析后的结果显示出来
• 网络－ 用来完成网络调用，例如http请求，它具有平台无关的接口，可以在不同平台上工作
• UI后端－ 用来绘制类似组合选择框及对话框等基本组件，具有不特定于某个平台的通用接口，底层使用操作系统的用户接口
• JS解释器－ 用来解释执行JS代码
• 数据存储－ 属于持久层，浏览器需要在硬盘中保存类似cookie的各种数据，HTML5定义了web database技术，同样是一种轻量级完整的客户端存储技术

上图：浏览器主要组件

需要注意的是，不同于大部分浏览器，Chrome为每个Tab分配了各自的渲染引擎实例，每个Tab就是一个独立的进程。
对于构成浏览器的这些组件，后面会逐一详细讨论。

4.组件间的通信(Communication between the components)
Firefox和Chrome都开发了一个特殊的通信结构，后面将有专门的一章进行讨论。

二、渲染引擎(The rendering engine)

渲染引擎的职责就是渲染，即在浏览器窗口中显示所请求的内容。
默认情况下，渲染引擎可以显示html、xml文档及图片，它也可以借助插件(一种浏览器扩展)显示其他类型数据，例如使用PDF阅读器插件，可以显示PDF格式，将由专门一章讲解插件及扩展，这里只讨论渲染引擎最主要的用途——显示应用了CSS之后的html及图片。

1.渲染引擎(Rendering engines)
本文所讨论得浏览器——Firefox、Chrome和Safari是基于两种渲染引擎构建的，Firefox使用Gecko——Mozilla自主研发的渲染引擎，Safari和Chrome都使用webkit。
Webkit是一款开源渲染引擎，它本来是为linux平台研发的，后来由Apple移植到Mac及Windows上，相关内容请参考http://webkit.org。

2.主流程(The main flow)
渲染引擎首先通过网络获得所请求文档的内容，通常以8K分块的方式完成。
下面是渲染引擎在取得内容之后的基本流程：
解析html以构建dom树->构建render树->布局render树->绘制render树

上图：渲染引擎基本流程

渲染引擎开始解析html，并将标签转化为内容树中的dom节点。接着，它解析外部CSS文件及style标签中的样式信息。这些样式信息以及html中的可见性指令将被用来构建另一棵树——render树。
Render树由一些包含有颜色和大小等属性的矩形组成，它们将被按照正确的顺序显示到屏幕上。
Render树构建好了之后，将会执行布局过程，它将确定每个节点在屏幕上的确切坐标。再下一步就是绘制，即遍历render树，并使用UI后端层绘制每个节点。
值得注意的是，这个过程是逐步完成的，为了更好的用户体验，渲染引擎将会尽可能早的将内容呈现到屏幕上，并不会等到所有的html都解析完成之后再去构建和布局render树。它是解析完一部分内容就显示一部分内容，同时，可能还在通过网络下载其余内容。

3.主流程图(Main flow examples)

上图：webkit主流程

上图：Mozilla的Geoko 渲染引擎主流程

从上两张图中可以看出，尽管webkit和Gecko使用的术语稍有不同，他们的主要流程基本相同。Gecko称可见的格式化元素组成的树为frame树，每个元素都是一个frame，webkit则使用render树这个名词来命名由渲染对象组成的树。Webkit中元素的定位称为布局，而Gecko中称为回流。Webkit称利用dom节点及样式信息去构建render树的过程为attachment，Gecko在html和dom树之间附加了一层，这层称为内容接收器，相当制造dom元素的工厂。下面将讨论流程中的各个阶段。

4.语法解析与构造DOM树(Parsing and DOM tree construction)

4.1 解析(Parsing－general)
解析原理介绍，略……

4.2 HTML解析器(HTML Parser)
HTML解析器的工作是将html标识解析为解析树。

4.2.1HTML文法定义(The HTML grammar definition)
W3C组织制定规范定义了HTML的词汇表和语法。

4.2.2 非上下文无关文法(Not a context free grammar)
正如在解析简介中提到的，上下文无关文法的语法可以用类似BNF的格式来定义。
不幸的是，所有的传统解析方式都不适用于html(当然我提出它们并不只是因为好玩，它们将用来解析css和js)，html不能简单的用解析所需的上下文无关文法来定义。
Html 有一个正式的格式定义——DTD(Document Type Definition 文档类型定义)——但它并不是上下文无关文法，html更接近于xml，现在有很多可用的xml解析器，html有个xml的变体——xhtml，它们间的不同在于，html更宽容，它允许忽略一些特定标签，有时可以省略开始或结束标签。总的来说，它是一种soft语法，不像xml呆板、固执。
显然，这个看起来很小的差异却带来了很大的不同。一方面，这是html流行的原因——它的宽容使web开发人员的工作更加轻松，但另一方面，这也使很难去写一个格式化的文法。所以，html的解析并不简单，它既不能用传统的解析器解析，也不能用xml解析器解析。

4.2.3 HTML DTD
Html适用DTD格式进行定义，这一格式是用于定义SGML家族的语言，包括了对所有允许元素及它们的属性和层次关系的定义。正如前面提到的，html DTD并没有生成一种上下文无关文法。
DTD有一些变种，标准模式只遵守规范，而其他模式则包含了对浏览器过去所使用标签的支持，这么做是为了兼容以前内容。最新的标准DTD在http://www.w3.org/TR/html4/strict.dtd