webkit架构和模块
本章从webkit内部的主要结构和模块开始，随后介绍基于webkit的chromium游览器的内部结构和模块，并介绍多线程和多进程模型，并将chromium的多进程模型同webkit2的多进程模型进⾏⽐较，剖析⽬前前沿的游览器架构和设计理念。
webkit架构
① 操作系统：webkit可以在不同的操作系统上⼯作，不同游览器可能会依赖不同的操作系统，同⼀个游览器使⽤的webkit也可能依赖不同的操作系统，如chromium游览器⽀持Windows，Mac OS，Linux，Android等；
② 第三⽅库：位于操作系统层⾯之上，是webkit运⾏的基础，包括图形库，⽹络库，视频库等；
③ webkit：webcore加载和渲染⽹页的基础，必不可少；JavaScriptCore引擎为webkit中默认JavaScript引擎，⾮唯⼀，其它还有V8引擎等；webkit ports不同游览器使⽤webkit，由于平台差异，依赖的第三⽅库和需求不同等原因按照⾃⼰的⽅式来设计和实现，属可移植部分；嵌⼊式编程接⼝主要是供游览器调⽤，由于与移植有关，因此有⼀个与游览器相关的绑定层；
基于blink的chromium游览器结构
Ⅰ 架构和模块
chromium基于webkit(blink)，blink只是其中的⼀块，和它并列的还有GPU/CommandBuffer(硬件加速架构)，V8 JavaScript引擎，沙箱模型，CC(Chromium Compositor)，IPC，UI等。在这些模块之上是Content模块和Content API(接⼝)，它们是chromium对渲染⽹页功能的抽象，将下⾯的渲染机制，安全机制和插件机制等隐藏起来，提供⼀个接⼝层，该接⼝层被上层模块或其他项⽬使⽤，内部调⽤者包括chromium游览器，Content Shell等，外部包括CEF（Chromium Embedded Framework）、Opera游览器等。Chromium游览器和Content Shell构建在Content API之上，Chromium具有完整的游览器功能，Content Shell是使⽤Content API来包装的⼀层壳，使得⽤户可以使⽤Content模块来渲染和显⽰⽹页内容；Android WebView是为了满⾜Android上的WebView设计的，其思想是替换原来Android系统默认的WebView。
Ⅱ 多进程模型
在webkit内核之上，chromium率先在webkit之外引⼊了多进程模型，使⽤多进程带来的好处包括如下三点：其⼀避免了因单个页⾯的不响应或者奔溃⽽影响整个游览器的稳定器，特别是对⽤户界⾯的影响；其⼆当第三⽅插件奔溃时不会影响页⾯或者游览器的稳定性，因为第三⽅插件也被基于单独的进程来运⾏；其三⽅便了安全模型的实施，沙箱模型就是基于多进程架构。
chromium游览器多进程模型如下图：
Browser进程：游览器的主进程，负责游览器界⾯的显⽰、各个页⾯的管理，是所有其他类型进程的祖先，负责它们的创建和销毁等，并且有且只有⼀个；
Render进程：⽹页的渲染进程，负责页⾯的渲染⼯作，blink/webkit的渲染⼯作主要是在这个进程完成，可能有多个，具体个数允许⽤户配置；
NPAPI插件进程：是为NPAPI类型的插件⽽创建的，其创建的基本原则是每种类型的插件只会被创建⼀次，⽽且仅当使⽤时才会创建，当有多个⽹页要使⽤同⼀个类型的插件的时候，插件进程是被共享的；
GPU进程：做多只有⼀个，并且仅当GPU硬件加速打开的时候才会被创建，主要⽤于对3D图形加速调⽤的实现；
Pepper插件进程：同NPAPI进程，不同是是为Pepper插件⽽创建的进程；
其它类型的进程：包括linux下的Zygote进程，render进程就是有它创建；Sandbox进程，⽤于安全进制中；
总结包括如下特征：Browser进程和页⾯的渲染是分开的，保证了页⾯的渲染导致的奔溃不会导致游览器主界⾯的奔溃；每个⽹页是独⽴的进程，保证了页⾯之间相互不影响；插件进程也是独⽴的，插件
本⾝的问题不会影响游览器主界⾯和⽹页；GPU硬件加速进程也是独⽴的。
render进程个数配置类型：
Process-per-site-instance: 为每个页⾯创建⼀个独⽴的Render进程，不管这些页⾯是否来⾃同⼀个域，带来的好处是每个页⾯互不影响，坏处是资源的巨⼤浪费；
Process-per-site: 属于同⼀个域的页⾯共享同⼀个进程，⽽不属于同⼀个域的页⾯则分属于不同的进程，好处是对于相同的域，进程可以共享，坏处是可能会有特别⼤的Render进程；
Process-per-tab: chromium为每个标签都创建⼀个独⽴的进程，不管它们是否是不同的域不同实例，chroimum的默认⾏为；
Single process: chromium不为页⾯创建任何独⽴的进程，所有的渲染都在Browser进程中进⾏，是Browser进程中的多个线程；
Ⅲ Browser进程和Render进程
Browser进程和Render进程都是在webkit的接⼝之外由chromium引⼊的，其代码层次如下：
webkit接⼝层： ⼀般基于webkit接⼝层的游览器直接在上⾯构建，⽽没有引⼊复杂的多进程架构；
黏附层：由于chromium中的⼀些类型和webkit内部不⼀致，需要⼀个简单的桥接层；
Render：主要处理进程间通信，接收来⾃Browser进程的请求，并调⽤相应的webkit接⼝层，同时，将webkit的处理结果发送回去；
上⾯界⾯的层都是在Render进程中⼯作的，下⾯就进⼊Browser进程。
RenderHost：与Render对应，⽬的是处理同Render进程之间的通信，是给Render进程发送请求并接收来⾃Render进程的结果；
Web Contents：表⽰页⾯的内容，页⾯可能有多个需要绘制的内容，如弹出对话框内容，因此是Contents，它同时包括显⽰内容的⼀个⼦窗⼝，这个⼦窗⼝最后被嵌⼊游览器的⽤户界⾯，作为⼀个标签页；
嵌入式多线程编程Ⅳ 多线程模型
chromium多线程模型：
基本⼯作⽅式如下
Browser进程收到⽤户的请求，⾸先由UI线程处理，⽽且将相应的任务转给IO线程，他随机将该任务传递给Render进程；
Render进程的IO线程经过简单解释后交给渲染线程，渲染线程接收请求，加载⽹页并渲染⽹页，这其中可能需要Browser进程获取资源和需要GPU进程来帮助渲染，最后Render进程将结果由IO线程传递给Browser进程；
Browser进程接收到结果并将结果绘制出来；
Ⅴ Content接⼝
Content接⼝不仅提供⼀层对多线程进⾏渲染的抽象接⼝，⽽且⽀持所有的HTML5功能、GPU硬件加速功能和沙箱机制，可以让使⽤者不需要很多的⼯作就可以得到强⼤的能⼒。Content接⼝的相关定义⽂件均在”content/public”⽬录下，按照功能分为六⼤部分，每个部分的接⼝⼀般可以分为两类，第⼀类是嵌⼊者(embedder，可以是chromium游览器，CEF3，Content Shell)调⽤的接⼝，另⼀类是嵌⼊者应该实现的回调，被Content接⼝的内部实现所调⽤，⽤来参与具体实现的逻辑或者事件的监听等。
App： 主要与应⽤程序或者进程的创建和初始化有关，它被所有的进程使⽤，⽤来处理⼀些进程的公
共操作，包括进程创建的初始化函数(Content模块的初始化和关闭动作)和各种回调函数(告诉嵌⼊者启动完成，进程启动，退出，沙盒模型初始化开始和结束等)；Browser：包括两类，第⼀类包括对⼀些HTML5功能和其他⼀些⾼级功能实现的参与，因为这些实现需要chromium的不同平台的实现，同时需要例如Notification、Speech recognition、Web Worker、Download、Geolocation等Content层提供的接
⼝，Content模块需要调⽤它们来实现HTML5的功能，第⼆类典型接⼝类是ContentBrowserClient，主要是显⽰部分的逻辑，被Browser进程调⽤，还有⼀些事件的函数回调；
Common： 定义⼀些功能的接⼝，被Browser和Render共享，如⼀些进程相关、参数、GPU相关等；
Plugin：仅有⼀个接⼝，通知嵌⼊者Plugin进程何时被创建；
Render：包括两类，第⼀类包含获取RenderThread的消息循环，注册V8 Extension，计算JavaScript表达式等，第⼆类包含ContentRenderClient，主要是实现部分逻辑，被Browser调⽤，还有为⼀些事件的函数回调；
Utility： ⼯具类接⼝，主要包括让嵌⼊者参与Content接⼝中线程的创建和消息的过滤；

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。