这是之前在简书上面的处女作，也搬过来了，以后就一直在 segmentfault 上面写文章了，webkit技术内幕-朱永盛是我大四买的书，很旧的一本书了，当时只看了一点点，一直没继续看完它，现在才看完，，，说来惭愧。

浏览器内核

浏览器中，内核模块（渲染引擎）作用是把HTML页面转变为可视化，可听化的图像结果。

下面我们来逐步打开渲染引擎这个黑盒：

渲染引擎模块及其依赖模块

html解释器是将HTML文本解释成DOM，CSS是为DOM的各个元素对象计算出样式信息，从而为计算最后网页的布局提供基础，JavaScript可以解释JavaScript代码并通过DOM接口和CSSOM接口来修改网页内容和样式信息

网页加载及渲染过程

首先是网页内容，加载完输入到HTML解释器，解释后构成DOM树，这期间如果遇到JavaScript代码就交给JavaScript引擎去处理，如果网页中包含CSS，就交给CSS解释器；DOM树简历的时候，渲染引擎接收来自CSS解释器的样式信息，构建一个新的你日不会吐模型，该模型由布局模块计算模型内部各个元素的位置和大小信息

为了简便起见，下文将网页加载过程及渲染过程统称为渲染过程，将其分为三个阶段：从网页URL到构建DOM树；构建webkit绘图上下文；生成最终的图像。

第一阶段较简单可跳过，第二阶段具体过程：

CSS文件被CSS解释器解释成内部表示结构
CSS解释器工作完之后，在DOM树构建RenderObject树
RenderObject节点仔创建的同时，webkit会根据网页的层次结构创建RenderLayer树，同时构建一个虚拟的绘图上下文。

细细道来：

对于head，script，display:none等等之外的‘可视节点’，webkit会为他们建立相应的RenderObject对象，一个RenderObject对象报错了微会之DOM借点所需要的各种信息，比如样式布局信息。这些RenderObject对象和DOM节点对象类似，也够成一棵新树：RenderObject树，HTMLDocument节点对应RenderView节点，RenderView节点是RenderObject树的根节点。

另外，网页是有层次结构的，webkit会创建相应的RenderLayer对象，当某些类型RenderObject节点或者具有某些CSS样式的RenderObject节点出现的时候，webkit就会创建RenderLayer对象。所以说RenderLayer树是基于RenderObject树建立起来的一颗新树，并且RenderLayer节点和RenderObject节点不是一一对应的关系。以下情况的RenderObject节点需要建立新的RenderLayer节点：

DOM树的Document节点对应的RenderView节点
DOM树中的HTML节点对应的RenderBlock节点
显示指定css position（not static）的RenderObject节点
有透明效果的RenderObject节点
节点有移除overflow，alpha或者反射效果的，v街道
使用canvas2d 3d（webgl）的RenderObject节点
video节点对应的RenderObject节点

最后就是根据绘图上下文来生成最终的图像

基于Blink的Chromium浏览器架构

架构和模块

chromium模块结构图：

没有Content模块的话，也可以在Webkit的Chromium移植上渲染网页内容，但是没有办法获得沙箱模型，跨进程的GPU硬件加速机制，众多的HTML5功能，因为这些功能是在Content层里面实现的。

Content模块和Content API将下面的渲染机制，安全机制，插件机制等等隐藏起来，提供一个接口层。该接口目前被上层模块或者其他项目使用，内部调用者包括Chromium浏览器，Content Shell，外部包括Chromium Embedded Framework，Opera浏览器等等。

Chromium浏览器和Content Shell是够健在Content API之上的两个‘浏览器’，Chromium具有浏览器完整的功能，也就是我们编译出来能看到的浏览器式样，content Shell是使用content API来包装的一层简单的壳，可以使用content模块来渲染和显示网页内容。

content Shell的作用，其一可以测试content模块的很多功能，比如渲染、硬件加速；其二是一个参考，被很多外部项目参考来开发基于content API的浏览器或者其他类型的项目。在Android上，其作用更大，因为chromium浏览器的部分代码没有开源，所以只能依赖于content Shell。

Android WebView其思想是利用chromium的实现来替换Android默认的webview。

多进程模型

Browser进程：浏览器主进程，负责浏览器页面的显示，各个页面的管理，所有其他类型进程的祖先，负责他们的创建和销毁。
Render进行：网页的渲染进程，可能有多个。
NPAPI插件进程
GPU进程：最多只有一个，GPU硬件加速打开时才会被创建。
Pepper插件进程
其他类型的进程，比如Linux的Zygote进程；Sandbox进程。

多线程模型

每个进程内部都有很多线程，对于Browser进程，多线程的主要目的是为了保持用户界面的高响应度，保证UI进程（主线程）不会被任何其他费时操作（比如本地文件读写，socket读写，数据库操作）阻碍，从而影响了对用户操作的响应；对于Render进程中，Chromium则不让其他操作阻止渲染线程的快速执行，多核的话chromium会将渲染过程管线化，可以让渲染的不同阶段在不同的线程执行。

网页加载和渲染过程在图中模型下的基本工作方式有以下步骤：

Browser进程受到用户的请求，首先由UI线程处理，而且将相应的任务转给IO线程，他随即将该任务传递给Render进程
Render进程的IO线程经过简单解释后交给渲染线程，渲染线程接受请求，加载网页并且渲染网页，其中可能需要Browser进程获取资源和GPI进城来帮助渲染。最后Render进程将结果由IOS线程传递给Browser进程
最后，Browser进程接收到结果并将结果绘制出来。

本文主要是讲webkit渲染模块，若是对其他模块有兴趣的话，可以去当当或者京东上买来看看

webkit渲染机制浅析