chromium kernel资源加载、解析、三树合成浅析(chromium39)

每次尝试去看看chromium kernel中具体逻辑的实现的时候,都会费一些时间去看代码,找逻辑。当然了,网上很多资料可以参看,但是每次看完这些资料,我都会要问一问:确实如此么?新版本的kernel是否这块逻辑更改了呢?

所以,为了让自己释惑,还是要亲自去看源码,一点点查看调用堆栈。然后再能在整体上理解下kernel的原理。

最近了看了看chromium kernel中,blink kernel part的网页的加载、html解析、以及三树(Dom tree、 Render Tree、Render Layer Tree)合成的逻辑。在这里总结下,以后有时间继续深入研究下。

>> chromium kernel 与blink kernel概念差异

刚接触到chromium项目的同学,往往有个疑惑,浏览器内核中,chromium kernel 和blink kernel有什么区别呢?

首先,要解释下,blink(webkit的google分支),是渲染内核,它是chromium kernel的一部分。提供了网页的加载、解析、渲染的基本机制,并提供port供不同的浏览器内核去实现。

而chromium kernel是一个浏览器内核,浏览器内核是对blink的一层封装与扩展再实现,chromium kernel不仅仅要提供网页的加载、解析、渲染功能,还有提供tab的前进、后退、刷新;多tab管理;历史记录与书签;各个回调接口等等诸多工作。并且可以再实现blink kernel的一些功能,比如渲染等等。

故总结一句:blink kernel是chromium kernel的 heart part。

>>加载

前面的blog中,总结了网页加载中住资源的下载逻辑。这里不再赘述。

总结一点:网页资源的加载是分步的、多线程的。

加载过程,从加载主资源开始,然后将整个主资源下载完毕之后,形成一个字符串(或者几个字符串),然后解析,形成dom树,此时遇到需要加载的标签,比如img、srcipt等,就启动相应的子资源加载过程

>>dom 解析

主资源下载下来,是字符串的形式存在,然后将该字符串进行标签化。具体的解析语法可以参看网上文章

DOM树、Render Tree 及RenderLayer Tree这三颗树是并行创建的,他们的创建与子资源的加载是并行的。

>>三颗树相应关系

Dom树到RenderTree的解析过程,可以参看文章:网上文章

Dom树的合成中,HTMLTreeBuilder.cpp是关键对象。其中方法:HTMLTreeBuilder::constructTree是将上一步中解析到的所有token,进行dom树的构建。

这里贴出从网页的字符串到dom树的构建堆栈:

W/WebKit  ( 7420): BackgroundHTMLParser::appendDecodedBytes
W/WebKit  ( 7420): BackgroundHTMLParser::pumpTokenizer()
W/WebKit  ( 7420): BackgroundHTMLParser::sendTokensToMainThread()
W/WebKit  ( 7420): BackgroundHTMLParser::pumpTokenizer()
W/WebKit  ( 7420): HTMLDocumentParser::didReceiveParsedChunkFromBackgroundParser
W/WebKit  ( 7420): HTMLDocumentParser::pumpPendingSpeculations()
W/WebKit  ( 7420): HTMLDocumentParser::processParsedChunkFromBackgroundParser
W/WebKit  ( 7420): HTMLDocumentParser::constructTreeFromCompactHTMLToken
W/WebKit  ( 7420): HTMLTreeBuilder::constructTree

Dom树的节点是Node类。关于节点的类型及子类的继承等逻辑关系,可以自己查看下代码。

RenderTree的根节点是RenderView类,其中的各个节点是RenderObject。关于RenderTree中的各个节点,可以自己查看下代码,对于RenderObject有好多的子类。

RenderTree的构建中,会创建多个RenderTreeBuilder对象。

RenderLayerTree的节点是RenderLayer对象

这里贴出部分从renderLayer的形成逻辑:

W/WebKit  ( 5275): Element::attach
W/WebKit  ( 5275): RenderTreeBuilder::RenderTreeBuilder
W/WebKit  ( 5275): RenderTreeBuilder::createRendererForElementIfNeeded()
W/WebKit  ( 5275): RenderObject::setStyle
W/WebKit  ( 5275): RenderBlock::styleDidChange
W/WebKit  ( 5275): RenderLayerModelObject::styleDidChange
W/WebKit  ( 5275): RenderLayerModelObject::createLayer
W/WebKit  ( 5275): RenderLayer::RenderLayer

RenderLayer Tree是最后显示网页的重要组件。

对于这三棵树形成过程,分析可以参看下blog:网上文章

之后,有时间的话,去从这里开始深入看看网页的渲染逻辑。

blink kernel对网页的下载、解析及三棵树的合成逻辑也比较复杂,细节上的东西比较多。这里只是总结了下我最近看这块代码的逻辑。以后有时间的话,还要深入研究下这块。看看如何在内核中去操作dom树(节点的增加,或者删除)等等

时间: 2024-12-06 17:48:31

chromium kernel资源加载、解析、三树合成浅析(chromium39)的相关文章

Chromium多进程资源加载

webkit笔记,主要来自 朱永盛 <WebKit技术内幕> 学习笔记,转载就注明原著,该书是国内仅有的Webkit内核的书籍,学习的好导师,推荐有兴趣的朋友可以购买 多进程 资源的实际加载在各个WebKit Port中有不同的实现.Chromium采用的是多进程的资源加载机制 根据带有资源缓存机制的资源加载过程,在ResourceHandle类之下的部分,是不同的移植对获取资源的不同实现. 在Chromium中,获取资源的方式是利用多进程的资源加载架构.如下图,描述了 关于 Chromium

chromium网络资源加载分析(二) 主资源加载逻辑分析 之head部分加载---chromium39

转载请标注: from 你吧吧 上一个blog中,主要理顺了chromium kernel在load mainSource的时候,相互调用的逻辑. 这个blog中,我们来看看HttpCacheTransaction对象和HttpNetworkTransaction对象相互协调,一致将网页加载下来的逻辑. 1. HttpCacheTransaction对象跟浏览器的cache模式有关,而cache模式决定了浏览器网页加载的资源的来源与处理方式. cache模式有如下几种: READ.READ_WR

chromium网络资源加载分析(一) 主资源加载逻辑分析

最近花了点时间看了看chromium加载网页的逻辑.由于这段内容较为复杂,现在只看了一部分.现将主资源的加载记录下来. 注:下面提到的文件,如果没有指明目录,则在third_party/WebKit目录下 1. ContentViewCore执行loadUrl之后,经过一些逻辑(这些逻辑比较简单,这里不做介绍),最终会走到:render_frame_impl.cc的方法:RenderFrameImpl::OnNavigate 该方法中,有代码:frame->loadRequest(request

【FastDev4Android框架开发】RecyclerView完全解析之下拉刷新与上拉加载SwipeRefreshLayout(三十一)

转载请标明出处: http://blog.csdn.net/developer_jiangqq/article/details/49992269 本文出自:[江清清的博客] (一).前言: [好消息]个人网站已经上线运行,后面博客以及技术干货等精彩文章会同步更新,请大家关注收藏:http://www.lcode.org 话说RecyclerView已经面市很久,也在很多应用中得到广泛的使用,在整个开发者圈子里面也拥有很不错的口碑,那说明RecyclerView拥有比ListView,GridVi

浏览器页面加载解析渲染机制(一)

mark一下zhq[2]. 前言:首先这个标题对我来说有不甚了解,这里引用了一些好的技文内容,分享一下我的一些理解,如果有说错的望评论里狠狠打脸,以共勉之. 一:为什么要了解浏览器渲染页面和加载页面机制,主要还是性能的优化. 了解浏览器如何进行加载,我们可以在引用外部样式文件,外部js时,将他们放到合适的位置,使浏览器以最快的速度将文件加载完毕. 了解浏览器如何进行解析,我们可以在构建DOM结构,组织css选择器时,选择最优的写法,提高浏览器的解析速率. 了解浏览器如何进行渲染,明白渲染的过程,

浏览器加载解析渲染网页原理

浏览器加载网页资源的原理 JS与CSS阻塞 重排与重绘 一.浏览器加载网页资源的原理 1.HTML支持的组要资源类型 在浏览器内核有一个管理资源的对象CachedResource类,在CachedResource类下有很多子类来分工不同的资源管理,这些资源管理子类分别是:  资源  资源管理类  HTML  MainResource ===> CachedRawResource  JavaScript  CachedScript  CSS  CachedCSStyleSheet  图片  Cac

高效地加载图片(三) 缓存图片

如果只需要加载一张图片,那么直接加载就可以.但是,如果要在类似ListView,GridView或者ViewPager的控件中加载大量的图片时,问题就会变得复杂.在使用这类控件时,在短时间内可能会显示在屏幕上的图片数量是不固定的. 这类控件会通过子View的复用来保持较低的内存占用.而Garbage Collector也会在View被复用时释放对应的Bitmap,保证这些没用用到的Bitmap不会长期存在于内存中.但是为了保证控件的流畅滑动,在一个View再次滑动出现在屏幕上时,我们需要避免图片

Cocos2d-x 3.0多线程异步资源加载

Cocos2d-x从2.x版本到上周刚刚才发布的Cocos2d-x 3.0 Final版,其引擎驱动核心依旧是一个单线程的"死循环",一旦某一帧遇到了"大活儿",比如Size很大的纹理资源加载或网络IO或大量计算,画面将 不可避免出现卡顿以及响应迟缓的现象.从古老的Win32 GUI编程那时起,Guru们就告诉我们:别阻塞主线程(UI线程),让Worker线程去做那些"大活儿"吧. 手机游戏,即便是休闲类的小游戏,往往也涉及大量纹理资源.音视频资

也许是被误解的浏览器资源加载优化

几乎每一个前端程序员都知道应该把script标签放在页面底部.关于这个经典的论述可以追溯到Nicholas的 High Performance Javasript 这本书的第一章Loading and Execution中,他之所以建议这么做是因为: Put all <script> tags at the bottom of the page, just inside of the closing </body> tag. This ensures that the page c