WebKit的一些笔记1（基础篇）

概述

WebKit是一个开源的网页渲染引擎项目，项目包括两部分：

1. 第一部分是WebCore，包含对HTML，CSS等很多W3C规范的实现；
2. 第二部分是狭义上的WebKit，主要是各个平台的移植并提供相应的Web接口，这些接口提供操作和显示网页的能力。

WebKit2是相对于狭义的WebKit而言，它是一个新的API层，最主要的变化在于将网页的渲染至于单独的进程，接口层则在另外一个进程，它们采用IPC进行通信。这样渲染出现问题的话，不会影响到接口调用者进程，提高了安全性和稳定性。（渲染和接口属于不同的进程）

Blink目前就是Google从WebKit直接复制出来一份，重新整理，只不过后来走的路不同。

Chromium界面（UI）

chromium的UI比较简洁，大体可以分为两部分：

1. 网页内容
2. 外边框修饰控件（工具栏，按钮等）

整个chromium浏览器是个顶层窗口，每个tab都对应了一个顶层窗口的子窗口，每个网页的内容都会绘制到一个子窗口当中。

Chromium的多进程模型

概述

多进程模型以消耗更多资源为代价，保证当某个页面崩溃的时候，其他页面还好好的。

多进程架构至少带来三点好处：

1. 避免单个页面崩溃时候，不影响这个浏览器的稳定性；
2. 第三方插件崩溃时，不影响页面和浏览器的稳定性；
3. 为了安全的沙箱模型是基于多进程架构的。

下图是Chromium的进程模型，方框代表进程，连线代表IPC。

通常来说，Chromium包括以下主要进程：

• Browser进程：主进程，负责界面的显示，页面和各种进程的管理；
• Render进程：WebKit的工作主要在这完成，负责页面的渲染；
• NPAPI插件进程：每种插件只有一个进程，被所有Render进程共享；
• GPU进程：最多只有一个，开启硬件加速时才会被创建；
• Pepper插件进程：和NPAPI插件进程一样，不同的是为了Pepper插件而创建的进程（pepper插件好像是用于支持flash显示的）。

模型的类型

process-per-site-instance：

你打开一个网站，然后从这个网站中打开的一系列链接都属于一个进程，这是Chrome默认模式。

process-per-site

属于一个域名内，认为是一个进程。

process-per-tab

一个tab一个进程。

single process

传统浏览器，没有多进程只有多线程。

沙箱模型

在页面的多进程模型中，页面的渲染由Render进程负责，而Render进程运行在沙箱模型中，没有访问本地资源的能力，可以保护渲染引擎被入侵。

Chromium的多线程机制

概述

Chromium是基于多进程模型的架构设计，同时每个线程里面也有很多线程，特别是browser进程。browser进程中有很多线程，官方的意思是为了保证UI的高度响应，因为有很多耗时的操作，如文件读写等，它们可能会阻塞用户操作，影响用户的体验。

线程之间的同步是非常难缠的问题，如死锁和资源冲突，Chromium精心设计了一套机制来处理它们，仅在非用不可的情况下才使用锁和线程安全对象。

在绝大多数情况下：

1. 使用事件；
2. 使用一种Chromium新创建的任务传递机制。

线程内部使用MessageLoop来处理这些事件和任务。每一个线程都有自己的MessageLoop，原理如下图所示：

任务被分派到线程的MessageLoop的队列中，MessageLoop负责调度执行这些Task。

任务（task）

Chromium的一个特色就是在事件的基础上加上任务新的一个机制——任务。当需要执行某个操作的时候，可以把操作封装成一个任务，由任务派发机制传递给相应进程或线程的MessageLoop。

• 线程内部：当需要费时操作的时候，为了避免阻碍更高优先级的事件或任务执行，我们不能直接调用。我们需要派发一个事件和回调函数给自身线程的MessageLoop，MessageLoop会调度该回调函数进行操作。
• 线程间通信：

1. 线程A传递任务给线程B；
2. 线程B调用执行该任务；
3. 线程B完成后回复线程A。很多情况下，线程A并不需要回复。

下图是待回复的线程间传递：

消息循环

（暂时先不整理了，目前关系不是很大）