一, chromium 浏览器的架构及模块:html
chromium, 是基于webkit(blink)的; 但将不少先进的理念引入到浏览器领域;html5
chromium架构: linux
一些基本底层模块: Blink只是其中的一块, 和他并列的还有众多的chromium模块, 包括 GPU/CommandBuffer硬件加速架构, V8 JavaScript引擎, 沙箱模型, CC(chromium Compositor), IPC, UI 等;android
底层模块之上是Content模块 和 Content API: 他们是chromium对渲染网页功能的抽象。 Context的本意是指网页的内容, 这里是指用来渲染网页内容的模块。 经过 Context 模块, 能够在获得渲染的基础上, 得到沙箱模型, 跨进程的GPU硬件加速机制, 众多的HTML5 功能, 这些不少是在Content层里实现的。web
content模块与content API, 将下面的渲染机制, 安全机制 和插件机制udeng隐藏起来, 提供一个接口层。 该接口目前被上层模块 或者 其余项目使用, 内部调用者 包括chromium浏览器, content shell等, 外部包括 CEF(chromium Embedded Framework)与opera 浏览器等。shell
Chromium浏览器 和 content Shell: 是构建在content API 之上的两个 “浏览器”, chromium 具备浏览器完整的功能。 content shell 是使用content API来包装的一层简单的 “壳”, 但他也是一个简单的“浏览器”, 用户可使用content模块来渲染和 显示 网页内容。windows
Content Shell: 其一能够用来测试 Content模块 不少功能的正确性; 其二, 是一参考, 能够被不少外部的项目参考开发基于content API的浏览器 或者各类类型的项目。 在android 系统上, contentshell的做用更大, 由于 同他并列的左侧的chromium浏览器 代码根本就没有开源, 这就致使开发者只能依赖content shell。浏览器
Android WebView: 他是知足android系统上的webview 而设计的, 其思想 就是利用chromium 的实现 来 替换原来 android 系统默认的 webview。安全
二, chromium 多进程模型架构
多进程优势: 其一, 避免单个页面的不响应或者 崩溃 而影响 整个浏览器的稳定性, 特别是对用户界面的影响;
其二, 当第三方插件崩溃是不会影响浏览器的稳定性;
其三, 他方便了安全模型的实施, 也就是沙箱模型 是基于对进程架构的, 其实, 这也是webkit2产生的缘由。
多进程缺点: 复杂度变大; 更多的资源消耗。
经常使用 Chromimu 浏览器多进程模型, 方框表明进程; 链接线 表明IPC 进程间通讯。
主要进程以下:
Browser进程: 浏览器的主进程, 负责路蓝旗界面的显示, 各个页面的管理, 是全部其余进程的祖先, 有且仅有一个。
Renderer进程: 网页的渲染进程, 复杂页面的渲染工做, 可能有多个, 与打开的网页数量没有一一对应关系;
NPAPI 进程: 为NPAPI 类型的插件而建立的, 每种插件只建立一次,当且仅当使用时才建立; 插件进程被共享的;
GPU 进程: 最多只有一个, 当且仅当硬件加速被打开的时候 才被建立; 主要对3D图形加速调用;
Peper插件进程: 同NPAPI进程;
其余类型的进程:
对于桌面系统windows, linux, mac os 中的chromium浏览器, 进程模型特征:
1, browser进程和 页面的渲染是分开的, 保证页面渲染致使的崩溃不会致使浏览器主界面的崩溃;
2, 每一个页面 是独立的 进程, 保证页面之间 相互不影响;
3, 插件进程也是独立的, 插件自己的问题不会影响浏览器主界面 和网页;
4, GPU硬件加速 进程也是独立的;
三, Browser进程 和 Renderer 进程:
最下面的是webkit接口层: 通常基于webkit接口层的浏览器 直接在上面构建, 而没有引入复杂的多进程架构;
粘附层glue层: 他的出现 主要是应为chromium中的一些类型 和webkit内部不一致, 因此要一个简单的桥接层;
Renderer层: 它主要处理 进程间通讯, 接受来自broser进程的请求, 并调用相应的webkit接口层。 同时将webkit的处理结果发送回去。
RendererHost层: 处理同Renderer进程之间的通讯。
Web Contents页面内容: 由于网页可能有多个须要绘制的内容,
chromium 多进程模型:
四, content接口
Content接口, 不只提供了一层对多进程 进行渲染的抽象接口, 要支持全部的html5接口, GPU硬件加速 和 沙箱机制。
Content 接口 相关定文件均在 content/public目录下, 按功能分红六个部分, 每一个部分的接口通常分红两类: 嵌入者embedder(chromium浏览器, CEF3 和 Content Shell)调用的接口; 嵌入者应该实现的回调接口, 被content接口的内部实现所调用, 用来参与具体实现的逻辑或者事件的监听等。
App: 这部分, 主要与应用程序或者进程的建立与初始化相关, 他被全部的进程使用, 用来处理 一些进程的公共操做。
Browser: HTML5功能 和 其余一些高级功能实现的参与,
Common: 定义一些公共的接口, 这些被Renderer 和browser共享, 例如 一些进程相关, 参数, GPU相关等
Plugin: 仅是一个接口类, 通知嵌入者 Plugin进程 什么时候被建立;
Renderer:
Utility: 工具类接口,
五, Chromium 的代码结构:
chromium 的content 目录结构