原文process models 网站更像一个应用而不是文档，所以浏览器要向操作系统一样有更高的安全性和鲁棒性。

进程模型

• 每个网站的一个实例对应一个进程 默认
• 每个网站对应一个进程 --process-per-site
• 每个tab页对应一个进程 --process-per-tab
• 单进程模型 --single-process
• 渲染进程运行在沙箱内
• 每个插件单独一个进程
• 网页跳转不能切换进程（将来会改进）
• 网页的frame在同一进程中（将来会改进）
• 进程数有限制

原文display a web page in chrome

层

• Browser
  • 代码位置：src/chrome/browser
• Tab contents
  • 代码位置：src/chrome/browser/tab_content
• Render host
  • 代码位置：src/chrome/browser/renderer_host
• Render
  • src/chrome/rendererer
  • RenderView
  • 代码位置：/content/render/renderviewimpl.cc
  • 继承于RenderWidget，RenderWidget负责input处理和绘制
• Webkit glue(WebView, WebWidget, WebFrame, etc)
  • 代码位置：src/webkit/glue
  • 封装webkit接口
  • 转化webkit内建类型为chromium类型，如，std::string 代替 WebCore::String；GURL代替KURL。
  • 简化webkit对象命名，如：WebCore::Frame 变成 WebFrame
  • test shell基于glue的测试程序
• Webkit/Webkit Port
  • 代码位置：third_party/Webkit
  • webkit开源代码，Port是webcore平台相关接口的实现

1. browser process的UI thread创建RenderProcessHost
2. RenderProcessHost创建render process并在browser process的I/O thread中创建ChannelProxy
3. ChannelProxy监听命名管道，将消息转发给RenderProcessHost
4. ChannelProxy中包含ResourceMessageFilter过滤某些消息（如网络通信）直接交给I/O thread 处理
   • ResourceMessageFilter::OnMessageReceived()
5. RenderProcessHost将view相关消息派发给RenderViewHost处理，本身处理view无关消息
   • RenderProcessHost::OnMessageReceived()
6. view相关消息在RenderViewHost和RenderWidgetHostView基类中处理
7. RenderView(Widget)Host都有与之对应的RenderView(Widget)位于render process，
8. 每个平台都有一个 (RenderWidgetHostView[Aura|Gtk|Mac|Win])用于集成至平台。

  render process                               browser process
       |                                            |
    +--+--------------+                +---------------------+
    |                  \              /                       \
render thread        main thread    I/O(IPC) thread     Main browser(UI) thread
    |                    |            |                         |
 webkit                  |            |                         |
    |                    |            |                         |
renderWidget::SetCursor  |            |                         |
    |                    |            |                         |
renderView::Send()       |            |                         |
    |                    |            |                         |
RenderThead::Send()      |            |                         |
    |            IPC::SyncChannel     |                         |
    |                    |-----IPC----|                         |
    |                    |      IPC::ChannelProxy               |
    |                    |            |                         |
    |                    | ResourceMessageFilter                |
    |                    |            |                         |
    |                    |            |   RenderProcessHost::OnMessageReceived
    |                    |            |                         |
    |                    |            |    RenderViewHost::OnMessageReceived
    |                    |            |                         |
    |                    |            |     RenderViewHost::OnMessageReceived
    |                    |            |                         |
    |                    |            |     RenderWidgetHost::OnMsgSetCursor 
    |                    |            |                         |

  render process                               browser process
       |                                            |
    +--+------------------------+                +---------------------+
    |                            \              /                       \
render thread                 main thread    I/O(IPC) thread     Main browser(UI) thread
    |                             |            |                         |
    |                             |            | RenderWidgetHost:ForwardMouseEventToRenderer
    |                             |            |                         |
    |                             |            |                   WebMouseEvent 
    |                             |            |                         |
    |                             |            | RenderWidgetHost::ForwardInputEvent
    |                             |            |                         |
    |                             |            |          RenderWidgetHost::Send
    |                             |      IPC::ChannelProxy               |
    |                             |----IPC-----|                         |
    |                         IPC::Channel     |                         |
RenderView::OnMessageReceived     |            |                         |
    |                             |            |                         |
RenderViewHost::OnMessageReceived |            |                         |
    |                             |            |                         |
RenderWidgetHost::OnMsgSetCursor  |            |                         |
    |                             |            |                         |

原文multi-process

需求

浏览器绝不可能不崩溃，也没有绝对的安全。 所以，为了像现代操作系统一样具有更强的鲁棒性，chromium采取多进程架构。

进程

• browser为主进程用于UI，管理tab页和插件进程。
• render为tab-specific进程用webkit(开源布局引擎)解释和布局HTML。
• browser为render的父进程
• 进程间采用Chromium's IPC system通信

+---------------browser--------------+ +----------render------------+
|RenderProcessHost+---RenderViewHost-|-|-RenderView--+-RenderProcess|
|                  \                 | |            /               |
|                   +-RenderViewHost-|-|-RenderView/                |
|                                    | +----------------------------+
|                                    | + ----------render-----------+
|RenderProcessHost----RenderViewHost-|-|-RenderView---RenderProcess |
+------------------------------------+ +----------------------------+

• browser拥有多个RenderProcessHost用于保存状态和与render进行通信。
• 每个render进程拥有一个RenderProcess用于保存状态和与browser进程进行中相应的RenderProcessHost通信。
• 每个render进程有一个或多个RenderView，每个RenderView相当于一个tab。在同一个render中 view被给予一个唯一的ID用于与其他view进行区别，但是对于browser，view的ID并不唯一。
• 每个RenderView通过其render对应的RenderProcessHost和ID与browser进行通信
• 多tab或windows共享一个进程，如javascript的window.open打开一个新窗口需要同步操作。
• browser监控render，对于render崩溃和异常进行容错处理
• webkit运行于多进程模型中，可以严格限制对系统资源的访问。例如访问网络通过父进程，通过操作系统内置权限限制对文件系统的访问。
• tab不显示的时候，browser可以回收其内存

1.下载depot_tools

2. 更新depot_tools

gclient

3. 获取代码，托GFW的鸿福，时间要很久。科学上网，是不错的选择

gclient config http://src.chromium.org/svn/trunk/src
gclient sync --force

• http://src.chromium.org/svn/trunk/src 为trunk下代码，有可能编译不过，即使编译成功 此版本的浏览器很可能有许多问题，建议使用release下的版本代码。 如： http://src.chromium.org/svn/releases/35.0.1916.153/
• 目录路径不能包含'@'字符，svn update时，会出... a peg version ...的错误

set GYP_MSVS_VERSION＝2013
set GYP_GENERATORS=msvs-ninja,ninja
gclient runhooks --force

5. 编译

debug版,不设置GYP_DEFINES link时会出错

set GYP_DEFINES=component=shared_library
ninja -C out\Debug chrome

release版

ninja -C out\Release chrome.exe

参考

Chromium building with nanja or najia+vs2013

源码版本

chromium源码基于r274914(35.0.1916.153)

吐槽

scope大法好，lock保平安，new在做，weakptr在看，不信factory留隐患，refcount不对自身灭。

chromium代码都是多个类按照一个模式进行组合，要按功能以模式为单位多个类放在一起理解。

用C++的OO写的代码，不管是好代码和烂代码都一样的不易读。好代码和烂代码唯一的区别就是读完了好代码结构比较清晰，而烂代码还是一样的烂。 继承给调试带来了无尽的痛苦，因为你跟到基类的方法不知道这个到底是基类实例化的对象还是子类实例化的对象。

一入chromium深似海，从此美剧是路人。

思路

            +--答案不正确-----+
            |                  \
            V                   \
提出问题->假设答案-+->静态走读代码印证答案--->调试代码确认答案-+->整理关系
                    \            |                  ^           \
                 没有思路        |                  |            +->整理时序
                      \          V                 /    
                       +->查找相关资料------------+    

每日工作

~note.txt +----> ~issuse.txt | +----> archive.md * 每日知识点，心得，问题记录在~note.txt中。 * 整理note内容，知识点和心得的归档为markdown格式的文档，问题归入issuse中， 未整理好的继续保留在note中。 * 使用有道词典管理chromium文档或源码中的词汇,每日复习词汇。

文档阅读

 略读 - 总结
  |
 保存
  |
 文中引用链接添加至~links.txt中
  |
找到作者其他相关的文档添加至~link.txt中

文档命名规则

0开头为笔记和总结 1开头的为base模块相关的源码分析

专有名词和缩写

• POD Plain Old Data 在C++中，我们把传统的C风格的struct叫做POD（Plain Old Data）对象。 POD