chrome渲染机制浅析

我已经很久没动笔了,,,之前在https://segmentfault.com/u/yiminanci上写文章, 这是处女座,写得不好大家见谅一下,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渲染模块,若是对其他模块有兴趣的话,可以去当当或者京东上买来看看。

你可能感兴趣的:(chrome渲染机制浅析)