webkit技术内幕读书笔记 (一)

时间:2020-12-31 18:42:10

本文部分摘录自互联网。

Chromeium与Chrome

Chromium是Google为发展自家的浏览器Google Chrome而打开的项目,所以Chromium相当于Google Chrome的工程版或称实验版(尽管Google Chrome自身也有β版阶段),新功能会率先在Chromium上实现,待验证后才会应用在Google Chrome上,故Google Chrome的功能会相对落后但较稳定。

Chromium的更新速度很快,每隔数小时即有新的开发版本发布,而且可以免安装,下载zip封装版后解压缩即可使用(Windows下也有安装版)。Chrome虽然理论上也可以免安装,但Google仅提供安装版。

Google Chrome是基于Chromium制造,但包含非开放源代码包,主要是多媒体相关。

Chromium

Blink

Google希望未来在Blink中加入的新技术如下:

  1. 实现跨进程的iframe。iframe允许网页中嵌入其他页面,这存在潜在的安全问题。一个新的想法就是为iframe创建一个单独的沙箱进程。该部分的介绍在第12章展开。

  2. 重新整理和修改WebKit关于网络方面的架构和接口。长期以来,WebKit中的一些实现是以Mac OS平台为基础的,所以存在某些方面的限制,Blink将会在这方面做比较大的调整。

  3. 一个更为胆大更为激进的想法就是将DOM树引入JavaScript引擎中。由前面的介绍可以看到,目前DOM和JavaScript引擎是分开的,这意味着JavaScript引擎访问DOM树需要较高的代价。笔者认为这是一个大胆而又具有革命性的尝试,会带来性能的极大提升,为什么呢?原因是JavaScript引擎访问DOM树需要额外的负担,这影响了访问速度。

  4. 就是针对各种技术的性能优化,包括但是不限于图形、JavaScript引擎、内存使用、编译的二进制文件大小等。

Chromium浏览器之渲染引擎Blink

whatwg与w3c

浏览器厂商和标准组织博弈出来的产物,重要的是明白它们背后的人是谁。WHATWG受到了Opera, Mozilla和Chrome, Safari的支持,而W3C的背后则隐藏着IE这个微软菊苣。私以为在工业发展速度远远超过标准定义的今天,WHATWG或许会更权威一点。关于HTML5标准的定制,最开始是WHATWG在做的,由于到后期大部分浏览器厂商都已经实现了统一标准,W3C想不支持也是不行的啊,这就是传说中的霸王硬上弓

xhtml还是html

总的来说我还是更喜欢html一点,尽管xhtml更加的规范,但我觉得怎么编写代码是开发人员自身的问题,而不应该将其强制,比如:单标签的闭合,我觉得单标签闭合可有可无。

html5

一次编写,到处运行(Write once, Run anywhere)是每一个程序员的梦想。当年的Java没有做到,原本程序员们指望Web标准能够做到。然而事实上是,只要浏览器大战没有消停,HTML5也做不到。

有人说HTML5不好,因为用户讨厌打开浏览器输入URL的过程。我想说这种想法是对HTML5的片面理解。HTML5!=传统浏览器,虽然编程语言还是HTML、Javascript、CSS,但发行方式绝不是传统网站那么简单。HTML5应用的入口,反而很少是启动浏览器输入URL,它可以是存在于手机桌面的图标、也可以来自超级App(如微信朋友圈)、以及搜索引擎、应用市场、广告联盟,到处都是它的入口。它的入口,比原生App更多。

目前各路浏览器厂商、应用市场厂商、甚至rom厂商,都在努力整合更优质的浏览器引擎。假使微信内嵌的webview可以运行更优秀的canvas游戏、假使360手机助手可以发行即点即用的HTML5应用并且能力体验与原生一致、假使小米rom内置更强大的webview使得所有HTML5应用在小米手机上运行的更流畅。所有巨头都会闻风而动,没错,这场战役会是移动互联网世界的二次世界大战。

早期HTML只需要记事本写几个Tag,中期的HTML、JS、CSS比较复杂,需要更高级的文本编辑器,但HTML5到来后,它的代码量、复杂度、开发模型将与原生开发看齐,需要类似XCode、Eclipse等专业的IDE工具来解决开发、调试的问题。一些以会使用记事本写代码为荣的开发者,将面临思路转换甚至被更高效的开发者淘汰。

web的不断发展意味着,会有更多的api,因此如果我们还靠去死记硬背是不行的了,同时也意味着你不可能将web的所有技术掌握,我们需要更强大的IDE工具,以及学习能力。

混乱的用户代理

早期内容供应商为了给用户提供更好的网站体验,为不同的浏览器提供了不同的内容,而IE厂商发现,很多内容供应商为Mozilla提供的内容比自己更加的丰富,后来IE厂商想出了一个法子,在用户代理中加入一条Mozilla的信息,后来其他浏览器厂商也纷纷效仿,导致最后用户代理异常混乱。

既然选择所有浏览器厂商都这样做了,还使用这种方式就没有什么用处了,我想以后浏览器厂商会重新回归到最初。

用户代理可以做什么

通过用户代理,我们可以用来判断用户使用的是什么浏览器,而根据浏览器的不同,使用不同的样式,又或是一次兼容问题,但如果涉及到一些安全性问题,千万别通过用户代理来判断,因为用户代理是可以通过人工修改的。

推荐阅读:自定义UserAgent绕过安全狗

更改Chrome用户代理

chrome 下修改 agent 的方法
Change User Agent in Google Chrome
浏览器USER-AGENT(用户代理)的介绍

浏览器内核

虽然使用Linux内核的操作系统非常多,但某些操作系统对内核做了很多改变,因此虽然很多操作系统使用的内核是一样的,但它们的差别还是很大的。

之前比较疑问,既然移动端大部分浏览器使用的是webkit内核的,但是显示出的效果差别却那么大,今天算是明白了,虽然它们是同一个内核,但是每个浏览器厂商却做了不同的处理。

多线程

一个应用程序是否是多线程,不仅仅是应用程序的问题,更取决于操作系统是否支持多线程,因为你的程序是在人家操作系统上跑的。

webkit于webkit2

WebKit2是面向WebKit的一个新的API层,从底层设计,以支持拆分过程模型,其中Web内容(JavaScript,HTML,布局等)与应用程序UI在一个单独的过程中。 该模型与Google Chrome提供的模式非常相似,主要区别在于我们将流程分割模型直接构建到框架中,允许WebKit的其他客户端使用它。

这与Chromium WebKit有何不同?

Chromium采用不同的多进程方法:

请注意,在这种情况下,进程边界是*以上的API边界。 Chromium WebKit不直接提供多进程框架,而是针对多进程应用程序的一个组件进行了优化,它可以执行所有代理和进程管理。谷歌的Chrome团队在开发Chrome浏览器的多进程浏览方面做得非常出色。但是很难重用他们的工作,因为进程管理,流程和沙盒之间的代理关键逻辑都是Chrome应用程序的一部分,而不是API层的一部分。因此,如果另一个基于WebKit的应用程序或另一个端口想要基于Chromium WebKit进行多进程,则需要重新创建或剪切并粘贴大量代码。

这是Google的一个可以理解的选择 - Chrome被开发为一个秘密项目多年,并且深入投资于这种方法。此外,还没有任何其他重要的API客户端。有Chrome浏览器,然后有紧密相关的Chrome框架。

WebKit2有一个不同的目标 - 我们希望流程管理成为WebKit本身提供的一部分,以便任何应用程序都可以轻松使用。我们希望聊天客户端,邮件客户端,twitter客户端以及人们使用WebKit构建的所有创意应用程序,以便能够利用此技术。我们相信这是Web内容引擎应该提供的基本部分。

Webkit2