开发者需要了解的WebKit

  这两年,教育可以说是 AI 落地场景中最为热闹的场景之一,不同公司分别从各种角度切入市场。有的公司以拍照搜题打开市场、更专注数理化科目,比如我们上一期采访的学霸君;有的公司更关注语音测评,比如科大讯飞,和我们今天文章的主角先声教育。 但只是侧重不同科目,足以在竞争激烈的 AI 教育市场圈地为王吗?这到底是一个怎么样的市场,小公司又该如何突破?

  这两年,教育可以说是 AI 落地场景中最为热闹的场景之一,不同公司分别从各种角度切入市场。有的公司以拍照搜题打开市场、更专注数理化科目,比如我们上一期采访的学霸君;有的公司更关注语音测评,比如科大讯飞,和我们今天文章的主角先声教育。 但只是侧重不同科目,足以在竞争激烈的 AI 教育市场圈地为王吗?这到底是一个怎么样的市场,小公司又该如何突破?

  Netflix使用会员的视频观看记录实时准确地记录用户的观看情况,并为会员提供个性化推荐。Netflix的发展,对视频观看记录时序数据存储的规模化提出了挑战,原有的单表存储架构无法适应会员的大规模增长。本文介绍了Netflix团队在规模化时序存储中的做法,包括数据存储方式的改进,以及在存储架构中添加缓存层。存储架构在Netflix的实际应用验证了该时序数据存储的有效性。

  当前人们日渐疏远传统的瀑布式开发,并转型为敏捷开发方法。有观点认为,开发中已不再需要做软件项目估算。这个观点看上去合情合理,但并不正确。实践中,即便是那些已经采用敏捷方法的企业,软件估算依然十分有价值。

  近期,InfoQ与solo.io的CEO Idit Levine进行了一次座谈。Idit新创立了一种称为“Squash”的开源微服务调试器。在此次座谈中,她介绍了观察和调试分布式系统和应用中的挑战。

  亲爱的读者:我们最近添加了一些个人消息定制功能,您只需选择感兴趣的技术主题,即可获取重要资讯的邮件和网页通知。

  对许多开发者来说,WebKit就像一个黑盒。我们把HTML、CSS、JS和其他一大堆东西丢进去,然后WebKit魔法般的以某种方式把一个看起来不错的网页展现给我们。但事实上,Paul的同事Ilya Grigorik说:

  现在,特别是Opera宣布将浏览器引擎转换为WebKit之后,我们有很多使用WebKit的浏览器,但是我们很难去界定它们有哪些相同与不同。下面我争取为这个谜团做些解读。而你也将会更懂得判断浏览器的不同,了解如何在正确的地方报告bug,还会了解如何在特定浏览器下高效开发。

  这里面哪些是WebKit浏览器共享的?差不多只有前两个。其他部分每个WebKit都有各自的实现,所谓的“port”。现在让我们了解一下这是什么意思

  WebKit最常见的参考实现是Apple在Mac OS X上的实现(这也是最早和最原始的WebKit库)。但是你也能猜到,在Mac OS X下,许多不同的接口在很多不同的原生库下被实现,大部分集中在CoreFoundation。举例来说,如果你定义了一个纯色圆角的按钮,WebKit知道要去哪里,也知道要如何去绘制这个按钮。但是,绘制按钮的工作最终还是会落到CoreGraphics去。

  不同的port专注于不同的领域。Mac的port注意力集中在浏览器和操作系统的分割上,允许把ObjectC和C++绑定并嵌入原生应用的渲染。Chromium专注在浏览器上。QtWebKit的port在他的跨平台GUI应用架构上给apps提供运行时环境或者渲染引擎。

  (作者注:很有意思,这些内容我写了很多次,每次Chrome团队成员都给我纠正错误,正如你看到的)

  就像Flickr和GitHub通过flag标识来实现自己的功能一样,WebKit也有相同处理。这允许各个port自行决定是否启用WebKit编译特性标签的各种功能。通过命令行开关,或者通过about:flags还可以控制是否通过运行时标识来展示功能特性。

  好,现在让我们再尝试一次搞清楚WebKit究竟有哪些相同

  让我们谈谈其中的2D图像部分: 根据port的不同,我们使用完全不同的库来处理图像到屏幕的绘制过程:

  更宏观一点来看,一个最近刚添加的功能:CSS.supports()在除了没有css3特性检测功能的win和wincairo这两个port之外,在其它所有port中都可用。

  现在到了卖弄学问的技术时间。上面讲的内容其实并不正确。事实上那是WebCore被共享的东西。而WebCore其实是当大家讨论HTML和SVG的布局、渲染和DOM处理时提到的WebKit。技术上讲,WebKit是WebCore和各种ports之间的绑定层,尽管通常来说这个差别并不那么重要。

  字体和文字渲染是平台上的重要部分。在WebKit中有两个独立的文字路径:Fast和Complex。这两者都需要平台特性的支持,但是Fast只需要知道如何传输字型,而Complex实际上需要掌握平台上所有的字符串,并说“请绘制这个吧”。

  WebKit就像一个三明治。尽管Chromium的包装更像是一个墨西哥卷。一个美味的Web平台墨西哥卷。

  现在,让我们放宽镜头看看一些port和一些子系统。下面是WebKit的5个port;尽管它们共享了WebCore的大部分,但考虑一下它们的stack有哪些不同。

  *iOS Chrome注:你可能知道它使用 UIWebView。由于UIWebView的能力限制。它只能使用移动版Safari的渲染层,JavaScriptCore(而不是V8)和单进程模式。然而,大量的Chromium 代码还是起到了调节作用 ,比如网络层、同步、书签架构、地址栏、度量工具和崩溃报告。(同时,由于JavaScript很少成为移动端的瓶颈,缺少JIT编译器只有很小的影响。)

  别这样!WebKit的layoutTests覆盖面非常广(据最新统计,有28,000 个layoutTests),这些test不仅针对已存在的特性,而且针对任何发现的回归。实际上,每当你探索一些新的或难懂的DOM/CSS/HTML5特性时,在整个web平台上,layoutTests经常已经有了一些奇妙的小demo。

  另外,W3C正在努力研究一致性测试套件。这意味着我们可以期待使用同一个测试套件来测试不同的WebKit port和浏览器,以此来获得更少的怪异模式,和一个带来更少的怪癖模式和更具互操作性的web。对所有参加过Test The Web Forward活动的人们致谢!

  我还应该指出,所有的Opera浏览器都将采用Chromium:包括他的Windows,Mac、Linux版本,和Opera Mobile(完全成熟的移动浏览器)。甚至Opera Mini都将使用基于Chromium的服务器渲染集群来替换当前的基于Presto的服务器端渲染。

  它是WebKit的mac port,和Safari运行的二进制文件一样(尽管会替换一些底层库)。因为苹果在项目中起主导地位,所以它的表现和功能与Safari的总是那么一致。在很多情况下,当其它port可能会试验新功能的时候,Apple却显得相对保守。不管怎样,如果你想我用中学一样的类比,想想这个好了:WebKit Nightly对于Safari就像Chromium对于Chrome。

  我们理解您使用ad blocker的初衷,但为了保证InfoQ能够继续以免费方式为您服务,我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单,感谢您的理解与支持。

相关阅读