前言

Something great

• render ：渲染
• Blink： chromium渲染引擎的名称
• parser： 解析器
• AST ：（Abstract Syntax Tree，抽象语法树）
• openGL ：(Open Graphics Library，开放图形库）；一个大部分平台都支持的 底层图形库的 API 标准。
• DirectX：（Direct eXtension，简称DX）微软的多媒体API。
• 沙箱（sandBox）：操作系统对 进程的可访问的内存地址所做的限制。
  • 渲染进程被 Sandbox 隔离，网页 web 代码内容必须通过 IPC 通道才能与浏览器内核进程通信，通信过程会进行安全的检查。
  • 沙箱运行：渲染器在单独的进程中运行，通过沙箱限制其对系统资源(文件、网络、显示、击键)的访问，而须通过父浏览器进程访问
• 插件：浏览器的插件用于显示网页特定内容
• 扩展：浏览器的扩展用于增加浏览器新功能的软件或压缩包
• inspector：（web inspector，调试页面））

第1章 浏览器和浏览器内核

浏览器

• 通常所谓的浏览器内核也就是浏览器所采用的渲染引擎，浏览器内核主要包括以下三个技术分支：排版渲染引擎、 JavaScript引擎，以及其他。

  • 渲染引擎决定了浏览器如何显示网页的内容以及页面的格式信息。
  • Google V8引擎是一个JavaScript引擎实现，使用C++开发。
  • 

• Webkit引擎包含WebCore排版引擎及JavaScriptCore解析引擎。WebCore是苹果公司开发的排版引擎，由排版引擎“KHTML”的基础上而来。

• Blink是一个由Google和Opera Software开发的浏览器排版引擎，这一渲染引擎是开源引擎WebKit中WebCore组件的一个分支

用户代理和浏览器行为

• 用户代理和浏览器行为体现了客制化，是浏览器的内卷结果。
  • 用户代理（User Agent）用于表明浏览器的身份，因而互联网的内容供应商能够知道发送请求的浏览器身份，浏览器能够支持什么样的功能。
    • 例如：服务器为Chrome的桌面版和Android版，发送不同的网页内容以适应屏幕和操作系统的差别，或者是因为不同的浏览器支持的标准不一样。
    • 这样做的目的当然是为了避免浏览器不支持的功能以及获得更好的用户体验。
• 实践：
  • 通过设置用户代理为 chrome -android mobile刷新后，可以看到页面是为安卓系统设计的，更适合手机交互。

内核特征

• 渲染引擎的功能主要包括：HTML解释器、CSS解释器、布局（lay out）、JS引擎。
  • HTML解释器：将HTML文本解释成DOM.
  • CSS解释器：为DOM各个元素计算出样式信息，为布局提供基础设施。
  • 布局：将DOM元素对象和样式信息结合，计算大小位置等布局信息，形成一个内部表示模型。
  • JS引擎：js可以修改网页内容，JS引擎解析js并通过DOM接口和CSSOM接口修改网页内容和样式信息，从而改变渲染结果。
  • 绘图：使用图形库，将布局计算后的网页节点绘制成图像结果。
• 渲染引擎依赖了：网络、存储、2D/3D图形、音频和视频、图片解码器。
  • 同样一起依赖了OS的支持（如线程、文件等）。
    • 

WebKit与blink

• 2001年WebKit来自KHTML，05年被苹果开源。
• 2013年 blink fork 自WebKit。

第2章 HTML网页和结构

网页构成与结构

• html 是一种半结构化数据表现方式，结构特征有：树状、层次、框结构。
  • js代码用于控制网页内部逻辑。即控制用户端逻辑。
  • CSS用于描述网页显示信息。
• HTML5 ：
  • 2D、3D图形以及多媒体方面的支持。使得2D、3D图形以及多媒体 被浏览器原生支持。不需要第三方插件。
• 网页结构：
  • 框结构：
    • 每个框结构包含一个HTML文档，使用元素嵌套框。桌面端应用较为广泛。
  • 层次结构：

    • 层次结构指：网页中元素可能分布在不同层次中，webkit 为他们构建新层，是为了渲染引擎在处理上的方便和高效。

      • 如：创建新层可以更有效的处理视频解码器和浏览器之间的交互和渲染问题。
        • 如：层1为video创建的层；；层2为需要3D变换的div创建的层；层3、4对应canvas，有着HTML5中的2D、3D绘图操作。
        • 可以使用浏览器的show composited layer borders 打开网页的层次结构显示详细观看。
        • 

WebKit的网页渲染过程

• 网页比我们屏幕可视面积要大，当前可见区域成为视图。
• 渲染分为三个阶段：URL到DOM、DOM到构建绘图上下文、绘图上下文到最终图像
  • URL到DOM：
    • js可能修改DOM树结构，如步骤7 。
    • 节点可能需要依赖其他资源，如图片、CSS、视频等，要异步加载他们，如步骤8 。
      • 如果是加载URL，没有标记异步方式，则需要停止DOM构建直到资源加载完。
    • 当DOM构建完成时，发出DOMconent事件
    • 当DOM构建完成、网页所依赖资源都加载完之后，发出onload 事件。
      • 因为资源加载不一定影响DOM树创建，所以这两个事件不一定同时发生。
    • 
  • DOM到绘图上下文：
    • webkit 利用CSS和DOM树，构建renderObject树，直到绘图上下文。
      1. CSS文件被CSS解释器解释成内部表示结构
      2. CSS解释器结束后，在DOM上附加解释后的样式信息，就是renderObject树
      3. renderObject 节点创建同时，webkit 根据网页层次结构创建 renderLayer树，同时构建一个虚拟的绘图上下文。
    • renderObject树的创建并不会让DOM树销毁，这四个结构一直存在，直到网页被销毁，因为都对网页渲染有很大作用。
    • 
  • 绘图上下文到最终图像：
    • 这个过程主要依赖2D、3D图形库。
      1. 绘图上下文是个与平台无关的抽象类，将每个绘图操作桥接至不同具体绘图实现类。
      2. 绘图实现类，在chromium 中需要其合成器完成复杂的多进程与GPU加速机制。
      3. 绘图实现类，将2D、3D图形库绘制的结果保存下来，交给浏览器和UI一起显示。
  • 
• 如今网页多是动态网页，渲染完成后，由于动画与交互，浏览器一直重复执行渲染过程。

第3章WebKit架构和模块

WebKit架构及模块 及 源代码结构

• WebKit支持不同浏览器，为了不同需求，有些代码是共享的，有些是不同的，不同的部分成为WebKit的移植（ports）。

  • 
  • • 虚线框部分：该模块在不同浏览器使用 webkit的实现不一样。
    • 第三方库是WebKit的运行基础，WebKit是这些库的使用者。
    • Webcore 部分是共享的，是网页加载和渲染的基础部分。（web inspector，调试页面））
    • jscore 是WebKit的js引擎，chromium中替换为了V8引擎。
    • WebKit ports 是非共享部分。由于平台差异、依赖第三方库、和需求不同，所以实现方式不同。
    • 嵌入式编程接口： 提供给浏览器调用。因为接口与移植有关，所以有个浏览器相关的绑定层。（？？？）
    • WebKit中其实还包括了测试用例，一般包括布局测试用例（layout tests）、性能测试用例（performance tests）。

• WebKit源代码结构：

• • 主要目录有四个。
    • WTF是基础类库，像是C++的 STL库。
    • webcore：
      • 按照目录组织了webcore 的模块代码。
    • webkit2：
      • 主要包含两种类型目录
        • 各个进程代码：
          • 如 web进程、UI进程、网络进程、插件进程以及它们的共享代码。
        • 各移植的简单主函数入口：
          • 一个构建webkit2接口的简单的可执行程序。

基于Blink的Chromium浏览器结构 及 代码结构

• 
  • content模块和content API，是chromium 对渲染网页功能的抽象。
    • 沙箱模型、跨进程GPU硬件加速、众多HTML5功能在content层实现
  • content模块和content API 将渲染机制、安全机制、插件机制封装一个接口层。
    • 接口层被上层模块使用，内部调用包括了chromium浏览器、content shell，外部包括CEF（chromium enbedded framework）、opera浏览器等。
      • chromium浏览器拥有完整功能，但是外壳没开源？
      • content shell 是使用content shell包装的简单的壳，用于验证功能有效性和作为开发的demo。
        • android 中，开发者大多依赖 content shell 进行移植开发。
  • android webview 为了满足android 系统的webview设计，即利用chromium 替换原来的android 默认webview。（这都是历史了吧）

• 多进程模型：

  • chromium常用多进程模型：

  • 
  • • 连接线代表IPC，可以看到NPAPI插件没有定义使用FPU进行加速的接口。

  • 多进程模型的好处：

    • 避免单个页面的不响应或崩溃影响整个浏览器的稳定性。
    • 第三方插件崩溃不影响浏览器稳定性。
    • 方便了安全模式的实施，沙箱模型基于多线程。

  • 主要进程类型：

    • browser 进程：浏览器主进程，负责浏览器界面显示、页面管理，是其他类型进程的祖先，负责他们的创建与销毁。仅有一个。
    • renderer 进程： 网页渲染进程，renderer进程数量和网页数量的关系不一定，根据配置改变。沙箱模型启动情况下，该进程会发生变化。
    • 插件进程： 每个类型插件创建一次，多个网页使用一种类型插件时，为每个使用者创造一个实例，即插件进程是被共享的。
    • GPU进程：最多一个，用于对3D图形加速调用的实现。

  • 进程模型特征：

    • browser 进程和页面渲染分开，保证页面渲染导致崩溃不影响浏览器主界面崩溃。
    • 每个网页独立进程，保证页面互不影响
    • 插件进程独立，保证插件问题不影响浏览器主界面和网页。
    • GPU硬件加速进程也独立。

  • render 进程创建的类型有：

    • Process-per-site-instance
    • Process-per-site
    • Process-per-tab
    • Single process

  • renderer和 browser进程：

    • renderer和 browser进程代码层次如图：
      • 
      • 首先是webkit接口层， 一般基于webkit接口层的浏览器直接在上面构建，不引入复杂的多进程架构。
      • 然后是黏附层，是个桥阶层，用于处理chromium和webkit内部的不一致。
      • renderer 主要处理进程间的通信，接受来自browser 进程的请求，并调用相应webkit 接口层。
      • browser进程 中的 rendererHost 与renderer 对应， 用于处理和renderer 之间的IPC。
      • web contents 表示网页内容。

• 多线程模型：

  • browser进程：多线程为了保持用户界面的高响应度，保证UI线程对用户操作的响应。
    • 主要有主线程、IO线程、还有很多其他线程，用于处理视频、存储、网络、文件、音频、浏览历史等，因为可能这些操作可能阻塞，所以需要置于单独的线程。
  • renderer进程： 将渲染过程管线化，利用多核优势。
    • 将blink的渲染过程解耦，创建新线程，利用CPU多核能力，加速渲染，像流水线处理一样，提高并发性。
  • 网页加载和渲染过程的基本工作方式：
    1. browser进程收到用户请求，UI线程处理，将任务转给IO线程，然后任务被传递到 renderer 进程。
    2. renderer进程 的IO线程经过简单解释后交给渲染线程。 渲染线程加载网页并渲染网页，其中可能需要browser进程获取资、需要GPU进程来帮助渲染。 最后renderer 进程将结果通过IO线程传递给browser进程。
    3. browser进程 将结果绘制出来。
  • 线程同步与通信：
    • 多线程容易造成死锁、资源竞争与冲突。chromium 使用事件、任务传递机制，仅在不得已时才使用锁或者线程安全对象。
      • 线程内部的消息和任务，在第九章 js引擎部分讲解。

• content 接口：

  • 提供了一层对多进程进行渲染的抽象接口。为了支持HTML5功能、GPU硬件加速功能、沙箱机制。
  • 相关部分分为：embedder调用的接口、embedder应该实现的回调接口（用于参与具体实现逻辑或事件监听）。
    • APP：包括了应用程序或进程的创建与初始化，被所有进程使用，处理一些进程公共操作。
    • Browser：HTML5功能等的实现参与，content模块需要调用他们实现HTML5功能；
    • Common：一些renderer、browser 共享的公共接口。
    • Plugin：通知embedder plugin进程何时被创建的接口类。
    • Renderer
    • Utility：

• chromium 代码结构：

  • chromiumOS 是一个基于web的OS，仅支持web网页和web 应用程序。
  • 还有个很重要的目录：third_party
    • 里面包含了Blink和一些依赖的第三方开源项目。
  • content 目录基本对应了多进程模型中的各种进程类型。
  • 

WebKit2 架构、模块

• webkit2 是一套全新结构与接口，同chromium一致，讲渲染过程放在单独进程中，独立于用户界面。
  • 
  • 这里的web进程对应chromium 的rederer进程。UI进程对应chromium 的browser 进程。
• webkit2 和chromium 多进程模型和接口。
  • webkit 和chromium 多进程的关系：
    • 
    • renderer进程直接调用webkit 接口。
    • content接口允许应用程序注入，并参与content之下各个进程的内部逻辑。
  • webkit2 接口希望将多进程结构隐藏，不让应用程序纠缠内部细节。
  • webkit 是给 chromium提供content 接口以便构建浏览器，其本身目标不是提供嵌入式接口。

chromium 的渲染

• 渲染：将web content，转换为正确的 openGL 调用，让其显示在屏幕上。

渲染过程

1. 样式计算 :渲染进程的主线程解析CSS,确定每个DOM节点的计算样式
   
2. 布局 - layout : 渲染进程知道每个节点的文档结构和样式。布局是查找元素几何的过程。
   • 布局过程主线程 遍历DOM并计算样式，并创建布局树（layout tree, 包含坐标和边界框大小等信息）。
     确定页面布局的挑战：
   • 从上到下的块流须考虑字体的大小以及在哪里划分它们，最终影响段落的大小和形状，影响下一段的位置
     CSS可以使元素浮动到一侧，屏蔽溢出项，并更改写入方向
     
3. 绘制 - Paint : 主线程遍历布局树以创建绘制记录（知道元素的大小，形状和位置，但是不知道绘制的顺序。）
   
4. 合成 :
   • 合成是一种将页面的各个部分分层，分别栅格化，并在合成器线程的单独线程中合成为页面的技术。
   • 如果发生滚动，图层已经被栅格化需要合成一个新帧。通过移动图层和合成新帧，可以以相同的方式实现动画。
   • 浏览器知道文档的结构、每个元素的样式、页面的几何形状和绘制顺序，需将信息转换为屏幕上的像素，称为光栅化。

• 渲染难点：
  1. 布局树变化：在每个步骤中，前一个操作的结果用于创建新数据。例如，如果布局树中的某些内容发生更改，则需要为文档的受影响部分重新生成“绘制”顺序。
     
  2. 动画：动画对人眼来说会很平滑（视觉停留效应）,但是如果动画错过了两者之间的帧或程序运行JS时，则页面将出现卡顿。需要将JS操作划分成小块，并安排在每个帧上运行
     

渲染步骤

1. 渲染的第一步需要解析HTML的标签，生成能反映该HTML结构的对象模型，即DOM（文档对象模型，document object model )。 V8 引擎 通过blindings system 将DOM简单包装后 暴露为：DOM web APIs。
   

• web content 有 HTML、CSS、JS、video、etc。
• DOM：用于作为页面的内部表示、将查询或修改渲染的API暴露给JS。
• • V8 引擎 通过blindings system 将DOM简单包装后 暴露为：DOM web APIs
• CSS 的样式属性(style propertys) 是web 开发者用来自定义DOM元素渲染的控制选项(control knob）
• • 样式属性很多，怎么确定样式作用于哪些元素也越来越复杂，（样式可能被多重规定，可能有冲突）。
• • 样式引擎用于整理这些样式属性。

HTML

• HTML的标签给了文档赋予了语义上的层级结构。
  • 如 div 可以分为多个文本段落
• HTML标签可以嵌套

DOM

• DOM：
  • 作为页面的内部表示；
  • 作为暴漏给JS 以查询、修改的API；
• V8 引擎 通过blindings system 将DOM简单包装后 暴露为：DOM web APIs。

CSS

• CSS 的selector 选择的就是DOM树的节点，然后将对应的 property 应用于对应节点。
• web 开发者用 properties 定义DOM元素 的渲染。(形变、格式、颜色、边距、位置等)
  • 解析CSS 难点在于解析 property具体作用于哪些元素。

浏览器架构

• 整体架构：

  • 操作系统：WebKit可以运行在不同的操作系统上，如Chromium浏览器支持Windows、Linux、Android等系统；
  • 第三方库：这些库是WebKit运行的基础，包括2D图形库、3D图形库、网络库、存储库、音视频库等；
  • WebCore：WebKit加载和渲染网页的基础，是不同浏览器所使用的WebKit中共享的部分，包括HTML解析器、CSS解析器、SVG、布局、渲染树等等；
  • JavaScript引擎：JavaScript解析器，WebKit默认的引擎是JavaScriptCore，Google的Blink为V8引擎；
  • WebKit Ports：WebKit中的移植部分，包括网络栈、音视频解码、硬件加速等模块，这部分对WebKit的功能和性能影响比较大。
  • WebKit嵌入式接口：WebKit对外暴露的接口层，这个接口是提供给浏览器调用的，如给chromium调用，因为接口与具体的移植也有关系，所以中间会有一个WebKit绑定层

• JavaScriptCore（用于Safari）

  • JavaSript Parser，JSON Parser
  • 字节编译器：使用内部字节码格式
  • 汇编程序：在运行时使用代码修补 - >它需要可写代码内存
  • 数据流图：基于编译时推测优化生成代码的新举措
  • 解释器：运行生成的字节码
  • Regexp引擎：支持JIT
  • 垃圾收集器：标记和扫描
  • 运行时：所有JS全局对象（日期，字符串，数字等）
  • 调试器，Profiler

• WebCore

  • 资源加载器：HTML和XML解析器，DOM
  • SVG和SMIL
  • CSS：分析器，选择器，动画
  • 渲染和布局
  • 绑定生成器：IDL文件：JSC，V8，ObjC
  • HTML5：音频，视频，画布，WebGL，通知功能
  • WebInspector
  • 平台集成：图形，字体，声音，视频

浏览器工作原理概述

先后经过页面导航、渲染、资源加载、样式计算、布局、绘制、合成到栅格化，最后完成GPU展示

• 浏览器内核经过了 Loader、Parser、Layout和Paint模块

  • Loader 负责处理HTTP请求、网络资源缓存。

    • 通常有两个IO管道，一个负责页面下载，另一个负责外链资源下载(js、CSS、image)。
    • 因为JS可能改变页面，因此需要保持执行顺序和下载管道后续处理的阻塞。

  • Parser 负责解析HTML页面，从HTML文本到HTML语法树到文档对象树(DOM) 的映射过程。

    • HTML 语法树生成主要包括词法解析和语法解析。
    • 词法解析：依靠词法规则将HTML 文本分割成大量标记(token)。(词法规则如正则表达式)；
    • 语法解析：按照语法规则匹配token序列生成语法树。(通产有自上而下、自下而上两种匹配方式)；
      
    • CSSParse解析CSS后，将CSS解析为对应树结构。 // problem
    • js由单独的脚本引擎解析执行。用于动态改变DOM树，如为DOM接天添加事件响应处理函数，即根据时间或事件映射一颗DOM树到另一个DOM树。

    简单的说，Parser将页面文本转换为带CSS style、会相应自定义事件的styled DOM树。

    • layout 负责排版。包括创建布局树(渲染树、render tree)、计算布局。

      • 布局树与DOM树同时存在于内核，render树是DOM树的排版表示，用以计算可视DOM节点的布局信息(坐标、高、宽)和后续阶段的绘制显示。

        • // 并非所偶的DOM节点都可视，这些节点没有在render树中对应，如标签。// DOM树可视节点的CSS style 就是对应render树节点的style。

      • 计算布局就是安排和计算页面中每个元素大小位置等几何信息的过程。

        • HTML采用流式布局模型，基本原则为页面元素在顺序遍历过程中依次从左到右、上到下的排列方式确定各自位置 区域。

参考

• WebKit技术内幕

• 朱永盛 csdn

• www.webkit.org

• 深入理解Android：WebKit卷

Chromium 系列之(5) blink相关知识

因为这段时间找工作，问的内核的相关问题比较多，所以记录下这些blink的相关的基础知识，一是帮助自己更好的理解blink，另一方面也当作笔记记录下来。

Blink的层级结构

一方面是HTML和CSS以及布局和JavaScript引擎部分，注意Blink中的JavaScript引擎为V8引擎。
另一方面是和系统相关的接口层，例如调用openGL等和音视频解码。Blink中的2D使用的是Skia，音频和视频是重点。
所以就会变成下面的样子。

Blink调用逻辑

platform/ - Blink中和平台相关的接口，主要有 geometry 和 graphics 等
core/ 和 modules/ - 主要core实现了主要有 Page, Node, Element, Document, Settings 以及接口层WebView(WebViewImpl), WebNode, WebElement, WebDocument,WebSettings, WebFrame等
bindings/core 和 bindings/modules/ - 概念上来说 bindings/core 属于 core/ 的一部分，bindings/modules/ 属于 modules/ 的一部分。放置于独立的目录是因为这部分代码跟 V8 紧密相关。
controller/ 一些使用 core/ 和 modules/ 的高级库。比如，devtools 的前端。

渲染流程

Blink Core基础概念

类的对应关系

Renderer process : Page = 1 : N 单进程的情况下， 多进程的情况下需要根据模式区分。
Page : Frame = 1 : M
Frame : DOMWindow : Document (or ExecutionContext) = 1 : 1 : 1

Frame和WebFrame

Frame和WebFrame是一一对应的关系，Frame可以通过client找到WebFrame, WebFrame也可以通过Client找到Frame。

其他的Web**封装的类可以参考这个

下一篇 Chromium 系列之(6)Blink视频相关的接口和文档

转载请注明出处：http://blog.csdn.net/yunchao_he/article/details/41577097

本文大部分内容转载于朱永盛的博客，原文地址：

http://blog.csdn.net/milado_nju/article/details/7292164

http://blog.csdn.net/milado_nju/article/details/7300074

本文将两篇原文合并，略有删改。并加入了一些新内容，比如添加了Blink的介绍。

在介绍各个专题之前，有必要先解释一下极其容易混淆的几个概念，它们是WebKit和WebKit2，Chromium和Chrome, Blink。

首先来了解WebKit。广义上来说，WebKit是一个开源项目，其前身来源于KDE的KHTML和KJS，由Apple发起并主导。该项目专注于网页内容的展示，并发展壮大为一流的网页渲染引擎。它不是浏览器，而且也不想成为浏览器。 该项目包含两个部分，第一部分是WebCore，其中包含了对HTML，CSS等很多W3C规范的实现；第二部分就是狭义上的WebKit，它主要是各个平台的的移植并提供相对应的Web接口，也就是WebView或者类似WebView的组件，这些接口提供操作和显示网页的能力。目前使用WebKit的主流的浏览器或者WebView包括Chrome, Safari, QtWebKit, Android Browser, IOS平台的WKWebView以及众多的移动平台的浏览器和WebView。

WebKit2相对于狭义上的WebKit而言，它不是WebKit简单的第二个版本，它是一个新的API层，其最主要的变化在于将网页的渲染置于单独的进程，而接口层(API层)则在另外一个进程，它们之间通过IPC来通讯。对于接口的调用者来说，中间的IPC和底下的实现是透明的，调用者感知不到它的存在，当然也无法做定制。这样做的好处有很多，一个很明显的好处是，当网页的渲染出现问题时，不会阻碍Web接口的调用者进程，这会在很大程度上解决或者帮助解决浏览器或者这些调用者的稳定性和安全性等问题。

Chromium是一个建立在WebKit之上的浏览器开源项目，由Google发起并主导。该项目被创建以来发展迅速，很多先进的技术被采用，如跨进程模型，沙箱模型等等。同时，很多新的规范被支持，例如WebGL，Canvas2D，CSS3以及其他很多的HTML5特性，基本上每天你都可以看到它的变化，它的版本升级很快，现在没6个月升级一个版本。在性能方面，它也备受称赞，包括快速启动，网页加载迅速等。

Chrome是Google公司的浏览器产品，它基于chromium开源项目，一般选择稳定的版本作为它的基础，它和chromium的不同点在于chromium是开源试验场，会尝试很多新的东西，当这些东西稳定之后，chrome才会集成进来，这也就是说chrome的版本会落后于chromium。另外，chrome会加入一些私有的codec，比如私有的音视频编解码器，这些仅在chrome中才会出现，而Chromium里相应的组件往往使用开源项目。再次，chrome还会整合Google的很多服务。 最后chrome还会有自动更新的功能，这也是chromium所没有的。

2013年5月，Google将WebKit从WebKit开源项目中克隆出来，称为Blink。这样，Google对Blink的改造将自由得多，不像对WebKit的改动时刻受Apple掣肘。从此，Blink与WebKit并驾齐驱，彼此不相关联。总体上，Blink的功能和WebKit相同，是Chromium的绘制引擎。当然，时至今日，Google对Blink在构架上做了一些改动，以更好的适应于Chromium项目。另外，Blink并不是一个完全独立的项目，而是作为Chromium项目的一部分。

简单来讲，WebKit/Blink是一个渲染引擎，Chromium是一个浏览器，它们那么分别包含哪些不同的功能模块？它们是如何划分地？下面为大家详细解读WebKit/Blink的功能。

WebKit/Blink:

1. HTML解析:：负责HTML语言的解析

2. CSS解析：负责CSS的解析工作

3. 图片解码：支持不同编码格式的图片

4. JavaScript引擎：JavaScript语言的解析引擎，缺省的是JavaScriptCore，但是目前Google 的V8 JavaScript被广泛使用

5. 正则表达式

6. 布局：负责布局(layout)的计算和更新工作

7. 文档对象模型(DOM)：DOM是W3C定义的对象模型，该部分负责DOM树及其相应的接口

8. 渲染：与渲染相关的基础设施，例如渲染树，渲染层次树等等

9. SVG：对SVG的支持

10. XML解析：XML语言的解析

11. XSLT：XSLT语言的解析执行

12. URL解析器：URL规范的解析

13. Unicode编解码器：各种编码解码工作

14. 移植：WebKit中比较大的一部分，因为WebKit要工作需要不同平台上有具体的实现，因而不同的移植有不同的实现。chromium的移植很复杂，因为其支持跨平台，所以它的移植需要在windows，linux和mac上工作。

... ...

由上面的模块大致可以看出，WebKit主要是跟网页的解析和渲染相关的工作，其不涉及浏览器的历史，书签，下载，cookie管理等等方面的工作。实际上，这些和浏览器紧密相关的功能在Chromium中，Chromium的功能模块包括：

Chromium:

1. Cookie管理器：cookie生命周期的管理

2. 历史管理器：历史记录的管理

3. 密码管理器：网页中密码登录信息管理

4. 窗口管理：多个Tab窗口的管理和切换

5. 地址栏：地址栏功能，智能地址填充与书签的协同工作

6. 安全浏览黑名单管理：安全浏览机制

7. 网络栈：与网络传输相关的工作，其有很多创新的东西

8. SSL/TLS：网络传输安全

9. 磁盘缓存：磁盘缓存页面及其替换策略等生命周期的管理

10. 下载管理器：管理下载相关

11. 粘帖板：clipboard的功能

12.书签管理：书签的组织和管理

13. URL解析器：同WebKit

14. Unicode编解码器：同WebKit

... ...

Chromium主要是实现浏览器相关的功能，如上面中的网络栈等等。其实以上只是一些浏览器基本功能，chromium实现的远不止这些，这其中包含沙箱模型，NaCl，扩展机制，硬件加速架构等等。这些我们将在之后的章节中逐一介绍它们。

URL解析器和Unicode编解码器在两者中都存在是因为它们都要使用到。