浏览器喧嚷过程

所有浏览器的引擎工作流程都差不多,如上图大致分5步:创建DOM tree –> 创建Style Rules -> 构建Render tree -> 布局Layout –> 绘制Painting


第一步,用HTML分析器,分析HTML元素,构建一颗DOM树。


第二步:用CSS分析器,分析CSS文件和元素上的inline样式,生成页面的样式表。


第三步:将上面的DOM树和样式表,关联起来,构建一颗Render树。这一过程又称为Attachment。每个DOM节点都有attach方法,接受样式信息,返回一个render对象(又名renderer)。这些render对象最终会被构建成一颗Render树。


第四步:有了Render树后,浏览器开始布局,会为每个Render树上的节点确定一个在显示屏上出现的精确坐标值。


第五步:Render数有了,节点显示的位置坐标也有了,最后就是调用每个节点的paint方法,让它们显示出来。

当你用传统的源生api或jQuery去操作DOM时,浏览器会从构建DOM树开始从头到尾执行一遍流程。比如当你在一次操作时,需要更新10个DOM节点,理想状态是一次性构建完DOM树,再执行后续操作。但浏览器没这么智能,收到第一个更新DOM请求后,并不知道后续还有9次更新操作,因此会马上执行流程,最终执行10次流程。显然例如计算DOM节点的坐标值等都是白白浪费性能,可能这次计算完,紧接着的下一个DOM更新请求,这个节点的坐标值就变了,前面的一次计算是无用功。

即使计算机硬件一直在更新迭代,操作DOM的代价仍旧是昂贵的,频繁操作还是会出现页面卡顿,影响用户的体验。真实的DOM节点,哪怕一个最简单的div也包含着很多属性,


算法实现
4.1 步骤一:用JS对象模拟DOM树
4.2 步骤二:比较两棵虚拟DOM树的差异
4.3 步骤三:把差异应用到真正的DOM树上

微信公众平台开发中,JS-SDK提供了很多实用的功能。操作微信界面、拍照、上传下载语音和图片、坐标获取、使用地图、微信支付 等都要用到JS-SDK,
在Android手机中内置了一款高性能webkit内核浏览器,在SDK中封装为一个叫做WebView组件。
所以联系就是WebView就是一个WebKit内核的浏览器,兼容性也一致.

WebKit 内核在手机上的应用也十分广泛,例如 Google 的手机Android、 Apple 的iPhone, Nokia’s Series 60 browser 等所使用的 Browser 内核引擎,都是基于 WebKit。

浏览器的内核引擎,基本上是四分天下:
Trident: IE 以Trident 作为内核引擎;
Gecko: Firefox 是基于 Gecko 开发;
WebKit: Safari, Google Chrome,傲游3,猎豹浏览器,百度浏览器 opera浏览器 基于 Webkit 开发。
Presto: Opera的内核,但由于市场选择问题,主要应用在手机平台--Opera mini
注:2013年2月Opera宣布转向WebKit引擎
注:2013年4月Opera宣布放弃WEBKIT,跟随GOOGLE的新开发的blink引擎

Webkit(Safari内核,Chrome内核原型,开源)
Trident(IE内核):
Gecko(Firefox内核)
Presto(Opera前内核) (已废弃)Opera现已改用Google Chrome的Blink内核。
Blink是一个由Google和Opera Software开发的浏览器排版引擎,Google计划将这个渲染引擎作为Chromium计划的一部分,并且在2013年4月的时候公布了这一消息。这一渲染引擎是开源引擎WebKit中WebCore组件的一个分支,并且在Chrome(28及往后版本)、Opera(15及往后版本)和Yandex浏览器中使用。

浏览器加载和渲染html的顺序-css渲染效率的探究

页面元素的CSS渲染优先级

网页渲染的基本过程

web页面加载、解析、渲染过程

原文地址:https://www.cnblogs.com/yancongyang/p/9042190.html