Subscribed unsubscribe Subscribe Subscribe

Chromeの新エンジンBlink ― なぜなに篇

4月3日、GoogleChromeに使っていたWebKitをフォークした新しいエンジンBlinkを発表した。

…だいぶ出遅れたのでとても書きづらいけれど、自分の理解のために書く。ただいろいろあるので、まずはWebKitをフォークするに至った経緯と、Blinkの概要について。

追記 (2013-04-30):別途ふたつエントリを書いたのでそちらもどうぞ。

Chromium port”としての負担

アナウンスしたAdam Barth曰く、Chrome開発時点でのWebKit採用は正しく、WebKitも大きく成長したと。

ただ、開発を続けるにあたり、アーキテクチャの違いなどからChrome, WebKit双方に負担がかかる状態になった。これを解決するため、WebKitをフォークしたエンジンBlinkに移行するとのこと。

Blinkのドキュメンテーション、GooglerがBlinkについて書いたポストからも、WebKitを使うことで生まれた解決しづらい問題、メンテナンスの負担がうかがえる。

Justin Schuhは、Chromeの設計が他のWebKitブラウザと違っており、WebKit2へのシフトでさらに違いが強まったと書いている。たとえば、セキュリティを向上させる重要な機能を追加したかったけれど、WebKitにフィットしないため見送ったことがあるとか。また、異なる開発スケジュールからくるリグレッションへの対処、古いWebKit APIが必要としていた挙動の管理など、維持にも問題があったようだ。

Philip Rogersの、WebKitはSkiaだけではなくCoreGraphics, Cairo, etc.など主要5つのグラフィックライブラリ上で動作しなければいけないという話からもつらそうなことがわかる。なにか機能を実装しようとしても、実装に必要な機能がどれかひとつのグラフィックライブラリにでも欠けていたら、その機能を実装できない。ひいては仕様策定にも影響したとあるので、Webにとってもヘルシーな状態ではない。

Alex Russellは、WebKitのいちportとして開発していくことの負担について、抽象度合いが低めのレベルなWebKitではあるportが他のportに影響を及ぼしてしまうため、portが増えるたびにコストが上がっていたと述べている。また、エントリのはじめのほうでこうも言っている。

What’s bound to be missing in most of this coverage is what’s plainly said, if not in so many words, in the official blog post: going faster matters.

Not (just) code execution, but cycle times

Chromeの掲げる「速さ」は、コード実行速度だけではなく、開発サイクルにおいても重要だと。

Blinkになるとどうなるか

BlinkはChromiumContentモジュール上に作られる抽象プラットフォームに依存するような設計になるとのこと。Contentモジュールは、マルチプロセス・サンドボックスな環境でページをレンダリングする際に必要な、コアなコードを束ねたモジュールだそう(うう、よくわかんない…)。
この設計によって、機能や変更を加える際に対応するプラットフォームがひとつになり、他のportが使うライブラリやレガシーなWebKit APIへの依存がなくなると。なお、Content APIWebKitやWebKit2, WebCoreなどがどう違うかは、Ben Goodgerのポストで取り上げられている。

Blinkの開発について。短期的には、Chromiumに必要ないWebKitのコードや、Chromium以外で使われていたビルドシステム7つ(!)を削除し、内部アーキテクチャの向上や、コードベースの単純化を行うとのこと。コミットログコードレビューの一覧を見ているのだけれど、コードの削除がガンガン行われている。新しい機能の追加についてもblink-devで既にいくつか提案されているけれど、コードの進みはなさげなので、Web開発における影響は今のところないだろう。

中長期的には、WebKitを使う都合上でできなかった設計変更が視野に入っているので、話は変わる。WebKitによる制約が取り払われることから、多くのアイデアが出ている。

たとえば、DOMの処理をJavaScriptの処理に移動させるというのがある。これまでJavaScriptからDOMにアクセスする際はJavaScriptのVMからコードがでなければならず、(それでも十分速いんだけど)コストがかかっていた。JavaScriptが直接アクセスし、VM内で処理を完結できるようにすることで、速くできるとか。

こういう大きな設計変更が入ってくると、KHTMLWebKitがもはや別のエンジンと考えられているのと同じように、BlinkもWebKitと違うエンジンとなるんだろう。いつ頃になるのかはわからない。何を持って「違う」と考えるかにもよりそうだけど。

BlinkはいつChromeに入るのか

もう発表当日のCanaryに入って、Dev Channelにも反映された。

SVNのログを見ると、Blinkがrollされたのが分かる。

というわけで、Chromeは28からBlinkに移行する。ChromiumベースのものはBlinkに移るので、OperaもBlinkになるとOperaのBruce Lawsonから発表があった。発表当日にあったQ&Aセッションでは、Chromiumを使うように進んでいるAndroidのWebViewもBlinkになっていくことが話されていた。メモしといたので、参考までに。

あ、ただ、Chrome for iOSについては話が別で、こちらはUIWebViewをつかった今までのもの(WebKit)と変わらない。どうしようもないものね。


ううむ。これくらいは金曜くらいまでには書いておきたかったなあ……。

次はBlinkの機能追加ポリシーについて書く。その後はBlinkによってほかのプレーヤーにどんな影響があるかを考えてようかと。