注意ios上的chrome使用的是系统控件uiwebview,因此它只能使用和mobile safari一样的渲染引擎(rendering layers),以及JavaScriptcore和单进程模型(single-process model)
webkit中的许多元件是可以替换的 (上图中的灰色部分)
webkit浏览器间差异之大,何去何从?
什么是webkit nightly?
它是webkit的mac port,和safari内部运行的版本是一致的(除了一小部分的基础库会被替换掉)所以它的行为和功能是和safari一致的你也可以这样理解webkit nightly就是safari,而chromium就是chrojava web开发me当然 chromium还是有它的应用的, 诸如网络层(network layer),同步和书签的基础组件(sync and bookmarks infrastructure), omnibox,metrics及崩溃报告(crashreporting). (之所值得这样做,是因为 JavaScript很少会成为移动端的瓶颈,而带有jit的编译器的影响也会很小)
举一个更细节的例子,一个刚被引入的特性css.supports()只有win和wincairo两个移植版本没有支持,因为它们并没有启用css3特性
并且所有opera浏览器都会采用chromium,甚至包括opera mini,会将原本presto实现的在服务java web教程器端的渲染方式放弃,转而使用chromium提供的渲染功能
如下图所示:
下图是2d graphics 在不同port中的依赖关系,几乎是各自使用了完全不同的库来实现绘制操作:
比如webkit的默认javascript引擎jsc(JavaScriptcore,当由khtml开始创建webkit的同时基于kde的kjs实现而来),在chromium port由v8替换,并用独特的dom bindings
robert nyman和rob hawkes都分析过了,但值得注意的是opera会采用chromium这表示webgl, canvas, html5 forms, 2d graphics等实现会和chrome一web前端工程师要求样相同的apist和相同的后台(backends)实现所以opera是chromium-based, opera与chrome会保持同步兼容
简单地说共享的组件就是webcore它其实就是通常意义上大家所说的webkit,一个排版、渲染引擎,同时是html和svg解析库而webkit是webcore与ports之间的绑定层(bindinglayer),平时的交流并不太在意它
(为什么是taco,看这里就可以了.)
大可不必!webkit中提供了layouttest提供了大量的测试用例(28,000),不但针对已存在的功能,还包括回归测试事实上,无论你何时发现了一些新奇的dom/css/html5特性,layouttest通常已经java web实战经典提供了一个简化版的演示
chrome canary 也会与webkit保持像是一天内的代码同步
字体和文字的渲染也严重依赖于平台webkit中有两种不同text path: fast and complex每一项都需要平台(port-side)支持fast只需要知道如何贴上位图轮廓(blit glyphs)就可以了,webkit会为平台准备数据而complex则完全依赖于平台去处理,它仅仅请求:”请画出这个”
另外w3c也正增加其在页面一致性测试上的投入这表示不同的webkit ports和所有浏览器会针对相同的页面进行测试,将带来更少的私有特性(quirks)和更多可以共同操作的页面
“webkit就像一个三明治新浪web前端面试题,而 chromium更像一个墨西哥玉米卷(taco)” dimitri glazkov, chromewebkit hacker. web components和shadow dom的拥护者
opera将如何转换?
下表中列出了5个webkit port的块图,了解一下它们之间的异同