標籤: webkit

Webkit 歷史圖示

Webkit-Browser-1-768x487

最早的技術擁有者應該是 Netscape, 但 KDE 用了一套自訂的 Javascript engine – KJS 和 webcore engine – KHTML. 其中 KHTML 做得比 Netscape Navigator 的 Gecko 還小, 所以被 Apple 相中拿來開發 Webkit. KDE 原本沒有做 webview 的部分, 所以 Webkit 的名稱是 Apple 取的.

Apple 除了開發 Webkit, 又以兩手策略開發封閉性的 Safari. 到了 2010 年, Apple 做出 multi-process 的技術, 把 main process 和 render process 分開, 因此把 Webkit 改為不相容的 Webkit 2.0.

Google 的策略是借用 Webkit 的 Webcore, 其他自己搞. 後來開發出  V8 Javacript engine, 算是有了重大突破. 接著 Google 又做出 Blink engine, 把 webcore 換掉, 這些好料都放進了 Chrome. 當然 Google 也是兩手策略, 不會平台讓 Apple 佔便宜.

QT 和 GTK 都基於 Webkit 2.0 做出新版. 同理, WPE (Wayland for Webkit) 當然也是 ‘for’ Webkit 2.0 才聰明. 

那 Chrome 有 multi-process 嗎? Chrome (Chromium) 的做法是起好幾個 Webkit [1]. 以空間換取時間. 至於沒有 mutli-process 的弱點, 據說是用 timer 來多工執行, 沒有用到多核的優點 [3].

Chrome-768x713

那 Blink 比起原來的 Webcore 差多少? 根據 [2], Blink 從 Webkit 裡面刪掉 8.8 百萬行的 source code…身輕如燕, 難怪叫做 blink. 不意外地, Qt 等等上層 API 也 port 到了 Blink.

對了, Chromium 是鉻, Cobalt 是鈷, 看起來是兄弟關係. 那麼 Google 的 Cobalt 又是做甚麼的? 這個資訊很難找, keyword 下錯絕對搜尋不到, 客官要看這裡 [4]. Cobalt 的作者本來是負責維護 Chromium 裡面的一段代碼, 叫做  H5VCC (HTML5 Video Container for Consoles). 他在各種平台 porting 這段 9 百萬行的 code  好幾年後, 終於受不了了. 決定要推出符合下面特色的功能:

  • Limited Memory. 記憶體少.
  • Slow CPUs. CPU 慢.
  • Fewer cores. 更少核.
  • Sometimes No GPU. 可能沒 GPU.
  • Sometimes No JIT. 考量安全性, 也不需要支援 just in time 代碼.
  • Heterogenous Development Environments. 跨平台環境.
  • No navigation. 不用瀏覽, 只要呈現.
  • No scrolling. 不需要捲動畫面.

因為 Cobalt 弱弱地不用處理很多事情, 連 Javascript engine 都可以偷掉. We have, perhaps surprisingly, not written our own JavaScript Engine from scratch. Because of the JITing constraint, we have to be flexible with which engine(s) we work with. We have a bindings layer that interfaces with the JS Engine so that application script can interface with natively-backed objects (like DOM elements). 因此近來成為 porting Youtube 的主流.

[REF]

  1. https://www.chromium.org/developers/design-documents/multi-process-architecture
  2. http://browserg.nom.es/
  3. https://www.zhihu.com/question/20930880
  4. https://cobalt.googlesource.com/cobalt/+/refs/heads/master/src/README.md

MSE 小筆記

MSE 是指 Media Source Extensions.

傳統的 HTML 網頁就支援 audio, video 的 tag, 然後將它送給 player 播放. Web-based 的 Jave script Applications 透過 MSE, 就能將片段的 media 送給 player, 因此可以實現 adaptive streaming, 例如 MPEG-DASH.

video-blob-768x468

既然要支援隨時變化的片源, MSE 的特色之一就是支援 multiple SourceBuffer objects. 當然, 普通 SourceBuffer 一定也支援. 以下是它的定義:

SourceBuffer

Represents a chunk of media to be passed into an HTMLMediaElement via a MediaSource object.

可以想像, 支援 multiple SourceBuffer 要有一個清單. 所以 MSE 也支援 SourceBufferList 這個 interface.

SourceBufferList

A simple container list for multiple SourceBufferobjects.

MediaSource 是一個 object [2], Sourcebuffer 是它的實體. 圖示如下 [3]:

HTML_MediaSource_SourceBuffer

由這張圖也可以看到 MediaPlayer 會負責處理播放. 由於可播放的格式相當多, 每個 browser 能支援的 audio/video formats 都有所差異. 像是 Chrome 當然要挺自家的 WebM, VP9…等等. 以 Webkit 為例, 透過 MediaPlayerPrivateInterface 就可以把 mediaSourcePrivate/SourbufferPrivate 的內容送給真正的 player.

若使用 gstreamer 來當 player, 它有特別的 WebkitMediaSrc 這個 element, 資料由這邊進去 gstreamer 的 pipeline  就可以做後續的解碼 [3].

mse3-768x530 [REF]

  1. https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API
  2. https://developer.mozilla.org/en-US/docs/Web/API/MediaSource
  3. http://eocanha.org/blog/2016/02/18/improving-media-source-extensions-on-gstreamer-based-webkit-ports/

Webkit 相關小檔案

原本我以為免費 browser 盛行之後, Opera 就沒搞頭了. 想不到他們和 Google 聯手在今天四月推出了新的 web browser engine – blink, 放到了 Chrome 28 版和 Opera 15 版.

大家都知道 Google 有 Chrome browser 而 Android 用 Webkit 當預設的瀏覽器, 但他們原先其實都是 Webkit [1]. 而 Webkit 是 Apple 從 open source 的 KDE project 中分支出來的, 它借用了 KDE 的 KHTML engine 和KJS  Javascript engine. 由於 KDE 是 open source, 當然 Webkit 也必須是 open source, 只是 KHTML 發展成 WebCore, 而 KJS 變成 JavaScriptCore.

等到 Apple 熟悉了瀏覽器的技術, 就做出了 Safari, 並且聲其中牽涉到 OS 的技術, 所以不用 open source. Google 同樣是先加入 Webkit 計畫練兵, 並且在 2006 年另外開了一個 Chromium 的 open source project 另外發展一套瀏覽器 [2].

Google 在 Chromium 計畫的主要成果包括 V8 Javasceipt 引擎, sandbox, 黑名單, 與無痕瀏覽等等. 其中, V8 就曾經被放進 Android 4.0 的 Webkit 當中. 當然最好的東西都進了 Chrome browser. 最後 Google 的人開始嫌棄 Webkit [3], 並且打算在 Android 5.0 把它拔掉, 換成自家的 browser.

話說, Google 和 Apple 是 Webkit 這個 open source project 的最主要的 reviewer, 自己在管的計畫為什麼還嫌東嫌西呢? 其實 Chome  之於 Google 就像 Safari 之於 Apple, 自己有了獨到的心得之後, 難免就不想再和別人分享. 上次 Chromium 最傑出的成果是 V8 JavaScript engine, 而這次 Google 的突破點在於 HTML engine – blink. 看來內外功都已經練成了.

Chrome 的 blink 比 Webkit 的 WebCore 強在那裡呢? [ref 3] 首先說到 multi-process, Google 認為 Webkit 在這個情境下會拖慢速度, 而 blink 當然只要一眨眼. [Ref 4] 則大致介紹了 blink 在 multi-process 的設計概念. 這個可以單獨寫一篇, 初步的理解就是改了 data structure, 用空間換取時間.

那麼 Opera 又扮演什麼角色呢? 它最近宣布放棄開發瀏覽器 [3], 準備擁抱 Chrome. 這件事引起許多人在網路上討論. 原來這也不是因為 Opera 有什麼高瞻遠矚, 而是 Opera 的 Mobile OEM 業務已經被 Android 打掛, 萎縮到不值得經營了. 它在 2012Q4 的業績就比前一個年度下滑 89% [5].

相對地 Opera 在 device OEM 的部份還有成長, 只要把內核換成和 Android 一樣, STB 上的 Opera browser 將會和大家用的 Chrome 或 Safari 更加神似. Opera 廢掉自己的武功, 雖然可以省下研發的費用, 但也有人說 Opera 的企業精神已經喪失. Google 殺人於無形, Opera 投敵求生, IT 業真是可怕.

[REF]

1. Webkit

2. Chromium

3. Google Forks WebKit And Launches Blink, A New Rendering Engine That Will Soon Power Chrome And Chrome OS

4. Design Plans for Out-of-Process iframes

5. Opera放弃自家内核转投WebKit的背后