愤怒的菜鸟

更快的加载时间和更省的流量无疑是所有浏览器都追求的目标。为了达成这个目标，经典的以空间换时间的缓存机制自然必不可少。本文就总结一下浏览器中常见的几种缓存机制，目前本人还没有深入研究这几种缓存机制，所得的资料基本来源于网上，日后有时间必定要对这几种缓存机制进行下系统的研究。1. 资源分类 在介绍缓存机制之前，先将资源分类罚抄一下：WebCore 把要加载的资源分成两类，一类是主资源，比如

chromium保存网页的功能是通过将DOM树序列化为html语言字符串的形式来实现的，它能够很好的将用户所看到的网页转换成一个html字符串。从WebCore::WebPageSerializerImpl::serialize函数可以看到整个流程。  大体思想是以document节点为起点，在WebPageSerializerImpl::buildContentForNode函数中递归序列化

chromium整个历史记录功能比较复杂，包括前进后退，浏览历史，用插件以后还可以显示树形的浏览记录。这里只分析一下我所看到的部分代码，没有搞的特别清楚，主要跟前进后台的功能相关。其实在webkit中已经支持前进后退，浏览历史等功能。这些类主要集中在third_party/WebKit/Source/WebCore/history/目录下。其中HistoryItem类标识一条基本的历史

实际上chromium是没有实现阅读模式的，但是阅读模式确实是移动浏览器比较实用的一个功能，特别对于喜欢在线浏览小说的人来说，一个良好的阅读模式可以提供极佳的阅读体验。所以实现阅读模式是非常必要的，但是想实现一个良好的阅读模式还算难度较大的。   其实实现方式是很容易理解的，就是玩弄当前的DOM树，一番折腾之后得出三个字符串：一是标题，二是内容，三是下一页或者上一页的URL。然后把这三个字符串

对于排版问题的调试，能够查看render树无疑有很大的帮助，webkit也提供了这样的接口来方便开发人员。chromium输出render树的接口可以参见WebFrameImpl::renderTreeAsText，实际实现在RenderTreeAsText.cpp文件中，一个典型的树的深度优先搜索遍历。

其实对于手机浏览器来说，设置字体大小实在是一个非常鸡肋又蛋疼无比的功能，因为本身可以缩放，还有缩放重排等功能。谁会有那么无聊想设置字体大小。改变字体大小强制改变了原网页的意图，排版完全改变，很可能造成较差的用户体验，真是一个吃力不讨好的功能。   在browser端设置字体大小之后，不会意外会最终设置到WebCore::Settings::setTextAutosizingFontScaleF

chromium手势事件的处理，简而言之就是browser进程调用系统接口捕获并判断事件，传给render进程处理事件的过程。   捕获事件的接口：ContentViewGestureHandler::onTouchEvent。在这个函数中有一些判断这里不再赘述，只提一个重要的函数ContentViewGestureHandler::offerTouchEventToJavaScript。这个

该特性主要包含两个js接口：window.external.AddSearchProvider(sUrl) 和 pdwResult = window.external.IsSearchProviderInstalled(sUrl)。主要功能是可以通过js来提示用户添加和管理搜索引擎。可以参见这个网页的介绍。    既然是js接口，那么首要的任务就是让v8能够识别这两个函数。自然的想法是在Web

光标显示的主要逻辑在FrameSelect.cpp文件中。FrameSelection::caretBlinkTimerFired函数即为光标的定时器，来控制光标闪烁。该定时器会调用invalidateCaretRect()来触发重绘请求。同时还会对m_caretPaint的值取反。m_caretPaint变量控制重绘过程中CaretBase::paintCaret 函数是否被调用。Caret

webnotifications的实现与inputtyp=color一样清晰，其最重要的一个类是content::NotificationProvider,不同的是该特性是由V8触发。其堆栈如下：#0 content::NotificationProvider::show (this=0x4aa08c38,notification=...) at content/renderer/noti

inputtype= month (date datetime datetimelocal weektime)，把这几个特性拿到一起说是因为它们的实现方法完全一样。以month为例，该特性的实现过程可以分为两步：一是记录type，二是相应事件。所谓记录type就是webcore在解析网页时记录下该input的type。Type主要分为下面几种（类似color那样需要特殊类支持的排除在外）：

人都知道浏览器将这个新特性称为Page Cache。Firefox将其称为“Back-Forward Cache”或“bfcache.” ，Opera则称其为“Fast History Navigation.” ，在WebKit的实现中我们称其为“Page Cache”， 以避免与“Back/Forward List.”的混淆。注意，页面缓存是使用用户更加流畅地浏览网页的一个客户端特性。而

恢复上次打开的网页是浏览器一个很实用的功能，相信大家都不会陌生。细心的人会发现，在恢复上次打开网页的过程中，不仅仅恢复了网页本身，还恢复了它的表单数据、滚动位置、缩放比例、历史记录列表等。  这不禁让我们想起历史记录功能，点击前进、后退按钮时也可以恢复网页的表单数据、滚动位置、缩放比例等。不难推测出，这两个功能应该是复用了相同的代码。所以实际上恢复上次打开的网页，关键是是恢复Navigatio

CC简介CC即是chromiumcompositing的简写，意思是chromium的合成器，是为webkit的硬件加速渲染提供合成和渲染逻辑的关键代码。关于硬件加速的基本知识可以参见chromium的官方文档http://dev.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome。最

有的网页（特别是桌面版网页）在手机上浏览时字体特别小，用户们不得不放大才能看清，为了避免网页放大后需要左右移动来看其内容，浏览器一般都会很贴心的对该网页的文字进行重排，以适应屏幕的宽度。这个功能很实用，但现在好像并不是webkit的自带功能，而是需要各家浏览器独自实现。那么这个功能主要涉及到两个技术点：缩放重排和重新定位。        首先说一下缩放重排，实际上就只需要设置RenderBlo

前一段时间以android4.1源码为基础比较深入的研究了一下其Surface系统部分的代码，主要是学习网上各位前辈的内容。其中老罗（http://blog.youkuaiyun.com/luoshengyang?viewmode=contents）和林学森（http://blog.youkuaiyun.com/uiop78uiop78/）的博客对我帮助最大， 在这里表示感谢。对于想要深入理解的朋友可以学习他们的博客

Android4.4 browser 渲染架构分析1.     整体分析Android4.4 browser与之前版本最大的不同就是在保持webview控件接口不变的情况下，将内核换成了chromium32。随之，它的硬件加速渲染架构也与之前版本和chromium本身都有一定差别，相当于androidbrowser与chromium的一个融合。它们都使用chromium的核心，直观来看

一、Render进程初始化Render进程的初始化流程与Browser进程非常相似，启动service后会调用到ContentMain::Start，并且在RunNamedProcessTypeMain函数中走RenderMain的流程。上述流程图是Render进程消息循环及IPC相关类的初始化，可见它们在Render进程刚一建立就相继被初始化了，因为它们是一个进程最最基础的类

一、概述ContentShell的启动过程比较复杂，涉及的类比较多，总是看了这忘了那，于是萌生了将看过的初始化过程记录一下的想法。本文从UI初始化，Browser进程初始化和Render进程初始化三个方面来浅析一下ContentShell的初始化过程。主要关注一些关键对象的构造。本文基于chromium31，android版本。二、UI的初始化整个CotnentShell的启动从U

本文只是简单记录一下在编译chromium前的一些准备工作的流程。关于chromium构建系统gyp的基本用法网上已经有不少文档介绍过，也可以参见gyp的官方网站：http://code.google.com/p/gyp/。无论gyp构建系统是优是劣，你习惯或不习惯，chromium已经使用了它，那我们就必须去适应。  开始编译chromium之前的一个关键步骤就是运行：android_gyp

对于很多链接打开以后会启动一个下载任务，本来以为这个功能也是通过shouldoverrideurlloding回调接口来判断的。实际发现并不是，下载链接最初被当作正常的url打开，在webkit解析response过程中判断出这是一个下载任务，并且启动下载。先给出一个webkit的调用堆栈：#0  WebKit::FrameLoaderClientImpl::download    Frame

我们的浏览器总是非常智能，除了可以打开http,ftp等众多常见协议之外，也可以调用第三方应用来打开某些特定url。比如调用淘宝客户端来打开taobao://的网页，再比如迅雷，你懂的。   实际上webkit或者说net库只支持标准的传输协议，对于特定的url就只有通过browser来支持了。在打开一个url之前，webkit总会回调到browser端的接口shouldOverrideUrl

3.2  工作流程chromium24和26在流程上的主要区别就是，26中painting被分成了record和raster两步。24中，painting过程发生在main线程（即上述的更新过程），26中record在main线程中执行，而将raster移到了impl线程。如图所示：painting过程是webkit将网页内容用skia绘制成skbitmap的过程。reco

CC的工作流程每个版本CC部分代码都有比较大的改动，所幸是主框架和主流程并没有改变，这里结合chromium24和chromium26，说一下CC模块的代码结构和工作流程。代码结构Cc模块porting自webkit的硬件加速部分，特别是GraphicsLayer类（该类即代表一个层）。Chromium对GraphicsLayer类的porting是Graphi

inputtype=color特性对应于宏ENABLE(INPUT_TYPE_COLOR)，如前所述，开启之后还需要browser的支持。其最重要的一个类为RendererWebColorChooserImpl，在该类中各个接口一目了然，剩下的就需要不同的平台去实现了。但点击该类型的input的时候，事件是怎样传递到该类的，看如下堆栈：#0 content::RendererWebColo

不久前移动浏览器领域掀起了一股抢分大战，国产浏览器频频刷新HTML5最高得分记录，最高得分者已经接近满分500，这让chromefirefoxsafari等一众浏览器汗颜。实际上HTML5得分虽然不是浏览器最重要的方面，但大家努力提升其得分肯定也是一件好事，一来使前端开发者可以更加方便，二来也能给用户呈现更加丰富多彩的内容。    最近真正研究HTML5特性实现时（基于chromium24），

一个web页面需要使用到JS的场景Parser阶段HTMLDocumentParser 中的HTMLTokenizer在解析到开始标签时，创建HTMLScriptElement对象，在解 析时，开始解析JS代码啊，如果中含有src,那么发出一个异步请求(在异步请求过程中，parser会中断，等待JS的解析结果，期间Webkit会来做一些 DNS预取，资源预解析等工作，总之WebKi

沙箱技术早在Windows2000的时候就已经出现了，但是因为大部分的人都不会接触到也没有机会应用这种技术，导致大部分的人根本就对这个没有印象。而在一本讲到沙箱技术的书上，上面的翻译是‘沙框’，当然这本书的翻译质量很是有些问题。在Windows操作系统上，沙箱实际上是一个内核对象，用一个句柄来存取的，用CloseHandle函数来销毁，这个内核对象与一个进程关联起来。这样，通过设计沙箱对象的属性，

原文：http://blog.sina.com.cn/s/blog_496be0db0100w39p.html沙箱其实就是一个硬盘过滤文件驱动，具体来说，就是你把要写的东西写到了硬盘上，但实际上并没有写到硬盘，而是到了一个转存处，读取内容需要判断是沙箱开启之前就存在的内容还是开沙箱之后写入的内容，要分别从不同的地方读取内容，重启之后把转存的地方清零。文件过滤的驱动编写和加载方法

Chromium的线程模型和消息循环机制一直是其很有亮点也非常值得学习的一部分，关于这部分的工作原理网上有很多好文章，比如这篇、这篇还有这篇。但是这几篇文章基本是站在一定的高度上来概括其思想，而深入到代码里还有一些流程及细节问题，在此略做总结。首先，在线程启动时基本会按以下流程来启动消息循环：#1base::MessagePumpLibevent::Run base/message_pum

Chrome源代码结构首先，开始接触Chrome的童鞋可能有一个疑惑，Chrome和Chromium是同一个东西吗？答案是，Chrome是Google官方的浏览器项目名称，Chromium是Google官方对Chrome开源项目。说白了就是Chrome是Google自己的官方浏览器版本，而Chromium是开源项目，所有有兴趣的开发者都可以参加，Chromium中出现的新技术如果经过测试是

转载自Soul Apogee本文链接地址：Chrome学习笔记（一）：线程模型，消息循环看Chrome已经有一段时间了，但是一直都没有沉淀些内容下来，是该写写笔记什么的了，免得自己忘记了。看的都是Windows平台下的代码，所以记录也都是记录的。。。废话。。那么首先，先从最基础的东西记录起吧：Chrome的线程模型和消息循环。多线程的麻烦多线程编

今天和朋友聊到关于chromium的线程模型的东西，在网上查了半天竟然没有哪篇能说清楚的，于是review了一下代码写点东西出来备忘一下，其实chromium（以下称为chrome）在对待多线程这个事情上的做法还是很值得一看的，chrome并不推荐过多的使用锁和threadsafe对象，在线程之间直接共享对象不可避免的设计操作原子性的问题；chrome的解决之道是通过command模式将对象隔离在

总体概览Chromium分为3个大模块(包括第三方库)：浏览器，渲染器，WebKit。浏览器负责主进程，UI展现和I/O。渲染器一般是由浏览器调用的标签子进程。它嵌入WebKit中做布局和渲染。你应该熟读多进程架构和Chromium如何显示web页。快速介绍sln文件有2个sln文件，chrome.sln是使用V8引擎的普通版本，chrome_kjs.sln是使用Webkit的

原文：http://www.guao.hk/posts/cutting-edge-native-client.html不知不觉，Google已经正式推出其Native Client (NaCl)过去约7个月之久。而目前国内似乎还没有多少关于NaCl的资料，所以在这里面向Web开发者做一下简单的介绍，希望能够起到一个抛砖引玉的效果。本文的所有代码均来自于https://devel

本文档从底层原理开始介绍了Chromium如何显示网页。阅读本文之前你应该首先阅读“Chromium的多进程架构”这篇文章，重点要理解主要组件结构图。您可能也有兴趣阅读“多进程资源加载“这篇文章来了解网页是如何从网络获取的。应用层次概念图 layers每个盒子代表一个概念中的应用层。通常情况下应该有可能通过替换任意一层及其上层组建来生成一个新的浏

目录1。背景2。概述3。WebKit4.渲染器5。浏览器6.Cookies背景所有网络通信由主浏览器进程处理。这样做不仅使浏览器进程可以控制每个渲染器的访问网络，而且这样还使我们能保持如Cookies和缓存的数据等对话的数据贯穿所有的进程中。这一点很重要，这是因为，作为一个HTTP/1.1中用户端，一个浏览器不能对一个站点打开过多的连接。在Windows上，我们

原文：Windows程序是基于消息的，不管其封装形式如何，最后都要包含如下代码Cpp代码  MSG msg;  while(GetMesssage(&msg))  {  TranslateMessage(&msg);  DispatchMessage(&msg);   }   大部分的工作都是在这个while循环里完成。

网上已经有网友duguguiyu针对Chrome的线程体系做了很专业的描述了，应该说从原理上已经很完整了。本文主要在网友的基础上从代码实现的角度上进行一些补充和分析。提到线程，我想大家关注的无非几点：线程的消息循环机制、多线程同步机制，线程间通信机制。本文也是从大家关注的几点来重点描述。在Chrome的代码中，与线程相关的文件主要在\base\base.vcproj中。主要包含了以

【三】 Chrome的进程模型1. 基本的进程结构Chrome是一个多进程的架构，不过所有的进程都会由老大，Browser进程来管理，走的是集中化管理的路子。在Browser进程中，有xxxProcessHost，每一个host，都对应着一个Process，比如RenderProcessHost对应着RenderProcess，PluginProcessHost对应着PluginP