jyl_sh的专栏

在Gecko层上面的是Gaia层，它包含了各种帮助生成Web应用的工具，以及基于系统的应用（如通信录、电话应用等）和经过认证的其他应用。而对于其他众多的操作系统功能，如果不需要，它根本不会被包含进来，所以它是一个很轻量级的操作系统，结构上非常简单和清晰明了，图15-7中的架构图就是来源于Chromium的官方网站，具体参见这个网址：http://www.chromium.org/chromium-os/chromiumos-design-docs/software-architecture。

不同于Cordova项目，Crosswalk不仅仅提供一些Web接口的扩展，也不是简单的基于系统默认的嵌入式应用接口，如Android WebView，而是使用新Blink和Chromium的能力，加强对HTML5能力的支持，同时加入了Web作为一个运行平台的各种能力，从功能上看，它对Web应用的支持和规范的支持更加完整，图15-5描述了Web应用在Crosswalk上的基本工作过程。当用户需要启动Web应用的时候，由Crosswalk加载Web应用的设置并使用运行环境来启动该Web应用。

但是，它也存在一些不足之处。图15-4描述了Cordova的主要工作思想，对于一个Web应用，结合Cordova提供的本地代码和框架，使用Cordova的打包工具将它们一起打包成一个个同系统相关的本地可执行文件，这里的打包工具不同于前面说的Web的清单文件，而是指将Web应用打包成操作系统支持的本地可执行文件。第二是提供了自动化的打包工具；Cordova的这一设计极大地方便了Web开发者，使得它在很短的时间内获得了巨大的成功，现在使用PhoneGap打包的Web应用成千上万，下面看一看它的优势和不足之处。

之后是该应用需要使用的功能和权限，它们的区别在于权限是系统中的一些非常敏感的信息，如个人信息，包括但是不限于通讯录、位置、文件系统等。与普通网页不同的是，一个Web应用通常包含一个称为清单（Manifest）的文件，该文件的目的跟很多系统如Android上的应用程序的清单文件类似，就是为了定义该应用的一些信息。很多技术对于Web网页和Web应用是共享的，如基础渲染工作、Canvas2D、WebGL、CSS、音视频等，但是还有众多的技术是为Web应用设计的，如Web manifest规范、运行模型规范等。

目前，该项目已经启动并取得了良好进展，核心思想在于保持WebView的接口兼容性，同时将内部的实现从当前默认WebKit内核变成了Chromium的内核，但是原有的WebViewAPI保持不变，这样对于WebView的用户来说，调试代码时不需要做任何改变，便可以使用功能更多性能更好的渲染内核了。所谓的嵌入式模式是指，在渲染引擎之上提供一层本地（如C++或者Java）接口，这些接口提供了渲染网页的能力，渲染的结果被绘制到一个控件或者子窗口中，本地应用通过本地接口来获得渲染网页的能力。

以上这些技术和方向，每个都可以花费很多篇幅去介绍和描述它们，本章主要是想着重从Web应用和Web运行平台两个最重要的地方着手，着重介绍目前的一些进展，未来的发展路程将会很长，笔者希望和读者一起关注它们。当然，如果读者完全相信了笔者这些关于趋势的描述并且认为Web前端就是这些变化，那还是赶紧从其中摆脱出来吧，因为它们会阻碍读者的思维。就目前Web前端来说，各种类型的技术非常多，极容易引起大家的误解，有鉴于此，结合笔者自身的理解，总结出一些比较明显的趋势同大家分享，分别从技术上和方向上来解读。

当然，为了查看网页的DOM结构和网页中的各种对象，开发者工具提供了命令行式的控制台，开发者可以以此查看任何DOM中的节点（这个在第5章中也使用过控制台来理解DOM树结构）和各种对象（包括对象值和它包括的函数，笔者经常使用它来查看Chromium支持的一些JavaScript接口是什么样的，因为不同浏览器对于接口的支持也是不一样的），甚至可以执行JavaScript语句。这一切对网页开发者来说是透明的。除此之外的JavaScript引擎内部的内存分析工具，也可以按照类似的情况来处理，这里不再做过多的介绍。

支持调试HTML、CSS和JavaScript代码是浏览器或者渲染引擎需要提供的一项非常重要的功能，这里包括两种调试类型：其一是功能，其二是性能。功能调试能够帮助HTML开发者使用单步调试等技术来查找代码中的问题，性能调试能够采集JavaScript代码、网络等性能瓶颈。当然，这只是对于HTML开发者来说的。因为对于性能而言，问题可能存在于HTML代码，也可能是浏览器本身的问题。

上面这段代码相对比较容易理解，设置的名字是“viewport”，视窗的宽度就是设备的宽度，而初始缩放大小是0.9，最小的缩放比例是0.5，最大的缩放比例是1.0，而且不允许用户使用手势来缩放它们。为了让网页在移动设备中也能像其他应用（这个会在第15章详细介绍）一样，可以设置该网页的图标，使用的方法是使用“link”标签设置，在Android浏览器中的方式是使用如下属性，与Safari中的设置类似。不过目前仅有iOS系统上的Safari浏览器提供类似的支持，还有一种并不完美的方式，但可能较为通用，代码如下。

这个事件同前面介绍的Safari提供的Gesture Events不是一回事，因为Safari只是提供了旋转和缩放的值给JavaScript，而这里的手势事件包括一个或者多个手指触发的动作，WebKit并不会将这里的手势事件传递给JavaScript代码，如“longPress”事件会触发浏览器弹出右键菜单的动作。下面分别来分析这两者。每个触控点都需要包含很多信息，也就是图13-2中的众多属性，主要是标记属性的唯一ID、触控的目标（也就是对于的DOM元素）、屏幕位置、视图中的位置等，看起来还是比较直观的。

但是，在Android上，系统支持的安全机制都已经在Chrome的Android版上得到了启用，主要体现在两个方面，第一是SUID，Android系统上稍微有些不同，它是UID isolation（UID隔离技术），Android可以为每一个进程设置一个新的UID，这样每个进程之间就不能随意修改和访问数据，这是有Linux内核机制来保证的，其实是上面讨论的沙箱机制的第一层。而沙箱模型工作的基本单位就是进程。对于网络上的网页，浏览器认为它们是不安全的，因为网页总是存在各种可能性，也许是无意的或有意的攻击。

在WebKit的Chromium中同样定义了两个类WebRTCPeerConnectionHandler和WebRTCPeerConnectionHandlerClient，根据WebKit的类名定义方式，前者是需要Chromium来实现，而后者则是由Chromium调用，并由WebKit来实现的，这里主要是应用连接事件的监听函数，所以WebKit能够将它们传递给JavaScript引擎。这里，不再使用新元素，而是利用原有的“video”元素，实在是一个好的设计。之后是Chromium的实现类。

自然而然地，W3C定义了两个主要的接口，分别对应识别和合成技术，接口定义比较清晰简单，例如对于SpeechRecognition，当调用start()函数时就开始语音识别，而后面的事件句柄则是让开发者知道识别的状态，当识别完成之后，可以通过监听“onresult”来获取识别的结果。Web Audio的绝大多数处理都是在WebKit中完成的，而不需要Chromium过多地参与，除了输入源和输出结果到实际设备，其他同前面的多媒体数据源是一致的，不再赘述，下面描述图11-15中的结构是如何被WebKit支持的。

2　视频2.1　HTML5视频在HTML5规范定义中，Web开发者可以使用“video”元素来播放视频资源。视频中有个重要的问题就是视频编码格式，对此，目前标准中包含了三种编码格式，它们分别是Ogg、MPEG4和WebM。其中Ogg是由Xiph.org组织开发的一个开放标准，不需要任何授权费用，它使用Theora作为视频编码格式和Vorbis作为音频编码格式。MPEG4是MPEG工作组开发的需要授权费用的标准，它使用H.264作为视频编码格式和AAC作为音频编码格式。而WebM是由G

说到浏览器对多媒体的支持，不得不提的就是Flash插件和HTML5之争。Flash对Web的发展起了非常重要的作用，它能够支持视频、音频、动画等多媒体功能，虽然现在大家都在讨论Web前端领域是否应该丢弃Flash插件转而支持HTML5。在本章中，笔者将回顾Web前端中的多媒体发展历程，然后详解现在HTML5中引入的多媒体技术。

首先当然是网页的解释工作，在创建Document对象的时候，WebKit使用ScriptController类来注入Chromium的Extension机制所需要的代码，这里会调用类Dispatcher，该类此时创建一个ModuleSystem对象，并将各种各样的NativeHandler对象注册，这里的NativeHandler就是各种各样的“chrome.*”的接口。本质上，它其实就是浏览器能力的简单扩展，而对于一些本地的功能，如书签、USB、蓝牙、电源管理等，该机制并没有这方面的能力。

当开发者完成接口的定义之后，需要生成JavaScript引擎所需的绑定文件，该文件其实是按照引擎定义的标准接口为基础，来实现具体的接口类，WebKit提供了工具能够帮助开发者自动生成所需要的绑定类，根据引擎的不同和引擎开发语言的不同，可能有不同的结果，主要包括为JavaScriptCore和V8生成的绑定文件，以V8引擎为例，使用下面的命令就能够为该IDL文件生成结果。除了JavaScript绑定机制之外，V8引擎另外又提供一种能够动态扩展的机制，它无须跟V8引擎一起编译，因而有很大的灵活性。

在WebKit中，对于PPAPI和NPAPI的支持都是类似的，所以可以回顾10-7中的NPAPI插件被创建的过程，二者同样根据MIME类型来查找PPAPI插件机制，如果Chromium发现查找到的是一个PPAPI插件而不是NPAPI插件，那么在创建WebPluginContainerImpl对象的时候，就会首先创建一个WebPlugin子类的对象。同其他的PPAPI插件不一样，它是一个在Renderer进程中运行的插件，因为这个插件显然是受信的，如图中的“Type: PPAPI(in-process)”。

NPAPI（Netscape Plugin Application Programming Interface）的全称是网景插件应用程序编程接口，最早是由网景公司提出的，用于让浏览器执行外部程序，以支持网页中各种格式的文件，典型的例子是视频、音频和PDF文件等（通过内容类型来区分）。对于这些网络资源或者文件，浏览器本身并不支持它们。但是，经过第三方开发者开发的插件程序，浏览器就可以做到支持了。

同时，时间相同的计时器可以合并。在浏览器中，JavaScript引擎和渲染引擎WebKit需要协同工作才能达到一个好的效果，结合这二者，这一小节来介绍一个简单的例子，就是后来被引入的新的JavaScript接口requestAnimationFrame，以此来解释它是如何解决两者之间一些比较难以处理的问题的，以及它给Web前端开发者带来的思考。关于如何使用JavaScript语言来编写高效的代码，有很多铺天盖地的经验分享，以及很多特别好的建议，读者可以搜索相关的词条，就能获得一些你可能需要的结果。

当然JavaScriptCore在不停地演进的过程中，目前的实现跟之前的实现差别非常大，所以这里介绍的是基于目前的结构的，在未来，可能还会有很多其他的变化，让我们拭目以待。第三，JavaScriptCore引擎在获悉热点函数后，需要对它们进行优化，就会使用到简单（Baseline）JIT编译器，该编译器根据信息收集器1中的信息，将对应函数的字节码翻译成本地代码，不仅因为时间问题，而且并不是所有代码都合适做深层次的优化，所以这里没有做特别多的优化，而是直接做转换。第五，要是你认为这样就足够了，那就更错了。

2　V8引擎2.1　基础V8是一个开源项目，也是一个JavaScript引擎的实现。它最开始是由一些语言方面的专家设计出来的，后被Google收购，成为了JavaScript引擎和众多相关技术的引领者。其目的很简单，就是为了提高性能。因为在当时之前的JavaScriptCore引擎和其他的JavaScript引擎的性能都不能令人非常满意。为了提高JavaScript代码的执行效率从而获得更好的网页浏览效果，它甚至采用直接将JavaScript编译成本地代码的方式。

基本的工作方式是这样，当创建对象a的时候（这个当然是执行阶段），如果它包含两个属性（根据JavaScript的语言特性，没有类型，而且这些属性都是动态创建的，属性就是前面说的C++的类成员变量），那么引擎会为它们创建如图9-2左边所示的结构，也就是属性名-属性值对，需要强调的是这些属性名（典型的做法就是采用字符串）都是会被保存的，因为之后访问该对象的属性值时需要通过属性名匹配来获取相应的值。在“add”函数中，执行环境同样会建立一个该函数的上下文，包含该函数中的心理，例如第三行，又是一个变量“me”。

在HTML5中，规范又引入了2D绘图的画布功能，它的作用是提供2D绘图的JavaScript接口，所以JavaScript代码可以很容易地调用该接口来绘制任意的2D图形。当然创建SkSurface_Gpu对象需要很多其他的对象，最重要的是SkGpuDevice对象，它是SkDevice的一个基类，同原先软件方式不同的是，它是将2D图形操作转变成对GL的操作，使用GrContext的3D图形上下文来绘制，并将结果存储在GrRenderTarget，该存储目标是GPU的内存缓冲区。第三个阶段就是绘图部分。

2　Chromium的硬件加速机制2.1　GraphicsLayer的支持GraphicsLayer对象是对一个渲染后端存储中某一层的抽象，同众多其他WebKit所定义的抽象类一样，在WebKit移植中，它还需要具体的实现类来支持该类所要提供的功能。为了完成这一功能，Chromium提供了更为复杂的设施类，这一节主要介绍从GraphicsLayer类到合成器这一过程中所涉及的众多内部结构。图(Chromium对GraphicsLayer的支持)描述了从WebCor

WebKit 技术内幕》之八（1）：硬件加速机制。

一个RenderObject类的“paint”函数在绘制时可能会被多次调用，因为不同的绘制阶段（前面的一张图提到的）都需要调用它来绘制不同的部分，所以读者会发现上图右侧标记了在哪些阶段才会调用该绘制函数（或者是哪些阶段该函数不会被调用），至于这些阶段的顺序则是由RenderLayer对象中的调用过程来控制的。这里是一个大致的过程，下面是详细分析。细心的读者其实可以发现，这一过程需要一些内存方面的拷贝，这是因为网页的渲染和网页的显示是在两个不同的进程，而这些拷贝在下一章介绍的硬件加速渲染机制中可以避免。

而这两个抽象基类的具体绘制则由不同的移植提供不同的实现，每个移植使用的实际绘图类非常不一样，依赖的图形率也不一样，图7-7描述了抽象类和WebKit的移植实现类的关系。在软件渲染中，通常渲染的结果就是一个位图（Bitmap），绘制每一层的时候都使用该位图，区别在于绘制的位置可能不一样，当然每一层都按照从后到前的顺序。首先，对于常见的2D绘图操作，使用GPU来绘图不一定比使用CPU绘图在性能上有优势，例如绘制文字、点、线等，原因是CPU的使用缓存机制有效减少了重复绘制的开销而且不需要GPU并行性。

为了直观地理解RenderLayer树，根据示例代码中的源代码，WebKit中的RenderObject树表示如图7-5左边所示的结构（省略了一些节点），图7-5的右边描述的就是WebKit所生成的对应RenderLayer树。除了根节点也就是RenderLayer节点，一个RenderLayer节点的父亲就是该RenderLayer节点对应的RenderObject节点的祖先链中最近的祖先，并且祖先所在的RenderLayer节点同该节点的RenderLayer节点不同。

WebKit 技术内幕》之七（1）： 渲染基础WebKit的布局计算使用 RenderObject 树并保存计算结果到 RenderObject 树。RenderObject 树同其他树（如 RenderLayer 树等），构成了 WebKit 渲染的为要基础设施。

这显然会增加处理的复杂性，为此，WebKit的处理方式是——对于一个块元素对应的RenderObject对象，它的子女要么都是块元素的RenderObject对象，要么都是非内联元素对应的RenderObject对象，这可以通过建立匿名块（Anonymous Block）对象来实现，在下一章也会作介绍。可惜的是，由于字体、平台的样式等差异性（如Qt、GTK等就不一样），相同的网页渲染出的结果可能不一样，所以，读者可以看到布局测试对不同的移植会有不同的期望结果。其次，网页的动画会触发布局计算。

最后，查看一下“styles”中的“Matched CSS Rules”，这些规则能够匹配上该节点的规则列表，但是不同的属性可能来源于不同的规则。下面的部分WebKit主要是将解释之后的规则组织起来，用于为DOM中的元素匹配相应的规则，从而应用规则中的属性值序列。这三个规则的匹配方式是类似的，这里是以自定义规则的匹配为例加以说明的。这些类基本上跟CSS的标准相对应，当然也有特例，那就是StyleRuleImport，它是WebKit引入的一个新的类型，主要对应的是导入CSS文件的元素。

先谈一谈HTML网页的开发者们所遭遇的痛苦和悲惨的经历。在CSS出现之前或者更早，HTML网页设计者们因为要设计不同风格和样式的元素，所以规范不停地加入很多新的元素来表示网页布局，例如p、span等元素。然而，问题依然存在，例如，使用表格（Table）元素来排列网页中的元素，这可能存在一些问题：其一，表格经常内嵌表格，导致网页内容较大，占用带宽；其二，被搜索引擎解析后，网页内容将会变得杂乱无章。所以这时候急需一种技术来解决这些问题。庆幸的是，此时CSS出现了。

当网页的开发者需要访问网页 DOM 树的时候，这些控件内部的 DOM 子树都会暴露出来，这些暴露的节点不仅可能给 DOM 树的遍历带来很多麻烦，而且也可能给 CSS 的样式选择带来问题，因为选择器无意中可能会改变这些内部节点的样式，从而导致很奇怪的控件界面。HTML5 支持了很多新的特性，例如对视频、音频的支持，读者会发现这些元素其实是由很复杂的控制界面组成，这些界面也是使用 HTML 元素编写，但是在 DOM 树中，你无法找到相应的节点，这其实也是使用了影子 DOM 的思想。4.1 什么是影子 DOM。

图中黑色圆形表示光标的当前位置，光标下面的元素注册了一个监听鼠标滚轮事件的函数，当用户滚动鼠标的时候，浏览器经过HitTest之后，发现有监听者，它需要将这些事件传递给WebKit，WebKit实际上最后调用JavaScript引擎来触发监听者函数。每个 事件都有属性来标记该事件的事件目标。当事件到达事件目标（如一个元素节点）的时候，在这个目标上注册的监听者（Event Listeners）都会有触发调用，而这些监听者的调用顺序不是固定的，所以不能依赖监听者注册的顺序来决定你的代码逻辑。

在 WebKit 中， DOM 中的接口 Interface 对应于 C++ 的类，Node 类是其他类的基类，在下面的图中 显示了 DOM 的主要相关节点类。对于每个不同的状态，都有相应的处理逻辑。上面介绍了 Frame 、Document 等 WebKit 中的基础类，这些都是网页内部的概念，实际上，WebKit 提供了更高层次的设施，用于表示整个网页的一些类，WebKit 中的 接口部分 就是基于它们来提供的，表示网页的类既提供了构建 DOM 树等操作，同时也提供了接口用于布局。

还有一些其他类型的节点，例如 属性节点（标记的属性）、Entity 节点、ProcessingIntruction 节点、CDataSection 节点、注释（Comment）节点等。DOM 结构构成的基本要素是节点：文档节点（整个文档 Document）、元素节点（HTML 中的标记 Tag）、属性节点（标记的属性）、Entity 节点、ProcessingInstruction 节点、CDataSection 节点、注释（Comment）节点。在图中没有表现出来。等 DOM 接口标准。

提高资源加载效率的方法还很多，如：减少无用空格、用异步资源的加载等。PageSpeed是一个Chromium的扩张工具，可以进行资源加载性能分析工具，它可以分析网页加载过程中出现的各种问题，给出各种建议帮助开发者解决这些影响性能的问题。4.实践：高效的资源使用策略。4.1 DNS和TCP连接。

表和表项如何组织和存储在磁盘上：至少有一个索引文件和四个数据文件（块文件），每个块文件的大小是固定的，当资源文件超过某个块的大小就会为其分配多个块来解决，但最多不能超过四个块，超过四个块能存储的时候会建立单独的文件来保存。HTTP 1.1 中新增的管线化技术：将多个 HTTP 请求一次性提交给服务器，可能将多个 HTTP 请求填充在 TCP 数据包内（相当于 HTTP 权威指南中串行事务处理中的管道化连接），HTTP管线化需要在网络上传较少的TCP数据包，因此减少了网络的负载。使用场景有很大的限制。

在Chromium架构的Renderer进程中，ResourceHandleInternal类通过IPCResource-LoaderBridge类同Browser进程通信，IPCResourceLoaderBridge类继承自ResourceLoaderBridge类，其作用是负责发起请求的对象和回复结果的解释工作，实际消息的接收和派发交给ResourceDispather类来处理。ResourceHandle 类之下的部分是不同移植对获取资源的不同实现，Chromium 中是 多进程资源加载。