Adam Barth「WebKitがウェブページをロードするしくみ」

Surfin' Safariの2010.4.18のブログエントリ。
記事では作者はabarth（post by abarth）となってる
歯が立たない。が読んだ

How WebKit Loads a Web Page

以下斜め読んだ内容

• レンダリングの前にページと各種コンポーネントのロードが必要
• このエントリはWebCoreとページロードの関係について
• エントリで説明する部分を図にしてくれてる
  • 
  • オリジナル（SVG画像）
• WebCore＝レンダリング処理をするWebKitのコンポーネント
• ページロードは二本立て
  • ドキュメント（ex.html）をロードし、Frameオブジェクト生成するライン
  • 画像や外部jsなどをロードするライン
• FrameLoaderオブジェクト
  • ドキュメントをロードする
  • ドキュメントをFrameオブジェクトに変換
  • DocumentLoaderオブジェクトを生成
    • トリガー例：ウェブページ上のリンクをクリック時
    • 生成時のstate="policy"
• DocumentLoaderオブジェクトのstateは、policy/provisional/committedの３つあり
  • state="policy"
    • 「待ち」状態。WebKitクライアント（ex.ブラウザ？）がリンク先のドキュメントをロード/ブロック/etc.を決めるのを待つ
  • state="provisional"
    • FrameLoaderオブジェクトが（DocumentLoaderの）stateを変更する
    • WebKitクライアントがドキュメントをロードすると判定したときにこのstateになる
    • DocumentLoaderがネットワークへリクエストを出す
    • DocumentLoaderがMainResourceLoaderオブジェクトの生成
  • state="committed"
    • FrameLoaderオブジェクトが（DocumentLoaderの）stateを変更する
    • ネットワーク側からレスポンスを受け取る。リクエストしたリソースがドキュメントであると判定
    • Frameオブジェクトは新規ドキュメントの表示へ推移
• MainResourceLoaderオブジェクト
  • 生成元：（"provisional"stateの）DocumentLoader
  • 役割：ResourceHandleインターフェースによってプラットフォームのネットワークライブラリとやりとり
• DocumentLoader／MainResourceLoader２つあるメリット
  • MainResourceLoaderからのコールバックの詳細なハンドリングからDocumentLoaderを隠蔽できる
  • DocumentLoader／MainResourceLoaderの生存期間（lifetime）を分離できる
• おさらい：ウェブページの表示には、html以外に色々（画像、スクリプト、etc.）必要
• DocLoaderオブジェクト
  • htmlファイルからリンクされたリソース（img/script/css/etc.）のロードを担当
• DocLoaderオブジェクトが画像をロードする仕組み
  • DocLoaderは、Cacheオブジェクトにメモリ上に該当画像があるか問合せ
    • CachedImageオブジェクトなどをチェック
  • 画像がCacheオブジェクトに存在する場合、DocLoaderは該当画像を読み込み表示
  • WebKitの高速なキャッシュの仕組み
    • キャッシュされた画像はvideo memory上にデコードされた状態で保存されている。同じ画像を２回解凍する必要がなくなる
  • 画像がCacheオブジェクトに存在しない場合
    • 新規CachedImageオブジェクトを生成
    • CachedImageオブジェクトはLoaderオブジェクトへネットワークリクエストを出すようにリクエスト
    • CachedImageからのリクエスト受けて、Loaderオブジェクトはネットワークリクエストを出すためにSubresourceLoaderオブジェクトを生成

• SubresourceLoader
  • ネットワークリクエストを出すのが役割
  • MainResourceLoaderオブジェクトとしてること同じ
  • ResourceHandleインターフェースでプラットフォームとやりとりする

• WebKitのページロードの仕組みの改善点
  • FrameLoaderオブジェクトをもっとシンプルにしていく
    • ドキュメントのロード以外にも仕事やってる
    • FrameLoaderの複数のloadメソッド
      • こんがらがってる
      • Frameオブジェクトに関係のある「新規ウィンドウの生成」にも色々やっててややこしい
  • ロードの複数の段階が相互に必要以上に複雑に絡み合ってる
  • オブジェクトの階層・レイヤー分けに違反するケースが多い
    • 低レベルAPIと高レベルAPIが直接やりとりしてるケース多い
    • 例。MainResourceLoaderオブジェクトは、ネットワークから受信したデータをFrameLoaderオブジェクトへ直接渡してる
      • レイヤー分けが守られてれば、データはまずDocumentLoaderオブジェクトへ渡されるべき
  • ドキュメントのロードでもCacheの有効活用
    • 現在ドキュメントからリンクされたリソースのロードでしかCacheオブジェクトが利用されていない
    • ドキュメントのロードの場合にもCacheが活用されれば高速化につながる。